AI-assisted development without compromising on quality

AI tools such as Claude Code, Cursor and Copilot have changed how quickly you can get from an idea to working code. An agent can read a repository, propose a solution, write the code and run the tests in a few minutes. "Vibe coding", where you describe what you want and let the tool write most of it, has become a real way of working.

Speed is not the problem. The problem is that code that looks right is not necessarily right, and it arrives faster than you can understand it. This post is about getting the gain without paying for it in quality, security and maintainability. The lessons come from real projects.

What the coding agent is good at

• Routine work within clear boundaries: boilerplate, mapping between formats, test data, migrating code from one API version to another.
• Getting started: a first draft of a component, a script or a test, which you then correct.
• Reading and explaining code: "where is this value set?" in an unfamiliar codebase.
• Mechanical changes across many files, when the pattern is unambiguous and the tests cover it.

Where the coding agent fails

• Domain knowledge and implicit requirements. The tool does not know the business rules that only live in people's heads or in an email from last year.
• Plausible but wrong details: a parameter that does not exist in that particular version of a library, or error handling that looks tidy but swallows the error.
• Security: input that is not validated, secrets that end up in code or logs, and dependencies that are added without anyone looking at them.
• Architecture over time: each change can make sense on its own while the whole drifts. You only notice when the system has to change again.

Where we humans fail

The coding agent is not the only link that can fail. The better the tool gets, the easier it is for us to relax:

• Trust grows faster than the evidence for it. After a long run of good suggestions, you read the next one less carefully. That is exactly where the mistake slips in.
• Review turns into skimming. The diff looks tidy, the explanation sounds convincing, and you approve without having understood what the code does.
• Green tests as a comfort blanket. The tests pass, but if the agent wrote both the test and the code, and nobody read the test, it only proves that the code does what the agent thought it should.
• Responsibility drifts. "The agent wrote it" becomes a quiet excuse for not having checked it yourself.

Responsibility cannot be delegated to a tool. When data leaks or a defect hits customers, it is not the coding agent that has to answer to the customer, management or the data protection authority. It is the company and the people who approved and shipped the code. That is why the agent's work deserves the same critical review as everything else, also, and especially, when things usually go well.

Guardrails for quality

What works is not using the tools less, but giving them fixed boundaries. Four of them make the biggest difference.

1. Tests first. When the test is written before the code exists, you have a precise description of what should happen and an objective measure of whether it did. That goes double for generated code. Let the agent write the test, read it carefully, watch it fail for the right reason, and only then let the agent write the code. A test you have not seen fail proves nothing.

2. Small changes. A change of a handful of lines you can follow line by line. A change that runs screen after screen gets approved because it looks reasonable. Ask for one step at a time and commit each step on its own, so the history shows what happened and a bad step can be rolled back by itself.

3. A human reviews the code. The agent's work is reviewed like any other pull request, with the same requirements. That is not distrust; it is the same process that makes human-written code better. Ask in particular: do I understand why the code looks like this? If the answer is no, it is not done. It is the person who approves the code, not the agent, who is accountable for it.

4. Clear instructions for the agent. Most tools read a file with project rules, for example CLAUDE.md for Claude Code. It is the place for what you would otherwise say again and again: how the project is structured, which commands run the tests, which libraries have been chosen, and what the agent must never do. An excerpt could look like this:

• run npm run test:unit before every commit, and show the test failing before the code is written;
• unit tests must not need a database or network; use stubs;
• do not add new dependencies without asking;
• schema changes only as additions; renames need a migration;
• secrets come from environment variables and must never be in the code;
• update the system documentation (architecture, system design and API documentation) in the same commit as the code that changes it.

The rules are not a guarantee, but they move the standard from "what the agent guesses" to "what the team has decided".

Security

Three areas need particular attention when an agent writes and runs code:

• Secrets. Never let the agent see production keys. Use environment variables, a .env.example without real values, and tokens with as few permissions and as short a lifetime as possible. Check changes for keys before they are committed; that can be automated.
• Dependencies. An agent will happily solve a problem by installing a package. Every new dependency is code from a stranger that runs in your system. Require new packages to be approved, pin the versions, and run a vulnerability scan as part of the build.
• Isolation. The agent runs commands. If it runs directly on the developer's machine, it has access to everything the developer has access to. A Dev Container limits what it can reach. We describe the setup and its limitations in Isolate your AI coding agent.

So where does the human stand?

The tools move the work; they do not remove it. Less time goes into writing code, and more into formulating what should be built, reviewing proposals and keeping the architecture together. That is not less demanding; it is a different kind of demanding. Experienced developers get the most out of the tools precisely because they can quickly see when a proposal is wrong. And the responsibility does not move into the tool: it stays with the people who approve and ship the code. The same goes for maintenance: code that nobody on the team understands becomes expensive to change, however quickly it was written.

For a team that wants to get started, a good first step is to pick a well-bounded area with good test coverage, write the project rules down and measure the same things as before: defects in production, time from idea to release and how easy the code is to change afterwards. If those numbers improve, the tools are a gain. If they get worse, it is the boundaries that need tightening, not the speed that needs increasing.