WEBVTT

1
00:00:00.559 --> 00:00:04.138
How do you get useful work from a coding
agent, instead of just more code?

2
00:00:04.418 --> 00:00:08.689
Thorsten Ball's October twenty twenty-six
article offers fifteen principles,

3
00:00:08.824 --> 00:00:10.716
grounded in his own experience.

4
00:00:11.008 --> 00:00:15.119
The central shift is to delegate an
outcome, give the agent contact with the

5
00:00:15.134 --> 00:00:18.082
real system, and require evidence that it
succeeded.

6
00:00:18.375 --> 00:00:21.116
We'll turn each principle into a practical
habit.

7
00:00:21.397 --> 00:00:24.174
These are Ball's opinions, not universal
laws.

8
00:00:24.455 --> 00:00:26.941
The examples in this lesson are
illustrative.

9
00:00:28.441 --> 00:00:32.360
First, Ball argues for using the latest and
most capable models.

10
00:00:32.652 --> 00:00:34.775
His concern is hidden unreliability:

11
00:00:35.067 --> 00:00:36.631
you don't know which answers are wrong.

12
00:00:36.912 --> 00:00:40.732
A lower price per attempt may not mean
lower total cost if you spend the

13
00:00:40.747 --> 00:00:42.918
savings on retries and supervision.

14
00:00:43.210 --> 00:00:47.128
Apply this by comparing models on
representative work, including how much

15
00:00:47.143 --> 00:00:49.338
human correction each result needs.

16
00:00:50.809 --> 00:00:54.738
Second, stop assuming agent-generated code
inevitably becomes an

17
00:00:54.753 --> 00:00:59.156
unmaintainable mess. Ball is skeptical of
that prediction, given how models

18
00:00:59.171 --> 00:01:03.391
have improved. That's a personal judgment,
not proof that every generated

19
00:01:03.406 --> 00:01:07.179
change is good. Don't turn it into
permission to ignore defects.

20
00:01:07.460 --> 00:01:11.268
Ask whether the result works, whether you
understand its design, and whether

21
00:01:11.283 --> 00:01:12.410
you can change it later.

22
00:01:13.929 --> 00:01:16.415
Third, prompt the what, not the how.

23
00:01:16.696 --> 00:01:20.297
Instead of prescribing a cache, describe
the slow experience you want to

24
00:01:20.312 --> 00:01:24.618
improve. For example: halve response time
on this workload, preserve the

25
00:01:24.633 --> 00:01:27.835
returned data, and show before and after
measurements.

26
00:01:28.116 --> 00:01:32.144
You still specify constraints, such as no
public API changes.

27
00:01:32.424 --> 00:01:36.355
The agent chooses the implementation, not
the definition of success.

28
00:01:37.846 --> 00:01:42.019
Fourth, make the entire software
development lifecycle legible to the agent.

29
00:01:42.348 --> 00:01:46.083
Ball credits tool calls with letting agents
touch reality instead of

30
00:01:46.098 --> 00:01:51.036
inventing it. Let it run the application,
inspect logs, understand releases,

31
00:01:51.098 --> 00:01:53.670
and follow bugs through to their user
impact.

32
00:01:53.950 --> 00:01:57.383
A safe implementation separates visibility
from authority.

33
00:01:57.664 --> 00:02:01.484
Access to deployment information does not
automatically mean permission to

34
00:02:01.499 --> 00:02:02.068
deploy.

35
00:02:03.554 --> 00:02:06.113
Fifth, give the agent tools for that
lifecycle.

36
00:02:06.406 --> 00:02:10.883
Ball describes custom plugins for bug
reports, system health, customer email,

37
00:02:10.993 --> 00:02:15.663
and feature flags. The practical lesson is
to expose the operations the job

38
00:02:15.678 --> 00:02:20.033
actually requires, rather than describing a
system the agent cannot reach.

39
00:02:20.350 --> 00:02:24.037
For your own tools, scope permissions and
preserve approval gates for

40
00:02:24.052 --> 00:02:28.308
consequential actions. That's an
implementation safeguard, not a claim from

41
00:02:28.323 --> 00:02:29.014
the article.

