From 750353aba6797fc827d54f787e199ff85efa3a02 Mon Sep 17 00:00:00 2001 From: Bill Date: Thu, 30 Apr 2026 19:01:42 +0000 Subject: [PATCH] Add full WhetstoneRSA cost story deck --- .../whetstoneRSA_full_story_deck.html | 935 ++++++++++++++++++ presentations/whetstoneRSA_overkill_deck.html | 725 ++++++++++++++ 2 files changed, 1660 insertions(+) create mode 100644 presentations/whetstoneRSA_full_story_deck.html create mode 100644 presentations/whetstoneRSA_overkill_deck.html diff --git a/presentations/whetstoneRSA_full_story_deck.html b/presentations/whetstoneRSA_full_story_deck.html new file mode 100644 index 0000000..9060160 --- /dev/null +++ b/presentations/whetstoneRSA_full_story_deck.html @@ -0,0 +1,935 @@ + + + + + +WhetstoneRSA - When LLMs Are Overkill + + + +
+ +
+
WhetstoneRSA
+
+

Product Spec In. Program Out.

+

Then make the planning layer local, cheaper, and repeatable.

+
+ +
+ +
+
The thing that matters
+
+

A working program in about five minutes.

+

That is already a different software-building experience.

+
+ +
+ +
+
Comparison I watched
+
+
+
30minutes agent loop
+
5minutes AST-first pipeline
+
+

Same general class of app-building demo.

+
+ +
+ +
+
Important distinction
+
+

AST-first generation created the speedup.

+

RSA attacks the remaining repeated LLM decisions.

+
+ +
+ +
+
Why AST-first is fast
+
+
    +
  • plan into structured work
  • +
  • generate from AST shape
  • +
  • validate against contracts
  • +
  • avoid long wandering agent loops
  • +
+
+ +
+ +
+
The remaining model work
+
+

The pipeline still has planning decisions.

+

Task splits, target files, required tools, acceptance checks, prep gates.

+
+ +
+ +
+
The starting point
+
+

LLMs are amazing.

+

But many software decisions are smaller than an LLM.

+
+ +
+ +
+
The shape
+
+
The input can be huge.
+
The output is small.
+
+ +
+ +
+
Example request
+
+

show me the failed builds from yesterday

+
+ +
+ +
+
Same intent, many phrasings
+
+
    +
  • what broke in CI yesterday
  • +
  • pull up yesterday's red builds
  • +
  • did the pipeline fail last night
  • +
  • which build jobs failed since yesterday
  • +
+
+ +
+ +
+
What the app actually needs
+
+
+
action
search_builds
+
status
failed
+
date
yesterday
+
+
+ +
+ +
+
Output scale
+
+
5 actions x 4 statuses x 4 date buckets
+= about 80 structured outputs
+
+ +
+ +
+
Classical code starts well
+
+
if text has "failed" and "build":
+    action = search_builds
+
+if text has "yesterday":
+    date = yesterday
+
+ +
+ +
+
Then regex pays the human tax
+
+

You enumerate the input side.

+

Every new phrase becomes another pattern, exception, or bug.

+
+ +
+ +
+
Rule explosion
+
+
5 actions
+x 10 common phrasings
+x 4 statuses
+x 8 time phrasings
+= 1,600-ish rule cases
+
+ +
+ +
+
Regex tradeoff
+
+
    +
  • excellent output control
  • +
  • tiny runtime cost
  • +
  • input coverage gets expensive
  • +
+
+ +
+ +
+
LLMs feel easy
+
+

They understand the messy input.

+

One prompt can replace a pile of brittle phrase rules.

+
+ +
+ +
+
But the scale is wrong
+
+

A giant general model

+

choosing from a tiny application menu.

+
+ +
+ +
+
API runtime scale
+
+ + + + + +
ModelInputOutput
gpt-5.4-mini$0.75 / 1M tokens$4.50 / 1M tokens
gpt-5.4$2.50 / 1M tokens$15 / 1M tokens
gpt-5.5$5 / 1M tokens$30 / 1M tokens
+
+ +
+ +
+
WhetstoneDSL example set
+
+
+
100easy programs
+
25challenging programs
+
+

