CAD for Software | Ryan X. Charles Blog

Picture an engineering office before computers. Rows of drafting tables, tilted toward the window. Each one has a T-square, a set of triangles, sharp pencils and an eraser worn down to a stub. A draftsman draws one view of a part, then another view, then a section, by hand. If the engineer changes a dimension, the draftsman picks up the eraser and draws it again.

Now picture the same office with CAD. The engineer types a dimension into a model on a screen. The model updates. The drawings update with it. Nobody erases anything.

My workday looks like the second office. Last week I opened an issue to take my phone number off my CV. I wrote the goal, set every dial to automatic and went back to other work. An agent planned the change, made it, checked the PDF, recorded a Pass and closed the issue, in four commits. I did not type a line of code. I have not typed one since October 2025, and I wrote about why in April.

What I write instead is the design file. That is the idea of this post.

Engineers stopped drawing by hand

CAD did not make engineers stop designing. It made them stop drawing.

Before CAD, the drawing was the design. The lines on the paper were the only record of what the part should be. To change the part, you changed the lines. To make a second version, you drew a second set of lines. The skill of the job was partly engineering and partly penmanship, and the penmanship took most of the hours.

CAD moved the design out of the lines and into a model. The engineer now describes the part: its dimensions, the constraints between its features, the tolerances it must hold. The machine produces the drawings from that description. Change the description, and the machine draws again.

Antony Marcano explains the modern form of this well, in What Everyone Gets Wrong About AI Coding Agents and the “Dark Factory”. Mechanical CAD tools include a capability called parametric design. “With parametric design, engineers define constraints, parameters and relationships.” When a parameter changes, the CAD system changes the model to match.

That is the important shift. The valuable artifact stopped being the drawing. It became the description that produces the drawing. Drawings became cheap, because the machine could make a new set whenever the description changed. The description became the thing that engineers argued about, reviewed, versioned and protected.

Software is at the same turn

I did not invent this comparison, and I want to be clear about that. Marcano wrote this summer: “AI-augmented coding is our parametric-design moment for software engineering.” Back in March, in a community discussion on OpenAI’s Symphony repository called Adding an architectural context layer, the author juanpabloaj wrote: “The mental model is a multilayer CAD for software development.” That post is a community proposal, not an OpenAI statement, but it puts the idea in one sentence.

I have used other words for the same turn. In May I called it very high level programming: “The agent is the compiler.” That post walks up a ladder of abstraction: machine code, assembly, FORTRAN, C, Python, and then the agent. Martin Fowler made a similar point a year earlier, in LLMs bring new nature of abstraction: “I think the appearance of LLMs will change software development to a similar degree as the change from assembler to the first high-level programming languages.” Andrej Karpathy, in his 2025 talk Software Is Changing (Again), calls it Software 3.0: prompts written in plain English become programs.

The compiler ladder is a good picture, but it is a picture from inside software. CAD adds a picture from outside. It is the same move in a different field, made decades ago, and we can see how it turned out. Engineers did not lose their jobs to CAD. Draftsmen’s tables went away, and engineers spent their time on the model instead of the lines.

So here is the claim. A business owner or an engineer now writes the description: the goal, the rules and the checks. A team of super intelligent (SI) agents produces the code from it, and produces it again when the description changes. The spec and the checks are the design file. The code is the output.

What goes in the design file

The Symphony post has a line I like: “A CAD file is authoritative, layered, version-controlled, and continuously updated by the people doing the actual work.” Every part of that sentence applies to software. A good design file for software has layers, and each layer has a job.

The goal. What should be true when the work is done, in plain words. This is the part’s purpose. “Remove my phone number from the CV PDF” is a goal. “Improve the CV” is not, because no one can check it.
The rules. The conventions that apply to every part in the shop. In my repo, these live in AGENTS.md files, from the root of the monorepo down to each package. They say which language to use for scripts, how to name things, which commands only a human may run, how commits look and where each kind of file belongs. This is the CAD template: the units, the standards, the title block. You set them once, and every new part inherits them.
The checks. How we know the output is right. Tests, types, lint, a build, a screenshot, a review by a second agent that tries to reject the work. These are the tolerances. A part that is out of tolerance is scrap, no matter how good it looks.
The context. The history, the related code, the past decisions, the failed attempts. In my repo, each issue holds a series of experiments, and each experiment records its design, its evidence and its result. A dead end that is written down is a dead end that no agent walks down again.

OpenAI’s post on harness engineering describes a team that built a product with no code written by hand. Its point is that the people steer and the agents execute, and that the repository’s own docs, starting from AGENTS.md, are the map the agents work from. That is a design file by another name.

Simon Willison found a stronger example. In How StrongDM’s AI team build serious software without even looking at the code, he describes StrongDM’s Attractor repository. It “contains no code at all—just three markdown files describing the spec”. You give those specs to your coding agent, and the agent writes the code. The repository ships the design file and nothing else. It is the purest version of this idea I have seen.

Code is the output

In April I wrote: “A prompt is a compressed specification. Code is the decompression.” I estimated that ten lines of good English can unpack into a thousand lines of working code, a hundred-to-one ratio. That number is my own rough estimate, not a measurement. But the direction is not in doubt. The same post had a shorter line: “The code is exhaust.”

