OMAR
Field NotesCV
Autonomous Coding Agents: Where the Line Is
← All Notes
AI Engineering13 August 2026 · 3 min read

Autonomous Coding Agents: Where the Line Is

An agent that plans, edits, runs and iterates on its own is impressive. The engineering question is what it is allowed to touch while it does that.

Give an agent a task, a repository and a shell, and it will plan, edit files, run commands, read the failures and try again until the task is done or it gives up. Watching it work through a real bug is genuinely striking.

The interesting question is not whether it can. It is what the sandbox looks like while it does.

Run it in a box, always

The agent executes commands it wrote. That is the entire premise, and it is also the risk. Non-negotiables:

  • A container, not your machine. Filesystem access limited to the checkout.
  • A branch, never the default one. Its output is a pull request you review.
  • No production credentials in the environment. Not the database URL, not the deploy token, not the cloud keys.
  • Network egress restricted to what it needs — the package registry and nothing else, unless the task requires more.

None of this assumes malice. It assumes a confidently wrong command, which is a thing every agent does eventually.

Task shape decides the outcome

Works well:

  • "The test suite has four failures on this branch. Fix them."
  • "Add pagination to this endpoint, matching how the other list endpoints do it."
  • "Upgrade this dependency across the monorepo and fix the resulting type errors."

Verifiable, bounded, with an existing pattern to copy.

Works badly:

  • "Improve the performance of the app."
  • "Refactor this module to be cleaner."
  • "Build the admin dashboard."

No success condition, so it never knows when to stop, and you get a large diff shaped by its judgement rather than yours.

Review is not optional and does not scale down

A four-hundred-line diff from an agent needs the same review as a four-hundred-line diff from a person. In practice it needs more, because the code is uniformly plausible — it looks right everywhere, including where it is wrong. Skimming for style tells you nothing.

If the diff is too large to review honestly, that is a signal the task was too broad, not a reason to trust it.

Where I have found it worth it

Mechanical migrations, test-driven fixes, and exploratory spikes I would otherwise not have time for — "try this approach on a branch and show me whether it works". The last one is underrated: a cheap way to get a real answer to a "would this work" question instead of a hypothetical.

What I do not do is treat it as a developer that needs no supervision. The code is your code the moment you merge it.

Resources

AIAutomationOpen Source

Need this built properly?

I build secure, fast, bilingual platforms for clients across Egypt, Saudi Arabia, the UAE and Kuwait.

Keep Reading