1
00:00:00,719 --> 00:00:03,510
Hi, I'm Dimmitri. In this session, I

2
00:00:03,520 --> 00:00:05,590
will show how I work on maintaining

3
00:00:05,600 --> 00:00:08,790
large AI coding projects. Coding agents

4
00:00:08,800 --> 00:00:12,709
made code cheap. They made entropy even

5
00:00:12,719 --> 00:00:15,589
cheaper. In the Marvel movie, Thanos

6
00:00:15,599 --> 00:00:18,310
watched his home planet Titan collapse

7
00:00:18,320 --> 00:00:20,630
under its own growth. So, when the

8
00:00:20,640 --> 00:00:23,590
universe got crowded, he raised half of

9
00:00:23,600 --> 00:00:26,950
everything. This talk is about the one

10
00:00:26,960 --> 00:00:30,070
time I did the same in one project. Our

11
00:00:30,080 --> 00:00:32,950
code was growing the way Titan did. When

12
00:00:32,960 --> 00:00:36,950
I found what my agents had done, I

13
00:00:36,960 --> 00:00:40,790
deleted tests and boil the plate code

14
00:00:40,800 --> 00:00:43,670
nobody used. I had to rewrite the whole

15
00:00:43,680 --> 00:00:46,310
project and I lost some useful pieces.

16
00:00:46,320 --> 00:00:49,350
And that's the dilemma. Drown and chaos

17
00:00:49,360 --> 00:00:53,189
or break what people use. And here we'll

18
00:00:53,199 --> 00:00:56,630
build the third option for that project.

19
00:00:56,640 --> 00:00:59,990
The rewrite didn't hold. The agents kept

20
00:01:00,000 --> 00:01:03,270
writing and the mess grew back. So I

21
00:01:03,280 --> 00:01:06,390
drew a line above it. There is more

22
00:01:06,400 --> 00:01:09,510
change than anyone can check. The third

23
00:01:09,520 --> 00:01:12,149
option is to stay under it with small

24
00:01:12,159 --> 00:01:15,030
sweeps every week and feedback loops

25
00:01:15,040 --> 00:01:17,510
built into the system. Each chapter of

26
00:01:17,520 --> 00:01:19,910
this talk is one thing I had to learn to

27
00:01:19,920 --> 00:01:22,870
get there. Thanos needed six stones for

28
00:01:22,880 --> 00:01:26,230
one snap. Ours are six questions and

29
00:01:26,240 --> 00:01:29,109
they light up in the corner as we go.

30
00:01:29,119 --> 00:01:32,149
The first one is time. How do we stay

31
00:01:32,159 --> 00:01:34,230
under the line?

32
00:01:34,240 --> 00:01:37,190
Chapter one. To stay under the line. I

33
00:01:37,200 --> 00:01:39,590
first had to know what's right means

34
00:01:39,600 --> 00:01:42,950
here. I used to think that tests decide

35
00:01:42,960 --> 00:01:46,630
that. So what does right actually depend

36
00:01:46,640 --> 00:01:48,149
on?

37
00:01:48,159 --> 00:01:50,870
Let's keep one task in mind. Someone

38
00:01:50,880 --> 00:01:53,830
wants to change the amount on an order

39
00:01:53,840 --> 00:01:56,630
we already approved. Two kinds of agents

40
00:01:56,640 --> 00:01:59,749
meet here. One wrote the instructions

41
00:01:59,759 --> 00:02:01,830
and the other follows them in

42
00:02:01,840 --> 00:02:04,069
production.

43
00:02:04,079 --> 00:02:07,749
We run this in 110 countries with about

44
00:02:07,759 --> 00:02:11,350
10,000 scenarios of pros instructions.

45
00:02:11,360 --> 00:02:14,949
Every task lands in a slice. One process

46
00:02:14,959 --> 00:02:17,990
in one country. There's a second stone

47
00:02:18,000 --> 00:02:21,430
space. It asks where a change is allowed

48
00:02:21,440 --> 00:02:25,190
to go. By default, it stays inside its

49
00:02:25,200 --> 00:02:27,110
slice.

50
00:02:27,120 --> 00:02:29,589
Most of this system is pros about three

