Over the past year, AI has become a major part of my software development workflow.
At first, it was probably helping me write around 50% of my code. Now, that number is closer to 95%.
The tools have become significantly more capable, more context-aware, and better at carrying work forward across larger parts of a system. But as they have improved, I have noticed something unexpected: I have also started making mistakes I was not making earlier on.
That is not because the AI has become worse.
It is because I gave it more room to interpret.
For most of my AI-assisted development cycle, the work has been heavily guided. The AI agent was not inventing the architecture from scratch. It was building from examples I had already written. It was following established patterns, using existing conventions, and operating within a structure I had already defined.
That matters.
My general development philosophy is to structure a project in a way that forces you to write as little code as possible, while still making the system easy to change where change is expected, and rigid where correctness matters.
That means avoiding unnecessary abstractions and ceremony. It means using clear, purpose-built contracts and DTOs that contain only what they need for their specific job. It means retrieving the minimum data required for a task, keeping systems fast, and only loading more detailed, hydrated datasets when a specific action requires them. It also means caching and reusing data carefully, rather than repeatedly pulling more than the system needs.
When these principles are enforced by design on the backend, frontend development becomes much easier. The frontend has clearer boundaries. The data contracts are predictable. The interaction patterns are easier to reason about. The system becomes simpler to extend because the complexity has been contained where it belongs.
But on a recent project, I allowed the AI to interpret these principles rather than follow clearly defined patterns. And whenever it became convenient for the AI to complete the immediate request, it drifted.
That is on me.
LLMs and agents are much smarter than they were a year ago. They can produce more code, reason across more files, and move faster than ever before. But they will still deviate without strict guidance. They optimise for completing the task in front of them unless the system, the prompt, and the technical structure force them to respect the architecture.
The old principle still applies: start slow to go fast.
Before leaning heavily on AI to build large parts of a system, it is worth taking the time to define a clear technical requirements document. Not a vague product brief, but a strict technical guide that explains how the system should be structured, how data should move, where business logic belongs, what patterns should be followed, and what must not be introduced without good reason. Nuance matters, so add the important small details, stress what is important to you.
Once those patterns exist in the codebase, AI becomes far more useful. It can follow examples. It can extend conventions. It can generate within constraints. But without those constraints, it will often produce something that works in isolation while quietly weakening the system as a whole.
For me, the backend remains the most important part of this equation.
If the backend is robust, if it enforces business logic properly, if it guarantees data quality, and if it exposes clean, intentional contracts, the frontend becomes much easier to build, replace, or evolve.
That matters even more now, because the way we interface with systems is changing.
AI has not just made it easier to change how we interact with software. It has also made it practical to build user experiences that would previously have been too expensive, too experimental, or not important enough to justify.
That is incredibly empowering.
We are no longer only building systems for humans clicking through interfaces. Increasingly, we are building systems for both humans and agents to use as first-class participants. That changes what good software design requires.
The backend is no longer just supporting a frontend. It is supporting multiple modes of interaction: traditional UIs, automated workflows, agent-driven tasks, integrations, and interfaces that may not even exist yet.
That reinforces the need for a solid base.
If the system underneath is inconsistent, loosely structured, or unclear about where rules and responsibilities live, AI does not solve that problem. It amplifies it. But if the system has strong contracts, predictable workflows, clean boundaries, and well-enforced business logic, then both humans and agents can operate against it with much more manageable and predictable outcomes.
There is a lot of discussion about whether AI will soon behave like a senior software engineer. In some ways, that promise may be possible. The models are already capable of producing impressive amounts of useful work.
But some of the nuance in software design is still not well replicated or deeply understood by LLMs.
They can follow patterns, but they do not always understand why the patterns matter. They can complete tasks, but they may not recognise when a local shortcut weakens the system globally. They can generate code quickly, but they do not inherently carry the long-term responsibility for maintaining the shape, durability, and integrity of the system.
That is why the human in the loop still matters.
Not just any human, but someone with enough technical understanding to define the direction, recognise drift, enforce constraints, and decide where flexibility is useful versus where rigidity is necessary.
AI changes the speed of implementation. It changes the economics of experimentation. It changes the types of interfaces we can afford to build.
But good outcomes still depend on good technical judgment.
The lesson is not that AI needs to be restricted because it is weak.
It is that AI needs structure because it is powerful.
The better the model becomes, the more important our architecture becomes. Without strong technical direction, AI can help you move very quickly in the wrong direction. But with the right foundation, it becomes an extraordinary accelerator.
The work is no longer just writing code.
The work is defining the system clearly enough that both humans and machines can build it without slowly destroying it.