The fastest way to lose control

Then work is different

But that is exactly why I do not trust the same instinct in my everyday job.

At work, especially in regulated environments, AI kicks different. The stakes are not a weekend side project. They are not my tiny paper-trading fantasy. You are inside a large organization, with customers, money, audit trails, compliance, production incidents, and other teams who have to live with what you ship.

Rules are not there for decoration. Some of them are boring. Some of them are badly explained. Some of them are painful. But a lot of them are just institutional memory in disguise: this thing broke before, this ambiguity hurt someone, this shortcut became expensive, this data must not move casually.

So the problem is not that AI makes you fast. I like fast. The problem is that the side-project mode can sneak into places where speed is not the main constraint.

The clean wrong shape

It is not that the model writes bad code.

Bad code is easy. Bad code gives itself away. It fails tests, looks weird, breaks the build, triggers the ordinary instincts of a developer.

The dangerous code is the code that looks fine.

It has the right naming style. The folder structure is plausible. The tests are not embarrassing. The abstraction has a respectable shape. You can imagine someone defending it in a review with words like future-proof, scalable, or clean separation of concerns.

And still, something has slipped.

The problem was smaller than the solution. The prototype accidentally became architecture. A temporary label became a domain concept. A simple workflow grew a permission system, a cache, an event stream, or a generic error framework because the model has seen that shape before and it knows how to make it look professional.

Faster than what?

This is why "AI writes code faster" is such an incomplete sentence.

Faster than we can type? Obviously.

Faster than we can understand? Often.

Faster than we can decide whether the code should exist? That is where it gets expensive.

Software used to have a built-in brake: human effort. Writing code was slow enough that we had time to notice what we were doing. That brake was annoying, but it also protected us. It limited the size of changes. It made complexity expensive. It forced some amount of local understanding before a system could grow.

AI removes a lot of that friction. That is useful. It is also why engineering has to change function.

The job is no longer just to produce movement. The job is to keep movement governable.

A different posture

This is where I think the word containment helps.

Containment is not being scared of AI. It is not pretending that hand-written code is morally better. It is a change of posture.

In a side project, I want the model to run ahead of me. I want it to open doors I did not ask for. I want it to try a weird stack, invent a shortcut, generate the ugly first version, and give me something to react to.

At work, that same energy needs friction. Not because speed is bad, but because acceptance has consequences. A prototype can be deleted on Sunday night. A production concept might sit in a bank for years, acquire owners, appear in audit logs, shape other teams' assumptions, and become expensive to undo.

So containment is the senior engineer looking at a beautiful AI-generated abstraction and saying: nice, delete it.

...and posture is not enough

But this cannot live only as an attitude in someone's head. "Be careful" is not a system. "Use judgment" is not a control.

Containment needs tooling controls.

Tool access is authority. If an assistant can read Jira, Figma, Confluence, the repo, production logs, analytics, policy documents, translation files, and old incidents, it has not just gained context. It has gained many ways to make the wrong thing feel relevant.

This is why I like specs in the repo. Keep the intent, the business logic, the reason we are doing something, and the shape of the decision as close as possible to the code.

Then the specs are versioned. Changes can be evaluated against the current codebase. A pipeline can detect the gap, suggest the tickets, and agents can work through those tickets under the same controls as everyone else.

Keep it together over time

But even that is not enough by itself. A pipeline that judges a spec change and creates tickets is useful. It is not containment if the agents running those tickets drift freely, change their habits silently, or evolve outside the team's understanding.

The hard part is keeping the whole loop coherent: specs, code, tickets, agents, prompts, tools, evaluations, and quality gates. When the spec changes, the system should react predictably. When an agent changes, the system should notice. When generated work crosses a boundary, something should push back.

I have been trying tools in this space: Angular's web code generation scorer, Promptfoo, and especially Retort. They are useful because they move the conversation from vibes to evidence. But the exact tools are not the point. This landscape changes every few months.

The point is to keep the workflow together in time: maintain control, reduce drift, react when specs change, and keep those reactions legible.

The containment test

Before accepting AI-assisted work, ask:

1. Is this solving the actual problem, or a more impressive adjacent one?
2. Which assumption became code?
3. Which tool or document gave the model authority to make that assumption?
4. What will we have to own if this survives for two years?

The theme is not discipline for its own sake. It is the difference between side-project speed, where consequences are disposable, and production work, where decisions accumulate.

Containment is how that difference stays visible: intent close to the code, tools under control, agents evaluated over time, and changes accepted only when the organization can still explain them.