We've written about AI-assisted development from the outside: Cursor's developer habits report and its doubling code volumes, Dries's experiments with AI-generated Rector rules for Drupal migrations. What we haven't done is turn the lens on ourselves. This post is that: where AI tooling actually sits in our workflow after two-plus years of daily use, where it has earned trust, and where we deliberately keep it out.
No vendor paid for this and no tool comes out unscathed. If you're an agency owner trying to figure out what "we use AI" should mean beyond a marketing bullet, this is the post we wish someone had written for us.
The short version
AI assistance is now involved in most code we write. It is unsupervised in almost none of it. The distinction matters more than any tool choice. Our rule of thumb: AI drafts, humans decide. Every deliverable still passes through the same senior review it did in 2023; what changed is how much gets drafted before a human touches the keyboard.
Where it earns its keep
Boilerplate and scaffolding. Custom post type registrations, Laravel form requests, Next.js route handlers, test file skeletons. This is the least controversial win and the biggest raw time saver. Work that was 40 minutes of typing is now 5 minutes of reviewing. Nothing here requires trust, because the output is either obviously right or obviously wrong.
Version migrations and mechanical refactors. This is where the Rector-rules story resonated with us. Upgrading a Drupal module across API changes, converting class components, chasing a renamed hook through 60 files: AI tools are genuinely good at wide, shallow changes where the pattern is clear and the risk per edit is low. We still run the full test suite and diff review, but the drudgery is gone.
Test scaffolding. Asking for test cases surfaces edge cases we'd have skipped on a deadline: empty states, timezone boundaries, malformed input. The generated assertions need human correction maybe a third of the time, but the coverage thinking is the value. Our test counts on new projects are meaningfully higher than two years ago and the effort is flat.
First-pass code review. Before a human reviews a pull request, an automated pass flags obvious issues: unhandled nulls, missed escaping, N+1 queries. It catches real problems often enough to keep, and it makes the human review faster because the trivial findings are already handled. It does not replace the human pass, for reasons in the next section.
Legacy code archaeology. Inheriting a decade-old WordPress or Drupal site means hours of "what does this function actually do." AI summarization of unfamiliar code is reliably useful and low-risk, because the output is understanding, not shipped code.
Where it fails, still
Anything requiring the client's context. The model does not know that this client's "members" are actually three different user roles for historical reasons, or that the checkout hack exists because of a payment provider quirk from 2021. Business logic lives in heads and old email threads. AI-drafted code in these areas is confidently wrong in ways that survive superficial review, which makes it more dangerous than obviously broken code.
Security-sensitive boundaries. Authentication flows, payment handling, permission checks. Generated code here tends toward plausible-looking patterns that miss the specific threat. We write these by hand and review them twice. The cost of being wrong is asymmetric, and saving twenty minutes is not worth it.
Accessibility. Generated markup persistently under-delivers on WCAG: missing focus management, decorative ARIA, contrast that fails AA. Our accessibility work stays manual and audit-driven. If anything, AI-generated frontends across the industry are making the average site less accessible, which for our clients is a liability question, not a style one.
Anything where the volume itself is the risk. The Cursor report's most striking number was code volume doubling. Volume is not value. More code means more review surface, more maintenance, more places for bugs to hide. We actively prune AI-drafted code for scope creep: the helper nobody asked for, the abstraction serving one caller.
The review gates that make it safe
The workflow answer that took us longest to land:
- Nothing merges without a senior human review. Unchanged from the pre-AI era. The reviewer knows which parts were AI-drafted and reads those with more suspicion, not less.
- AI-drafted code is labeled in the PR. Not for blame, for calibration. Review attention is a finite resource; we spend it where the failure modes are.
- Generated tests don't count as verification of generated code. If the same tool wrote both, the tests inherit the same blind spots. A human writes or at minimum rewrites the assertions on anything non-trivial.
- Client code never leaves approved tooling. We use business-tier tools with training opt-outs, and client agreements say what tooling touches their code. If a client says no AI on their codebase, that's the answer, and it has happened.
What this means if you're hiring an agency
Ask any agency you're evaluating how they use AI tools. The red flags are the extremes. "We don't use AI" in 2026 usually means either they do and won't say so, or their velocity lags the market. "AI writes most of our code" without a described review process means you're paying agency rates for unreviewed generated code you could produce yourself.
The answer you want is boring: specific tools, specific use cases, specific review gates, and a clear statement of what stays human. That's the shape of every mature tooling adoption, from version control to CI. AI assistance is a power tool, and the question is never whether the shop owns power tools. It's whether anyone there still knows how the joinery works.
We think the joinery still matters. Talk to us if you want the team that knows both.
