WEBVTT

1
00:00:00.297 --> 00:00:02.162
Why can an agent follow a detailed

2
00:00:02.172 --> 00:00:04.076
plan and still build the wrong thing?

3
00:00:04.799 --> 00:00:06.582
Because a plan is not evidence that

4
00:00:06.592 --> 00:00:09.109
the problem, design, or result is right.

5
00:00:10.380 --> 00:00:13.177
This lesson adapts Lauren, known as poteto, and

6
00:00:13.187 --> 00:00:16.400
her article, The Complete Guide to p-stack, Part Two.

7
00:00:17.111 --> 00:00:21.338
Her workflow connects research, planning, prototyping, and architecture.

8
00:00:22.630 --> 00:00:24.995
The central idea is to understand the problem,

9
00:00:25.119 --> 00:00:28.980
explore solutions through code, and verify what actually happens.

10
00:00:29.703 --> 00:00:33.400
Verification is the prerequisite, not the finishing decoration.

11
00:00:35.089 --> 00:00:39.882
The article identifies two recurring failures: the agent misunderstands your intent,

12
00:00:40.077 --> 00:00:42.936
or it lacks the context needed to do the work correctly.

13
00:00:44.255 --> 00:00:46.962
A capable coder can still solve the wrong problem.

14
00:00:47.672 --> 00:00:50.835
Specifying every implementation detail does not repair a

15
00:00:50.845 --> 00:00:53.539
misunderstood goal or an incomplete mental model.

16
00:00:54.839 --> 00:00:57.376
Your job is to supply high quality context and

17
00:00:57.386 --> 00:00:59.510
a clear outcome, while leaving room for the

18
00:00:59.520 --> 00:01:02.462
agent to discover a solution you did not anticipate.

19
00:01:04.172 --> 00:01:06.006
Start with an indirect prompt.

20
00:01:06.716 --> 00:01:09.148
Ask the agent to read the issue and restate the

21
00:01:09.158 --> 00:01:12.394
underlying problem in its own words before changing anything.

22
00:01:13.672 --> 00:01:15.962
This compresses a noisy conversation into

23
00:01:15.972 --> 00:01:17.876
a problem statement you can inspect.

24
00:01:18.587 --> 00:01:20.263
It also exposes a red herring

25
00:01:20.273 --> 00:01:22.342
before the agent turns it into code.

26
00:01:23.630 --> 00:01:26.431
Avoid embedding your favorite diagnosis in the question.

27
00:01:27.142 --> 00:01:30.225
For example, workers time out is an observation.

28
00:01:30.939 --> 00:01:32.875
The database needs a larger timeout

29
00:01:32.885 --> 00:01:35.367
is a hypothesis, not yet a conclusion.

30
00:01:37.047 --> 00:01:39.624
The article describes four complementary skills.

31
00:01:40.334 --> 00:01:43.497
How traces runtime mechanics: what calls what, where

32
00:01:43.507 --> 00:01:45.965
state lives, and how the subsystem behaves.

33
00:01:47.255 --> 00:01:50.563
Why investigates motivation using evidence such as commits,

34
00:01:50.628 --> 00:01:54.879
review comments, issues, conversations, errors, and analytics.

35
00:01:55.602 --> 00:01:59.994
Teach combines mechanics and rationale into an explanation you can understand.

36
00:02:01.297 --> 00:02:04.565
Recall retrieves relevant earlier conversations, so a

37
00:02:04.575 --> 00:02:07.305
fresh agent does not repeat old investigations.

38
00:02:08.028 --> 00:02:10.105
Teaching helps the agent too, because

39
00:02:10.115 --> 00:02:13.352
explaining its reasoning can reveal unsupported assumptions.

40
00:02:15.047 --> 00:02:18.422
For an ambiguous production bug, request three things: what we

41
00:02:18.432 --> 00:02:21.550
know, the data supporting it, and the best hypotheses.

42
00:02:22.261 --> 00:02:24.920
This is one of the article's practical examples.

43
00:02:26.214 --> 00:02:27.941
Keep these categories separate.

44
00:02:28.652 --> 00:02:32.549
A plausible explanation should not quietly become an established fact.

45
00:02:33.263 --> 00:02:36.618
Use the code and historical evidence to narrow the uncertainty.

46
00:02:37.922 --> 00:02:40.094
The outcome of research is a grounded problem

47
00:02:40.104 --> 00:02:43.600
statement and constraints, not merely a confident sounding answer.

48
00:02:45.297 --> 00:02:47.374
Once the problem is understood, work

49
00:02:47.384 --> 00:02:49.371
backwards from the experience you want.

