What AI changes about how we build software

AI writes a growing share of the code on most teams, and within a few years almost every engineer will use it. Gartner expects 75% of enterprise software engineers to be on AI coding tools by 2028. The honest question for a team that builds software for a living is what that changes about the work.

AI changes how fast code appears and how an engineer spends the day. The judgment about what to build, how to structure it, and what to throw away still decides whether the software is any good. That judgment matters more now, because code itself is getting cheap.

We build software for clients every day, with these tools in our own hands. This is what we see changing, what stays the same, and what both mean for how you staff and run an engineering team.

Key Takeaways

• AI coding tools are near-universal: Gartner expects 75% of enterprise engineers to use them by 2028.
• They raise individual output. DORA's 2024 research found delivery stability fell about 7% as AI adoption rose, because more code means bigger, riskier batches.
• Architecture, the data model, review, and knowing what to throw away stay human, and they decide quality.
• As code gets cheap, judgment gets scarce. That is what a senior team is for.

The repetitive and the unfamiliar. AI is genuinely good at boilerplate, scaffolding, first drafts, and getting you moving in a library you have not used before. DORA's 2024 State of DevOps report found real gains here: as teams adopted AI, individual productivity, flow, and job satisfaction all rose (DORA, 2024).

On our own bench, that is roughly how it shakes out. AI drafts the obvious code, fills in the shape of a component, writes the first pass of a test, and answers the “how does this API work” question that used to be a browser full of tabs. It compresses the part of the work that was always mechanical, and it makes the first draft much faster.

The gains are real and worth having. The open question is what happens to the software once all that code exists.

On its own, no. DORA's 2024 research found that as AI adoption rose, individual productivity went up while delivery stability fell by about 7%. The reason is mechanical: AI makes it easy to write more code, more code means bigger changes, and bigger changes carry more risk. About 39% of developers in the same study said they distrust AI-generated code.

The quality of the code matters too. Veracode's 2025 study, a static analysis of code generated for known-vulnerability tasks, found AI-generated code introduces a security flaw 45% of the time, and over 70% of the time in Java (Veracode, 2025). AI will write the insecure version confidently, and it will write it fast.

So output goes up and the outcomes have to be earned separately. What earns them is the unglamorous discipline that always has: small batches, real tests, and someone senior reading the code before it ships. AI raises how much you can produce in a day. The decision about what is good enough to ship stays where it was.

The decisions. Architecture, the data model, the boundaries between parts of the system, the review that catches what the model got confidently wrong, and the call about what to throw away. AI is weakest exactly here, and these are the parts that decide whether the software lasts.

On our bench, those are the things we keep in senior hands. AI can draft a data model in seconds; whether that model survives the relationships that show up in month six is a judgment call, and getting it wrong is expensive to undo. AI can write a function; whether that function belongs there, or belongs at all, is the kind of decision that compounds. We let AI move fast where a mistake is cheap, and we keep experienced people on the parts where a mistake is permanent.

It is the same judgment that decides how to rebuild an AI-built MVP without starting over, and the same judgment that let us ship an AI feature on a public deadline. That judgment is the constant underneath all the new tooling.

Let AI move fast where mistakes are cheap, and hold the discipline where they are not. In practice that means AI for drafts and breadth, senior review on everything that ships, batches kept small enough to actually review, and tests that actually run.

The DORA data points the same way. The teams that get the productivity gain without the stability hit are the ones that keep the fundamentals while they adopt AI: small batches, testing, review. AI amplifies whatever process a team already has, so it rewards a disciplined team and exposes a sloppy one.

A senior bench is what turns AI speed into shipped quality. A junior-heavy team with AI produces a lot of code and a lot of risk. A senior team with AI produces a lot of code and catches the risk before it ships. The judgment around the tool is what makes the difference.

When anyone can generate working code in minutes, the code stops being the scarce thing. The scarce thing becomes the judgment to point it in the right direction and the discipline to keep it sound. That is the part you cannot prompt your way to.

This is the part of the shift that gets undersold. Cheaper code raises the value of good engineers, because their judgment is now the bottleneck on quality, where their typing speed used to be. The teams that come out ahead in the AI era are the ones with enough senior judgment to spend all that cheap code well.

That is the work we do: a senior team that owns the architecture and stays with the product, now with AI making the mechanical part faster and the judgment part more valuable. The code is getting cheap. The judgment is the job.