51
00:02:29,599 --> 00:02:32,309
quarters by my estimate. So pros needs

52
00:02:32,319 --> 00:02:35,270
engineering too. At start we borrowed

53
00:02:35,280 --> 00:02:37,830
mutation testing. You break one sentence

54
00:02:37,840 --> 00:02:41,430
on purpose and you watch for red test.

55
00:02:41,440 --> 00:02:44,550
Here almost none turned red. And if your

56
00:02:44,560 --> 00:02:47,190
wrapper is all code, your agent

57
00:02:47,200 --> 00:02:49,750
instructions and your tests are your

58
00:02:49,760 --> 00:02:53,990
pros. With agents, a rewrite is easy.

59
00:02:54,000 --> 00:02:56,070
The hard part is knowing what has to

60
00:02:56,080 --> 00:02:59,190
survive it. For code, tests can tell

61
00:02:59,200 --> 00:03:02,790
you. For pros, only people can. Agents

62
00:03:02,800 --> 00:03:05,030
can't build a complex system on their

63
00:03:05,040 --> 00:03:08,550
own. They fix what is easy to see and

64
00:03:08,560 --> 00:03:11,589
break consistency on the way. And people

65
00:03:11,599 --> 00:03:13,910
also get tired. So we spend their

66
00:03:13,920 --> 00:03:17,350
judgment only where it's needed. When

67
00:03:17,360 --> 00:03:20,149
business asked check with the team, it

68
00:03:20,159 --> 00:03:23,030
hides a real question. Is this a human

69
00:03:23,040 --> 00:03:25,910
step or can we automate it? Experts

70
00:03:25,920 --> 00:03:28,550
can't answer that. They don't see how

71
00:03:28,560 --> 00:03:30,869
the systems connect inside. So

72
00:03:30,879 --> 00:03:33,110
developers dig through the traces and

73
00:03:33,120 --> 00:03:35,589
logs with their coding agents and they

74
00:03:35,599 --> 00:03:38,710
decide which it is. In our task, the

75
00:03:38,720 --> 00:03:41,830
team leads decision stays human. The

76
00:03:41,840 --> 00:03:45,030
limit was data we could connect.

77
00:03:45,040 --> 00:03:47,589
Business experts see the rules.

78
00:03:47,599 --> 00:03:50,390
Developers see what's under the water.

79
00:03:50,400 --> 00:03:53,270
And that's where most bugs leave. They

80
00:03:53,280 --> 00:03:55,350
have their coding agents write those

81
00:03:55,360 --> 00:03:58,149
links down so the runtime can check

82
00:03:58,159 --> 00:04:00,710
them. Our guide for experts says it

83
00:04:00,720 --> 00:04:04,949
simply business tell us what we work out

84
00:04:04,959 --> 00:04:09,190
how. One document to readers. Agents

85
00:04:09,200 --> 00:04:11,670
read the blogs. So their blocks have to

86
00:04:11,680 --> 00:04:14,710
be exact. Experts read the text around

87
00:04:14,720 --> 00:04:17,749
them and they sign it. We keep one copy,

88
00:04:17,759 --> 00:04:20,310
a second one with drift and works both

89
00:04:20,320 --> 00:04:22,629
ways. Our code needs a plain description

90
00:04:22,639 --> 00:04:26,469
for experts too. Experts can only fix

91
00:04:26,479 --> 00:04:29,189
what they can see. Each of them reviews

92
00:04:29,199 --> 00:04:33,030
a task exactly the way the agent saw it.

93
00:04:33,040 --> 00:04:35,909
The node becomes the next change made by

94
00:04:35,919 --> 00:04:38,469
a coding agent and test it on the same

95
00:04:38,479 --> 00:04:42,469
task. So right depends on people. No

96
00:04:42,479 --> 00:04:45,110
single person knows it. A group of

97
00:04:45,120 --> 00:04:48,390
experts decides and that's why we bring

98
00:04:48,400 --> 00:04:51,510
them in from the start. You'll see the

99
00:04:51,520 --> 00:04:54,230
soul stone here a lot. We take it in

100
00:04:54,240 --> 00:04:56,310
chapter 4.

101
00:04:56,320 --> 00:04:59,510
Chapter two. Experts correct one task at