50
00:02:50.094 --> 00:02:52.879
For a shared package, the article recommends readme

51
00:02:52.889 --> 00:02:56.538
driven development: write the user facing documentation first.

52
00:02:57.839 --> 00:02:59.786
A tutorial forces you to ask what a

53
00:02:59.796 --> 00:03:02.125
developer must do to get a visible result.

54
00:03:02.836 --> 00:03:04.901
That makes awkward APIs and missing

55
00:03:04.911 --> 00:03:07.559
concepts easier to spot before implementation.

56
00:03:08.880 --> 00:03:12.164
The tutorial becomes a concrete target the agent can check.

57
00:03:12.875 --> 00:03:15.035
You are specifying the outcome and the caller's

58
00:03:15.045 --> 00:03:18.317
experience, rather than over prescribing the internals.

59
00:03:20.005 --> 00:03:22.307
The article uses the Diataxis framework

60
00:03:22.317 --> 00:03:24.622
to keep four documentation modes separate.

61
00:03:25.333 --> 00:03:27.626
A tutorial teaches a newcomer by doing.

62
00:03:28.352 --> 00:03:31.930
A how-to guide helps an experienced user solve a specific problem.

63
00:03:33.255 --> 00:03:37.495
Reference is the complete technical description of an API or configuration.

64
00:03:38.217 --> 00:03:42.209
Explanation discusses background, design choices, and tradeoffs.

65
00:03:43.505 --> 00:03:45.512
The technical writing skill separates these

66
00:03:45.522 --> 00:03:48.558
modes, and the unslop skill improves readability.

67
00:03:49.269 --> 00:03:51.523
Choose the document that serves the immediate goal

68
00:03:51.533 --> 00:03:54.570
instead of mixing all four into one sprawling readme.

69
00:03:56.255 --> 00:03:59.716
The article combines these ideas in a virtualization example.

70
00:04:00.439 --> 00:04:03.778
First, recall recent bug fixes and investigate how

71
00:04:03.788 --> 00:04:06.294
and why the existing virtualized list works.

72
00:04:07.589 --> 00:04:09.937
Next, use that context to propose a new

73
00:04:09.947 --> 00:04:13.003
design, beginning with a tutorial showing how a developer

74
00:04:13.013 --> 00:04:14.953
would use the package in a React app.

75
00:04:16.255 --> 00:04:19.807
Finally, ask the agent to explain the tradeoffs and demonstrate

76
00:04:19.817 --> 00:04:22.016
why the approach is better than the current engine.

77
00:04:22.727 --> 00:04:24.085
Better is something to show through

78
00:04:24.095 --> 00:04:26.471
verification, not a label to assert.

79
00:04:28.172 --> 00:04:30.654
Two opposite mistakes produce weak designs.

80
00:04:31.365 --> 00:04:33.375
One is accepting the first proposal.

81
00:04:34.101 --> 00:04:38.022
The other is endlessly refining an abstract plan without running anything.

82
00:04:39.339 --> 00:04:42.328
The article's alternative is prototyping: use cheap,

83
00:04:42.440 --> 00:04:44.969
throwaway code to answer a concrete question.

84
00:04:45.680 --> 00:04:48.858
Planning becomes an experiment, not just a conversation.

85
00:04:50.172 --> 00:04:53.806
Give the agent room to try genuinely different approaches, and judge

86
00:04:53.816 --> 00:04:57.583
what the prototypes reveal rather than how persuasive the proposal sounds.

87
00:04:59.255 --> 00:05:02.394
For a dropdown interaction, the article suggests two

88
00:05:02.404 --> 00:05:04.650
or three variants behind a simple switcher.

89
00:05:05.361 --> 00:05:07.607
Drive the real interaction, record it,

90
00:05:07.696 --> 00:05:10.355
and compare screenshots and relevant measurements.

91
00:05:11.672 --> 00:05:14.425
Use the same task and conditions for each variant.

92
00:05:15.136 --> 00:05:17.367
Decide what you are trying to learn, such as

93
00:05:17.377 --> 00:05:20.342
whether the menu remains usable in a constrained layout.

94
00:05:21.630 --> 00:05:23.429
The prototypes are disposable.

95
00:05:24.151 --> 00:05:26.453
Their purpose is to replace open questions with

96
00:05:26.463 --> 00:05:28.850
observations and help you choose a design.

97
00:05:29.564 --> 00:05:33.060
This applies to backend behavior as well as visual interfaces.

98
00:05:34.755 --> 00:05:37.835
One distinction matters: p-stack playbooks are reference

99
00:05:37.845 --> 00:05:40.999
files inside poteto mode, not separate skills.

