Double Agent

Originally published on Medium.

Agentic coding assistants are becoming the double agents of software engineering.

On one side, they are loyal allies. They help you move faster, ship sooner, explore ideas quicker, and get unstuck in places where you would have otherwise spent hours digging through documentation, boilerplate, unfamiliar code, or some frustrating edge case buried three layers deep in a framework.

At this point, it is hard to seriously argue that agentic coding assistants do not improve delivery speed. They do. They help engineers produce more in less time, and for many teams, that improvement is already visible in real products, real pull requests, and real releases.

But on the other side, while they are helping you deliver faster, they may also be quietly weakening the very skillset that made you valuable in the first place.

That is the uncomfortable part.

The risk is not simply that AI will replace weak engineers. The risk is that strong engineers may slowly become weaker by letting the agent do too much of the thinking.

The danger is not just that AI will sometimes write bad code. Sometimes it will, and sometimes it will not. The bigger danger is that software engineers may slowly stop practicing the core act of engineering. We may stop forming the solution in our own minds. We may stop carrying architecture in our heads. We may stop feeling the texture of a codebase. We may stop building the instincts that tell us when something is elegant, overcomplicated, fragile, or simply wrong.

The assistant helps you move faster, but it can also move some of your muscles for you.

And any muscle you stop using eventually gets weaker.

This is why I believe every software engineer working with agentic systems should enforce a simple discipline:

Three times per week, build a full feature with no AI help.

Not a tiny refactor. Not renaming a variable. Not asking the model to explain an error and then pretending you did the work. A real feature. Designed, implemented, tested, and reviewed by you, without agentic assistance.

This is not anti-AI. It is the opposite. It is how you remain qualified to use AI well.

Because here is the first problem: you cannot review agent code if you forgot how to code.

A lot of engineers are starting to confuse code acceptance with code review. The agent generates something, the tests pass, the UI looks right, and the pull request gets merged. But reviewing code is not just checking whether the output appears to work. Reviewing code means understanding the tradeoffs. It means knowing whether the abstraction fits. It means seeing whether the system will survive the next feature, the next scale problem, the next developer, and the next incident.

If your own coding ability declines, your review ability declines with it. You become dependent on the same system you are supposed to supervise.

That is not engineering. That is delegation without judgment.

The second problem is the deadman switch.

What happens when the AI is not available?

Maybe you hit the maximum token cap. Maybe the service goes down. Maybe you are on an airplane. Maybe you are working inside an air-gapped environment. Maybe your company restricts what can be sent to external models. Maybe the model is unavailable for legal, compliance, security, or cost reasons.

Does the world stop?

It cannot.

Software engineering existed before agentic assistants, and every serious engineer still needs the ability to operate without them. AI can be an accelerator, but it cannot become the oxygen supply. The moment you cannot function without it, you have moved from augmentation to dependency.

This matters even more in high-pressure situations. Production incidents do not always happen when your tools are perfect. Critical bugs do not wait until your context window is clean. Security fixes do not care whether your favorite model is rate limited. In those moments, the engineer still has to be able to think, debug, reason, and act.

The third problem is the future of software engineering itself.

AI models are incredible at giving us back what humanity has already produced. They are trained on the past. They are powerful pattern machines. They can synthesize, remix, translate, accelerate, and automate. That is useful beyond belief.

But software engineering cannot only be the repetition of known patterns.

Someone still has to push the boundary.

Someone still has to imagine the thing that does not exist yet. Someone still has to question the architecture everyone accepts. Someone still has to invent the new abstraction, the new protocol, the new developer experience, and the new way of thinking about systems.

AI can generate novelty, but it does not carry intent, taste, lived context, or responsibility. It can explore the space of what is likely. Humans still decide what is worth building.

That is the distinction that matters.

Progress does not always come from the highest probable next token. Sometimes it comes from the weird idea. The unpopular architecture. The uncomfortable question. The thing that looks wrong until the world catches up.

That is still the job of the human mind.

So how do we make this practical?

Engineering teams should not rely on vague self-control. The urge to let the agent do the work is too strong, especially when deadlines are tight and the agent is sitting one shortcut away. If we believe this discipline matters, then we need to design it into the way teams work.

One idea is a token lock.

A token lock is a simple team policy or tooling mechanism that prevents agentic coding usage during specific periods. For example, Monday, Wednesday, and Friday can become no-AI feature days. On those days, engineers build features themselves. They read the code themselves. They trace the execution themselves. They write the tests themselves. They debug the failures themselves.

No agent. No generated implementation. No AI-written test suite. No shortcut around the thinking.

This does not mean engineers sit alone pretending the rest of the team does not exist. Quite the opposite. No-AI days should bring back real engineering conversations. You talk to another engineer. You walk through the design. You argue about tradeoffs. You whiteboard the flow. You ask someone why the system was built this way. You pair program. You review the code with human attention.

That matters because engineering is not only a typing activity. It is a social reasoning activity. A good team does not just produce code. It transfers judgment. It builds shared context. It teaches taste. It develops instincts across people.

Agentic systems can compress work, but they can also reduce the number of moments where engineers actually talk through the hard parts together. If every question becomes a prompt, teams lose the conversations that used to create senior engineers.

A no-AI discipline protects those conversations.

It also makes AI usage healthier on the other days. If Tuesday and Thursday are AI-assisted days, then the agent becomes an accelerator again, not a crutch. Engineers come back to the tool with sharper judgment because they have recently exercised the underlying skill.

The point is not to ban AI. The point is to build enough friction that engineers do not lose themselves inside convenience.

Teams already enforce all kinds of disciplines to preserve quality. We require code reviews. We require tests. We require security checks. We require production approval. We do these things because raw speed is not the only goal.

The same principle should apply to engineering ability.

If AI is now part of the development environment, then maintaining human engineering capacity also has to become part of the development process.

This is why the future software engineer cannot be someone who merely prompts machines. The future software engineer has to be someone who can think with machines, without surrendering the ability to think without them.

The best engineers will not be the ones who reject AI. That would be foolish. They also will not be the ones who blindly outsource their judgment to AI. That would be dangerous.

The best engineers will be the ones who use AI aggressively while preserving their own independent technical strength.

They will let agents generate code, but they will still know how to build the system themselves. They will use AI to explore options, but they will still know how to choose. They will move faster, but they will not forget how to walk.

That is the balance.

Use the agent. Trust it sometimes. Question it often. Review it seriously. And a few times every week, turn it off completely.

Build something with your own hands.

Not because AI is bad.

Because you are still the engineer.