The Code You Don't Write

As code becomes easier to produce, the most important engineering skill is increasingly deciding which code not to write.

For a long time, the amount of software a team could build was constrained by the number of engineers available and by their skills. Features were scarce because implementation was expensive. That's very much not the case anymore. Today, anyone can generate a LOT of code and ship working products.

But the central product challenge has not changed: deciding which features deserve to exist.

"Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte."

("I didn't have time to write a short letter, so I wrote a long one instead.")

Blaise Pascal, Lettres provinciales

Writing less code, or building a smaller product, often requires more judgment than building something large.

You may have heard the term taste used more and more in recent days: the ability to ship code has become the common denominator, and taste is the differentiator.

Taste is the ability to identify which features need to be shipped, determine their scope, and create a coherent product experience from those decisions.

In a world with an abundance of ideas and an abundance of implementation capacity, that judgment becomes even more important. A product needs a coherent line. Its design, behavior, and user flows need to feel intentional. That requires human intervention and steering.

You cannot simply operate a software factory, ship a large amount of code, and expect the result to become a polished product by itself. The most polished software tools are made with clear human intent. They are not successful because someone happened to assemble enough features. They are successful because someone decided what belonged in the product and what did not.

I have been building SimplePDF since 2019, and people have often asked us to turn it into a PDF editor. By "PDF editor," they usually mean the ability to edit the text inside an existing PDF.

That sounds like a natural feature for a PDF product. In practice, it is an extremely complex problem.

Ordinary visual PDF documents do not work like documents in a word processor. A PDF generally describes text at specific positions on a page. It does not contain a straightforward concept of reflow where adding a sentence automatically moves the rest of a paragraph, section, or page.

Suppose a paragraph contains one additional sentence. The new text may no longer fit in the original space. The layout can break, and the software then has to decide what should happen next. It may need to move surrounding text, change page boundaries, or provide tools for the user to repair the result.

Font subsetting creates another category of problems. A PDF may contain only the subset of a font needed for the text already present in the document. If a PDF contains the text "hello ben" and the user changes it to "hello john," the new letters may not exist in the embedded font subset.

Supporting that workflow reliably means dealing with the original font, including custom fonts. If the complete font is not available, the editor cannot simply assume that it can render every new character correctly. What looks like a small text change can therefore become a chain of difficult edge cases.

These cases multiply quickly. Text positioning, line wrapping, page boundaries, font availability, missing glyphs, and custom document behavior all interact. A PDF editor can appear to work for most documents while still producing broken or surprising output for the documents that fall outside its happy path.

That is why I intentionally chose not to build this feature into SimplePDF.

This decision is ultimately about trust.

My wife recently filled out a long form to register with a general practitioner in Amsterdam, after we moved there. She spent around twenty minutes completing it. When she clicked "submit," the form errored and returned her to a blank page.

She was frustrated and left. She came back two hours later because she needed a doctor, and completed the form again. If this had been a product she was considering purchasing, rather than a service she needed, she probably would have gone somewhere else.

Users need to trust that clicking a button will produce the expected result. When they are unsure what will happen next, they do not come back.

The opposite of that experience is delight. Delight happens when a user clicks a button and something happens that is unexpectedly positive.

One example is SimplePDF's automatic form detection, powered by CommonForms. The feature detects form fields in a PDF and automatically positions them on the document. A user clicks a button, waits around ten seconds, and sees dozens of fields placed for them, depending on the size of the PDF.

The feedback has been outstanding. Users save an average of thirty minutes to one hour when filling out these forms.

Piggybacking on the ONNX Runtime, I was able to make CommonForms work in the browser and open-source it, with Joe's blessing. However, I did not deploy it to all SimplePDF users, who number around 9,000 daily, until Summer 2026. I was not satisfied with the output before then.

There were still difficult cases to handle. Comb fields, for example, were not supported. I developed a deterministic set of heuristics based on the glyphs in the PDF to detect and support them.

The point is not that every feature needs years of work before it can be released. The point is that the scope of a feature does not determine whether it deserves care. Automatic form detection has a focused purpose, and I wanted that purpose to work reliably before putting it in front of all users.

With AI systems such as Fable 5.1 and GPT-6 Astra, I could now embark on building a full PDF editor. I also have distribution through SimplePDF, so there would be a plausible path to putting the feature in front of many users.

But deliberately narrowing the scope helps preserve quality.

If I were careless, I could let the AI generate the feature, ship something that technically qualifies as a PDF editor, and call the problem solved. It might work for 90 percent of documents. The remaining edge cases would create paper cuts for users, and those paper cuts are exactly what prevent a product from feeling delightful.

A product that occasionally damages a document, changes its layout unexpectedly, or fails after a user has spent twenty minutes editing it does more than contain bugs. It breaks the user's expectation about what the product can be trusted to do.

The decision not to write the code is therefore not a lack of ambition. It is a product decision.

A tight product is not defined only by the features it contains. It is also defined by the problems it refuses to pretend it has solved. In a time when implementation is abundant, restraint is one of the ways to protect quality.

The code you do not write can be part of the product's design.