AI is quickly becoming part of everyday software development. It went from asking ChatGPT the occasional coding question to now running several autonomous agents in parallel, developers can now delegate more of the actual work than ever before.
But just because we can hand over more, does that mean we should?
In a recent Learning Lunch at Softhouse, web developer and system architect Jonathan shared how his own way of working with AI has evolved, what he has learned from letting agents loose in a real codebase, and why faster development also creates new demands on architecture, testing and, perhaps most importantly, the developer.
The short version; Old knowledge and findings should not be discarded just because we now have AI agents writing most code.
Start with boundaries, not prompts
It should be easy to do the right thing.
For both people and AI agents, doing the right thing should always be the easy choice. How do we verify that what we’re doing follows the specifications we’ve previously established, and how do we enforce that new changes don’t break previously implemented features? The answer is simple, and has existed way before agents were introduced. Automated tests, API service contracts and strict strict rules.
Jonathan’s experience comes from a real-world KPI dashboard project built for a customer with a limited budget. The system manages department hierarchies, permissions, shared metrics and tracking logic. AI-assisted development made it possible to move quickly, but speed only worked when the surrounding architecture gave the AI clear boundaries. The project therefore relies heavily on strict TypeScript, Prisma schemas, Fastify, and Zod validation across API routes. The principle is fairly simple: the more clearly the system defines what valid data and behaviour look like, the less room there is for incorrect assumptions. Equally true for both people and AI agents.
In other words, good architecture becomes even more important when AI starts writing more of the code. But there is another rule Jonathan considers just as important: the developer still needs to understand the system.
If you cannot explain the architecture and logic on a whiteboard, you probably do not understand enough of what the AI has built to maintain it safely over time.
From TDD to test-enforced development
Testing plays a central role in Jonathan’s workflow, but not necessarily in the traditional Test-Driven Development (TDD) sense. He describes his approach as Test-Enforced Development (TED).
When a bug appears, the first task is not to ask the AI to fix it. Instead, the goal is to create an integration test that reproduces the problem and fails. Only then is the agent asked to make the test pass. This changes the role of testing slightly. The test becomes both proof that the bug exists and a boundary for what the agent is allowed to change.
Jonathan has also moved away from relying heavily on the traditional test pyramid. Instead, he favours what he calls an Integration Diamond, with greater emphasis on integration tests and complete service tests.
For AI-assisted development, this provides something extremely valuable: a fast feedback loop that checks whether the agent’s changes actually work across the system rather than only in isolation.
Climbing the AI ladder
Jonathan describes his own journey with AI development as a kind of ladder. At the first level, development looks much like it always has: writing code manually, searching the web, reading documentation, and finding answers on Stack Overflow. Then came the chatbots. ChatGPT and Claude sit alongside the development environment and become somewhere to discuss problems, generate ideas or review code. The next step is bringing the AI into the development environment itself. Integrated IDE agents can read the project, modify files and follow project-specific instructions through files such as .claude or .agent.
From there, things start moving quickly.
Multiple agents can run simultaneously in separate workspaces, each working on different tasks. In theory, this means dramatically more work can happen in parallel. In practice, there is another bottleneck:
the developer.
Every output still needs to be understood, reviewed and verified. Running four agents at once does not necessarily make you four times as productive if you constantly have to switch context between four different streams of work.
Jonathan describes this level as powerful, but also mentally exhausting.
And at the top of the ladder are agentic swarms, where agents coordinate tasks and delegate work to other agents with increasingly limited human involvement. That raises a different question altogether: what happens when the developer is no longer meaningfully in the loop?
Sometimes the agent does exactly what you asked
One of Jonathan’s experiences illustrates why guardrails matter. During a refactoring task, an agent was instructed to make a failing test suite pass.
So it did… By deleting the failing tests.
Technically, the test suite was now green. The application, of course, had not been fixed. The incident led to an explicit project rule: agents are not allowed to alter or delete existing tests without human approval.
Agents were instructed to use standardised date utilities such as `date-fns` rather than creating their own date-comparison logic, reducing subtle time-zone and date bugs. They were also prevented from hardcoding CSS values and instead required to use the application’s existing design tokens and themes.
These rules might sound small, but together they point to something bigger. In order to work effectively and efficiently with coding agents, you need both guardrails and steering. It’s your job to govern and define what the agent is allowed to do, and which conventions it must follow. Human approval is, in the end, required. Since the machine cannot be held liable.
The risk of small mistakes at scale
Code does not have to be dramatically wrong to become a problem. A small percentage of questionable architectural decisions, unnecessary abstractions, or subtle bugs may seem manageable in isolation. But if those decisions keep accumulating across hundreds or thousands of changes, the effect compounds.
The result can be a codebase that still works but becomes progressively harder to understand, maintain, and change. This is why code review remains essential, even when the code was produced faster. AI can accelerate implementation. It does not remove the need for engineering judgement.
And what happens to the developer?
There is also a less technical side to all of this. AI makes it remarkably easy to outsource the moment when you would previously have stopped, thought through a problem, and worked your way towards a solution.
That convenience has a cost.
The more often we hand that process over to AI, the easier it becomes to reach for the model before thinking through the problem ourselves. Over time, there is a legitimate question about what that does to our ability to reason, debug, and build deep technical understanding.
Jonathan sees the contradiction in his own work.
He uses AI every day. It helps him develop faster, translate presentations, understand legacy systems and solve problems that would previously have taken considerably longer. At the same time, some of the joy of software development comes from solving those problems yourself. And perhaps that is one of the more interesting questions of the agentic era.
The challenge may not simply be figuring out how much work we can hand over to AI, but deciding which parts of the work we still want, and need, to own ourselves.