102
00:04:59,520 --> 00:05:02,870
a time while agents run the same pros

103
00:05:02,880 --> 00:05:06,550
all day. We track every outcome accepted

104
00:05:06,560 --> 00:05:10,550
or rejected. The accuracy shows us where

105
00:05:10,560 --> 00:05:13,110
people still need to look. I used to

106
00:05:13,120 --> 00:05:15,189
think the goal was to move everything

107
00:05:15,199 --> 00:05:18,070
into code. So where do we still need

108
00:05:18,080 --> 00:05:21,590
judgment? Here is our task again. The

109
00:05:21,600 --> 00:05:25,110
pro says the limit is 1,500. The code

110
00:05:25,120 --> 00:05:28,550
says a,000. The same order is fine in

111
00:05:28,560 --> 00:05:31,909
one place and too high in the other and

112
00:05:31,919 --> 00:05:34,469
nothing throws an error. Even a line

113
00:05:34,479 --> 00:05:37,670
like do not call X teaches the model

114
00:05:37,680 --> 00:05:41,270
that X exists. That's the third stone

115
00:05:41,280 --> 00:05:44,790
reality. Is it true or does it only look

116
00:05:44,800 --> 00:05:47,749
true for the model? Pros has no

117
00:05:47,759 --> 00:05:50,790
compiler. So we built one. Then the

118
00:05:50,800 --> 00:05:53,510
author lints every changed file into

119
00:05:53,520 --> 00:05:58,790
ledger just like code.

120
00:05:58,800 --> 00:06:02,070
Lind can't stop copies drifting aparts.

121
00:06:02,080 --> 00:06:04,629
So we watched the walks. A walk is the

122
00:06:04,639 --> 00:06:07,909
path one agent takes through the pros.

123
00:06:07,919 --> 00:06:09,909
When agents keep walking in the same

124
00:06:09,919 --> 00:06:12,870
path, we turn it into one workflow tool

125
00:06:12,880 --> 00:06:16,790
and we delete the pros that walked it.

126
00:06:16,800 --> 00:06:19,510
Our first workflow of tools made things

127
00:06:19,520 --> 00:06:21,990
worse. The pros still named the steps

128
00:06:22,000 --> 00:06:25,189
inside them. So agents run those steps

129
00:06:25,199 --> 00:06:27,749
again. It worked once. The pros kept

130
00:06:27,759 --> 00:06:31,430
only the decisions. Now a walk becomes

131
00:06:31,440 --> 00:06:34,710
code only when it repeats and agrees

132
00:06:34,720 --> 00:06:37,510
across countries otherwise it stays

133
00:06:37,520 --> 00:06:41,590
pros. What still varies stays in pros

134
00:06:41,600 --> 00:06:44,070
inside the frame. Code prepares the

135
00:06:44,080 --> 00:06:47,110
facts and carries out the decision.

136
00:06:47,120 --> 00:06:49,990
Experts own the decision table and the

137
00:06:50,000 --> 00:06:53,990
model only picks a row. If no row fits,

138
00:06:54,000 --> 00:06:56,710
a person takes over. We haven't built

139
00:06:56,720 --> 00:06:58,950
the next step yet. The model will take

140
00:06:58,960 --> 00:07:01,749
the small decisions and workflows will

141
00:07:01,759 --> 00:07:04,550
connect them. This boundary moves both

142
00:07:04,560 --> 00:07:07,510
ways. We moved hundreds of lines of

143
00:07:07,520 --> 00:07:11,189
expressions out of code and into pros

144
00:07:11,199 --> 00:07:14,230
because experts couldn't read them. A

145
00:07:14,240 --> 00:07:15,830
reax is still fine for spotting a

146
00:07:15,840 --> 00:07:18,550
critical signal. When there are many,

147
00:07:18,560 --> 00:07:21,670
they move into config. Judgment stays

148
00:07:21,680 --> 00:07:24,870
wherever the answer varies in a place an

149
00:07:24,880 --> 00:07:28,550
expert can read. Chapter three. Now the

150
00:07:28,560 --> 00:07:31,029
model decides and its decision becomes