125 product specs used as generation/evaluation examples.

+
+ +
+ +
+
Measured extraction slice
+
+ + + + + + +
ArtifactCount
runs999
taskitems1,321
extracted gate rows5,284
gates per taskitem4 extracted
+
+ +
+ +
+
125 programs implies
+
+
125 programs x 1.32 taskitems/program
+= ~165 taskitems
+
+~165 taskitems x 10+ planning decisions
+= ~1,650+ decisions
+
+ +
+ +
+
Planning-only token estimate
+
+
125 specs:
+~56K planning input tokens
+~99K planning output tokens
+
+This is before implementation calls.
+
+ +
+ +
+
125-program planning cost
+
+ + + + + +
ModelPlanning-only estimate
gpt-5.4-mini~$0.49
gpt-5.4~$1.63
gpt-5.5~$3.25
+
+ +
+ +
+
Add implementation calls
+
+
165 taskitems
+x 5K input + 2K output tokens
+= ~826K input + ~330K output
+
+Still a modest example.
+
+ +
+ +
+
Estimated API cost
+
+ + + + + +
ModelModerate tasksHeavier tasks
gpt-5.4-mini~$2.60~$6.70
gpt-5.4~$8.65~$22.30
gpt-5.5~$17.30~$44.60
+
+ +
+ +
+
Scale changes the economics
+
+

At codebase scale, token spend becomes infrastructure spend.

+

Retries, larger context, regressions, and many users multiply the meter.

+
+ +
+ +
+
Team-scale intuition
+
+
$20 per substantial generation run
+x 10,000 runs/month
+= $200,000/month
+
+before engineer review time
+
+ +
+ +
+
Different cost shape
+
+

From recurring token meter

+

toward a few good GPUs, local gates, and occasional subscriptions.

+
+ +
+ +
+
My original plan
+
+

Use LoRA on a local SLM.

+

Adapt a small language model to WhetstoneDSL decisions.

+
+ +
+ +
+
LoRA still carries the base model
+
+
    +
  • 1B / 3B / 7B parameter base
  • +
  • adapter is small
  • +
  • runtime model is still big
  • +
+
+ +
+ +
+
The better question
+
+

Was the task ever large enough to deserve that model?

+
+ +
+ +
+
Where this came from
+
+

WhetstoneDSL

+

AST-first programming and universal transpiling

+
+ +
+ +
+
What a taskitem is
+
+
    +
  • a small implementation work packet
  • +
  • title, requirements, constraints
  • +
  • acceptance criteria and dependencies
  • +
+
+ +
+ +
+
Taskitems need prep decisions
+
+

What has to happen before this task runs?

+
+ +
+ +
+
The prep checklist
+
+
    +
  • validate the intake
  • +
  • resolve dependencies
  • +
  • send to architect review
  • +
+
+ +
+ +
+
In the repo
+
+

prereq_op_selector

+

picks the prerequisite operations for a taskitem

+
+ +
+ +
+
Tiny transformer gate
+
+

Learn the messy input.

+

Keep the output menu fixed.

+
+ +
+ +
+
Actual training cost
+
+
+
3 to 5minutes
+
3060RTX GPU
+
+

per transformer gate

+
+ +
+ +
+
Local gate cost shape
+
+
10 planning gates
+x 3 to 5 minutes each
+= ~30 to 50 minutes one-time training
+
+then local inference
+
+ +
+ +
+
Decision runtime intuition
+
+
training speed proxy:
+4000 steps / 3 to 5 min
+= ~13 to 22 steps/sec
+
+1,650 planning decisions
+= minutes, not token invoices
+
+ +
+ +
+
Actual model scale
+
+
+
213Kparameters
+
800KBcheckpoint
+
+

one specialist per small gate

+
+ +
+ +
+
Training data source
+
+

LLM as scaffolding.

+

Use it to bootstrap examples, not to sit in every runtime decision.

