Automating the Software Development Lifecycle With AI: Where It Pays and Where It Does Not

Most conversations about automating software development with AI are actually conversations about automating typing. The agent writes the function, the developer reviews it, everyone reports a productivity gain, and the calendar looks exactly the same three months later.

That gap is not a mystery. Writing code was never the expensive part of shipping software. It is the most visible part, and it is the part with the cleanest demo, which is why it got automated first. The expensive parts are the ones on either side of it.

We run four platforms with a very small team, three of them live and one in build. What follows is where AI automation has actually compounded for us across the whole lifecycle, and where we have decided, on purpose, not to use it.

The lifecycle is bigger than the coding

Walk a feature from idea to production and count the stages. Someone decides what to build and why. Someone writes down what "done" means precisely enough to be checkable. Someone builds it. Someone verifies it does what the spec said and does not break the seventeen things it touches. Someone documents it. Someone deploys it. Someone answers for it at 2 a.m. when it misbehaves.

Building is one of seven. On a mature codebase it is frequently not even the longest one.

The stages around it share a quality that makes them miserable for humans and well suited to machines. They are high-volume, low-ambiguity, and mechanically checkable. Reading a diff against a written convention. Finding every call site of a function you are changing. Working out which of forty files a stale claim in a doc refers to. That work is tedious precisely because it is systematic, and systematic is what these tools are good at.

The framing we use internally is simple. Automate the connective tissue. Keep the judgment.

Where automation actually compounds

Four places, roughly in order of return.

Specification. This is the least discussed and the highest leverage. An agent that turns a loose request into a written spec with explicit acceptance criteria does two things at once: it produces something a second agent can build against, and it surfaces the ambiguity in the original request while ambiguity is still cheap. Half the value is the document. The other half is discovering, before anyone writes code, that nobody had decided what happens when the customer has two active subscriptions.

Verification. Not just tests, though tests too. The broader category is any check where the correct answer is knowable from the code and the conventions. Does this match how the rest of the repo does it. Does this migration have a rollback. Does this route have an auth-failure test as well as a happy path. We wrote about the specific shape of this in AI code review automation, and the summary is that automated review works well on convention and consistency, and works poorly on whether the design was a good idea.

Mechanical change at scale. Renames, framework upgrades, deprecating a pattern across a hundred files. This is the most reliably automatable work in the entire lifecycle because the definition of correct is unusually crisp: the behavior is identical and the shape is different. We covered the mechanics in using AI agents for large migrations and codemods.

Operational memory. Documentation that describes the code as it was eight months ago is worse than no documentation, because people trust it. Keeping architecture notes, changelogs, and runbooks synchronized with the actual repository is a genuinely dull job that nobody volunteers for and that an agent does well, because the source of truth is right there and diffable.

Notice what these four have in common. None of them are the part a developer finds satisfying. All of them are the part that decays quietly when a team gets busy, and the decay is what makes month nine slower than month two.

Where we do not automate

The line we hold is about accountability rather than capability.

Deciding what to build. No agent has the context that makes this decision correct: which customer is about to churn, which promise was made on a call last week, which technically inferior option is the right call this quarter. This is the "figure it out" half of how we work, and it is the half that determines whether the rest of the effort was worth spending.

Anything that touches money, identity, or health data. In Smile PreVue the AI renders the preview. It does not decide who may see a patient record. Multi-tenant isolation, the payment split, the audit trail, and the BAA boundary are hand-written, hand-reviewed, and tested like the liabilities they are. The Smile PreVue case study has more on that trust layer, and the lesson it taught us was that the model was the easy part.

The final review before production. Someone with a name signs off. Not because the machine review is bad, but because accountability does not survive being delegated to something that cannot be held to it. Automated review is a filter that makes the human review cheaper by removing the noise. It is not a replacement for it.

Anything where being wrong is silent. Loud failures are safe to automate aggressively, because you find out. A permission check that is subtly too permissive fails silently for months. We weight our attention by how a mistake announces itself, not by how hard the code is.

What it looks like on a real project

Howdy Dispatch, our dispatch platform for small fleets, has a feature where a dispatcher uploads a broker's rate confirmation PDF and the load comes back filled in, roughly twenty seconds of review instead of five to ten minutes of typing.

The feature itself is a good illustration of the same principle applied to someone else's job. It does not decide whether to take the load. It removes the transcription.

But the more relevant part here is how it got built. The extraction schema was specified as a document before any code existed, because the failure mode of a document parser is not a crash, it is a plausible wrong number that flows into a rate. The evaluation set came before the implementation. The parser was written fast with heavy AI assistance, because it is well-specified mechanical code. The address validation, the tenant scoping, and the auto-matching against the customer address book were reviewed line by line by a person, because that is where a quiet error costs a customer real money.

Fast where the spec is tight. Slow where the blast radius is wide. That is most of the discipline, and it is what our agent orchestration methodology is organized around.

How to start

If you are looking at this for your own team, the sequencing matters more than the tooling.

Instrument before you automate. For two weeks, note where the time actually goes between a decision and a deploy. Almost every team we talk to guesses wrong about their own bottleneck, and a team whose real constraint is a two-day code review queue gets nothing from a faster code generator.

Start where correctness is checkable. Migrations, test generation, documentation sync. You want early wins in the category where you can tell immediately whether the output is right, because that is how you build a calibrated sense of what these tools actually do.

Write the convention down first. An agent enforcing a rule that lives only in a senior engineer's head will enforce something else. The written convention is the thing that makes automation possible, which is why teams often find the documentation exercise pays for itself before any agent runs.

Add the eval before you add the agent. If you cannot describe how you would know the automation is degrading, you are not going to notice when it does. This is the single most skipped step and the one that separates a system that keeps working from one that quietly stops.

If your interest is more personal than organizational, meaning you want to work this way yourself rather than roll it out across a team, that is a different and much shorter path. We teach it one on one over at /learn.

The honest constraint

Automating the lifecycle does not remove the human bottleneck. It relocates it.

When specification, mechanical change, and verification all get faster, the constraint moves to the two things that did not: deciding what is worth building, and reviewing what came back. Both are senior-judgment work, and both scale with attention rather than with tooling. A team that automates aggressively without noticing this ends up generating more code than it can responsibly review, which is a worse position than the one it started in.

That is the actual reason we are careful about where the humans go. Not caution for its own sake, but because the reviewer's attention is now the scarcest thing in the system, and spending it on formatting nits is the most expensive mistake available.

Coding was never the bottleneck. It just looked like one, because it was the only part anyone was watching.

If you are working out where AI fits in how your team ships, tell us what you are building and we will tell you honestly whether it is worth automating.