151
00:07:31,039 --> 00:07:35,270
an action. I used to think control meant

152
00:07:35,280 --> 00:07:37,909
permissions on the agent. So what does

153
00:07:37,919 --> 00:07:41,189
it mean to stay in control?

154
00:07:41,199 --> 00:07:44,629
Control starts with what the model sees.

155
00:07:44,639 --> 00:07:47,670
That's what the fourth stone mind. What

156
00:07:47,680 --> 00:07:49,909
does the model know? When we let it

157
00:07:49,919 --> 00:07:52,070
choose what to load, it loaded

158
00:07:52,080 --> 00:07:55,110
everything. Then it invented a pricing

159
00:07:55,120 --> 00:07:58,070
check just because prices were visible.

160
00:07:58,080 --> 00:08:01,029
Whatever sits in its context becomes a

161
00:08:01,039 --> 00:08:04,629
reason to act. The runtime decides

162
00:08:04,639 --> 00:08:07,029
what's the model sees for our task.

163
00:08:07,039 --> 00:08:09,909
That's three facts from the order. The

164
00:08:09,919 --> 00:08:12,710
full record stays with the runtime and

165
00:08:12,720 --> 00:08:17,830
the model makes fewer wrong moves.

166
00:08:17,840 --> 00:08:20,629
Here how we minimize context blo for a

167
00:08:20,639 --> 00:08:22,710
big set. The model passes a handle, a

168
00:08:22,720 --> 00:08:24,550
short name for date that the runtime

169
00:08:24,560 --> 00:08:27,430
already holds. The runtime checks it

170
00:08:27,440 --> 00:08:29,749
before any write. It keeps the context

171
00:08:29,759 --> 00:08:32,709
small and still enough for the decision.

172
00:08:32,719 --> 00:08:35,670
At the same time, it uh validates

173
00:08:35,680 --> 00:08:39,029
context for consistency. A model with

174
00:08:39,039 --> 00:08:41,829
the right facts can still do damage.

175
00:08:41,839 --> 00:08:45,190
That's the fifth stone, power. What made

176
00:08:45,200 --> 00:08:47,910
change? We control a change twice.

177
00:08:47,920 --> 00:08:50,470
during development and again at the

178
00:08:50,480 --> 00:08:53,670
right at runtime only code opens the

179
00:08:53,680 --> 00:08:56,230
right path so we can change pros many

180
00:08:56,240 --> 00:08:59,430
times a day the open rings are the parts

181
00:08:59,440 --> 00:09:02,790
that still depend on people let's zoom

182
00:09:02,800 --> 00:09:06,150
in and run right five walls stand in

183
00:09:06,160 --> 00:09:08,949
front of it and the sixth checks that it

184
00:09:08,959 --> 00:09:12,150
landed if a right looks like it failed

185
00:09:12,160 --> 00:09:15,110
an agent retries and the journal makes

186
00:09:15,120 --> 00:09:18,310
sure it runs only once means much more

187
00:09:18,320 --> 00:09:23,990
than permissions on the agent.

188
00:09:24,000 --> 00:09:27,509
Chapter 4. Most days I glide over the

189
00:09:27,519 --> 00:09:30,310
system. From up here, everything looks

190
00:09:30,320 --> 00:09:32,790
fine, so I don't go down into every

191
00:09:32,800 --> 00:09:36,389
change my agents made. Then the surface

192
00:09:36,399 --> 00:09:39,269
gets rough. How do we know we're losing

193
00:09:39,279 --> 00:09:41,110
control?

194
00:09:41,120 --> 00:09:43,350
All those controls protect the system.

195
00:09:43,360 --> 00:09:46,310
Nothing protected my attention. At the

196
00:09:46,320 --> 00:09:48,949
start, I read every change and that's

197
00:09:48,959 --> 00:09:52,150
how the system picked up my habits. Then

198
00:09:52,160 --> 00:09:55,590
the volume grew past what one person can

199
00:09:55,600 --> 00:09:58,230
read. I was burning out and I stopped

200
00:09:58,240 --> 00:10:00,949
reading every change. That was the price

201
00:10:00,959 --> 00:10:04,470
of the last stone. So, who judges and

202
00:10:04,480 --> 00:10:07,430
what does it cost? With it, the gauntlet