42
00:02:30.476 --> 00:02:32.853
Sixth, evaluate agentic knowledge.

43
00:02:33.134 --> 00:02:37.548
Adding an instruction file or skill doesn't
establish that agents use it, or

44
00:02:37.563 --> 00:02:41.954
that it helps. Run blind agents on
comparable tasks, with and without the

45
00:02:41.969 --> 00:02:46.008
guidance. Keep the task and evaluation
criteria consistent.

46
00:02:46.289 --> 00:02:50.450
Compare observable outcomes, not whether an
agent says it read the document.

47
00:02:50.743 --> 00:02:53.593
Ball's suggestion is to experiment rather
than assume.

48
00:02:55.059 --> 00:02:59.013
Seventh, local development can become
awkward when several agents need to

49
00:02:59.028 --> 00:03:02.364
install dependencies and test applications
end to end.

50
00:03:02.681 --> 00:03:06.925
Ball prefers remote machines where each
agent can run what it needs without

51
00:03:06.940 --> 00:03:09.087
competing for the same local resources.

52
00:03:09.367 --> 00:03:14.025
In practice, isolation should include test
databases and services, not just

53
00:03:14.040 --> 00:03:18.080
separate source folders. Otherwise the
collisions simply move elsewhere.

54
00:03:19.505 --> 00:03:22.793
Eighth, don't iterate with the agent one
tiny step at a time.

55
00:03:23.073 --> 00:03:25.329
Let it build tools that make iteration
cheap.

56
00:03:25.646 --> 00:03:30.073
For design work, request twenty variations
and a page where you can compare

57
00:03:30.088 --> 00:03:33.290
and combine them, rather than twenty
separate conversations.

58
00:03:33.632 --> 00:03:38.143
For debugging, ask for four explanations of
the slowdown and experiments that

59
00:03:38.158 --> 00:03:42.053
test each one. Explore the problem as well
as the solutions.

60
00:03:43.505 --> 00:03:45.749
Ninth, ask for irrefutable proof.

61
00:03:46.042 --> 00:03:49.281
Ball calls this a major improvement in how
he works with agents.

62
00:03:49.561 --> 00:03:54.121
Request an end-to-end walkthrough, a demo
video, or before and after numbers

63
00:03:54.136 --> 00:03:55.215
from the same workload.

64
00:03:55.496 --> 00:03:57.072
Match the evidence to the claim.

65
00:03:57.401 --> 00:04:01.828
For a bug fix, show the original failure,
rerun the same scenario after the

66
00:04:01.843 --> 00:04:05.458
change, and check relevant cases that
should remain unchanged.

67
00:04:06.893 --> 00:04:08.809
Tenth, don't wait for your agents;

68
00:04:09.041 --> 00:04:10.047
let them wait on you.

69
00:04:10.351 --> 00:04:14.391
Ball recommends larger, more ambitious
tasks and asynchronous work.

70
00:04:14.672 --> 00:04:18.916
Give the agent enough context to finish a
meaningful unit, then do something

71
00:04:18.931 --> 00:04:20.059
else while it works.

72
00:04:20.339 --> 00:04:25.130
A good handoff includes the desired
outcome, constraints, expected proof, and

73
00:04:25.145 --> 00:04:27.668
the decisions that genuinely require your
input.

74
00:04:29.130 --> 00:04:31.471
Eleventh, use automation and schedules.

75
00:04:31.752 --> 00:04:35.561
Some important feedback arrives after the
initial task is finished.

76
00:04:35.866 --> 00:04:39.844
Ball's examples include checking logs in
two hours, notifying you when

77
00:04:39.859 --> 00:04:42.624
something is live, and performing a daily
check.

78
00:04:42.917 --> 00:04:45.379
Specify the trigger and what should be
reported.

79
00:04:45.647 --> 00:04:49.542
A monitoring request is not blanket
authorization to change production.

80
00:04:51.005 --> 00:04:53.625
Twelfth, stop manually managing context.

81
00:04:53.918 --> 00:04:57.580
Ball says compaction works well enough that
he doesn't organize work around