CAD makes that line easier to accept. Nobody in a modern engineering office treats a printed drawing as precious. If the drawing is wrong, you do not fix the drawing with an eraser. You fix the model and print again. A hand edit to the drawing is worse than useless, because the next print will overwrite it and the model will still be wrong.

The same rule now applies to code. When an agent ships a bug, the tempting move is to open the file and fix the line. Don’t. Ask what was missing from the design file. Was the goal unclear? Was a rule not written down? Was there no check that would have caught it? Fix that, and run the agent again. In May I put it this way: “Don’t edit the code, edit the spec.” The fix then survives the next regeneration, and every future change benefits from it.

This also explains why I do not read diffs anymore. I read the goal, the plan, the evidence and the product. The diff is a drawing. The design file and the checks are where I spend my attention, because that is where my attention changes the result.

What CAD did not remove

CAD did not remove engineering judgment. It removed drafting. Those are different things, and it is easy to confuse them.

A CAD system will happily model a bracket that cannot carry its load. It will dimension a part that no machine can cut. It will hold a tolerance that is far tighter than the job needs, and the part will cost ten times more. The model does what you describe. Describing the right thing is still the job.

Software is the same, with one big difference that Fowler names directly. Mechanical CAD is deterministic. Marcano says so himself: “Parametric CAD is deterministic. Given the same model, parameters and constraints, it will produce the same design.” He is careful about the limits of his own comparison: “So I’m not suggesting that AI coding agents are parametric CAD for software in any literal technical sense.” I agree with that caveat. CAD for software is an analogy, not a product category.

Fowler explains why. “Large Language Models introduce a non-deterministic abstraction, so I can’t just store my prompts in git and know that I’ll get the same behavior each time.” He quotes his colleague Birgitta Böckeler: “we’re not just moving up the abstraction levels, we’re moving sideways into non-determinism at the same time.”

That sideways step is why the checks belong in the design file, not next to it. If the same description can produce a different program each time, then the description alone does not define the part. The description plus the checks defines it. The checks are the tolerances that every regenerated output must hold.

Addy Osmani says it best, in Software Factories, Light and Dark: “Verification, not generation, is the real constraint on a factory.” Generation is cheap now. The machine will draw as many parts as you want. The hard part is knowing which ones are in tolerance.

And there are costs. Willison notes that StrongDM’s guidance points to $1,000 a day in tokens for each engineer, and he pushes back: “If these patterns really do add $20,000/month per engineer to your budget they’re far less interesting to me.” I take that seriously. A design file that needs a huge token budget to produce working code is not a good design file yet. A clear goal and a fast check make the machine cheaper, not only better.

So three things are still human work:

Judgment. Which part to make, and whether it is worth making.
Tolerances. What “good enough” means, written as a check the machine can run.
Review. Reading the evidence and deciding what ships. At Astrohacker, a second agent with a fresh context reviews the design and the result adversarially, and I decide what to accept. The reviewer reads the evidence. I read the reviewer.

For a business owner

If you run a business and you do not write code, this is the most important part of the story. CAD let engineers stop drawing. CAD for software lets you stop depending on people who type.

You already know how to write most of a design file. You do it every time you explain a job to a contractor. The difference is that you now write it down, in a place where an SI agent can read it, and you add a way to check the result.

Here is what to write instead of code:

The goal, as an outcome. “A customer can book a 30-minute call from the website and gets a confirmation email.” Not “build a booking system.”
The rules of your shop. Your brand colors and fonts, your prices, the words you never use, the data you never collect, the steps that only you may approve, such as payments or emails to customers.
The checks. How you will know it works, in words a machine can turn into a test. “Book a call on a phone. Book a call on a laptop. Try to book the same slot twice; the second try must fail.”
The context. Who your customers are, what you tried before, what failed and why. Agents do much better work when they know the history.

None of that is code. All of it is design. And it is the part of the job that you were always the best person to do, because you know the business.

What you still need is a factory around the design file: a repository, agents, a reviewer and a deploy path. That is real infrastructure, and it is the part that most business owners should not build alone. It is what we do at Astrohacker. Our own factory is not finished. Most of the stages already work as commands that agents run every day, but the graph that connects them, the classifier and the queue are still in progress. I described the plan in Inside the Software Factory That Writes All My Code.

CAD is also a third metaphor, next to two I have used before. In Software Factory vs. Software Garden, I argued that the factory is how changes move and the garden is where they land. CAD answers a different question: what do you hand to the factory? You hand it a design file. And the design file is also how you tend the garden, because a weed that you fix in the rules does not grow back.

Draw your first part

You do not need a factory to start. You need one part. Try this today:

Pick one small change you want, such as a new field on a form or a fix to one report.
Write the goal in one or two sentences. Say what is true when it is done.
Write one check. Make it something a machine can run: a test, a build, or a page that must load with the new field on it.
Write three rules the agent must follow, such as “do not change other pages” or “use the existing styles.”
Give the goal, the check and the rules to one agent, such as Claude Code or Codex, in your repository.
Do not edit the output. If it is wrong, change the goal, the check or the rules, and run it again.
Save what you wrote in an AGENTS.md file or an issue, so the next part starts from it.

That is your first design file. It is small, and it is the right shape. Each part you make adds to it, and the file gets better while the code gets cheaper.

I stopped writing code in April. This is what I write instead. If you want help to build a factory around your own design file, get in touch.

Stop drawing. Start describing.