WORKING WITH AGENTS — VIDEO TRANSCRIPT

Based on “How I work with Agents” by Thorsten Ball (October 25, 2026).
Source: https://x.com/thorstenball/status/2114386050638336082

Independent teaching adaptation. Examples and safety notes are instructional additions.
AI-generated narration and graphics.

[00:00] Work with agents. Not autocomplete.

How do you get useful work from a coding agent, instead of just more code? Thorsten Ball's October twenty twenty-six article offers fifteen principles, grounded in his own experience.
The central shift is to delegate an outcome, give the agent contact with the real system, and require evidence that it succeeded.
We'll turn each principle into a practical habit. These are Ball's opinions, not universal laws. The examples in this lesson are illustrative.

[00:27] Start with a capable model.

First, Ball argues for using the latest and most capable models. His concern is hidden unreliability: you don't know which answers are wrong.
A lower price per attempt may not mean lower total cost if you spend the savings on retries and supervision.
Apply this by comparing models on representative work, including how much human correction each result needs.

[00:50] Don’t assume “slop” wins.

Second, stop assuming agent-generated code inevitably becomes an unmaintainable mess. Ball is skeptical of that prediction, given how models have improved.
That's a personal judgment, not proof that every generated change is good. Don't turn it into permission to ignore defects.
Ask whether the result works, whether you understand its design, and whether you can change it later.

[01:13] Prompt the what. Not the how.

Third, prompt the what, not the how. Instead of prescribing a cache, describe the slow experience you want to improve.
For example: halve response time on this workload, preserve the returned data, and show before and after measurements.
You still specify constraints, such as no public API changes. The agent chooses the implementation, not the definition of success.

[01:37] Make the whole lifecycle visible.

Fourth, make the entire software development lifecycle legible to the agent. Ball credits tool calls with letting agents touch reality instead of inventing it.
Let it run the application, inspect logs, understand releases, and follow bugs through to their user impact.
A safe implementation separates visibility from authority. Access to deployment information does not automatically mean permission to deploy.

[02:02] Give it tools for the job.

Fifth, give the agent tools for that lifecycle. Ball describes custom plugins for bug reports, system health, customer email, and feature flags.
The practical lesson is to expose the operations the job actually requires, rather than describing a system the agent cannot reach.
For your own tools, scope permissions and preserve approval gates for consequential actions. That's an implementation safeguard, not a claim from the article.

[02:29] Test whether knowledge helps.

Sixth, evaluate agentic knowledge. Adding an instruction file or skill doesn't establish that agents use it, or that it helps.
Run blind agents on comparable tasks, with and without the guidance. Keep the task and evaluation criteria consistent.
Compare observable outcomes, not whether an agent says it read the document. Ball's suggestion is to experiment rather than assume.

[02:54] Give each agent room to run.

Seventh, local development can become awkward when several agents need to install dependencies and test applications end to end.
Ball prefers remote machines where each agent can run what it needs without competing for the same local resources.
In practice, isolation should include test databases and services, not just separate source folders. Otherwise the collisions simply move elsewhere.

[03:18] Build tools for iteration.

Eighth, don't iterate with the agent one tiny step at a time. Let it build tools that make iteration cheap.
For design work, request twenty variations and a page where you can compare and combine them, rather than twenty separate conversations.
For debugging, ask for four explanations of the slowdown and experiments that test each one. Explore the problem as well as the solutions.

[03:42] Ask for proof. Not reassurance.

Ninth, ask for irrefutable proof. Ball calls this a major improvement in how he works with agents.
Request an end-to-end walkthrough, a demo video, or before and after numbers from the same workload. Match the evidence to the claim.
For a bug fix, show the original failure, rerun the same scenario after the change, and check relevant cases that should remain unchanged.

[04:06] Let agents wait on you.

Tenth, don't wait for your agents; let them wait on you. Ball recommends larger, more ambitious tasks and asynchronous work.
Give the agent enough context to finish a meaningful unit, then do something else while it works.
A good handoff includes the desired outcome, constraints, expected proof, and the decisions that genuinely require your input.

[04:28] Make follow-up automatic.

Eleventh, use automation and schedules. Some important feedback arrives after the initial task is finished.
Ball's examples include checking logs in two hours, notifying you when something is live, and performing a daily check.
Specify the trigger and what should be reported. A monitoring request is not blanket authorization to change production.

[04:50] One task. One thread.

Twelfth, stop manually managing context. Ball says compaction works well enough that he doesn't organize work around the token count.
His rule is one thread per task, whether the conversation takes a few messages or thousands.
That does not make memory infallible. Keep important constraints and decisions explicit so the task can be checked and resumed.

[05:12] Threads become team memory.

Thirteenth, threads become company memory. A patch shows what changed, but the conversation can preserve why.
Ball describes Amp threads connected to git commits, making earlier reasoning available to other people and agents.
Before reopening an old design question, recover the previous investigation. Reusing that context can prevent duplicate work across the team.

[05:35] Keep your human voice.

Fourteenth, Ball advises against letting agents write for humans. This is one of the article's deliberately opinionated boundaries.
He makes exceptions for mechanical writing, including debugging instructions, incident reports, and some documentation.
The useful distinction is between transferring technical information and expressing your own judgment or relationship with another person.

[05:59] Review by blast radius.

Fifteenth, review code with high blast radius. Ball focuses on a small number of central files and database migrations, rather than every stylistic detail.
He asks whether it works, whether he understands the design, whether it was tested end to end, and whether he can change it later.
Apply the principle as risk-based review, not an excuse to skip scrutiny of consequential changes. Proof and human judgment serve different roles.

[06:26] A better delegation loop.

Put the ideas together. Ask an agent to make checkout faster without changing payment behavior. Give it a representative workload, an isolated environment, and the tools it needs.
Have it test competing explanations, implement the improvement, and return comparable measurements plus an end-to-end walkthrough. Let it work asynchronously.
Review the payment-sensitive changes, arrange a follow-up health check, and preserve the decision in the task thread. That's the operating model: outcomes, reality, and proof.

[06:58] Give agents a complete job.

This lesson adapts Thorsten Ball's article, How I Work with Agents, published October twenty-fifth, twenty twenty-six. Read the original for his exact wording and context.
The examples and safety notes are additions for teaching. They should not be mistaken for quotes from the author.
The narration and graphics in this video are AI-generated. The takeaway: give agents a complete job, and ask them to show you what actually happened.