203
00:10:07,440 --> 00:10:10,710
is complete. Every tech lead I know has

204
00:10:10,720 --> 00:10:13,670
been here. The one person every change

205
00:10:13,680 --> 00:10:16,870
waits on. agents just get you there in

206
00:10:16,880 --> 00:10:19,910
weeks instead of years. I needed a way

207
00:10:19,920 --> 00:10:22,389
of working that doesn't run through one

208
00:10:22,399 --> 00:10:25,509
head. And the first gauge was me. When

209
00:10:25,519 --> 00:10:27,750
I'm tired and I can't explain what

210
00:10:27,760 --> 00:10:30,069
changed, that's the signal. The

211
00:10:30,079 --> 00:10:33,110
dashboard can be green while that gauge

212
00:10:33,120 --> 00:10:36,230
is firing. So, I stop and fix the

213
00:10:36,240 --> 00:10:38,630
process first. I don't wait for a

214
00:10:38,640 --> 00:10:41,670
number. I couldn't read every div

215
00:10:41,680 --> 00:10:43,990
anymore. So I built instruments that

216
00:10:44,000 --> 00:10:46,550
watch how things change and their

217
00:10:46,560 --> 00:10:49,509
derivatives. One of them is blast

218
00:10:49,519 --> 00:10:52,389
radius. Before we built one new check,

219
00:10:52,399 --> 00:10:54,550
we replayed its rule over several

220
00:10:54,560 --> 00:10:56,949
thousand past sessions. It would have

221
00:10:56,959 --> 00:11:00,310
fired on less than 1%. Where the numbers

222
00:11:00,320 --> 00:11:04,150
jump, I go down and read. When something

223
00:11:04,160 --> 00:11:06,870
looks wrong, we wait. One signal waits

224
00:11:06,880 --> 00:11:09,350
until it comes back, even when it comes

225
00:11:09,360 --> 00:11:12,630
from an expert. A cluster across slices

226
00:11:12,640 --> 00:11:15,430
is different. Then we fix the concept

227
00:11:15,440 --> 00:11:18,470
behind it once. Left alone, an agent

228
00:11:18,480 --> 00:11:20,710
keeps adding conditions until today's

229
00:11:20,720 --> 00:11:23,829
tasks pass. The eval score drops when

230
00:11:23,839 --> 00:11:26,230
you take them out and you get an honest

231
00:11:26,240 --> 00:11:31,110
list of gaps.

232
00:11:31,120 --> 00:11:34,069
One red slice is rarely alone. The

233
00:11:34,079 --> 00:11:36,870
experts note becomes an eval and an

234
00:11:36,880 --> 00:11:39,110
agent searches the siblings for the same

235
00:11:39,120 --> 00:11:42,389
failure. Siblings differ on purpose by

236
00:11:42,399 --> 00:11:45,670
market and by local law. So we sweep

237
00:11:45,680 --> 00:11:48,470
them and the fix goes only where the

238
00:11:48,480 --> 00:11:53,829
failure is confirmed.

239
00:11:53,839 --> 00:11:57,110
At any time 10 to 20 of these loops are

240
00:11:57,120 --> 00:11:59,750
open. At one point I had become the

241
00:11:59,760 --> 00:12:03,110
message bus between users and my agents.

242
00:12:03,120 --> 00:12:06,069
At this scale, every user has to be an

243
00:12:06,079 --> 00:12:08,949
evaluator with a screen to give feedback

244
00:12:08,959 --> 00:12:12,310
without me. My job as the architect is

245
00:12:12,320 --> 00:12:15,110
to build those loops into the system.

246
00:12:15,120 --> 00:12:17,990
Each loop writes to a ledger. So nothing

247
00:12:18,000 --> 00:12:20,949
waits on my memory and nothing waits on

248
00:12:20,959 --> 00:12:24,150
me.

249
00:12:24,160 --> 00:12:26,629
Agents forget everything when a session

250
00:12:26,639 --> 00:12:29,430
ends. So the memory has to leave in

251
00:12:29,440 --> 00:12:32,790
files. We keep two kinds. what happened

252
00:12:32,800 --> 00:12:35,750
and what is true now. The next session

