Working with AI
I lead a team that develops 100% of its code with AI, working spec first. That is a change in where the engineering happens, not a shortcut — and it only holds up because the verification underneath it is serious.
Spec first, code second
The failure mode of AI-assisted development is prompting your way toward something that looks finished. You get working code fast, and you find out later that nobody ever decided what it was supposed to do.
Spec-driven development puts that decision first. The specification is the artifact the team argues about: what the thing does, what it must not do, what the edges are, what done looks like. Once that is settled, generating the implementation is comparatively cheap — and if the implementation is wrong, you have something concrete to check it against.
TODO: describe what a spec looks like on your team — where it lives, who writes it, how much detail it carries, and how you know it is ready to build from.
The bottleneck moved, it did not disappear
When generation gets cheap, review becomes the constraint. A team that can produce five times the code and review it at the old rate has not got faster — it has built a queue.
So the interesting work is in making review fast and making it trustworthy: small changes, tests that actually assert behaviour rather than restating the implementation, linting and type checking that catch the boring class of error before a human ever looks, and CI that fails loudly. None of that is new practice. AI just raises the price of not having it.
TODO: how does your team handle review volume? Pair review, review rotations, automated gates before human review — whatever it actually is.
What I do not claim
AI does not know what your organisation needs. It does not know that the change-management system is the real constraint, that one team owns the thing nobody documented, or that the obvious design fails at your scale for a reason you learned the hard way three years ago. Judgement about what to build, and whether it worked, stays with people.
It also does not remove accountability. If code I own breaks production, “the model wrote it” is not a finding — it is an admission that nobody reviewed it.
The worked example
This site and the infrastructure carrying it were built this way. Rather than take that on faith, you can read both repositories and check the verification for yourself: unit tests against mocked AWS, linting and type checking in CI, IaC and dependency scanning, drift detection that opens an issue when the live account stops matching the code, and a deploy that fetches the live URL and refuses to report success until the new commit is actually being served.
That is the part that makes the delivery model defensible. Generating code quickly is not interesting on its own; being able to prove the generated code does what you said it would is.