I gave an AI agent shell access. Here's what I learned.
A week of running an autonomous coding agent on a real project taught me where the ceiling is — and it isn't intelligence.
By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer
For one week I let an AI coding agent work directly in a project repository — reading files, editing code, running builds. I wanted to find where the ceiling actually is, not where the demos say it is.
The ceiling is not intelligence. The agent reads code well, reasons about architecture decently, and writes competent implementations. The ceiling is verification. Without a fast, trustworthy way to check its own work, the agent drifts: it fixes one thing, breaks a subtle other thing, and reports success because nothing told it otherwise.
The three things that changed everything
- a test suite that runs in seconds — slow feedback kills autonomous work
- a small, enforced scope per session — "fix the pagination bug", never "improve the app"
- a hard rule that git state is sacred — branches for everything, no direct pushes
What I would still never do
Let an agent touch production data, deploy on its own, or run with secrets it doesn't need. Autonomy in software should be proportional to how cheaply you can reverse a decision. Reversible? Go wild. Irreversible? Keep the human in the loop, permanently.
Agents are best understood as very fast interns with no memory of yesterday. Managed that way, they're excellent.
Keep reading
- AI
The model is not the product
Everyone debates which model is smartest. Almost nobody talks about the ninety other things standing between a prompt and a shipped feature.
- AI
My AI workflow is boring, and that's the point
No autonomous agents rewriting my codebase. No prompt wizards. Just a disciplined loop between a draft, a review, and a test suite.
- AI
Prompting is just requirements gathering with worse vocabulary
The teams that get good results from AI aren't better at talking to models. They're better at saying what they want.