Attention and feedback. That’s where the game is now.
Agents make mistakes. Tokens are expensive. But the biggest blocker to solving problems is still that we all need to sleep sometimes :D
Until (if?) AGI/ASI arrives and we trust our agents more than ourselves, our attention and judgment remain scarce. That’s what I want my workflows to protect while keeping agents busy.
The crucial distinction is interactive work vs. delegated work.
On your main machine, you want quick iteration: verify ideas, research, learn, try things. You shouldn’t have to wait for an agent to finish its delivery checklist before you can keep thinking.
Then delegate the work—with the tests, verification, adversarial reviews, fixes and rechecks—ON ANOTHER MACHINE.
Once the agents have done their thing and spent their tokens, bring the result back into the conversation. Inspect it, give feedback, decide what happens next.
But don’t turn this into a giant planning exercise. Software has taught us that lesson several times already. A plan starts changing as soon as you build something.
For a small change, it can be faster to make a simple plan, try it, see what failed and redo it.
For bigger unknowns, prototypes become GOAT.
I think parallel exploration is one of the most underused advantages of agents. Have a rough idea? Let four different models build four disposable prototypes. Compare the approaches, ask them to explain the tradeoffs, try the results yourself.
Learn quickly why they suck. Find what works. Then make a better plan—which will also miss things, so leave room for another round of feedback.
That’s where attention matters: choosing the next question, spotting a wrong direction, deciding whether the result is useful.
Funny how decades of software “best practices” become relevant all over again when the software starts writing itself.
Further reading
- (2001). Manifesto for Agile Software Development. agilemanifesto.org.The 2001 statement that values responding to change over following a plan.Open access · Checked 2026-09-13
- (1986). No Silver Bullet: Essence and Accidents of Software Engineering. Technical Report TR86-020, Department of Computer Science, University of North Carolina at Chapel Hill; revised in IEEE Computer 20(4), 1987.Brooks argues for rapid prototyping to refine requirements and for growing software incrementally instead of building it in one go.Open access · Checked 2026-09-13