Essay / AI & Automation
AI Coding Gets Better When You Make the Model Prove It
AI-assisted changes need inspectable evidence: repository context, meaningful tests, visual checks and diff review. Generation is the beginning of the workflow.
The least interesting part of an AI-assisted change is often the moment when code appears. The more useful questions arrive afterwards. Did the agent understand the existing implementation? Did it preserve the behavior that was already approved? Can another person inspect what changed and reproduce the checks?
In the work on this website, those questions matter more than whether a proposed component looks plausible in isolation. The repository already has content rules, accessibility conventions, publication boundaries and a deployment process. A useful change needs to fit that system.
The model should not merely answer. It should leave evidence that the answer works.
“Prove” here means provide appropriate engineering evidence, not establish mathematical certainty about an entire application. Tests, inspection and review all have limits. The point is to make those limits visible instead of replacing them with a confident completion message.
Repository inspection changes the task
A request to add an article may sound like a writing task. In a real repository, it also depends on a content schema, allowed topics, date rules, related-content behavior and generated search. A new page can look correct while bypassing one of those systems.
Before editing, I want the agent to find the existing source of truth. If article numbers already come from a shared helper, adding another counter in a new component is a regression disguised as progress. If the deployment guard rejects unknown output, a new public verification file needs a narrow, reviewed allowance rather than a disabled guard.
Repository inspection should produce useful findings, not a transcript of every file opened. Identify the files that own the behavior, the constraints that affect the change and any existing work that must be preserved. That gives the implementation a clear starting point.
The agent should also inspect the working tree. Uncommitted work may belong to the user or another task. A clean solution that erases unrelated changes is not a successful collaboration.
Acceptance criteria should describe observable results
“Make it functional” is a reasonable goal and a weak test specification. For a PDF reader, useful criteria include opening at page one, keeping the controls within a mobile viewport, recovering from a failed document request and leaving the original download available.
Those criteria guide both implementation and verification. They do not dictate every helper function. The model can choose an internal structure while remaining accountable for the behavior the user asked for.
It helps to state preservation requirements with equal precision. Existing article copy should remain unchanged. Canonical URLs should keep the public domain. A technical deployment hostname should not appear in generated content. These are observable constraints rather than a vague instruction to avoid breaking things.
For an established site, preserving an approved experience is productive work. A model does not need to invent a redesign to demonstrate initiative. Sometimes the best evidence of understanding is a small diff surrounded by explicit checks.
The agent needs permission boundaries it can recognize
Reading files, running local checks and changing a component are different from publishing a release or deleting remote files. An effective workflow makes that distinction explicit so the agent can move independently within its authorized scope.
For this project, publication follows the verified repository and deployment process. Credentials remain in the deployment system. The agent does not need to paste a password into source code to make progress, and a connectivity problem is not permission to remove certificate verification.
The same principle applies to unfamiliar tools. If an action is outside the request or depends on missing authorization, the agent should surface the exact boundary. If the action is already authorized and reversible, repeatedly asking for confirmation just makes collaboration harder.
These are workflow design choices, not special reasoning powers attributed to a particular model. They make the task easier to execute responsibly because the consequences of each step are clearer.
Tests need an independent question
An agent can generate an implementation and a test that repeat the same mistaken assumption. That combination produces a convincing demonstration of consistency, not necessarily correctness.
Start the test from the requested behavior or a known failure. If a future-dated article must remain private, give the test a future article and inspect the public outcome. Do not merely assert that the implementation’s chosen helper was called.
GitHub’s documentation explicitly notes that agentic and chat experiences can produce incorrect or insecure code and calls for review and testing. The important practical response is to give that review a concrete object: a diff, a failing example, a rendered page or an observed network request.
The testing essay develops this further. A generated test earns trust when it can distinguish the intended behavior from a plausible mistake, including mistakes the agent itself is likely to make.
Visual review answers a different class of questions
A build can pass while a mobile toolbar overflows. A button can exist while its label is unreadable. A page can contain all the requested words while the hierarchy becomes difficult to scan.
For changes to a visible interface, use the browser. Inspect relevant sizes, keyboard behavior and error states. Look at the actual output rather than relying only on DOM assertions that confirm an element exists.
Screenshots are evidence of appearance at a particular state and viewport. They do not prove that search works or that a worker loads from the production host. Conversely, a successful interaction test does not guarantee that the resulting layout feels coherent. The checks complement each other.
Verification should follow the risk of the change, not the tool that happened to generate it.
That can mean a short visual check for a small copy change, or a more extensive browser sequence for a stateful reader. Adding identical checks to every task is not the same as being careful.
Read the diff after the tests pass
Passing tests should make a diff easier to assess, not make it unnecessary to read. Look for unrelated edits, duplicated logic, changed defaults and configuration that weakens an existing boundary.
A dependency addition deserves a reason. A new library may be the right way to render PDFs safely and consistently. It still has a bundle, maintenance and update cost. The review should distinguish that justified addition from installing a framework to solve a small interaction already supported by the platform.
Generated code can also leave debris: unused styles, commented alternatives, temporary diagnostics or broad exception handling that hides an error. These are reviewable details. They should not be accepted merely because removing them feels less impressive than adding another feature.
For content changes, review the words with the same care. Correct frontmatter does not establish credible claims. Links should support the nearby assertion, personal experience should remain truthful, and a polished paragraph should not smuggle in an invented result.
An external failure needs an external explanation
A static deployment can pass every local check and still fail because the configured hostname reaches the wrong server. The useful response is to inspect connectivity and configuration, not rewrite the application until the failure disappears.
This site’s deployment work illustrates why status reports should separate local verification, remote upload and public HTTPS. Those are different observations. A successful transfer does not establish that the domain’s certificate and DNS are ready, while a public certificate problem does not necessarily mean the uploaded files are wrong.
A coding agent should report the evidence it has and the boundary it cannot cross. “The build passed; authentication succeeded; this path returned an error” is much more actionable than “deployment failed.” The former helps identify the next step without exposing credentials or making unsupported claims.
Leave a handoff that another person can use
The final result should include the changed behavior, relevant checks and remaining limitations. If something still depends on a provider or owner action, say exactly what it is. Avoid treating an untested step as complete because the implementation looks ready.
Durable decisions belong in the repository when the next task will need them. That includes how to replace a research PDF, how publication dates work and which command verifies the production artifact. A chat message alone is a poor substitute for nearby documentation.
The strongest AI coding workflow makes the model’s confidence almost incidental. The next maintainer can inspect the code, understand the constraints and rerun meaningful checks. Generation helped produce the change; the evidence is what makes the change usable.