AI-Driven Development: What Actually Changes (And What Doesn't)

Every week there's a new take on AI and software. Half of them say engineers will be gone by next year. The other half are written by people who tried Copilot for an afternoon, didn't like the autocomplete, and decided the whole thing was overblown.

Neither is right, and the gap between them is where the interesting stuff lives.

We build software for a living, inside real teams, on real deadlines. So this is what we actually see — not the keynote version, the Tuesday-afternoon version. Some of it matches the hype. A lot of it doesn't. And the teams getting real value out of AI are not the ones with the longest list of tools. They're the ones who worked out where AI helps and, just as importantly, where it quietly makes things worse.

Start with the boring observation

Software gets built in stages. Figure out the problem, design the system, write the code, test it, review it, document it, ship it, run it, change it. The names shift depending on who's drawing the diagram, but the work is roughly that.

Here's the thing nobody tells you: AI does not touch these stages equally. It transforms a couple of them. It's mildly useful for a few. And for the most important ones, it does almost nothing — occasionally it actively gets in the way.

Most teams miss this. They either sprinkle AI across everything and wonder why the gains are smaller than promised, or they get burned in one area and write the whole thing off. Both mistakes come from treating "AI for software" as one thing. It isn't.

Where it genuinely earns its keep

Writing code

This is the part everyone's heard about, and honestly, the noise is justified here. Tools like Copilot, Cursor, Claude Code — they don't write your application for you, but they collapse the time between "I know what I need" and "the code exists and runs."

On a team using these well, the distance from intent to working code drops by something like a third to a half. Not because the AI is thinking — the engineer still has to know exactly what they want — but because the dull mechanical bit, turning a clear idea into syntax, stops being the bottleneck.

The catch is the part the tool vendors skip over. This only works if the person driving already knows what good looks like. A strong engineer with AI ships better code, faster. A weak one ships code that looks right, compiles, passes a casual glance — and may be quietly wrong in ways they can't see. The tell is always in the unglamorous places: the off-by-one in the pagination logic, the race condition the happy-path demo never triggered, the error handler that swallows the exception it should have surfaced. AI is an amplifier. Point it at skill and you get more skill. Point it at confusion and you get faster, more confident confusion.

Testing

This one doesn't get enough attention, and it might be the biggest win of the lot.

Nobody likes writing tests. Engineers under-invest in them because they're tedious and the payoff is invisible until something breaks at 2am. So coverage stays low, and everyone feels vaguely guilty about it.

AI is genuinely good at this. Hand it a function and it'll generate sensible cases — happy path, edge cases, the error conditions people forget — in seconds. The real shift is subtler than "it writes tests faster": it moves your engineers off the tedious scaffolding — mocking a database context, faking OAuth states, standing up test fixtures — and onto the part that actually needs a brain, which is reasoning about what could go wrong. We've watched teams go from "we should really write more tests" to 80%-plus coverage in a couple of weeks, simply because the friction collapsed. And the second-order effect is the real prize: a well-tested codebase is one you can change without fear. That changes how fast a team can move on everything else. The compounding over a year is enormous and almost nobody factors it in.

Review and documentation

Two chores that are everyone's job and therefore nobody's. Both improve a lot with AI.

For review: AI catches the stuff humans miss in the third review of a tired Friday afternoon. Null-pointer risks, inconsistent error handling, the performance smell nobody clocked. It doesn't replace a senior eye, but it raises the floor of every review, and fewer bugs slip through to production.

Documentation is where it's almost embarrassing how much changes. The docs that used to take an afternoon — API references, architecture decision records, runbooks — take minutes now. One warning: AI will happily document behaviour that doesn't exist, with total confidence, so somebody has to actually read it. But with that check in place, docs go from "perpetually six months stale" to "actually current," which any engineer will tell you is close to a miracle.

Where it helps a bit, and don't oversell it

A few stages get a real but modest lift, and it's worth being clear-eyed so you don't over-invest.

Deployment and ops: this is where the boundary is sharpest, and worth drawing clearly because it's where your team probably spends more time than anyone admits. AI is genuinely excellent at the bulk-production end of infrastructure work — it'll draft three hundred lines of boilerplate Terraform, scaffold a Kubernetes manifest, translate a half-remembered PromQL query, or stub out a CI pipeline, and it'll do it in seconds without the usual slog through documentation. That's real time saved. But it has no idea what it's deploying into. It cannot calculate the blast radius of a live state migration. It cannot tell you whether to fail forward or roll back when a database migration is half-applied and the clock is running. It cannot weigh canary against blue-green for your traffic shape and your risk tolerance. It does the typing; the deciding — the part where a wrong call takes production down — is still entirely yours.

Refactoring: fine for the small stuff, renaming, extracting a method, modernising old syntax. Much shakier on large architectural moves, where the right answer depends on things that aren't written down anywhere in the code.

Debugging: a decent rubber duck. Moderately good at matching an error to a likely cause, much weaker the moment the bug is genuinely novel — which is exactly where the hours go. Most senior people we work with use it to think out loud, not to diagnose.

Where it does nothing — or hurts

This is the part the marketing decks leave out.

Understanding what to actually build. The earliest, most expensive stage — working out what the business needs and what it's really asking for, underneath what it said it wants. AI can summarise the meeting. It cannot tell you the stakeholder's stated requirement isn't their real one. It can't push back on a woolly brief or ask the one question that reframes the whole project. This is where the costliest mistakes get made, and AI is no help. Worse: lean on it here and you'll ship faster in the wrong direction, which is the most expensive kind of fast.

System design. How services split, where the data lives, what scales and how, what the security model is — these depend on context that exists nowhere in any codebase. AI can pull a pattern from a library of patterns. It can't tell you whether this pattern fits your situation, your team, your five-year plan. We've seen teams generate gorgeous architecture diagrams that have nothing to do with what should actually be built, because asking the machine felt easier than doing the thinking. That bill always comes due.

The judgement calls. When to say no. When to rebuild instead of patch. When the imperfect version is the right one to ship. When to stop and rethink the whole thing. This is the actual job, the part you pay senior people for, and it's the part AI can't do and probably won't for a long time.

Which is also where "AI replaces engineers" quietly falls apart. AI hugely increases how much one engineer can produce. It does nothing to reduce how much judgement they need to apply. If anything it raises the stakes — more code, more decisions, more forks in the road, and bad calls now compound faster than ever.

So what do you do with all this

If you're running a team or a software-dependent business, three things actually matter.

Put your AI effort where the gains are real: coding, testing, review, docs. Teams that go hard on those four ship more, faster, with fewer bugs, and they will pull ahead on cost and speed. It's not subtle.

Resist using it for the early thinking. AI for discovery, for architecture, for the genuine judgement calls — that's where it wastes time at best and generates expensive, confident mistakes at worst. Be deliberate about keeping it out of those rooms.

And stop treating senior engineers as the line item to cut. The companies trimming experienced staff to "do it all with AI" are setting themselves up for code that runs, tests that pass, and systems that fall over the moment real traffic hits. The premium on people who know what good looks like — who can spot the plausible-but-wrong and challenge a confident wrong answer — went up, not down.

That last point is really the whole thing. AI didn't make engineering judgement cheap. It made it the scarcest, most valuable part of the job.

---

Plexa Solutions is a senior European engineering consultancy. We've woven AI through how we build — coding, testing, review, docs — not as a talking point but because it's how the work gets done now, and we help our clients' teams work the same way. If any of this sounds like a conversation worth having, find us at plexasolutions.ie.