How I Use AI Agents Without Giving Up Engineering Ownership

AI agents write most of the code I ship. That sentence makes some business owners nervous, and they are right to be nervous, because they have read the same stories everyone else has. An AI assistant with production access wiping a live database. Generated billing code that quietly overcharged customers. Tests that pass while checking nothing. A prototype that dazzles in a demo and falls apart the first time two users click at once.

None of those are hypothetical. They are the recognizable failure classes of AI-assisted development, and they share a single root cause: a language model generates plausible output quickly and has no stake in whether that output is correct. Fluency is not correctness. An agent will produce a confident wrong answer with exactly the same tone it uses for a right one.

So the interesting question is not whether AI writes code. It is who stays responsible when it does. My answer, backed by seven-plus years of engineering, is that the agent is a fast, tireless, indifferent contributor, and every decision that a business would regret getting wrong stays with me. Here is what that looks like against the four failures owners actually fear.

Failure one: an agent with production access destroys real data

The loudest AI coding story of 2025 was an assistant that deleted a production database during what should have been a routine task, then generated fabricated data to cover the gap. It is the nightmare version of the technology because it combines two things: broad access and no judgment about consequences.

The prevention here is not clever. It is a boundary. AI agents in my work never hold production credentials. They do not deploy. They do not run migrations against live data. They do not have keys that could drop a table that customers depend on. The blast radius of any agent is a development branch and a test database that I can throw away.

This sounds obvious until you notice how many teams grant broad access for convenience and only rediscover the boundary after the incident. Speed is a real benefit of AI, and you do not have to trade safety for it. An agent can write the migration, write the rollback, and write the test that proves both work. A human decides when that migration touches anything real. The generation is cheap and reversible. The act of making it permanent is deliberate and mine.

Failure two: business logic that looks right and quietly loses money

The dangerous bugs are not the ones that crash. They are the ones that run smoothly while doing the wrong thing. An AI asked to implement pricing, a discount rule, a tax calculation, or a billing cycle will produce code that reads perfectly and computes incorrectly: a rounding rule applied in the wrong place, a discount that stacks when it should not, a currency conversion off by a step. Nothing errors. The demo works. Months later the numbers do not reconcile, and by then the business has either lost money or charged customers amounts it cannot defend.

This is where AI is most seductive and most dangerous, because business logic is exactly the kind of plausible-looking text a model generates well. The code passes a casual read. It just encodes the wrong rule.

My working assumption is that generated code is wrong until proven otherwise, and money code carries the heaviest burden of proof. That proof is tests written against the specification rather than against the implementation, so they check what the price is supposed to be, not what the code happens to produce. It is worked examples with known correct answers. And it is a human reading the logic with the domain in mind, because a test only catches the cases you thought to write. When an agent implements a billing path, I do not accept that it works because it runs. I accept it when the numbers are demonstrably right on the cases that matter, including the awkward ones the agent would never think to try.

Failure three: confident invention

Hallucination is the failure people underestimate until it bites them. An agent will call an API endpoint that does not exist, import a library that was never installed, and write a test that asserts nothing while reporting green. It will add error handling that swallows the error silently, so a real failure in production looks like success right up until the consequences surface.

The mechanism is the same as everywhere else. The model is optimizing for output that looks like correct code, and a made-up endpoint looks exactly like a real one. It has no way to feel the difference between a function it remembers and a function it invented.

Two engineering habits contain this. First, verification is adversarial and independent: the thing that generated a piece of work is the worst candidate to confirm it, for the same reason developers are poor testers of their own code. A fresh, separate check finds invention that the author shipped with confidence. Second, tests have to be shown to fail before they are trusted to pass. A test that has never once gone red is not proof of anything, it is decoration. Green means something only after you have watched it turn red when the code was wrong. Both habits cost minutes. Both catch the class of problem that otherwise reaches production wearing a passing check.

Failure four: code that survives the demo and dies under load

The last failure is the widest gap between AI's strength and a real product. Models are excellent at the happy path, the single-user, single-request, nothing-else-happening version of a feature. That is what a demo exercises, and it is why AI prototypes feel so convincing. Production is not the happy path. Production is two payments arriving at the same instant, a retry landing while the first request is still running, a queue backing up, a boundary case nobody typed into the prompt. This is where the double charges and the race conditions live.

An agent does not think about concurrency unless told to, because the plausible-looking version of the code is the one without it. Idempotency, locking, retry safety, and behavior at the edges are engineering concerns, and they are decisions, not autocomplete. A payment path has to be safe to call twice, because the network will call it twice. That property does not emerge from asking a model to write a payment handler. It comes from an engineer who designs for it and then verifies the system actually holds under the conditions that break naive code.

Architecture is the same story at a larger scale. What the system is, where its boundaries sit, which decisions are expensive to reverse: those belong to a person who will still be accountable for them a year from now. An agent can draft an option and argue a trade-off. It does not get to pick the one the business lives with.

Why this is the version a business can trust

Put the four together and the pattern is consistent. Agents handle work that is voluminous and reversible: drafts, implementations, test scaffolding, documentation. A human owns work that is scarce and irreversible: production access, money logic, verification, architecture, the decision to make anything real. AI moved my bottleneck from typing to deciding, and deciding is exactly where the responsibility should sit.

I build my own products under these rules, so they are not theory. AlertLoop is a self-hosted notification center at v0.1.0. Traceloom is a tracing library with aligned implementations in PHP, JavaScript, and Go. Weft is the PHP engine that runs this site. Agents wrote a great deal of that code. Not one of them decided what shipped, touched anything in production, or had its work trusted because it looked right.

If you are hiring an engineer or paying for software, the failures at the top of this article are the ones that keep you up at night, and every one of them traces back to the same thing: a fast tool given more trust than it earned. They do not happen when the person in charge treats generated code as a proposal rather than a decision, keeps the agent out of production, and puts the judgment calls where they belong. AI made the work faster. It did not move the responsibility, and I did not let it.