253
00:12:35,760 --> 00:12:40,870
starts from what is true now.

254
00:12:40,880 --> 00:12:43,829
Every issue has to connect to its root

255
00:12:43,839 --> 00:12:46,389
cause. Without that, the agent decides

256
00:12:46,399 --> 00:12:49,110
on wrong facts and the check has nothing

257
00:12:49,120 --> 00:12:51,590
to count. So we don't act without

258
00:12:51,600 --> 00:12:54,310
evidence.

259
00:12:54,320 --> 00:12:58,389
Reality comes back. In chapter two, it

260
00:12:58,399 --> 00:13:01,590
asked if the pros is true. Now it asks

261
00:13:01,600 --> 00:13:05,509
if the change is I used to trust green.

262
00:13:05,519 --> 00:13:08,949
So what would make us change our mind?

263
00:13:08,959 --> 00:13:11,350
Green was tempting because checking is

264
00:13:11,360 --> 00:13:13,990
where the times goes. My agent spend

265
00:13:14,000 --> 00:13:17,269
almost 9/10en of that time on a change

266
00:13:17,279 --> 00:13:19,670
just checking it and checking took a

267
00:13:19,680 --> 00:13:22,150
bigger share of my own week too.

268
00:13:22,160 --> 00:13:27,670
Verification speed is the limit.

269
00:13:27,680 --> 00:13:30,870
We rank evidence by what it proves. A

270
00:13:30,880 --> 00:13:33,990
replay on real tasks sits at the top.

271
00:13:34,000 --> 00:13:36,710
Before the data arrives, we write down

272
00:13:36,720 --> 00:13:39,190
what would prove us wrong. And every new

273
00:13:39,200 --> 00:13:41,990
check has to fail once on purpose before

274
00:13:42,000 --> 00:13:46,629
we trust it.

275
00:13:46,639 --> 00:13:50,150
AI refactors fail quietly. Every

276
00:13:50,160 --> 00:13:53,190
condition and every decision table row

277
00:13:53,200 --> 00:13:56,150
is a branch. And after a refactor, each

278
00:13:56,160 --> 00:13:59,430
one has to land exactly once. Here the

279
00:13:59,440 --> 00:14:01,590
branch for amounts over the limit got

280
00:14:01,600 --> 00:14:04,550
lost. Our [snorts] order would have gone

281
00:14:04,560 --> 00:14:07,910
through without the team lead. Real

282
00:14:07,920 --> 00:14:11,350
tasks decide what we test. We freeze

283
00:14:11,360 --> 00:14:14,470
them as a set and replay the old version

284
00:14:14,480 --> 00:14:17,189
against the new one. If no real task

285
00:14:17,199 --> 00:14:19,829
takes a branch, we call that no

286
00:14:19,839 --> 00:14:21,430
evidence.

287
00:14:21,440 --> 00:14:24,310
You can't trust one agent to judge its

288
00:14:24,320 --> 00:14:27,990
own work. A second agent checks it with

289
00:14:28,000 --> 00:14:30,629
a checklist and without the author's

290
00:14:30,639 --> 00:14:32,870
reasoning. It can't be talked into

291
00:14:32,880 --> 00:14:36,470
agreeing. Over 6 months, it grew to most

292
00:14:36,480 --> 00:14:39,829
of my checking.

293
00:14:39,839 --> 00:14:43,030
Coding agents finish most of a batch and

294
00:14:43,040 --> 00:14:45,189
quietly skipped the rest, especially

295
00:14:45,199 --> 00:14:48,150
when their context is full. The ledger

296
00:14:48,160 --> 00:14:51,590
shows what was skipped in one backlog.

297
00:14:51,600 --> 00:14:54,550
Most items looks covered, but only about

298
00:14:54,560 --> 00:14:58,389
a quarter could really be closed. So now

299
00:14:58,399 --> 00:15:01,750
evidence we can count is what changes

300
00:15:01,760 --> 00:15:05,910
our mind. And this is the third option

301
00:15:05,920 --> 00:15:08,389
from the start of the talk. I used to

302
00:15:08,399 --> 00:15:11,030
think there were two choices. Keep

