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.