Pedro Arantes

When these rules started working and my agents could code, review and merge on their own, the bottleneck became decisions. What waits now: which trade-off, which intent, which task to cut when the queue is full.

I prefer a different goal: keep speeding up your deliveries using agents, then find where the next bottleneck is.

I’m enjoying defining framing statements. A framing statement is a short instruction that changes how the model sees its situation instead of telling it what to do. It produces the right behaviour in cases nobody listed. Two things got me here. The first was Anthropic’s guidance: “This codebase is yours: what it’s for and how it’s built are your call, and you’ll keep building on it.” With that one sentence, the model cleaned up duplicated code in about half the tries, against under a tenth without it. The second was a prompt someone shared days ago: “Find all implicit state machines in my app.” Seven words, and the model reads your codebase through a lens you never spelled out. So I’ve started rewriting my agent instructions with more frames than rules.

For the first time, I'm using claude web and not claude. I want to stop thinking as a software engineering and start thinking in a manager of agents.

If the work keeps flowing, in the right order, checked by someone who did not write it, and closed only when it is seen working, you have a factory. The agents are the machines. The rules are the factory.

I disagree when the instructions carry years of experience only you have. A proprietary agent keeps the method on their side and delivers only the result. Think in a consulting firm that found a process nobody else in the world runs. To work with the client’s agent, that process has to ship as a prompt or skill the other agent can read, and their core becomes public the moment they hand it over.

I made my agents stop starting new work when my release queue is full. Then my own rule stopped everything. The release queue is everything between an implementation and a customer seeing it in prod: review, merge, validation, flag removal. Agents ship faster than I can review, and an unbounded queue only grows. Little’s Law: wait ≈ queue size ÷ processing rate. With 10 items in the queue and 2 cleared a day, every new PR waits 5 days. So I cap it. What bit me: validations I had scheduled for later (“check the logs on the 20th”) were counted on the release queue. The queue filled with items nobody could act on yet, and new work stopped for nothing. The fix: a scheduled validation enters the queue on its date only. It's optimum economic timing. I already chose when the check pays off, so blocking agents before that date buys nothing. A full queue needs a person to drain it. Here are some actions that one can do to decrease queue size: - cancel what no longer pays off - send it back upstream queues, where waiting is cheap - date it for when the check makes sense With agents, human attention is the critical queue. Cap it, and count only what’s really in it.

My agentic workflow never lets the two agents talk to each other, so there’s no debate to collapse into agreement. The reviewer runs in a fresh context, didn’t write the change and never fixes it. It leaves its verdict as a commit status on that exact head, with evidence for each finding. Any push makes that verdict stale and triggers a new review.

I want to share a problem in my agentic workflow. One of my agents was ready to start a task, but the graph said it had to wait for a refactor first, and that refactor didn’t change any behavior. The refactor was already in main, unit and smoke tests green. Its task stayed open anyway, waiting on a release, a version bump in another repo and a check against the real API. The blocks edge held the dependent task until the refactor closed, so it waited on a release that changed nothing for it. Someone had to remove the edge by hand. It exposed a hole in my rule: close tasks on observed results, confirmed in production. My first idea to solve was to let blocks release on merge. No. It would put a bad decision inside the graph, make it assume merges nobody verifies, and silently change the meaning of every edge already there. The real cause was the closing rule. Each project had one rule for every task: implementation, release, bump, real validation. In Reinertsen’s terms, that turns every task into one big batch: the slowest gate sets the pace for all of them. The new rule: a task closes on the evidence of what it promises. How I apply it: each project keeps a list of closing validations. Mine has three: - merged: PR and main pipelines green. For refactors, tests, CI, docs, agent instructions. - api: a call to the API right after deploy. For what a user sees through an operation. - logs: analytics events checked on a set date. For what no call can reach. Every ready brief names its validation before work starts, so edges point at the right node from day one. The payoff: 1. code-only changes close at merge, so the work behind them never sits idle 2. each release and real-world check is owned by the task that actually needs it 3. stuck work unblocks itself, with no manual edge removal

I’m pushing my teams toward this on purpose. As CTO, one of my jobs is getting each engineer to run more agents in parallel, for three reasons: - they build the muscle for context switching - they learn to spend their energy on the highest-leverage work - the faster we ship, the more bottlenecks show up, and we only fix the ones we can see The bigger shift is where their time goes. Code became a commodity, so I want them writing less of it and making more decisions.