100
00:05:41.710 --> 00:05:44.464
The agent loads the relevant playbook for the task.

101
00:05:45.755 --> 00:05:47.762
For example, ask poteto mode to

102
00:05:47.772 --> 00:05:49.959
prototype a few options for a feature.

103
00:05:50.670 --> 00:05:53.302
The workflow organizes exploration and uses

104
00:05:53.312 --> 00:05:55.605
verification tools to inspect the result.

105
00:05:56.922 --> 00:05:58.929
You do not need to manually invoke every

106
00:05:58.939 --> 00:06:02.164
ingredient when the established workflow already selects it.

107
00:06:03.880 --> 00:06:07.479
For larger changes, the architect skill structures the work into five

108
00:06:07.489 --> 00:06:12.719
phases: ground the problem, sketch competing designs, cross judge and synthesize,

109
00:06:12.819 --> 00:06:16.127
implement, and scrap the design if evidence shows it is wrong.

110
00:06:17.422 --> 00:06:20.234
This is a loop, not a one way approval ceremony.

111
00:06:20.945 --> 00:06:23.883
Architecture starts from how the affected systems actually

112
00:06:23.893 --> 00:06:26.258
work and what their ownership boundaries allow.

113
00:06:27.547 --> 00:06:29.801
The goal is a coherent interface and data

114
00:06:29.811 --> 00:06:33.036
model before the agent fills in the implementation details.

115
00:06:34.714 --> 00:06:36.944
In the sketch phase, independent candidate

116
00:06:36.954 --> 00:06:39.118
runners receive the same grounding brief.

117
00:06:39.829 --> 00:06:41.733
They may use different model families,

118
00:06:41.834 --> 00:06:44.233
and each produces a complete design package.

119
00:06:45.547 --> 00:06:48.367
That package contains a caller usage sketch, core

120
00:06:48.377 --> 00:06:51.968
types, public function signatures, and a concise rationale.

121
00:06:52.679 --> 00:06:54.308
The signatures should follow from how

122
00:06:54.318 --> 00:06:55.868
the call sites ought to look.

123
00:06:57.172 --> 00:07:00.370
The candidates also examine interface depth, design red

124
00:07:00.380 --> 00:07:03.027
flags, and failure modes with weaker models.

125
00:07:03.738 --> 00:07:05.355
The contract must be usable in

126
00:07:05.365 --> 00:07:07.753
practice, not just elegant on paper.

127
00:07:09.422 --> 00:07:11.299
A cross judge using a different model

128
00:07:11.309 --> 00:07:14.039
evaluates the candidates against a strict rubric.

129
00:07:14.761 --> 00:07:16.485
The point is to challenge the designs

130
00:07:16.495 --> 00:07:19.413
before selecting and combining their strongest ideas.

131
00:07:20.714 --> 00:07:24.186
Do not confuse this with adversarially reviewing a vague plan.

132
00:07:24.909 --> 00:07:27.069
The article warns that abstract debate

133
00:07:27.079 --> 00:07:30.339
can invent theoretical risks and unnecessary complexity.

134
00:07:31.630 --> 00:07:34.950
Use executable prototypes to settle real uncertainties.

135
00:07:35.661 --> 00:07:39.000
Different models provide competing perspectives; empirical

136
00:07:39.010 --> 00:07:41.515
evidence still decides whether the design works.

137
00:07:43.214 --> 00:07:46.852
Implementation replaces the sketch's placeholders with real logic.

138
00:07:47.562 --> 00:07:50.465
If it suddenly needs extra parameters or unexplained

139
00:07:50.475 --> 00:07:53.936
shared state, surface that discrepancy instead of hiding it.

140
00:07:55.255 --> 00:07:59.408
The article highlights repeated workarounds across unrelated callers and forced

141
00:07:59.418 --> 00:08:02.006
casts as evidence that the design may be wrong.

142
00:08:02.729 --> 00:08:05.247
Investigate the model, not just the symptom.

143
00:08:06.547 --> 00:08:08.298
When the architecture does not fit,

144
00:08:08.387 --> 00:08:10.315
throw away the sketch and start again.

145
00:08:11.037 --> 00:08:13.421
Do not preserve a bad boundary merely because

146
00:08:13.431 --> 00:08:15.276
effort has already been spent on it.

147
00:08:16.964 --> 00:08:18.652
A tactical plan comes after you

148
00:08:18.662 --> 00:08:20.283
have a design you are happy with.

149
00:08:21.006 --> 00:08:23.001
The multi phase planning playbook breaks

