Watching an agent turn a prompt into a pile of code is still a little magical. It is also the least interesting part once you try to use agents for real work.
The hard question is not “can it write this function?” It usually can. The question is whether it can understand the job, make a sensible change inside an existing codebase, prove that the change works, and leave the repository in a state that another human—or agent—can pick up.
Good context beats a heroic prompt
I get better results when the repository explains itself: small architecture notes, useful commands, clear ownership boundaries, and examples of the patterns already in use. A giant one-off prompt can compensate for missing context, but only once. Good project context keeps paying rent.
Boundaries make agents more capable
“Do whatever you think is best” sounds freeing, but it quietly hands the agent a huge decision tree. A clear scope, a definition of done, and a few explicit non-goals let it spend more effort on the engineering instead of guessing what I meant.
The checks are part of the product
An agent that writes code but cannot run the test, inspect the failure, and try again is a very fast autocomplete. The useful loop is change, verify, observe, correct. Tests, linters, builds, and small commits are not chores around agentic coding; they are the rails that make it work.
I am still experimenting with the right harnesses. That is probably why I enjoy this space so much: the model matters, but the system around the model is where engineering taste shows up.