Deleting 20,000 lines of rules from the builder
Cutting code is one of the real pleasures of the work. One day in May I deleted a little over twenty thousand lines from the part of the platform that builds websites. The pages it produced afterward were better than before. That deletion was not a one-off cleanup. It was one of several across the platform. They all had the same cause. The creative work was never something rules could govern. So I stopped writing them.
A model now reasons out what a page should say, what a customer's next email should be, and whether there is any work worth doing at all. The code that is left does not make those calls. It carries them out. This is the largest change the platform has been through. The clearest way into it is the code I deleted to get there.
0+
lines deleted in one day
Why rules cannot govern creative work
A model that designs a website has, for any practical purpose, unlimited outputs. No two runs give the same page. When you are trying to ship something dependable, the instinct is to put rules around it. A rule to reject this layout. A check to repair that section. A nudge between one step and the next to pull the result back toward something acceptable. I wrote thousands of lines of exactly that. Every kind of creative work in the platform grew its own version of it.
That approach cannot be made to work. The reason is structural, not a shortage of effort. A deterministic rule needs a bounded set of cases to be right about. A creative model's output is not bounded. So the rules never finish covering it. The ones you do write collide. A rule tightened to fix one page breaks a different page nobody has seen yet. You never converge. You just keep patching, because the cases never stop coming.
And what the rules reliably produce is the one outcome creative work cannot afford. Conformity. A rule can only push every output toward the same safe middle. It makes a marketing site that reads like every other marketing site. Every rule passes. The site still fails. A rule can check that a section has a heading. It cannot tell you the page is dull. Only a reader can. The only reader that scales is a generative one.
No rules between the steps
The answer was not better rules between the steps. It was no rules between the steps.
The work is done by a chain of agents, each reasoning over what the one before it produced and handing its result straight to the next, with nothing in between reaching in to correct them. They draw their facts from the customer's own files so that nothing on the page is invented. At the end, other agents read the finished result and send it back to be reworked until it holds up. Whether the work is any good is itself a creative judgment. Only a model can make that judgment at scale. The reasoning runs free from the first step to the last. Only then does deterministic code take the finished result and build it.
Where the rules used to sit
The rules used to sit between the steps:
step ──▶ rule ──▶ step ──▶ rule ──▶ step ──▶ rule ──▶ out
Now nothing does. The steps reason straight through, and a generativejudge reads the finished result:
step ──▶ step ──▶ step ──▶ judge ──▶ outThat is the part that runs against instinct. The more of the reasoning you hand to the model, the less you have to steer it. The control was never buying reliability. It was costing quality.
The same shape, everywhere
None of this is particular to websites. It is how every creative surface in the platform works. I arrived there the same way each time, by deleting the rules that stood between the model and the work.
One part of the platform decides what is even worth doing at all. It reads everything a project already has and proposes what should exist next. I built it to lean on code that looked for what a project was missing. The plan was that code would decide whether a piece of work was needed and the model would only decide what it was. The model turned out to be better at both questions than my code was at the one it had. So its findings became a hint the model is free to ignore. The decision, whether and what, is the model's. The system is more autonomous than I designed it to be, and better for it. That drift, from code deciding to the model deciding, is the whole story in one subsystem.
Editing is the same move in miniature. A customer asks the platform to change a header. One agent works out what they meant, another writes the new state in full, and deterministic code applies it, keeping everything the customer did not touch exactly as it was. The agents decide the edit. The code only carries it out.
On email, the deletion is most of the story. It used to run on campaigns and segments and scheduled triggers, the ordinary deterministic machinery of marketing software. All of it is gone. Each email now carries a plain-language note about when it should go out. The model reads a customer's history against those notes and decides what to send and when. The rules that used to make that call were deleted. The model makes it.
One shape, every creative surface
One shape, every creative surface. Determinism sits on both edges of thereasoning and never inside it:
what work to do ─┐ a whole page │ a header edit ├──▶ gate ──▶ the model reasons ──▶ build a customer email ─┘ run? decides, writes, assemble, (code) judges, reworks schedule, nothing between deliver the steps (code)
deterministic generative deterministicWhere determinism lives
Determinism did not disappear. It moved to the edges, ahead of the reasoning and after it, where the answers really are fixed. Code schedules the pass that wakes the system up. Code surveys what a project has so the model has something concrete to reason over. Code takes an approved plan and turns a loose sense of timing into exact dates, files the records, and delivers each message once and only once. Code assembles a finished page into a working site. None of that is a creative judgment. All of it has a right answer.
Even the judging splits this way. When the system rates its own output, the model produces the score and deterministic code only applies the cutoff, keeping what clears it and rejecting what does not. The judgment is the model's. The cutoff is the code's. That division runs through the whole platform. Reasoning makes the decisions and code executes them. Nothing deterministic sits in the middle correcting the reasoning.
What it buys
This is the difference between a demo and a product, multiplied across every surface. Rules gave me capped, conforming output and a codebase that grew an edge case at a time, on the builder and the email system and everywhere else creative work happened. Autonomy gives output that is varied and good, systems that settle instead of ones you patch forever, and a great deal less code to carry. Every rule layer I deleted is a maintenance burden I will never pay again.
The output
Capped and conforming
Varied and good
The codebase
Grows an edge case at a time
Settles instead of patched forever
Code to carry
A rule layer on every surface
A great deal less
And none of it is particular to this platform. It is how you build on generative models at all. Put the reasoning in the model's hands and shape the result, rather than refereeing every step it takes to get there. The rules you add between the agents to hold them in line are exactly the rules that keep the work from being good. Give the model more and restrict it less. Hold determinism for the edges, where the answers are already fixed.
The platform I started with was a machine I programmed. The one I have now reasons out its own creative work, top to bottom. My code has moved to the outside of that reasoning, to carry out what it decides. That is not a smaller system doing less. It is a larger one that needs me to tell it far less. Autonomy did not cost me reliability. It is where the reliability came from.
Building something like this
I'm Jesse. I build platforms end to end, and I'm open to work. If this is the kind of engineering you need, get in touch.