150
00:08:23.011 --> 00:08:26.070
it into small, self contained, reviewable changes.

151
00:08:27.380 --> 00:08:30.558
Each task is organized around proof and verification.

152
00:08:31.269 --> 00:08:33.795
Tests are useful, but the article says tests

153
00:08:33.805 --> 00:08:36.519
alone are not sufficient: the agent must actually

154
00:08:36.529 --> 00:08:38.445
run the code and check that it works.

155
00:08:39.714 --> 00:08:42.844
The playbook also checks the plan's structure automatically.

156
00:08:43.567 --> 00:08:47.260
Temporary plans can coordinate large projects, but the author does

157
00:08:47.270 --> 00:08:50.094
not keep them as permanent competing sources of truth.

158
00:08:51.797 --> 00:08:55.034
Consider the article's UI library migration example.

159
00:08:55.757 --> 00:08:58.274
The request is not to improve the interface.

160
00:08:58.988 --> 00:09:00.605
It is to move the implementation

161
00:09:00.615 --> 00:09:03.463
while preserving the original result, bugs included.

162
00:09:04.755 --> 00:09:08.366
A useful execution unit therefore needs a baseline, a bounded

163
00:09:08.376 --> 00:09:12.650
slice of migration, and visual regression plus live verification steps.

164
00:09:13.964 --> 00:09:16.446
This shows why the acceptance target matters.

165
00:09:17.157 --> 00:09:19.529
If preserving behavior is the contract, an

166
00:09:19.539 --> 00:09:22.021
attractive redesign is still the wrong result.

167
00:09:23.714 --> 00:09:28.342
For an ambiguous bug, investigate first and report evidence and hypotheses.

168
00:09:29.053 --> 00:09:32.852
For a new webhook rate limiting boundary, architect first, answer

169
00:09:32.862 --> 00:09:36.724
open questions with prototypes, and review the design before proceeding.

170
00:09:38.005 --> 00:09:41.325
For a reported regression, reproduce it on the baseline branch,

171
00:09:41.425 --> 00:09:44.662
fix it if confirmed, and show the real behavior afterward.

172
00:09:45.385 --> 00:09:48.468
The article gives a video as one useful form of proof.

173
00:09:49.755 --> 00:09:51.856
Short prompts can work when the context is

174
00:09:51.866 --> 00:09:54.278
already rich and the workflow is established.

175
00:09:54.989 --> 00:09:56.323
Do it is a shorthand for a

176
00:09:56.333 --> 00:09:59.004
grounded process, not a replacement for one.

177
00:10:00.714 --> 00:10:01.592
Quick check.

178
00:10:02.303 --> 00:10:05.080
An agent presents a convincing architecture plan.

179
00:10:05.794 --> 00:10:07.682
You have not tried alternatives, and

180
00:10:07.692 --> 00:10:10.280
the key usability question remains unanswered.

181
00:10:11.006 --> 00:10:12.568
What is the best next move?

182
00:10:13.839 --> 00:10:16.140
Add more detail to the same plan, try

183
00:10:16.150 --> 00:10:19.646
competing prototypes, or implement the entire design immediately?

184
00:10:20.369 --> 00:10:22.037
Pause here and make your choice.

185
00:10:23.339 --> 00:10:25.007
Try competing prototypes.

186
00:10:25.718 --> 00:10:28.868
Make the uncertain behavior observable, compare the options

187
00:10:28.878 --> 00:10:31.514
fairly, and use the result to choose the design.

188
00:10:32.227 --> 00:10:34.403
More prose would not answer the question.

189
00:10:36.130 --> 00:10:37.799
Here is the workflow to remember.

190
00:10:38.510 --> 00:10:41.169
Restate the problem without leading the diagnosis.

191
00:10:41.882 --> 00:10:45.131
Ground it in code, history, and relevant earlier work.

192
00:10:45.845 --> 00:10:48.327
Design backwards from the user's experience.

193
00:10:49.630 --> 00:10:51.464
Prototype real alternatives.

194
00:10:52.175 --> 00:10:54.421
Sketch contracts for larger changes.

195
00:10:55.135 --> 00:10:58.214
Let implementation expose design mistakes, and then

196
00:10:58.224 --> 00:11:00.801
execute in small units with observable proof.

197
00:11:02.089 --> 00:11:03.816
That is the article's core lesson:

198
00:11:04.023 --> 00:11:06.293
rigorous planning is not a longer document.

199
00:11:07.003 --> 00:11:10.016
It is a process that turns uncertainty into evidence.

200
00:11:10.742 --> 00:11:14.828
Source: Lauren at poteto, The Complete Guide to p-stack, Part Two.