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

Model	Input	Output
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

Artifact	Count
runs	999
taskitems	1,321
extracted gate rows	5,284
gates per taskitem	4 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

Model	Planning-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

Model	Moderate tasks	Heavier 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

Gate	Accuracy	Training
resolve dependencies	69.4%	3-5 min on 3060
architect review	75.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

Approach	Input handling	Runtime	Output control
Regex	manual enumeration	tiny	excellent
LLM / SLM + LoRA	easy	base model still runs	needs guardrails
Tiny gate transformer	learned	~800KB specialist	fixed 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.