We Don’t Code Anymore #
Since late 2025, many developers around the world have discovered that the quality of the code generated by AI models has increased significantly. They have started getting comfortable giving instructions to the coding agents & letting them do the actual coding part. Many people I’ve talked to (friends, colleagues, and others I meet at tech events) have told me the same, that they haven’t written code by hand since they’ve discovered how good these models have become.
But somewhere in that hype, not writing code by hand got mixed up with not looking at code.
Personal Projects #
It is true for me when it comes to my personal projects. I don’t write code by hand, nor do I look at the code. I focus mainly on two things:
- UI/UX - because the default designs by the models have that strong AI smell that makes me dismiss the product right away.
- Cloud setup - I have a lot of experience with AWS, so during the planning stage, I tell the agent which services to use (mostly serverless) and for what purpose.
Production Code #
But when I work with production code, I make that distinction explicit. Here’s my usual approach:
- I gather every minute detail of the requirement . I try to fully understand exactly what the requirement is, what the scope of it is, and why it is being done. This is crucial because I want to make sure the agent gets all the context it needs to do the changes. I think, telling the agent why a change is being made will result in better output than just telling it what to do.
- I make sure I tell it to ask me questions if anything is unclear or ambiguous . The newer models tend to be more proactive and wanting to just get the task done. I find that adding this instruction makes it to clarify rather than assume incorrectly.
- I read its commentary of what it is doing to catch the incorrect assumptions it is making and steer it regularly . The model can still make a few incorrect assumptions despite being instructed to clarify, so I make sure to read the commentary and when I catch one, I send another message to steer it in the right direction.
- I spend a lot of time questioning the diff . I usually want the cleanest and smallest possible change that works for any requirement. And a lot of times, questioning a change will result in the model realizing that it “overengineered” and edits it to make a more minimal change. I have also been using the/show-me skill more recently to understand larger diffs.
I do all of these in an attempt to get as close to having the same mental model about the code as I would have if I wrote the code myself.
Being a Responsible Human #
The reason I do things differently at work is because my role becomes important especially when things go wrong.
Coding agents are not nearly as good at diagnosing and fixing bugs as they are at implementing a change. Things like Cursor’s debug mode come close but aren’t there yet. This is mainly a context problem.
- They usually have an incomplete operational picture. Your production environment is going to be very different from your local setup (deployment environment, networking setup, different environment variable values, serving traffic, other connected services etc.)
- In an attempt to quickly fix things, most people tend to only tell the agent what is not working (the incorrect behavior observed, like a QA would).
- With only the codebase and logs, the agents tend to come up with an overfitting solution.
- That results in multiple deployments, each one with a “hopeful” fix or an attempt to rule out a possible cause.
When things break in production, a proper fix requires that I understand what actually broke. It is my responsibility to understand the system well enough to identify where it broke.
Don’t Be A Meat Proxy #
I call this “Being a responsible human in the loop”. You may not write the code by hand but you understand it enough to investigate and fix it when it fails. It is how I think we should leverage AI instead of becoming a meat proxy.