A year ago I treated AI coding assistants as fancy autocomplete. Today an agent runs my test suite, triages production exceptions, drafts the fix, and opens the pull request — and my job has shifted from writing every line to reviewing and directing. Here is what I have learned about making that shift productive rather than chaotic.
What a day actually looks like
A concrete morning, recently: a Sentry alert fires overnight for a 500 error in an admin screen. Before my first coffee, I paste the issue link into the agent and ask it to investigate. It reads the stack trace, finds the controller, notices an unchecked save followed by a path helper called with a nil id — a pattern it has seen in this codebase before, because our recurring bug patterns are written down in the project instructions. It drafts the fix, adds a regression spec, runs the suite, and presents a diff. I read the diff, tighten one error message, and merge. Elapsed time: maybe twelve minutes, most of it my reading.
That is the honest shape of the change: not “the AI writes my code,” but the mechanical middle of the work — locate, reproduce, draft, verify — compressing to near zero, leaving the judgment calls to me.
What agents are genuinely good at
- Mechanical changes at scale. Renames, API migrations, applying a lint rule across a hundred files. The agent does in minutes what used to be an afternoon of careful tedium.
- First drafts of well-specified work. If I can describe the change precisely — inputs, outputs, edge cases — the draft is usually 80–90% right.
- Reading unfamiliar code. “Explain how authentication flows through this app” is answered faster and often better than by a teammate.
- Triage. Given a stack trace and repository access, an agent will usually find the failing line, the commit that introduced it, and a plausible root cause before I have finished reading the alert.
Where they still fail
- Under-specified product decisions. An agent will happily invent behaviour where the requirements are silent — and it invents confidently.
- Long chains of implicit context. Conventions that live in your team’s heads, not in the repo, get violated.
- Knowing when to stop. Left unattended, an agent can “fix” its way into a much larger change than you wanted.
The failures share a root cause: the agent optimises for a plausible-looking completed task, and plausibility is not correctness. Which is why the habits matter more than the tool.
The habits that matter
The single biggest lever is writing things down where the agent can see them: conventions in a project instructions file, recurring bug patterns, deploy procedures, the reasons behind non-obvious decisions. Every piece of tribal knowledge you externalise turns a class of agent mistakes into a class of agent competencies. As a side effect, your documentation gets better for the humans too.
The second lever is review discipline. I review agent code the way I review a fast, eager junior engineer’s code: assume the happy path works, and go hunting for the unhappy ones — nil inputs, empty collections, concurrent writes, the branch the tests don’t cover. An agent’s diff always looks clean; that is exactly why the review must be adversarial.
The third is scoping. Small, well-bounded tasks succeed; “improve the performance of the app” produces a sprawling change you will be afraid to merge. I have learned to hand the agent the same size of task I would hand a new team member in their first month.
Practical cautions
Two boring but important notes. First, cost: agent workflows consume far more tokens than chat, so watch the bill for the first month and learn which tasks are worth automating. Second, secrets: an agent with shell access can read what your shell can read. Keep production credentials out of the repository and out of the environment you let the agent loose in.
The tools will keep improving. The habits, I suspect, will transfer.