Thorsten Ball describes his agent workflow as of October 2026. He works on Amp, and some recommendations depend on its features. His central demand is concrete: give agents the means to complete a task and require evidence that the result works.

Specify outcomes and make the work observable

  • Describe what success looks like. Ball prefers goals over implementation instructions. His example asks an agent to make a compiler and virtual machine twice as fast.
  • Expose the whole software development lifecycle. Let agents run the product, inspect production logs, follow deployments, and investigate bugs. He describes custom tools for health checks, bug reports, customer email, and feature flags.
  • Use stronger models. He argues that cheaper models can cost more through repeated attempts and uncertainty about their mistakes.

Build ways to test alternatives

  • Ask for an iteration tool. Instead of repeatedly adjusting one result in chat, request twenty variations and a page for comparing them. For debugging, ask for four explanations and tests of each.
  • Demand evidence. Ball asks for end-to-end walkthroughs, demo videos, and before-and-after measurements. An agent saying it finished is a weaker deliverable than an observable result.
  • Test the instructions, too. Compare blind agents with and without particular documentation, skills, or scripts. Writing an AGENTS.md file does not show that agents use it effectively.

Delegate asynchronously, with isolated environments

Ball prefers larger batches of work over waiting through every exchange. He recommends scheduled checks and follow-ups, such as revisiting logs after two hours. Separate remote environments help agents install dependencies and run complete tests without competing for local resources.

He also favors one conversation per task and automatic context compaction, which summarizes older conversation material. In Amp, he treats conversations linked to commits as a searchable record of decisions and previous work.

Review according to the consequences of failure

Ball concentrates his own code review on central files and database migrations. He cares more about working behavior, architectural understanding, end-to-end tests, and future changeability than stylistic choices or duplication.

He is also less worried about accumulating generated code than he was six months earlier. That is a judgment about his tools and codebase, not a measured result about long-term maintenance. He keeps a separate boundary around writing for people, making exceptions for mechanical material such as debugging instructions and incident reports.

Caveat: this is a practitioner’s workflow, not a controlled comparison. Tool access does not remove hallucinations, and convincing demos can miss failures.

A practical version of the workflow pairs visible evidence with independent checks. Access to logs need not grant deployment authority, and permission to investigate a bug need not include emailing a customer. Review can follow risk only when tests and permissions support that choice.