I removed myself from code review. Every merge got safer. The problem: my agents open PRs faster than I can read them. Every PR waiting on me gathers conflicts, and a review done in a hurry checks less than it looks. Again, a review done in a hurry checks less than it looks. The principle: the author never verifies its own work. A separate agent reviewer judges the change, and the code host (GitHub in my case) enforces the verdict, so no agent can argue its way past it. How it runs: 1. When a PR’s checks pass, a scheduled job starts a fresh agent session to review it. That session did not write the change and is not allowed to fix it. 2. The verdict is a commit status, flow/review, on the exact commit it read. A new push needs a new verdict. 3. Branch protection requires "flow/review", and only the reviewer’s identity can set it. 4. With every gate green, the scheduler merges. 5. Findings send the PR back for one automatic round. If it fails again, it comes to me. 6. Every PR states how to undo it. If the pipeline breaks after the merge, the scheduler reverts first and fixes after. Agents cannot merge changes to the CI checks and to the agent instructions. A PR that waits two days for me collects two days of changes on main to conflict with. Reviewed in the next hourly run, it waits an hour. I’ve been using this rule for the last month and haven’t had any serious problems in my projects, mainly because a bad merge only lives until the next pipeline run.

I think if you opt to not review your code anymore, you must have observability to watch what you ship on production. That’s what I did with my agents. A task only closes when: - I see its effect in e2e tests - live validation works - production logs shows what I expect

My rules in building software with AI: 1. Keep all state outside the agent’s conversation. Store each task’s status, blockers, PRs and decisions in a shared record. If an agent did not write it there, treat it as not done. 2. Give each stage one owner. Only the owner of a stage may change a task’s status in that stage, so two agents never act on each other’s stale view. 3. Separate the author from the reviewer. Review every change in a fresh agent session that did not write it and is not allowed to fix it. 4. Close tasks on observed results. Have the implementer state what to check, where and when. A separate check confirms the effect in production before the task closes. 5. Cap the automatic fix attempts. After a set number of failed rounds, hand the change to a person. 6. Let reversibility set the agent’s freedom. Agents act alone on what can be undone and noticed in time. A person approves the rest. 7. Never let an agent guess an open decision. Record it as a question for the person who decides, and block only the work that depends on it. 8. Order the work by the cost of waiting, read from its stage. A broken main branch first, then urgent items, then high-priority bugs, then deploys nobody has verified, then due follow-ups, then open PRs, and new work last. 9. Limit the work in review and release. When that queue is full, agents stop starting new tasks and help finish the open ones. 10. Enforce merge rules in the code host. Use branch protection and required checks, and require a person’s approval for any change to the checks or the agent instructions. 11. Start every agent session from a schedule. A scheduled job wakes the agents, and each session reads the current state from scratch. 12. Write down why each rule exists. A rule you cannot justify with a principle is one to remove.

Yesterday, I finished the order my agents pick up work. New features come last. The main principle: Do first the job that is most expensive to leave waiting (cost of delay). The problem: agents start work faster than anyone can finish it. If they pick new features, half-done work queue increases and value doesn't reache users. The rule comes from Reinertsen: order work by cost of delay. My agents read it from the stage the work is in. Every tick works in this order: - main branch red: fix it first, it holds every change in the repo - anything a person marked very high - bugs marked high - merged work nobody has validated in production - waits that came due - open PRs: conflicts, fix rounds, reviews - new work A small example: main is red and 6 PRs wait on it. One repair frees these six changes. A new feature started in that hour frees nothing. The priority labels only order work inside a stage. A high-priority feature still waits behind an unmerged low-priority PR. Only “very high” jumps stages.

I tell clients they can build it themselves with AI. The question I ask back: do you want to spend your energy on architecture, security, tests and servers, or on your product and your customers? Whoever picks the second one will continue hiring a software engineer.

I want to present you my agentic workflow.

I tell them yes, they can. But they own the rest: - define the architecture - review security - maintain it - add observability - write tests - run the deploy and the servers If they’d rather spend their energy there than on the product, their customers and their brand, they should do it themselves with AI.

In naturali, you can attach a guardrail on agent's tools. The guardrail is a versioned rule document, and it sorts the call into four tiers: A: read-only, it runs B: runs only if its guard passes C: waits for a person to approve D: blocked, and the model is told so