82
00:04:57.595 --> 00:05:02.022
the token count. His rule is one thread per
task, whether the conversation

83
00:05:02.037 --> 00:05:04.390
takes a few messages or thousands.

84
00:05:04.683 --> 00:05:06.429
That does not make memory infallible.

85
00:05:06.721 --> 00:05:10.931
Keep important constraints and decisions
explicit so the task can be checked

86
00:05:10.993 --> 00:05:11.732
and resumed.

87
00:05:13.209 --> 00:05:15.622
Thirteenth, threads become company memory.

88
00:05:15.903 --> 00:05:19.578
A patch shows what changed, but the
conversation can preserve why.

89
00:05:19.883 --> 00:05:24.274
Ball describes Amp threads connected to git
commits, making earlier reasoning

90
00:05:24.289 --> 00:05:26.496
available to other people and agents.

91
00:05:26.776 --> 00:05:31.290
Before reopening an old design question,
recover the previous investigation.

92
00:05:31.570 --> 00:05:34.955
Reusing that context can prevent duplicate
work across the team.

93
00:05:36.429 --> 00:05:40.044
Fourteenth, Ball advises against letting
agents write for humans.

94
00:05:40.325 --> 00:05:43.782
This is one of the article's deliberately
opinionated boundaries.

95
00:05:44.087 --> 00:05:48.163
He makes exceptions for mechanical writing,
including debugging instructions,

96
00:05:48.395 --> 00:05:50.845
incident reports, and some documentation.

97
00:05:51.138 --> 00:05:54.933
The useful distinction is between
transferring technical information and

98
00:05:54.948 --> 00:05:58.309
expressing your own judgment or
relationship with another person.

99
00:05:59.792 --> 00:06:02.824
Fifteenth, review code with high blast
radius.

100
00:06:03.129 --> 00:06:07.327
Ball focuses on a small number of central
files and database migrations,

101
00:06:07.510 --> 00:06:09.718
rather than every stylistic detail.

102
00:06:10.010 --> 00:06:13.867
He asks whether it works, whether he
understands the design, whether it was

103
00:06:13.882 --> 00:06:16.781
tested end to end, and whether he can
change it later.

104
00:06:17.073 --> 00:06:21.621
Apply the principle as risk-based review,
not an excuse to skip scrutiny of

105
00:06:21.636 --> 00:06:25.846
consequential changes. Proof and human
judgment serve different roles.

106
00:06:27.309 --> 00:06:28.558
Put the ideas together.

107
00:06:28.838 --> 00:06:32.502
Ask an agent to make checkout faster
without changing payment behavior.

108
00:06:32.783 --> 00:06:36.687
Give it a representative workload, an
isolated environment, and the tools it

109
00:06:36.702 --> 00:06:41.554
needs. Have it test competing explanations,
implement the improvement, and

110
00:06:41.569 --> 00:06:44.905
return comparable measurements plus an end-
to-end walkthrough.

111
00:06:45.185 --> 00:06:46.555
Let it work asynchronously.

112
00:06:46.836 --> 00:06:50.862
Review the payment-sensitive changes,
arrange a follow-up health check, and

113
00:06:50.877 --> 00:06:52.987
preserve the decision in the task thread.

114
00:06:53.280 --> 00:06:54.541
That's the operating model:

115
00:06:54.809 --> 00:06:57.077
outcomes, reality, and proof.

116
00:06:58.547 --> 00:07:02.986
This lesson adapts Thorsten Ball's article,
How I Work with Agents, published

117
00:07:03.001 --> 00:07:05.427
October twenty-fifth, twenty twenty-six.

118
00:07:05.707 --> 00:07:08.861
Read the original for his exact wording and
context.

119
00:07:09.142 --> 00:07:11.980
The examples and safety notes are additions
for teaching.

120
00:07:12.273 --> 00:07:14.711
They should not be mistaken for quotes from
the author.

121
00:07:15.003 --> 00:07:18.631
The narration and graphics in this video
are AI-generated.

122
00:07:18.935 --> 00:07:22.622
The takeaway: give agents a complete job,
and ask them to show you what

123
00:07:22.637 --> 00:07:23.570
actually happened.