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
- Böckeler, B. (martinfowler.com), Harness Engineering for Coding Agent Users, 2026 — a mental model for building the agent’s environment: guides that steer it before it acts (rules, examples, specifications) and sensors that let it correct itself afterwards (linters, tests, drift detection).
- Schluntz, E. and Zhang, B. (Anthropic), Building effective agents, 2024 — a catalogue of patterns with examples: prompt chaining, routing, orchestrator-workers, and the generator-evaluator pattern, in which one model produces and another critiques. It favours defined workflows over autonomous agents.
- Alshahwan, N. et al. (Meta), Automated Unit Test Improvement using Large Language Models at Meta, FSE 2024 — a real production case of “assured” AI engineering: only what passes deterministic automatic filters (it compiles, passes reliably, improves coverage) reaches human review.
- Ziftci, C. et al. (Google), Migrating Code At Scale With LLMs At Google, FSE 2025 — a migration workflow documented step by step: locating changes with deterministic tools, making the change with the model, validation and human review. Twelve months, 39 migrations and lessons learned.
- Liu, B. et al., An Empirical Study on the Potential of LLMs in Automated Software Refactoring, Automated Software Engineering, 2025 — two concrete techniques: restricting the type of refactoring in the instructions raises accuracy dramatically, and what the model proposes is reapplied and validated with proven refactoring engines.
- Shinn, N. et al., Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023 — the learning mechanism without retraining the model: each error becomes a written reflection that the agent reads in subsequent attempts.
- Wang, C. et al., LLMs Meet Library Evolution: Evaluating Deprecated API Usage in LLM-based Code Completion, 2024 — measures when and why models suggest deprecated APIs and tests two lightweight fixes: replacing the API and warning in the instructions.
- Spracklen, J. et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, USENIX Security 2025 — quantifies how many non-existent packages models invent (at least 5.2% on average for commercial models and 21.7% for open ones) and the supply-chain risk this opens up.
- Dhanorkar, S., Passi, S. and Vorvoreanu, M., Human oversight of agentic systems in practice: Examining the oversight work, challenges, and heuristics of developers using software agents, 2026, preprint — real heuristics from 17 experienced developers for overseeing agents, in four forms: upfront control, joint planning, real-time monitoring and after-the-fact review.
- Mathews, N. S. and Nagappan, M., Test-Driven Development and LLM-based Code Generation, ASE 2024 — a direct experiment: providing the tests along with the problem statement improves the code the model generates.