Growing Software Like Ripples in a Pond

Throw a stone in a pond. Watch the rings. The first is just the drop: small, certain. Each ring after is born from the one before it, spreading outward until it reaches the shore and the water goes still.

I've spent the last stretch building a coding tool around that image. You give it one sentence that says what you want, plus the rules it must obey. It builds the thinnest thing that actually runs, then grows outward in rings: skeleton, then the seams between the parts, then the depth, then the edges. It keeps going until there's nothing left to implement and the wave reaches the shore. It's called Gluk: the sound the stone makes when it hits the water.

I could tell you it works. It does. I've watched it grow a working web app, a double-entry ledger, and a real woodworking cut-optimizer from one sentence each, live. But that's not the interesting part. The interesting part is what building it taught me, because the lessons weren't about whether AI can write code (it can, fine). They were about the shape of the collaboration, and about the one thing that quietly decides everything.

Neither a spec nor a loop

Every AI-coding tool I looked at sits at one of two extremes. On one side, spec-driven: write a big specification up front, then have the model execute it. That's waterfall wearing a new coat: the spec is the bottleneck, and you've front-loaded all the guessing. On the other side, the autonomous loop: point a model at a goal and let it churn until it stops. That's momentum without a rudder.

Gluk is neither. Nobody writes a task list. Each ring is derived from the one before it. The running skeleton reveals its own seams; those seams reveal the modules they need; the modules reveal the primitives beneath them. The wave stops on its own when everything it reveals already exists. You get a rigorous definition of "done" (the wavefront is empty) without ever enumerating the work.

Two moves make it more than a code generator. Reflection: when a test fails, the failure travels back inward like a wave bouncing off the shore, and how deep it reaches tells you how fundamental the mistake was: a wrong function body, a wrong architecture, or a wrong idea. And interference: throw a second stone (a new feature) and Gluk changes only the files where the two waves overlap. Adding auth to a URL shortener it had grown touched the routing and the storage and nothing else; the redirect path stayed byte-for-byte identical. Integration cost drops from "the whole system" to "the overlap."

The day it lied to me

Here's the part I keep coming back to.

I pointed Gluk at something real: a saw-kerf cut optimizer, the kind of tool my shop actually needs. It grew the whole thing, wrote its own tests, ran them, and reported: shore verified. Green.

The tool was useless. It placed one part per sheet: eleven sheets for a job that fits on two, 90% waste. And it passed every test, because the tests checked validity (no overlapping parts, everything placed) and never checked the actual objective (minimize waste). The tool was structurally perfect and semantically worthless, and nothing in the system knew the difference.

An AI system only achieves what it can verify. Prose intent is not an enforced invariant.

That failure reorganized how I think about all of this. "Minimize waste" written in prose is a wish. Nothing enforces it. The model will faithfully build to whatever the tests actually enforce, and silently skip whatever they don't.

So I built a critic: a second shore, this one semantic. Before declaring anything done, it judges the output against the drop's objectives, finds the most important one no test enforces, and writes the failing test itself. On the broken optimizer it flagged "minimize waste" as unverified, wrote a real efficiency test, and handed it to reflection, which then fixed the packer. The gap I'd had to catch by hand became something the tool catches on its own.

I'm telling you about the failure because it's the whole point. Anyone can demo the success. What separates a tool you can trust from a tool you can't is whether it tells you the truth, and whether you remember that it's only as smart as what you asked it to check.

What the map showed me

At one point I turned the whole codebase into a knowledge graph, with every design concept wired to the code that implements it. It surfaced something I hadn't seen: one tiny function, the JSON parser that reads the model's replies, was the single busiest crossing in the entire system. Every mechanism passed through it. It was the membrane between "the AI is talking" and "the machine is acting": the exact point where untrusted text becomes structured action.

So that's where I spent the next round of hardening: validate everything the model says at that seam, and on a mismatch, hand the error back and make it try again. Harden one function, and every mechanism gets more trustworthy at once. The graph found the one spot where a single fix pays off everywhere. I'd never have guessed it.

The same map showed the framework's hardest idea, reconciling where modules meet, and reminded me that the worst class of bug is two modules that each look correct but disagree about a shared convention. (The kerf bug was exactly this: one module thought the gap between parts was one blade-width, the other thought two.) So now, when Gluk reveals a shared interface, it also freezes a one-line contract (the convention every caller must honor) and carries it to everyone who touches it. It doesn't make that bug impossible, but it turns it from a human-required dead-end into something reflection fixes in one shot.

What it's actually for

I'll be honest about the shape of it, because honesty is the only version worth publishing.

Gluk gets you about 90% of the way to a working small tool, fast, and it tells you the truth about the other 10%. When it can't crack something, it says so and hands you the wheel. It doesn't ship a confident wrong answer. It shines on small, self-contained, new tools whose correctness you can state: internal utilities, data transforms, API glue, domain calculators. It's weak at surgery on large existing systems, useless for anything where "good" can't be tested, and it is not a replacement for the person who owns the last mile.

The skill it demands is writing a good center: the one sentence and the handful of rules. Everything the wave carries outward is an amplification of that. Gluk's ceiling is the quality of the drop.

You run it in one line now: gluk build "a sentence". It drafts the rules for you, grows the tool, tests it, fixes its own mistakes. A few minutes, a few cents.

The bigger point

We already have plenty of models that will happily generate a wall of code. The frontier is structure, the shape of the collaboration. And it is verification: being ruthlessly honest about what "done" and "good" actually mean, and encoding them where the machine can't route around them.

Build the pond, not the loop. Spend everything on the center. Verify at the edge. And keep a human at the shore.