I use Claude Code almost every day while building Zenovay.
It can scaffold a feature, trace a bug across several files, write tests, refactor an old module, and explain an unfamiliar part of the codebase before I have finished my coffee.
That sounds like pure leverage.
But it created a problem I did not expect:
AI can produce code much faster than I can build a reliable mental model of it.
The bottleneck is no longer writing code.
It is human attention.
A large diff still feels like progress
There is something satisfying about watching an agent work through a task.
Files change. Tests appear. Type errors disappear. The terminal keeps moving.
Twenty minutes later, there is a 700-line diff and everything is green.
It feels like a productive session.
Then I open the diff and realize I cannot confidently explain every decision it made.
Why was this abstraction added?
Does this retry create duplicate events?
Is the permission check happening at the API boundary, or only in the interface?
What happens when the webhook arrives twice?
Did the code preserve the privacy rule I described three prompts ago?
The dangerous output is rarely code that obviously fails.
It is code that compiles, passes the happy-path test, and quietly implements the wrong assumption.
Generation got cheap. Review did not.
Before coding agents, the effort required to write a feature naturally limited its size.
You had time to think while typing. You noticed awkward interfaces because you had to use them repeatedly. You remembered why a branch existed because you wrote it ten minutes earlier.
AI removes much of that friction.
That is useful, but the friction was also doing hidden work.
It slowed the amount of new code entering the system.
Now a solo developer can generate changes at something close to team velocity. The review capacity is still one person.
That creates a kind of review debt.
Every accepted line that I do not fully understand becomes a small future obligation. Maybe it is harmless. Maybe it becomes the function nobody wants to touch six months later because nobody remembers why it works.
The code was generated quickly.
The understanding was deferred.
Some decisions should stay slow
While building an analytics product, small technical decisions can carry real consequences.
A mistake in attribution can show a customer the wrong acquisition channel.
A mistake in session replay can capture something that should have been masked.
A mistake in billing logic can affect real money.
A mistake in authorization can expose one customer’s data to another.
I still use AI around all of these areas, but I do not let it silently decide the important boundaries.
There are a few things I now treat differently:
Data and privacy boundaries
The agent can help implement the rule.
The rule itself has to come from me.
I want to know exactly what enters the system, where it is transformed, how long it stays, and what must never be stored.
Authorization and billing
A plausible-looking permission check is not enough.
For auth, subscriptions, invoices, refunds, and webhooks, I review the full path instead of only the changed function.
Database migrations
AI is very good at generating a migration that looks correct.
It is less aware of the strange data already living in production, the old client still sending a deprecated field, or the rollback you will need at 2 AM.
Product assumptions
An agent will happily turn an unclear requirement into working code.
That does not make the requirement correct.
When the model fills in a missing product decision, it often chooses the most conventional answer. Conventional is not always what your product needs.
My workflow changed
I used to prompt for an implementation and review the result.
Now I separate thinking from writing.
First, I ask for the proposed approach, affected files, assumptions, failure cases, and the parts of the task that are still ambiguous.
Only then do I let it edit.
I also try to keep each change small enough that I can review it without scrolling through an entire afternoon of generated code.
For critical paths, I ask the agent to attack its own solution:
- Where can this fail silently?
- Which input breaks the current assumption?
- What happens during retries?
- What happens when two requests arrive at the same time?
- Which authorization check is missing?
- What data could be stored accidentally?
This catches useful issues, but it does not transfer responsibility to the model.
Tests do not do that either.
A test suite proves that the cases we thought about behave as expected. It says nothing about the cases nobody considered.
At the end, I ask myself one simple question:
Could I explain this change to another developer without mentioning the AI?
If the answer is no, I am not ready to merge it.
AI did not remove the need for engineering judgment
Coding agents are probably the biggest productivity improvement in my workflow.
I am not going back.
But I no longer measure a good AI session by the number of files changed or how quickly the task reached a green checkmark.
The useful metric is how much verified progress entered the codebase.
That is usually less impressive than the generated diff.
It is also much more valuable.
AI can help write the code.
It can suggest tests, point out risks, and challenge an implementation.
But once that code reaches production, the model is not maintaining the promise behind it.
I am.
How are you handling this in your own workflow?
Do you review every line of AI-generated code, or are there areas where you deliberately trust it more?
Disclosure: I use AI heavily while building Zenovay and used it to help structure and edit this post. The opinions, examples, and final decisions are my own.
답글 남기기