How Thorsten Ball Uses Amp, October 2026

Summary

Thorsten Ball describes how he uses Amp and coding agents in October 2026, arguing that AI has changed the economics and pace of software development. Building, debugging, prototyping, and iterating are cheaper and faster, so teams should reconsider established practices and account for how quickly models and tools are improving. He also argues that code quality problems are not automatically permanent: capable models can help find and fix poor code.

How He Works With Agents

• Prompt for outcomes, not implementation details. Give the agent a goal—such as speeding up a compiler, building an interface from screenshots, or adding workspace chat—rather than prescribing files and steps. Detailed context can still help, but manual context-management rituals and file mentions are less important than before.
• Use capable models for demanding work. Ball favors the latest strong model, reasoning that cheaper models may require repeated correction and ultimately cost more time and effort. He sees cheaper models as better suited to constrained tasks such as classification or routing.
• Dictate longer requests. Speaking through a microphone lets him explain what he wants in more detail, giving agents useful context.
• Use agents for mechanical writing, not personal communication. He is comfortable delegating documentation, incident reports, and routine answers, but prefers messages to colleagues to reflect his own thoughts.
• Automate follow-ups. Amp can schedule an agent to wake up later, check results, and report back—for example, by monitoring an error rate after a release. “Snooze until next message” keeps dormant tasks out of the sidebar.
• Work asynchronously. Rather than wait for agents or monitor many active windows, Ball starts tasks and reviews the results when convenient. For design or uncertain tasks, he asks for multiple alternatives—sometimes a page of options to compare—instead of repeatedly steering one attempt.

Reviewing Agent Work

Ball recommends reviewing the parts of a change that carry the most risk rather than treating every line equally. A central file or database migration deserves more scrutiny than a peripheral styling issue.

A key practice is asking the agent for “irrefutable proof” that a change works. Evidence can include:

• Test matrices, logs, and end-to-end results
• Screenshots and demo videos
• Builds and native-app or simulator testing
• Before-and-after behavior comparisons
• Profiling results for performance changes

This evidence changes the review process. Instead of assuming the code is broken, a reviewer can first assess whether the demonstrated behavior is correct, then examine the approach, risks, and maintainability. The talk includes examples of agents testing refactors, implementing queue ordering, checking macOS permissions, and profiling search performance.

Amp’s Development Setup and Team Practices

Ball says Amp is built predominantly with AI in a large TypeScript monorepo. He emphasizes a three-part system: agent, codebase, and process. An agent is most useful when it can understand the repository and participate in the team’s actual development and release workflow—not merely write code for a human to integrate.

• Make the codebase legible to agents. Amp uses AGENTS.md instruction files and skills to explain how to work with different areas and tools, including development servers, cloud monitoring, and BigQuery. Agents are given ways to inspect and verify the environment, which Ball says reduces guesswork and hallucination.
• Treat discussion threads as context. Amp threads can contain prior decisions and implementation details. Agents can search them to understand why code exists and avoid undoing earlier work.
• Use Orbs and Runners. Orbs are ephemeral remote machines associated with an agent and thread. They can install the tools needed for a task and scale down when idle. Runners let agents work with a developer’s local machine when needed, such as for testing macOS-specific behavior. The team shares and documents these capabilities so improvements to the agent environment benefit everyone.
• Give agents production visibility. With documented access to monitoring, logs, canaries, and other production information, agents can help investigate whether releases behave as expected. Some canaries use anonymized production cases for agent testing.
• Change the process, not just the coding tool. Ball says the team pushes directly to main and does not use pull requests. He argues that its testing, feature flags, monitoring, and ability to fix problems quickly make that process workable for them. Designers also prototype and contribute code with agents rather than relying on a separate Figma-to-implementation handoff.
• Connect bug reports and incident response to agents. Amp plugins can load diagnostic data from bug reports, interact with monitoring and logging systems, manage feature flags, and support customer follow-up. Ball describes an incident-response plugin that helps assess system health.

The team also tests whether its instructions work: it can launch fresh Orbs with varied prompts, observe whether agents use the intended tools, and revise the instructions based on the results.

Case Study: Orb Memory Issue

The talk ends with a bug report that Orbs were running out of memory. An agent investigated the report, logs, related reports, and production data; proposed a way to identify memory-heavy processes; and implemented the change behind a feature flag. It then deployed the change, created test Orbs that consumed memory, and checked the behavior in production. Ball reviewed the central code and observed the test results before proceeding.

He presents this as an example of agents carrying work across investigation, implementation, testing, deployment, and monitoring—with a human still approving important steps.

Main Speaker and Sources

• Thorsten Ball — primary speaker, describing his personal Amp workflow and his team’s development practices.
• Amp and its team’s tools and examples — including Amp, Orbs, Runners, plugins, agent instructions, and the bug-report and incident-response workflows shown in the talk.