+
+ +
+ +
+
Synthetic data can help
+
+
    +
  • generate taskitem variants
  • +
  • assign known labels
  • +
  • oversample edge cases
  • +
  • train the tiny gate directly
  • +
+
+ +
+ +
+
First extracted dataset
+
+
+
1297clean rows
+
1102train
+
195eval
+
+
+ +
+ +
+
The data caught a design mistake
+
+

needs_validate_intake

+

was always true: 1297 / 1297

+
+ +
+ +
+
Split the gate
+
+
+
Gate 1
resolve dependencies?
+
Gate 2
architect review?
+
+
+ +
+ +
+
First results
+
+ + + + +
GateAccuracyTraining
resolve dependencies69.4%3-5 min on 3060
architect review75.0%3-5 min on 3060
+
+ +
+ +
+
What we learned
+
+

1297 rows did not mean 1297 different examples.

+

There were only about 17 unique text templates.

+
+ +
+ +
+
The comparison
+
+ + + + + +
ApproachInput handlingRuntimeOutput control
Regexmanual enumerationtinyexcellent
LLM / SLM + LoRAeasybase model still runsneeds guardrails
Tiny gate transformerlearned~800KB specialistfixed output head
+
+ +
+ +
+
Final claim
+
+
+
AST-first gets the program out fast.
+
RSA makes the repeated planning local.
+
+
+ +
+ +
+
Number sources
+
+
    +
  • taskitem counts: extracted WhetstoneRSA rows
  • +
  • 10+ decisions/taskitem: pipeline audit
  • +
  • 3 to 5 min/gate: RTX 3060 training run
  • +
  • API prices: OpenAI model docs, Apr 2026
  • +
+
+ +
+ +
+
End state
+
+

Product spec in.

+

Program out.

+

Faster, cheaper, more predictable each time the gates move local.

+
+ +
+ +
+ +
Click / arrows: navigate · N: notes · F: fullscreen
+
+
+ + + + diff --git a/presentations/whetstoneRSA_overkill_deck.html b/presentations/whetstoneRSA_overkill_deck.html new file mode 100644 index 0000000..0732e6a --- /dev/null +++ b/presentations/whetstoneRSA_overkill_deck.html @@ -0,0 +1,725 @@ + + + + + +WhetstoneRSA - When LLMs Are Overkill + + + +
+ +
+
WhetstoneRSA
+
+

When LLMs Are Overkill

+

Messy input, small menu, local transformer gate

+
+ +
+ +
+
The starting point
+
+

LLMs are amazing.

+

But many software decisions are much smaller than an LLM.

+
+ +
+ +
+
The shape
+
+
The input can be huge.
+
The output is small.
+
+ +
+ +
+
Example request
+
+

show me the failed builds from yesterday

+
+ +
+ +
+
Same intent, many phrasings
+
+
    +
  • what broke in CI yesterday
  • +
  • pull up yesterday's red builds
  • +
  • did the pipeline fail last night
  • +
  • which build jobs failed since yesterday
  • +
+
+ +
+ +
+
What the app actually needs
+
+
+
action
search_builds
+
status
failed
+
date
yesterday
+
+
+ +
+ +
+
Output scale
+
+
5 actions x 4 statuses x 4 date buckets
+= about 80 structured outputs
+
+ +
+ +
+
Classical code starts well
+
+
if text has "failed" and "build":
+    action = search_builds
+
+if text has "yesterday":
+    date = yesterday
+
+ +
+ +
+
Then regex pays the human tax
+
+

You enumerate the input side.

+

Every new phrase becomes another pattern, exception, or bug.

+
+ +
+ +
+
Rule explosion
+
+
5 actions
+x 10 common phrasings
+x 4 statuses
+x 8 time phrasings
+= 1,600-ish rule cases
+
+ +
+ +
+
Regex tradeoff
+
+
    +
  • excellent output control
  • +
  • tiny runtime cost
  • +
  • input coverage gets expensive
  • +
+
+ +
+ +
+
LLMs feel easy
+
+

They understand the messy input.

+

