“AI shifted my focus from writing code to designing systems. That’s the real acceleration.”

Question

When did AI become a genuine part of how you work, and what actually changed?

The shift happened when I realised AI wasn’t just speeding up the writing of code. It was changing what I could do with my time.

Before, a significant part of my day went on the mechanics: searching for libraries, reading documentation, working out how different components fit together. With AI, a lot of that disappears. I can build custom tooling that fits the specific project rather than wrestling with an off-the-shelf library that was never quite right. I can open a new codebase and understand its architecture in hours rather than weeks.

The bigger change is that I can experiment more. Testing three different approaches to an architectural decision used to be expensive. Now it’s fast enough to actually do. That changes how you make decisions. You’re not picking the option you think will work. You’re picking the one you’ve tested.

Question

Can you give a concrete example of where this changed an outcome?

Two come to mind, both involving projects that had accumulated problems underneath the surface.

The first was a project with about five bugs that needed fixing in a week. When I looked at the codebase, I could see the bugs were symptoms of a deeper issue: the functionality had been built feature by feature without any unifying structure. Fixing the bugs individually would have bought a week. What the project actually needed was a rethought architecture.

With AI, I was able to do both within the timeframe. I ran a full audit of the existing codebase, mapped the components, collected the bug history, and used that to design a new architecture rather than patch the old one. Then I worked through implementation in structured stages, with validation at each step. The bugs were fixed, the underlying structural problems were resolved, and no further issues appeared in that part of the system.

The second was a scaling problem that surfaced a month into a project. The original requirements had been met correctly, but no one had thought through what happened when the system grew. By the time it became urgent, the problem wasn’t just technical. The requirements themselves were wrong, conflicting, and not designed for where the business was heading.

I used AI to work through the full picture: original documentation, current state of the codebase, business requirements, scaling criteria. From that I built a transition plan with timeline and cost estimates. In the end, the business decided not to refactor at that point, which was a legitimate call. But the analysis directly shaped how requirements were written and evaluated going forward. The value wasn’t the refactoring. It was the quality of the decision-making that followed.

Question

What’s the honest account of where AI falls short?

The limitation people don’t talk about enough is that AI works with the context you give it. If that context is incomplete or poorly organised, the output reflects that. An agent can interpret a prompt and produce code. It can’t fill in the business logic, the architectural history, or the judgement calls that weren’t written down anywhere.

There’s also a real tension between moving fast and maintaining coherence. You can move very quickly with AI-assisted development. But the faster you move, the more disciplined you have to be about review, consistency checking, and validation. If you skip that work, you end up with a system that functions at the current moment but can’t be changed without things breaking. The speed is real. The risks of using it without the right verification habits are also real.

Question

What does your verification process look like in practice?

Every piece of work goes through a structured review cycle. Build checks, linting, type checking, dependency validation. For projects with specific architectural patterns like clean architecture or domain-driven design, I check that the structural rules are being respected and that nothing is leaking across boundaries that should be enforced.

AI-assisted code review is part of this, but it works from a knowledge base: the API contracts, the architectural documentation, the integration specifications. Without that foundation, automated review is superficial. With it, it catches issues that manual review under time pressure might miss.

I also carry a deliberate view on technical debt. Not everything needs to be perfect at the current moment. Some things get deferred because the pace of development or the flexibility required at this stage makes perfection the wrong goal. The judgement is in knowing which category something falls into, and documenting that explicitly rather than leaving it implicit.

Question

What do you think engineering managers most misunderstand about how AI-native developers actually work?

The most common misunderstanding is what “faster development” actually means.

AI does speed things up. Coding is faster. Requirements validation is faster. Architecture planning is faster. But developers still review, still test, still make architectural judgements. The work doesn’t disappear. It changes shape.

If a manager expects that hiring an AI-native developer means the same output with no review time, no architectural thinking, and no back-and-forth on requirements, they’ll be disappointed. And they’ll probably get a codebase that works now and causes serious problems in six months.

The acceleration that’s real and valuable is the ability to design better solutions in less time, to test multiple approaches rather than committing to one, to catch structural problems before they become expensive. That’s what AI delivers. Capturing that value requires an environment where those things are valued, not just raw delivery speed.

There’s also the cost question. Using AI at different levels of the development process has different costs. Having an AI generate a code snippet is cheap. Having AI plan, validate, and adjust an architectural approach requires more investment, but produces something qualitatively different. The teams that get the most from AI-native developers are the ones that understand this distinction and invest accordingly.

Question

What are you watching closely in terms of where this is heading?

The direction is clearly towards autonomous systems that can handle much longer, more complex tasks. The models are improving specifically on this. What that means in practice is that the developer’s role continues to shift: less time on execution, more time on the things that require genuine judgement. Requirements quality, architectural decisions, validation criteria, understanding the business context well enough to know when a technically correct solution is the wrong answer.

That shift is already happening for developers who are working this way. The ones who are developing those judgement capabilities alongside their AI fluency are the ones who will be valuable as the tools keep improving. The ones treating AI as a faster way to do what they were already doing are building on a foundation that gets less relevant over time.