AI has changed how I write software, but not in the way I first expected.
When LLMs and coding agents started becoming useful, I went in early. I built my own agents. I subscribed to the tools. I pushed them into my workflow as far as I could, partly out of curiosity and partly because it felt obvious that software engineering was about to change.
For a while, it was easy to believe the conclusion was simple: agents would write more of the code, engineers would supervise, and output would go up.
That is not where I have landed.
The more I worked with agents, the more I started seeing the cracks. They produced code quickly, but not always good code. They duplicated logic. They added abstractions that did not need to exist. They solved the local prompt without understanding the wider system.
Most importantly, I noticed something more dangerous: when you let the agent drive too much, you start losing touch with the codebase.
You lose the domain-level understanding of how the system actually works. You stop building the internal map. Bugs creep in. The code gets larger. The shape of the product becomes harder to reason about.
And that matters because every line of code is risk.
More code is not automatically progress. Every line has to be read, tested, understood, deployed, operated, debugged, and eventually changed. A good engineer is not trying to maximize code output. A good engineer is trying to minimize unnecessary complexity while still solving the business problem.
That is where my view on agentic engineering changed.
The pendulum swing
After going very hard into agents, I swung back in the other direction.
I went back to writing most of the code by hand. I used LLMs more for brainstorming, discussion, and exploring ideas than for implementation.
That was useful. It brought back something I had started to miss: real ownership of the problem.
When you sit down and write the code yourself, you build understanding. You notice the edge cases. You feel where the system is too complicated. You discover where the model in your head does not match the model in the code.
That work still matters.
In fact, I think it matters more now.
The mistake is thinking that because agents can generate code, the engineer no longer needs to deeply understand the problem. The opposite is true. The more leverage the tools give you, the more important your judgment becomes.
Where agents are genuinely useful
I do still use agents heavily. I just use them differently.
There is plenty of software work that needs to get done but is not the core intellectual problem.
Admin dashboards are a good example. Internal tools. CRUD screens. Boilerplate. Certain UI flows. Test scaffolding. Data migration helpers. API client wrappers. First drafts of documentation. Repetitive integration work once the pattern is understood.
If the tools are chosen well and the boundaries are clear, agents can move very quickly through this kind of work.
That is valuable.
Not every part of a product deserves the same amount of senior engineering attention. Some parts need to be solid and maintainable, but they are not where the competitive advantage lives. They are supporting systems. Necessary, but not central.
Agents are excellent at helping clear that work faster.
The mistake is using the same approach on the critical parts of the product.
The core domain still belongs to the engineer
Every product has areas where the team needs deep understanding.
The architecture. The core workflows. The data model. The reliability boundaries. The deployment model. The places where failure is expensive. The parts that make the product different.
Those are not areas I want to outsource blindly to an agent.
For example, I have been working on Deploy Crate, an infrastructure management tool. In that kind of system, there are details I need to understand deeply. The interesting engineering work is in the technical decisions: what should be abstracted, what should stay explicit, where the failure modes are, what the operational model should be, and how much complexity the system can afford.
That is the work I do not want the agent to own.
But I do want the agent involved.
I want it to help me explore the problem space. I want it to generate small prototypes. I want to compare different approaches. I want to ask it to challenge assumptions, map tradeoffs, and produce quick proof-of-concepts that I can inspect.
Then I decide.
Often, I delete the generated code and write the final version myself.
That is not wasted work. That is the point.
The value was not the code. The value was the exploration.
Agents make exploration cheaper
This is the biggest shift for me.
In the past, spending a week exploring multiple technical directions could be hard to justify. A manager might ask why nothing “real” had shipped. A client might wonder why the first implementation was being thrown away.
But good software often requires exploration.
You need to test assumptions. You need to understand the shape of the problem. You need to see where an approach breaks before you commit to it.
Agents make that cheaper.
They let a senior engineer explore more options in less time. You can generate two or three possible implementations. You can test an API. You can simulate a migration. You can compare architectures with real code instead of only talking about them.
Then you throw away most of it.
That is not a failure of the tool. That is a better development process.
The output of the agent is not necessarily production code. Sometimes the output is clarity.
A real example: CMS integrations and embeddings
One client project required integrating with many different CMS systems. Each CMS had its own API, but the overall problem was similar: ingest content, process it, generate embeddings, and make that content available for LLM-powered search.
There were around 15 to 20 systems to support.
The wrong approach would have been to immediately ask an agent to generate integrations for all of them.
Instead, I started with one of the biggest systems and used the agent to explore the API, the ingestion model, the content structure, the polling frequency, and the embedding pipeline.
The goal was not to blindly ship the first generated implementation.
The goal was to understand the problem.
Once the shape became clear, I used the agent to compare the same approach against the other CMS APIs. A common pattern started to emerge. From there, I could design the integration model properly, write the core implementation myself, deploy it, and verify that it worked.
After that, the repeat work became much easier.
At that point, agents could help accelerate the remaining integrations because the important decisions had already been made. The pattern was understood. The domain model was clear. The implementation had a foundation.
That is where agents become very powerful.
Not as a replacement for engineering judgment, but as leverage around it.
The dependency risk is real
There is also a practical business risk here.
These tools are incredible, and they are not going away. But they are still external dependencies. Prices can change. Capabilities can shift. Models can regress. Products can disappear. Access can be limited. A workflow that feels cheap today may become expensive tomorrow.
That does not mean teams should avoid agents.
It means they should not build their engineering capability on top of rented understanding.
If an AI tool disappears tomorrow, a good team should still be able to operate its product. Maybe slower. Maybe with some rust. But the core knowledge should still be inside the team.
You can relearn a tool. You can pick coding speed back up.
What is much harder to recover is deep understanding of a technical problem you never really owned.
The useful version of agentic engineering
The useful version of agentic engineering is not “let the agent run the product.”
It is this:
- Use agents to explore more options.
- Use them to test assumptions faster.
- Use them to remove low-value implementation drag.
- Use them to generate prototypes you are willing to delete.
- Use them to compare tradeoffs before committing.
- Use them to accelerate the work around the core problem.
But keep ownership of the critical path.
The senior engineer’s job is still to frame the problem, understand the domain, choose the architecture, reduce risk, and leave behind software that the team can operate and extend.
Agents can help with all of that.
They just cannot replace the responsibility.
The best teams will not be the ones that generate the most code. They will be the ones that use AI to arrive at better decisions faster, while still maintaining control over the systems they ship.
That is the version of agentic engineering I trust.