303
00:15:11,040 --> 00:15:14,710
everything or snap. So what is worth

304
00:15:14,720 --> 00:15:16,870
carrying forward?

305
00:15:16,880 --> 00:15:19,670
This one process over a year. Some

306
00:15:19,680 --> 00:15:22,870
branches merged back, some still drift,

307
00:15:22,880 --> 00:15:25,910
and some are dead but still look alive.

308
00:15:25,920 --> 00:15:30,710
Which ones deserve to survive?

309
00:15:30,720 --> 00:15:33,910
A fix is only a moment. These forces

310
00:15:33,920 --> 00:15:36,949
keep pushing right after it. You've met

311
00:15:36,959 --> 00:15:39,829
most of them already. This chapter deals

312
00:15:39,839 --> 00:15:44,550
with regrowth and branching.

313
00:15:44,560 --> 00:15:46,870
The first gauge was me back in chapter

314
00:15:46,880 --> 00:15:50,629
4. These are the gauges for the code.

315
00:15:50,639 --> 00:15:53,110
Time gets its answers here. The bridge

316
00:15:53,120 --> 00:15:56,150
line comes back as a number. A ratchet

317
00:15:56,160 --> 00:15:58,790
means the count can only go down. Two

318
00:15:58,800 --> 00:16:04,150
gauges run today and six more are next.

319
00:16:04,160 --> 00:16:07,670
Every week real use decides what stays.

320
00:16:07,680 --> 00:16:10,550
Anything no real task reaches gets a

321
00:16:10,560 --> 00:16:13,829
name and its evidence before it goes.

322
00:16:13,839 --> 00:16:16,629
Test the evidence I didn't have when I

323
00:16:16,639 --> 00:16:20,470
snapped. Tests kept that variants alive.

324
00:16:20,480 --> 00:16:23,350
Agents kept every option a test still

325
00:16:23,360 --> 00:16:27,030
mentioned. Now retired variant takes its

326
00:16:27,040 --> 00:16:30,790
test with it. Here's the whole method as

327
00:16:30,800 --> 00:16:34,629
one week. This is the third option as a

328
00:16:34,639 --> 00:16:39,189
process.

329
00:16:39,199 --> 00:16:42,230
together. That's the full gauntlet.

330
00:16:42,240 --> 00:16:45,430
Thanos used his for one snap. We use

331
00:16:45,440 --> 00:16:48,470
ours every week in small doses with

332
00:16:48,480 --> 00:16:55,829
evidence. I haven't had to snap again.

333
00:16:55,839 --> 00:16:58,870
Soul had a second price and I only saw

334
00:16:58,880 --> 00:17:01,110
it later. After we deliver it to

335
00:17:01,120 --> 00:17:03,829
production, I found my own engineering

336
00:17:03,839 --> 00:17:06,150
principles built into the systems

337
00:17:06,160 --> 00:17:09,350
design. Its skills and its memory carry

338
00:17:09,360 --> 00:17:12,949
my habits and my biases. Conway said the

339
00:17:12,959 --> 00:17:16,390
system copies the orc chart. Ours copies

340
00:17:16,400 --> 00:17:19,909
whoever corrects it. Here are 18

341
00:17:19,919 --> 00:17:22,949
questions, three for each stone. I'm

342
00:17:22,959 --> 00:17:26,470
using them when working on my projects.

343
00:17:26,480 --> 00:17:29,110
Pause here and pick one your own

344
00:17:29,120 --> 00:17:32,710
repository can't answer yet. That's

345
00:17:32,720 --> 00:17:37,750
where to start.

346
00:17:37,760 --> 00:17:40,549
I learned to use this process when I was

347
00:17:40,559 --> 00:17:43,270
already burning out. If you're the one

348
00:17:43,280 --> 00:17:46,230
your team's changes weight on today,

349
00:17:46,240 --> 00:17:49,190
this is for you. Use your stones while

350
00:17:49,200 --> 00:17:52,230
you can still read every change. In the

351
00:17:52,240 --> 00:17:55,350
end, Thanos retires to a garden. Maybe

352
00:17:55,360 --> 00:17:59,350
he should start using them daily. Thank

353
00:17:59,360 --> 00:18:02,360
you.