I can now finish several coding tasks at once.
Some days, I cannot explain the code behind all of them.
That is the uncomfortable side of AI coding I have been thinking about lately.
Claude Code has made me much faster. It can explore a project, implement a feature, run tests, find problems, and fix them while I focus on something else.
With Agent view, I can dispatch multiple Claude Code sessions from one screen. Each session works on an independent task in the background, and I can see which ones are still working, waiting for input, or ready for review.
It is an incredibly productive way to work.
It has also made it easier than ever for me to stop paying attention to the code itself.
When three completed tasks become three black boxes
At my full-time job, I am currently working on two fairly large projects at the same time.
One is a migration from Webflow to Astro + Sanity.
The other is a completely new web app.
My company provides Claude for employees, so I use Claude Code for both projects. When I have several independent tasks, I often open Agent view and run multiple sessions in parallel.
One session might work on a component for the migration.
Another might implement a feature in the web app.
A third might investigate a bug or clean up an existing implementation.
Instead of completing those tasks one by one, I can dispatch all three and watch them progress from one screen.
When a session finishes, I usually check the result. I open the page, click through the feature, and make sure there are no obvious errors or bugs. If it works, I move on to the next task.
But I often do not carefully review the code.
I do not always read every changed file.
I do not always trace how the data moves through the application.
I do not always ask why Claude chose one implementation over another.
The feature works, the session is complete, and another task is already waiting.
That is the moment when productivity can turn into distance.
I have finished the task, but part of the implementation is now a black box to me.
Image source: Claude Code
Before AI, writing the code created understanding
Before AI coding agents became part of my workflow, I coded more or less like everyone else.
I opened the documentation.
I searched Stack Overflow and GitHub.
I looked for examples.
Then I wrote the code myself.
If something did not work, I debugged it. If I did not understand something, I researched it. The implementation was my responsibility, and the process of building it forced me to understand it.
I knew why a function existed because I had created it.
I remembered the alternatives I had rejected.
I knew where the awkward parts were because I had struggled with them.
Today, I probably write only around 2–5% of the code manually. The other 95–98% is written by AI.
I do not mean autocomplete. I mean giving Claude Code a task and letting it handle almost the entire implementation.
I review the result, request changes, and run another iteration. I use a more structured version of this in my workflow for turning AI conversations into plans, GitHub Issues, and isolated worktrees.
This is much faster than implementing everything myself.
But speed changes the kind of understanding I develop.
When I wrote every line, understanding was a side effect of the work. Now, understanding requires a separate, deliberate step—and that is the easiest step to skip when the result already works.
Working software is not the same as understood software
I can still read and understand AI-generated code.
The problem is that I do not always do it.
There is a strong temptation to treat working software as sufficient proof that the implementation is good. If the page renders, the interaction works, and there are no visible errors, the task feels finished.
But a quick functional check does not tell me everything.
It does not tell me whether the abstraction fits the rest of the project.
It does not tell me whether the code will be easy to change six months from now.
It does not tell me whether I could debug it without asking Claude first.
And it does not tell me whether I have learned anything from the implementation.
When something breaks, my first reaction is increasingly:
Claude, can you debug this?
Instead of opening the code and figuring it out myself.
That is useful, but it is also a warning. The application is still my responsibility, even when I am not the person writing most of it.
This shift has changed what I want from a code editor, because I spend more time reviewing, directing, and iterating than typing code myself.
The role feels less like writing software and more like supervising its production.
AI did not eliminate research
One part of the work I still do manually is research.
This is especially important with frameworks and libraries that change quickly. AI does not always have the latest information. Sometimes an answer was correct six months ago but is wrong for the version I am using today.
So I still open the official documentation.
I check the current version.
I read the migration guide.
I verify the API.
Sometimes I give that documentation back to Claude and tell it to use the current information.
That work matters because AI can write code based on a false assumption just as confidently as it can write code based on a correct one.
AI can implement the feature, but I still need enough knowledge to decide whether the implementation is built on the right foundation.
Parallel agents also consume parallel quota
My original frustration with Claude Code was the usage limit.
Claude’s allowance operates within a five-hour usage window. When I worked on one project with one session at a time, I rarely noticed it.
Agent view changed that equation.
Each background session consumes subscription quota independently. The official documentation warns that running ten agents in parallel can use quota roughly ten times as fast as running one.
I do not normally run ten, but even a few active sessions can consume my allowance much faster than a single interactive conversation. I can reach the limit roughly an hour into a busy period of parallel work.
Before AI, one of my biggest constraints was how quickly I could write code.
Now, sometimes the constraint is how quickly I can consume AI.
The better Claude becomes at implementing tasks, the more tempting it is to dispatch more work. The more work I dispatch, the less attention I give each implementation—and the more dependent my workflow becomes on having enough quota available.
More parallelism gives me more output, but not necessarily more understanding.
It also creates more context to manage, which is why I started saving useful session state instead of carrying entire AI conversations forward.
The hidden cost is cognitive distance
I still think AI coding is incredible.
I do not want to return to manually writing every piece of code. It would be hard to justify that after experiencing how much faster I can move with an agent.
But letting AI write almost everything is not free.
A 2025 Microsoft Research survey of 319 knowledge workers found that higher confidence in generative AI was associated with less critical thinking. AI also shifted effort toward verification and task stewardship.
The research was not specific to programming, but that shift describes my experience surprisingly well.
I spend less effort producing the implementation and more effort directing and verifying it. Agent view makes that shift visible: several sessions work while I monitor their status and step in when they need me.
The danger is not simply that AI might produce bad code.
The danger is that it can produce good-enough code so quickly that I stop building a mental model of my own application.
That can make me less familiar with the implementation, more dependent on AI for debugging, and less confident working without it.
It does not necessarily make me a worse developer.
But it changes what being a developer feels like.
I need a review habit, not just a working result
I do not think the answer is to stop using Agent view or force myself to write everything manually.
The better answer is to make understanding part of the definition of done.
I am trying to be more deliberate about a few things:
- Reading the diff before I consider an agent’s task complete.
- Tracing the important path through the implementation, not only testing the visible result.
- Asking Claude to explain decisions I would not have made myself.
- Debugging simple problems manually before handing them back to AI.
- Occasionally implementing something without an agent so writing code does not become an unfamiliar skill.
I will not do all of these perfectly for every task. Sometimes speed really is the priority.
But if I never slow down, I risk becoming someone who can ship a lot of software without feeling at home in any of it.
The question is no longer just:
Can AI write the code?
It clearly can.
The more interesting question is:
What happens to the developer when AI writes almost all of the code?
I am still figuring that out.
For now, I am happy to let AI do most of the implementation. I just do not want a green “Completed” status to become the only thing I understand about the result.
Because there is a difference between not needing to write code and not knowing how the code works.
And I do not want those two things to become the same.