BLUF: I have been using AI coding agents for over a year now — from simple code suggestions to letting them build entire features end to end. I ship code faster than I ever have. But in that same year, I failed a whiteboard interview because I could not write a basic sorting algorithm on paper, I have struggled to debug my own codebase on live calls, and I have noticed that my code looks less and less like mine. After 12 months of AI-driven development, I am faster — and I am also a worse engineer than I was a year ago. Here is the honest breakdown of what happened, what it cost me, and how I am fixing it.
Here is the outline of what we will cover:
- How My Development Process Changed
- The Three Things I Lost
- The Real Cost: Speed vs Depth
- How I Fixed My Workflow
- The Rule I Follow Now
1. How My Development Process Changed
A year ago, my workflow for any new feature looked like this: read the business requirement document, understand the data flow, sketch the component structure in my head, and start writing code. Every function, every conditional, every edge case — I wrote it. The code was mine. I knew where every piece of logic lived because I put it there.
Now my workflow is completely different.
When I get a business requirement today, I don’t start writing code. I pass the requirement document to the AI agent. It gives me the insights, the necessary steps, and a knowledge transfer for what to build. As soon as I understand the basic requirement, I start building — but “building” now means describing what I want and reviewing what the agent writes.
Of course, this saves a lot of time. The speed improvement is real and I am not going to pretend otherwise. Tasks that used to take me a full day now take a few hours. But here is what nobody talks about: your relationship with your own codebase changes completely.
2. The Three Things I Lost
Your code stops being yours
Before AI agents, every developer had their own coding style. Their own patterns, their own naming conventions, their own way of solving problems. If you gave the same feature requirement to five senior developers, you would get five different implementations. Each one reflected how that developer thinks.
With AI agents, that individuality is disappearing. Everyone’s code is starting to look the same because the agent writes in a standardized way. The code is often more optimized and follows best practices, but it does not reflect how you think about the problem. It reflects how the model was trained to solve it.
And here is the part that actually hurts: some of the logic the agent writes is far more advanced than what you would have written yourself. That sounds like a good thing until your manager pulls you into a call and asks you to explain a specific function. You are staring at code that lives in your repository, under your name, and you are not entirely sure how it works.
Debugging on live calls becomes a nightmare
This is the scenario that keeps happening to me. A production issue comes up, the team jumps on a call, and someone says “Can you walk us through what this service does?”
If you wrote the code yourself, you can trace the flow from memory. You know the edge cases because you thought about them when you wrote the conditional. But when the agent wrote it, you might know what the function does at a high level, but you don’t always know why it chose a specific implementation pattern or where it added internal logic that you did not explicitly ask for.
On the call, you are scanning your own code like it is someone else’s pull request. That is not a good position to be in as a senior developer.
Your velocity has a single point of failure
This one hit me the hardest. On days when the AI agent is down — maybe the service has an outage, or you have hit your quota limit — your entire day feels different. Your speed drops significantly. Tasks that you got used to finishing in two hours now take you five or six, because your brain has outsourced the “writing code from scratch” muscle.
It is the same thing I described in my article Whiteboard Reality Check: Why AI Won’t Save Your Next Interview. In that interview, I could not write a basic bubble sort on paper because I had not written code by hand in over a year. The same dependency that failed me in that interview room is the same dependency that slows me down when the agent is unavailable at work.
3. The Real Cost: Speed vs Depth
Let me be honest about the trade-off. With AI, I can ship code faster. That is a fact. But the cost I am paying is in quality and coverage.
I have noticed that when AI writes a feature for me, the happy path works perfectly. But the edge cases — the weird user flows, the race conditions, the boundary scenarios — those get missed more often. I end up with more reopened tickets because the feature did not cover all the possible flows.
Before AI, I would think through every scenario while writing the code because the writing was the thinking. When you type out each conditional yourself, you naturally ask “what if this value is null?” or “what happens if the user clicks this twice?” That internal questioning was built into the process of writing code.
When you delegate the writing to an agent, you also delegate that internal questioning. The agent might handle some edge cases, but it does not know your users. It does not know the weird things your QA team will try. That domain knowledge lives in your head, and if you are not the one translating it into code line by line, some of it gets lost.
And there is one more cost that I did not expect: losing track of your own project. When the team wants some insights about the codebase — like where a specific piece of logic lives or how an internal service works — sometimes I genuinely don’t know. I can’t always track which files the agent modified or how the internal wiring connects, because I was not the one who made those decisions at the code level.
4. How I Fixed My Workflow
After the whiteboard interview failure and a few uncomfortable debugging calls, I changed how I use AI agents at work. The shift was simple but it changed everything.
Instead of telling the AI “build this feature,” I now tell it exactly what I want and how I want it done.
The difference matters. In the early days, I would give the agent a generic prompt: “Create a user authentication flow with JWT tokens.” The agent would produce a complete implementation, and I would review it and merge it. But I did not always understand the internal decisions it made — why it structured the middleware a certain way, why it chose one validation library over another.
Now I break down the feature the same way I would if I was writing the code myself. I ask: what are the steps I would take if I was building this from scratch? Then I write those same steps as instructions for the agent.
For example, instead of “Build the auth flow,” my prompt now looks like:
- Create a middleware that extracts the JWT from the Authorization header
- Use
jsonwebtokenlibrary for verification, not a custom decoder - If the token is expired, return a 401 with the message “Token expired”
- Store the decoded user object in
req.userfor downstream handlers
This way, even if I miss some small internal piece of logic — like how the library handles clock skew — I at least know what every function is for and why it exists. I control the architectural decisions. The agent handles the typing.
5. The Rule I Follow Now
After a year of going back and forth, I settled on one rule that I follow every day:
AI should speed up your process, not replace your thinking.
The moment you start blindly trusting the agent’s output without understanding the decisions behind it, you are no longer an engineer. You are a project manager who happens to have a code editor open.
That might sound harsh, but I have seen what happens when you cross that line. I crossed it, and it cost me an interview. It made me look unprepared on debugging calls. It made me dependent on a tool that can go offline at any time.
The agent is a force multiplier, not a replacement. Use it to type faster, to scaffold boilerplate, to explore solutions you might not have considered. But the architecture, the edge cases, the debugging flow — that still has to live in your head.
I am now making it a habit to write at least one feature per week completely by hand, without any AI assistance. Not because it is faster. It is not. But because it keeps the muscle alive. It keeps me honest about what I actually know versus what I have been outsourcing.
If you are using AI agents every day at work — and in 2026, most of us are — ask yourself this: if someone took the agent away tomorrow, could you still do your job at the same level? If the answer is not a confident yes, you might want to rethink your workflow.
What is your experience with AI coding agents at work? Are you seeing the same patterns? Hit reply to the newsletter and let me know.