Field note / AI & Automation
Coding Agents Are Useful When You Stop Treating Them Like Autocomplete
Building this website with a coding agent changed the unit of delegation: a bounded engineering task, with repository context, checks and a reviewable result.
A surprisingly demanding instruction in the development of this website was: change this part, and keep the rest exactly as approved.
Writing another component was rarely the whole task. A revision might affect the homepage hierarchy, the About hero, article navigation or deployment preparation. Each arrived inside a repository with existing decisions, shared components, tests and a visual identity that had already been reviewed.
That made the work a useful case study for coding agents. The interesting capability was not completing a line of JavaScript. It was following a change through enough of the project to leave it in a coherent state.
I used Codex through iterative briefs and revisions. This is a reflection on that workflow, not a controlled productivity study. I have no defensible percentage for how much faster it made me, and a successful local build is not evidence that an agent understood every intention.
Delegate a loop with an ending
The unit of work that makes sense to me is a bounded engineering loop: inspect the relevant implementation, make the change, validate its behavior, review the diff and prepare the handoff. The boundaries are as important as the actions.
For example, replacing the About portrait should begin with the existing image component and asset pipeline. It should preserve the hero frame, alternative text requirements and responsive dimensions. It should end with the new image rendered at the intended sizes, without an unrelated rewrite of the About page.
A request to “improve the About page” leaves far more room for interpretation. Sometimes exploration is exactly what I want. Once the design is approved, however, broad interpretation becomes a liability. The task should say what is settled and what is open.
OpenAI’s Codex guidance recommends supplying relevant context and using durable repository instructions. That supports the general workflow. The specific boundaries still have to come from the project owner: documentation cannot decide which part of my site I consider finished.
Completion needs an observable condition. “The image was replaced” is weaker than “the replacement is visible in the existing hero on desktop and mobile, with no layout regression.”
Reading the repository is part of the work
There is a large difference between generating a plausible implementation and extending the one that already exists. This site has shared navigation, typed professional data, a publication gate and article layouts. Recreating any of those in a new component could look correct on one page while splitting the source of truth.
An agent therefore needs permission and time to inspect. Which data file owns the copy? Which layout produces the metadata? Does a helper already filter unpublished articles? Which commands represent the project’s normal verification path?
I want the answer expressed through the change itself. Reusing the existing helper is stronger evidence than a paragraph saying the agent “followed best practices.” If a new abstraction is necessary, its purpose should be visible in the diff.
This also changes how I give feedback. “The link is wrong” should lead to locating the shared navigation definition. A quick patch on the rendered page may solve the symptom while leaving the next page wrong. The useful agent follows the issue to its owner without expanding the task into a general cleanup campaign.
A small feature can carry a large infrastructure bill
The clearest example was the visitor counter. The earlier implementation included a small API, persistent storage and supporting deployment preparation. The final hosting decision was static shared hosting, so removing the visible number alone would have been an incomplete change.
The work had to follow the dependency chain: browser request, footer element, API integration, storage, service entrypoint, environment variables, tests and operating instructions. The counter’s removal was valuable because it removed the need for a production application service, not because it saved a few characters in the footer.
That is a task an agent can help carry across a repository. It is also a task where a convincing partial result is easy. The homepage can look correct while an obsolete startup command remains in the README or a deployment workflow still expects the old runtime.
I would assess the result at both levels. Does the product behave as intended? Does the repository now describe and support the same architecture? If the answers diverge, the task is not finished.
The hosting decision deserves its own discussion. Here, it illustrates why repository-wide understanding matters more than typing speed.
Plausible output needs a resistant environment
An agent can produce configuration that looks reasonable and fails under the actual tool. During preparation of this site’s static transfer process, a local FTPS test exposed a problem with directories that already existed. The configuration needed a correction even though the intended synchronization strategy sounded sensible.
That incident is a useful scale for trust. The agent did not need to be banned from writing deployment code. The code needed a test against the transfer behavior it relied on, before it was allowed near the production destination.
Different checks answer different questions. Type checking can find an invalid interface use. A build can reveal malformed content. A browser test can exercise navigation. A screenshot comparison can reveal an unintended visual change. A transport test can expose server behavior that none of the previous checks touches.
More checks are not automatically better. I want checks connected to a plausible failure. Repeating a successful test ten times is less useful than testing the boundary that has never been exercised.
The agent’s final summary should make that boundary visible. “Verified locally; provider access remains untested” is an actionable handoff. “Production-ready” without the conditions can conceal the very uncertainty I need to manage.
Review the omissions as well as the additions
When I review an agent-assisted change, I look for work that should have disappeared. Removed features often leave CSS selectors, environment variables, obsolete tests or instructions behind. Those remnants are easy to miss because the visible result still works.
I also look for additions that the request never required. A dependency may solve a small problem while adding an update obligation. A second navigation component may simplify the current edit while creating future inconsistency. A clever fallback may hide a real failure instead of making it diagnosable.
A useful review asks whether every changed file has a reason to be in the task. That does not mean the smallest diff is always correct. Removing the visitor backend required touching more files than hiding a number. The wider diff was justified by the architecture change.
What matters is the connection between the requested outcome and the scope of the implementation. The agent should be able to explain that connection in plain language, and the repository should support the explanation.
Keep authority separate from capability
An agent that can edit a workflow is not automatically authorized to publish a site, change DNS or contact someone. Those actions have different consequences from a local refactor. In this project, keeping the old hosting untouched while preparing a new destination is a concrete boundary.
I find it helpful to specify which actions are part of the task and which depend on external readiness. That reduces both unnecessary pauses and unsafe assumptions. The agent can continue writing, testing and documenting while a credential or provider activation remains unavailable.
This is one reason I think of the relationship as closer to supervising a fast junior engineer than issuing a magic prompt. The analogy is limited: a model does not have a colleague’s accountability or stable understanding. But the management habits transfer well. Give a clear outcome, provide access to the relevant context, expect evidence and review consequential decisions.
The owner still has to decide what the product should do. Delegating implementation does not delegate the meaning of success.
A better handoff than “done”
For a finished change, I want to know what behavior changed, what was checked, what remains uncertain and where I can inspect the result. A local URL, a focused commit and a clear limitation are often more useful than an elaborate account of every command executed.
The brief that produces this result is mostly project knowledge: approved decisions, constraints, sources of truth and validation expectations. I discuss that more directly in context engineering.
Autocomplete helps at the point where code is being written. A coding agent becomes useful across the surrounding work: discovering where a change belongs, carrying it through the repository and showing why it is safe enough to review. That is a larger delegation, and it deserves a clearer finish line.