A Drupal site is not finished the day it goes live: that is when it starts. For years you will need to apply security updates, adapt custom code to each major version, review performance and permissions, and keep developing on a base that never stops moving. That is where a website quietly degrades, or where it keeps performing years later.
When we decided to integrate artificial intelligence into our work, the starting question was which part of our method would gain depth and coverage if a system that never tires of checking ran it. The result covers the full lifecycle: base knowledge, audit, development, dependencies and version migration.
AI executes, the methodology is ours
Opening a chat with a language model and asking it for code works for a demo. Maintaining for years a platform that a business depends on takes something else: a generic model does not know the project’s conventions, cites APIs that no longer exist and answers to nobody for its decisions.
That is why every process (auditing, developing, updating, migrating) is written by our team as an explicit methodology: which steps are taken, what is checked before moving on, what is delivered and who approves. The agents run it without reinterpreting it or skipping it, because at every critical point there is an automatic check or a person who gives the go-ahead. The methodology, the knowledge and the quality criteria do not live in the AI engine or depend on it: they live in our system, versioned and under our control.
A Drupal knowledge base that is verified, not remembered
The weak point of any AI applied to Drupal is version knowledge. Drupal publishes two minor versions a year, deprecates APIs in each one and removes what was deprecated in the next major version. A model trained on documentation from two years ago mixes Drupal 9, 10 and 11 without knowing it.
We have built our own knowledge base for each major version, from Drupal 8 to 11 and with Drupal 12 in preparation: PHP APIs, hooks, plugins, Twig and theming, JavaScript, coding standards, deprecations per minor version, what each major version removed on arrival and the toolchain that fits each jump. Every piece of data is checked against the Drupal core source code, dated and sourced. When an agent needs to know how something is done in Drupal 11.2, it looks it up instead of recalling it, and a correction in the base reaches every process at once.
Audit: 12 axes and a diagnosis that does not fix
A Drupal site in production changes every month, even if we built it. Before any intervention, the first thing is to know what state it is in. Our audit analyses it across 12 axes: platform and support cycle, pending updates and known vulnerabilities, patches and whether they still apply, installed modules and missing modules, quality of custom code, content and configuration, theme and frontend, performance and cache, permissions and roles, operational health, a functional walkthrough by content type and by user role, and technical SEO.
It cross-checks three sources: the project code, the admin panel of the staging or production site, walked through with a real browser and a logged-in session, and the Drupal command line on a local container replica. Every finding is classified by severity and effort and arrives in a double backlog: one for you, in business language, and an internal one with the technical detail.
The practical difference from a manual audit is coverage. A human team samples: the most sensitive permissions, the most critical modules. The system reviews every permission, every route by role and every deprecated API, and a person on our team validates the findings and decides what matters.
And one important design decision: the audit only diagnoses. Each finding is passed to the specialised process that has to resolve it, which avoids the classic mistake of fixing, along the way, something nobody has validated.
Development: five phases and an adversarial reviewer
Writing custom Drupal code is where AI contributes most and where it does the most harm without a method. Our assisted development process follows five phases.
The five phases of assisted development
No line is written without a plan approved by a person, and none is accepted without passing the automatic checks.
The agent always works on a local replica of the project, never on production.
Before proposing anything, it studies the existing code, separates what it has verified from what it has only inferred and states its assumptions. On large projects it builds a graph of the custom code, with its components and dependencies, so as not to get lost.
It drafts a plan with verifiable acceptance criteria and recorded architecture decisions. Without the explicit approval of a developer on our team, it does not run.
First the test that must fail is written; then the code, in small blocks that pass the Drupal coding standards, static analysis and unit tests.
The definition of “done” is checked with real data and in a real browser, and a second agent acts as an adversarial reviewer: its only goal is to find what the first one did wrong.
The same method works in review mode on code that already exists, whether it is ours or inherited from another provider.
Dependencies, patches and version migrations
A typical Drupal project carries dozens of contributed modules and, often, patches on core or contrib that can stop applying at the worst moment. We keep a central registry of validated versions, with the patches that work on each one and the tests that check them. On top of that registry, the agents replace or remove patches, generate them from the community’s fix proposals, detect outdated packages and known vulnerabilities, and upgrade versions only when they pass a prior check. What is learned on one project (a patch that has to be replaced, an incompatibility, a version that works) is recorded in the registry and benefits the next one. When it is finished, you receive a summary of actions: what was changed, why and with what result.
Jumping to a new major version is the riskiest moment in a site’s life, and custom code suffers the most: removed APIs, services that change signature, templates and JavaScript that stop working. Our migration process combines automatic refactoring with Rector, static analysis with PHPStan at the level of the target version, a compatibility check of all dependencies, a code quality review and validation of the migrated project in a real environment. The knowledge base says which tool and which configuration fit each jump. And if your team keeps pushing code while we migrate, the process reconciles those changes with what has already been migrated.
Why AI does not decide for us
Four control guarantees
What makes this system different is not what AI can do, but what it cannot do without us.
No plan runs, no change reaches the repository and nothing is sent outside without a person on our team authorising it, every time.
When an agent says “done”, deterministic scripts verify it: static analysis, tests, counts, connections. If the check fails, it is not done.
The agent works with our base checked against Drupal core and with our registry of validated versions, not with what it remembers.
Every error detected becomes a written rule that is added to the step of the method where it applies, in generic terms and with no data from any client.
Your data, credentials and database dumps are never part of the system: the methodologies are generic and the state of each project lives in the project itself.
What changes for your project, and what does not
Coverage changes: an audit or a migration no longer relies on a sample, but on a full review of what is there. Traceability changes: every decision, check and approval is recorded and cross-referenced with the code history, so you can ask us why any change was made, even months later. And memory changes: each project keeps an index of its state, its decisions and its pending items, so a working session picks up where the previous one left off, and your project inherits what was learned in earlier ones.
Who is accountable does not change. The plan is approved by one of our developers, the diagnosis is prioritised by a person and responsibility for what is delivered stays with the team. What you hire us for is that judgment and that responsibility, with a system behind them that makes them more thorough.
What you hire us for is that judgment and that responsibility, with a system behind them that makes them more thorough.
Sources
- Drupal Association, Drupal core release cycle, drupal.org — schedule of minor and major versions and deprecation policy.
- Rector, Drupal Rector, drupal.org/project/rector — automatic refactoring of deprecations by version.
- PHPStan, phpstan-drupal, GitHub — static analysis with Drupal-specific rules.