One prompt can replace a pile of brittle phrase rules.

+
+ +
+ +
+
But the scale is wrong
+
+

A giant general model

+

choosing from a tiny application menu.

+
+ +
+ +
+
API runtime scale
+
+ + + + + +
ModelInputOutput
GPT-4.1$2 / 1M tokens$8 / 1M tokens
GPT-4.1 mini$0.40 / 1M tokens$1.60 / 1M tokens
GPT-4.1 nano$0.10 / 1M tokens$0.40 / 1M tokens
+
+ +
+ +
+
Fine-tuning scale
+
+ + + + +
Fine-tuned modelTrainingRuntime inputRuntime output
GPT-4.1 mini$5 / 1M tokens$0.80 / 1M$3.20 / 1M
GPT-4.1 nano$1.50 / 1M tokens$0.20 / 1M$0.80 / 1M
+
+ +
+ +
+
My original plan
+
+

Use LoRA on a local SLM.

+

Adapt a small language model to WhetstoneDSL decisions.

+
+ +
+ +
+
LoRA still carries the base model
+
+
    +
  • 1B / 3B / 7B parameter base
  • +
  • adapter is small
  • +
  • runtime model is still big
  • +
+
+ +
+ +
+
The better question
+
+

Was the task ever large enough to deserve that model?

+
+ +
+ +
+
Where this came from
+
+

WhetstoneDSL

+

AST-first programming and universal transpiling

+
+ +
+ +
+
What a taskitem is
+
+
    +
  • a small implementation work packet
  • +
  • title, requirements, constraints
  • +
  • acceptance criteria and dependencies
  • +
+
+ +
+ +
+
Taskitems need prep decisions
+
+

What has to happen before this task runs?

+
+ +
+ +
+
The prep checklist
+
+
    +
  • validate the intake
  • +
  • resolve dependencies
  • +
  • send to architect review
  • +
+
+ +
+ +
+
In the repo
+
+

prereq_op_selector

+

picks the prerequisite operations for a taskitem

+
+ +
+ +
+
Tiny transformer gate
+
+

Learn the messy input.

+

Keep the output menu fixed.

+
+ +
+ +
+
Actual training cost
+
+
+
3 to 5minutes
+
3060RTX GPU
+
+

per transformer gate

+
+ +
+ +
+
Actual model scale
+
+
+
213Kparameters
+
800KBcheckpoint
+
+

one specialist per small gate

+
+ +
+ +
+
Training data source
+
+

LLM as scaffolding.

+

Use it to bootstrap examples, not to sit in every runtime decision.

+
+ +
+ +
+
Synthetic data can help
+
+
    +
  • generate taskitem variants
  • +
  • assign known labels
  • +
  • oversample edge cases
  • +
  • train the tiny gate directly
  • +
+
+ +
+ +
+
First extracted dataset
+
+
+
1297clean rows
+
1102train
+
195eval
+
+
+ +
+ +
+
The data caught a design mistake
+
+

needs_validate_intake

+

was always true: 1297 / 1297

+
+ +
+ +
+
Split the gate
+
+
+
Gate 1
resolve dependencies?
+
Gate 2
architect review?
+
+
+ +
+ +
+
First results
+
+ + + + +
GateAccuracyTraining
resolve dependencies69.4%3-5 min on 3060
architect review75.0%3-5 min on 3060
+
+ +
+ +
+
What we learned
+
+

1297 rows did not mean 1297 different examples.

+

There were only about 17 unique text templates.

+
+ +
+ +
+
The comparison
+
+ + + + + +
ApproachInput handlingRuntimeOutput control
Regexmanual enumerationtinyexcellent
LLM / SLM + LoRAeasybase model still runsneeds guardrails
Tiny gate transformerlearned~800KB specialistfixed output head
+
+ +
+ +
+
Final claim
+
+
+
LoRA adapts a large model to the task.
+
WhetstoneRSA asks whether the task deserved the large model.
+
+
+ +
+ +
+ +
Click / arrows: navigate · N: notes · F: fullscreen
+
+
+ + + +