Agents can write the code. The hard part is running it.

Sagar P — Mon, 12 Oct 2026 17:55:55 +0000

I have pasted agent-generated code straight into my terminal without reading it. More times than I want to admit.

Usually it’s fine. I build something most weeks and the loop is always the same. Describe what I want, let something write it, run it, find out what breaks.

The step I skip past every time is “run it.” On my own machine. With my project files sitting right there and my API keys loaded in the shell.

What that code can actually do

The generated script that reads a .csv and writes a summary is also a Python process with your user’s permissions. While it runs, it can:

Read any file your user can read, including .env, ~/.ssh, and your browser’s cookie store
Write or delete anywhere in your home directory
Open outbound network connections to anywhere
Pull packages at runtime, which means code you never saw gets executed too
Spin until it exhausts memory or disk

None of that requires malice. A model that hallucinates a path and a model that targets one produce the same rm. The failure mode you should plan for isn’t an attacker. It’s a confident wrong guess running with your credentials.

This mattered less when the loop had a human reviewing every line before execution. It matters a lot more when the agent is the one deciding to run it, in a loop, unattended.

The options people reach for

Run it locally and read it first. Works until the code is 200 lines, or the agent is running ten steps and you’re not watching step seven. Reviewing every line defeats the point of delegating.

Docker. Real isolation, and the right instinct. But you own the Dockerfile, the mounted volumes, the network mode, and the resource limits. Most people mount the project directory read-write and run with default networking, which gives back most of what they were trying to contain. It also doesn’t solve anything if the agent is the one generating the container config.

A throwaway VM. Good isolation, slow to start, annoying to wire into an agent loop that needs to execute something in under a second and read the result back.

A hosted sandbox. Execution happens somewhere that isn’t your filesystem, with boundaries set before the code arrives rather than configured per run.

What I’d want from one

Whatever you pick, the questions are the same:

What can the process read, and is my source tree in that set
Can it reach the network, and can I turn that off per run
What are the memory, CPU, and wall clock limits, and what happens when it hits them
What do I get back when it fails on step six of nine, and do I know it was step six
Are credentials scoped to the run, or is it inheriting my whole environment

That last one catches people. An agent given “the API key” usually gets the same key you use for everything, with the same scope, because that’s the key that was sitting in the environment.

Try this on Saturday

CreateOS is running a one-day hackathon on exactly this problem. Build an AI agent that writes its own code and executes it in a CreateOS Sandbox, with your stack set up through Stripe Projects.

Sat Oct 17, 12 to 7 PM PT, online on Discord. Solo or teams of up to 3, one person registers per team. $10,000 prize pool. Kickoff is a Stripe Projects walkthrough from the Stripe team, then a Sandbox brief from the CTO, @pratikbin. Demos and awards at 6 PM PT.

Spots are approved one by one, so apply early and say what you want to build.

👉 https://luma.com/6stm74wk

If you’re already running agent-generated code, where does it execute right now, and what would it reach if it went wrong?

Last week I watched a product demo that should have landed and didn't.

Sagar P — Tue, 29 Sep 2026 13:25:10 +0000

The feature was real. An agent that runs a multi-step workflow end to end, no human in the loop, proper retry handling. The engineer who built it was proud of it and had every reason to be.

Then a VP of Ops in the room asked one question. "Okay, so what does this replace on my team's plate on a Tuesday?"

Nobody answered. We had built the entire walkthrough around what the thing does instead of around her Tuesday.

Why this happens to engineers specifically

When you build something, you know it by its mechanism. You spent three weeks on the executor, so the executor is the interesting part. Parallel dispatch is interesting. The retry policy is interesting.

None of that is interesting to the person deciding whether to pay for it, and more importantly, none of it is interesting to the person who has to live with it.

The gap isn't a marketing problem that gets handed off later. It shows up in everything you write before marketing ever sees it.

Where it leaks into your own work

Changelog entries.

Before: Added support for multi-step agent execution with configurable retry policies.

After: Your agent can now finish a nine-step workflow without you watching it. If step four fails, it retries three times, then tells you which step broke instead of dying silently.

README opening line.

Before: A lightweight orchestration layer for autonomous agents.

After: Run agents that do the work while you sleep. You get a log of what they touched and a flag when they need you.

PR descriptions.

Before: Refactored the executor to support parallel task dispatch.

After: Workflows with independent steps now finish in about a third of the time. A ten-step run that took 90 seconds takes 30.

The second version in each pair contains the same information. It just leads with the consequence instead of the mechanism.

The test

Can someone who has never heard of AI agents read what you wrote and finish this sentence?

"This means I no longer have to ___"

If they can't, you've described a feature. Features are fine. They belong in the docs, under a header, where someone who already understands the problem goes looking for the mechanism.

But the first line of your README, the first slide of your demo, and the first sentence of your changelog are not for that person. They're for someone who has a Tuesday problem and no idea yet that you solve it.

What I'm still bad at

Writing feature-first copy is faster. It's also more flattering, because the mechanism is the part you're proud of.

I catch myself doing it constantly. The fix isn't a better instinct, it's running the test before I publish rather than after someone asks me the Tuesday question in a room full of people.

What's the last piece of AI or developer tooling copy you read that actually passed?

DEV Community: Sagar P

Agents can write the code. The hard part is running it.

Last week I watched a product demo that should have landed and didn't.