Sunday, May 24, 2026 · 9:41 AM
ok i keep hearing “use coding agents for bigger tasks” and my whole body rejects it
fair. tiny tasks feel safer.
because the alternative sounds like “please produce one giant cursed PR while i make lunch”
that is the bad version.
the good version is more like a little production line. somebody plans, somebody implements, somebody checks the work, somebody kicks the tires.
so not one agent free-soloing my repo
but the pitch is still “scope bigger,” right?
yeah, but bigger means bigger project, not vaguer prompt.
instead of ten tiny errands, you give one long-running implementer a real workstream.
real workstream as in days?
days, sometimes weeks. but only if it has a task list it keeps coming back to, and the context doesn’t fully reset every morning.
compaction is where the agent forgets everything and becomes a different intern
that used to be the fear.
the claim now is it preserves enough repo conventions and decisions that you stop re-teaching the project every morning.
so the implementer stays on the factory floor
right. the task list is the line.
each task has three things: what to do, how to verify it, and what proof to leave behind.
tests, screenshots, command output, files changed, edge-case notes. whatever would let a reviewer trust but verify.
so my job is still annoying
yes, but it changes shape.
you write plans an agent can finish and prove, instead of babysitting terminals.
what stops it from making garbage and writing a beautiful little victory memo
fresh adversarial review.
a read-only subagent checks the diff against the plan before anything counts as done.
yep. did the diff satisfy the plan? did verification actually happen? did unrelated stuff sneak in?
that is the first part that makes the big-task idea less horrifying
yeah. the same agent doesn’t have to both fall in love with the solution and grade it.
who else is on this production line?
start with three roles: planner, implementer, adversarial reviewer.
add black-box tester, issue triager, or deep code reviewer only when the work actually needs them.
thank you. i was about to invent a tiny bureaucracy
that’s the trap.
some meta-work is worth it: better instructions, better tests, a proof format you can scan fast.
it is bad when it creates ceremonies nobody wants to maintain.
what should i stop doing first?
stop being the default operator: manual PRs, terminal poking, CI refreshing.
agents should produce proof. humans should judge the proof.
give me the smallest non-cult version
pick one annoying bug cluster or feature slice.
write a plan with expected behavior and end-to-end verification. let an implementer do one slice and leave proof notes. then send a fresh reviewer to attack it.
and if that saves attention instead of creating work, expand the line
exactly. don’t build the whole factory first. run one small line and fix the jam points.
Read Sun, May 24 · 10:03 AM