The first time an AI coding agent hands you a working tool, it feels like cheating.

You described the thing you wanted. It created files, installed packages, wrote functions, fixed errors, and gave you something that actually runs. A few years ago, that gap between “I want this” and “I built this” was where the whole project died.

Now the code exists. The uncomfortable part starts after that: can you tell whether it is right?

I keep coming back to this because I cannot code in the way developers mean it. I can read around code. I can usually understand the shape of what is happening. I can debug with help. I can ask decent questions.

But I cannot honestly pretend that “read the diff” is my main quality-control process.

A lot of AI coding advice assumes the human at the end of the loop is a developer reviewing a pull request. For people like me, that is the wrong safety net.

The old barrier was code⌗

For me, AI mostly killed the syntax wall.

If you can describe a small tool clearly enough, a coding agent can often build a useful version of it. Scripts, dashboards, scrapers, data cleanup tools, internal workflows, little utilities that save an hour here and there. I use this stuff constantly.

The same pattern shows up across professional software work. OpenAI says more than 85% of its own company uses Codex every week. Anthropic says users are handing off difficult coding work that previously needed close supervision. A 2026 research dataset called AIDev includes 932,791 agent-authored pull requests across 116,211 GitHub repositories.

My own problem shows up after the first working version: I can get past the blank-file stage and still have no good reason to trust the output.

A script that crashes is annoying. A script that confidently produces wrong data is expensive. A tool that fails to launch is easy to reject. A tool that works in the demo and corrupts your assumptions quietly is harder to spot.

The tools are built for supervision⌗

The product design tells you what role the human is supposed to play.

OpenAI’s Codex app, announced in February 2026, goes well past editor autocomplete. It is a command center for multiple coding agents: separate threads, built-in worktrees, diff review, editor handoff, skills, and automations.

OpenAI described the developer challenge as a shift from what agents can do to how people direct, supervise, and collaborate with them at scale.

Then in May, OpenAI added Codex remote access from the ChatGPT mobile app. You can start or continue threads, answer questions, change direction, approve actions, review findings, and move across connected hosts from your phone. The host Mac has to stay awake, online, and running Codex.

Anthropic is describing the same operating model from another angle. Claude Code’s best practices are basically management advice:

  • Let it explore the repo before it edits.
  • Make it plan before it starts changing files.
  • Give it tests, screenshots, or expected outputs.
  • Watch the context window because performance degrades as it fills.
  • Use separate agents for investigation and review.

For a non-developer, the useful instruction in that list is “give it tests, screenshots, or expected outputs.” When code judgment is unreliable, behavior becomes the test.

Better models make bad trust easier⌗

OpenAI announced GPT-5.5 in April 2026 and positioned it as especially strong in agentic coding, computer use, knowledge work, and scientific research. The company reports 82.7% on Terminal-Bench 2.0, 58.6% on SWE-Bench Pro, and 73.1% on its internal Expert-SWE benchmark.

Anthropic announced Claude Opus 4.7 around the same time, describing it as better at difficult software engineering tasks and long-running coding work. Anthropic says the model follows instructions closely and devises ways to verify its own outputs before reporting back.

As the tools improve, the output gets easier to trust for the wrong reasons.

A bad coding agent fails in ways you can see. It errors out. It cannot install the package. It loops on the same mistake. It gives you nonsense.

A good coding agent fails in ways that look professional. It creates clean files. It explains itself well. It runs a test. It tells you the implementation is complete. It gives you enough polish to make you feel like the remaining risk is low.

Sometimes the remaining risk is low. Sometimes the output is wrong in the one place that matters.

A developer might catch that in the diff. My process has to force the truth out through observable behavior.

Task shape matters⌗

The pull request data backs this up in a useful way.

A later analysis of 7,156 PRs from the AIDev dataset found that acceptance depends heavily on task type. Documentation tasks were accepted 82.1% of the time. New features were accepted 66.1% of the time. OpenAI Codex ranged from 59.6% to 88.6% across nine task categories. No single tool dominated every category.

Bounded work is easier to verify. Documentation has a visible output. A bug fix with a reproduction step has a binary result: the case passes or fails. A data script can be tested against a known input and known output.

Feature work is fuzzier. The requirement is incomplete. The edge cases live in someone’s head. The “right” answer depends on product judgment, customer context, and weird assumptions no model can infer from a vague prompt.

This is why “build me a dashboard” is risky and “take this CSV, group rows by month, output a table with these five columns, and match this sample result” is much safer.

The agent can write code either way. The second task gives you something you can check.

Design verification first⌗

Developers may hit a code-review bottleneck. My own bottleneck comes earlier: I have to design verification I can understand.

In practice, I turn the job into checks I can evaluate myself. I start with a tiny sample dataset whose answer I already know and write down the expected result before the agent builds anything. For a web tool, I click through the actual workflow. For a script that changes data, I run it against a copy and compare counts, totals, and samples. Bad input should produce a visible failure. Plausible nonsense is the dangerous outcome.

I also ask for a plain-English explanation, get a second model to look for missing tests and edge cases, and keep the work isolated with a rollback path.

Behavior stays visible even when elegance is beyond my judgment. I can check whether the output matches a known result, whether the tool handles empty files, whether the totals reconcile, and whether running the command twice duplicates data.

My workflow follows that logic. Define the job, make a tiny test case, write down the expected result, ask the agent to explain its plan, and have it build the smallest useful version. Run the normal case, try one ugly edge case, and ask another model to review the approach. Real data comes last.

That takes longer up front. The extra minutes buy small pieces of personal infrastructure that I can trust after the chat window closes.

Deterministic code still matters here. If the agent helps you write a script that calculates something the same way every time, great. Let code handle it. Keep verification outside the model’s vibes: known input, known output, repeatable command, visible result.

Leverage still requires ownership⌗

AI coding agents are a huge deal for technical-adjacent people. They let you build things that used to be blocked by syntax, framework knowledge, and setup pain.

Easy access to agents makes the competence gap easy to miss; supervising them still takes actual work.

The dangerous move is letting the agent’s confidence substitute for your own verification. When the diff is beyond your depth, say that plainly and build a process around it. Skip the code-review cosplay. Keep important changes out of production until the behavior holds up under checks you understand.

Use agents where the downside is limited, the output is visible, and the result can be checked. Start with tools that chew through copied data, generate reports, clean files, or automate annoying local workflows. Avoid giving a model write access to anything you cannot restore.

Define what “done” looks like before the code exists. The agent becomes useful when that outcome is clear; vague requirements let better code generation carry you to false confidence faster.