I have a project that is (debatably, like any real-world system) well-structured and follows solid engineering practices. Clear separation of concerns, proper build pipeline, and strict rules around what should and shouldn’t be committed.
A new developer joins the project.
They are eager. Productive. And like many developers today, they have AI tools like Claude Code in their workflow.
At first, everything looks fine.
Code is being written fast. Features are landing quickly. The velocity looks great.
Then I start noticing something small — but important.
Version-controlled files begin including artifacts like:
storybook-static/- build outputs
- generated files that should never be committed
This is where things get interesting.
Because the system already defines what should and shouldn’t be tracked in Git. There are rules, .gitignore, and established conventions.
So the real question becomes:
Why wasn’t this the first thing caught before committing?
The shift I’ve noticed with AI-assisted development
From what I observe, tools like Claude Code, Copilot, or agent-based workflows change the development pattern:
Instead of:
write code → think → review → commit
It becomes:
ask AI → accept output → commit → move on
And if you're not careful, one subtle behavior emerges:
“It works, so I ship it.”
But “it works” is not the same as “it’s correct for the system.”
A real workflow gap
In my own experience using tools like Opencode, I noticed a pattern:
Once I ask it to commit, the next instruction often becomes:
just commit everything that changed
That is extremely powerful — but also dangerous.
Because it subtly removes a critical step:
human verification of what is actually being committed
And that’s exactly where things like build artifacts, debug files, or unintended changes slip in.
Not because the AI is wrong —
but because the human stopped reviewing deeply.
The real problem isn’t AI
AI is not the issue.
The issue is delegated responsibility without retained awareness.
When developers start trusting AI outputs blindly, the workflow shifts from engineering to execution:
- AI writes
- AI prepares commit
- AI suggests changes
- Human approves without deep inspection
That’s where subtle but serious mistakes start appearing in production systems.
What this teaches me
This experience reinforced a few important principles:
1. Review and re-review
Every commit matters — even if it was generated by AI.
2. Always be the second pair of eyes
AI can be the first author.
You must always be the reviewer.
3. You are still the engineer
AI gives you speed, not judgment.
You might now have “100 hands” to write code —
but that doesn’t mean you stop thinking.
If anything, you need to think more, not less.
The uncomfortable truth about “vibe coding”
This is also why many “vibe-coded” applications look fine at first — but slowly accumulate:
- security issues
- misconfigurations
- leaked build artifacts
- inconsistent architecture decisions
Not because developers are incapable.
But because:
they stop inspecting what they didn’t personally write.
Final thought
AI didn’t make development worse.
But it did change the failure mode:
From:
“I wrote bad code”
To:
“I didn’t review what was written”
And that is a much harder problem to notice — until it reaches production.
