Journal · The AI Architect · 2026-09-02
Restraint is the skill. Reach for the simplest thing that works, and make every added part earn its place.
Restraint is the skill. Reach for the simplest thing that works, and make every added part earn its place.
The tension isn’t between simple and complex. It’s between what looks impressive and what actually works. Every engineer, every writer, every person building something knows the pull: add one more layer, one more feature, one more safeguard, and it will feel more serious, more finished, more like the thing you imagined when you started. That pull is almost never wrong on its face. It’s wrong in accumulation. The hard part isn’t knowing that simple is good in theory. The hard part is saying no to the next reasonable-sounding addition, over and over, while other people are adding things and getting credit for it.
The cost of an added part is not what it looks like
When you’re deciding whether to add something — a config option, a middleware layer, a fallback path, an extra check — the visible cost is small. An hour of work, maybe a day. That’s what gets weighed against the benefit, and the benefit usually wins that comparison easily. But the real cost shows up later and belongs to someone else. It’s the person six months from now trying to understand why there are three ways to configure the same behavior. It’s the new hire who has to hold the whole shape of the system in their head before they can safely change anything. Complexity doesn’t charge interest at checkout. It charges interest every time someone touches the system afterward.
This is why restraint feels unrewarded in the moment and only pays off in a currency most people aren’t measuring yet. If you’re the one adding the part, you rarely stick around to pay that interest. Someone else does.
Try this: before adding anything, write one sentence describing what breaks if you don’t add it. Not what would be nice, not what might come up later — what actually breaks, today, for a real user or a real case in front of you. If you can’t write that sentence honestly, the part hasn’t earned its place yet. Put it on a list and wait. Most items on that list never come back.
Simple isn’t the same as easy, and it isn’t the same as few
People sometimes hear “reach for the simplest thing” and translate it as “do the least work” or “use the fewest lines.” That’s a misreading, and it causes its own kind of harm — the clever one-liner that nobody can maintain, the shortcut that saves an hour now and costs a week later. Simplicity isn’t about minimizing effort or minimizing surface area. It’s about minimizing the number of things a person has to keep in their head at once to understand what’s happening and why.
Sometimes the simplest thing that works is a little more code, spelled out plainly, instead of a clever abstraction that saves five lines but requires the reader to hold a mental model of how the abstraction works before any of it makes sense. Sometimes it’s the boring, obvious approach that a junior person could read cold. Restraint, in this sense, is partly a form of respect — for the next reader, and for your own future self, who will not remember the clever reasoning that made sense at 11pm on a Tuesday.
Try this: when you’re proud of how clever a solution is, treat that pride as a signal to double-check, not a signal to ship. Ask whether someone unfamiliar with the problem could read it and understand what it does within a minute or two. If not, it may be solving a problem you don’t actually have — the problem of seeming clever — instead of the one in front of you.
Earning a place is an ongoing test, not a one-time gate
The trickiest part of this idea is that it doesn’t end once something is added. A part that earned its place a year ago might not deserve it now. The feature that made sense when you had ten users might be dead weight at ten thousand. The safeguard that protected against a real risk might be guarding against a risk that no longer exists, because the system around it changed. Restraint isn’t a filter you apply once at the door. It’s a habit of periodically asking old decisions to justify themselves again, on today’s terms, not the terms they were made under.
Most systems — and most lives, most projects, most habits — don’t get bloated in one bad decision. They get bloated in a hundred small additions that each made sense on their own, none of which were ever revisited.
Try this: pick one thing you built or adopted more than six months ago and ask, plainly, would I add this today, knowing what I know now? If the honest answer is no, that’s not a failure of the original decision. It’s just information. Remove it, or at least mark it as a question you’re sitting with.
None of this is really about code or systems specifically — it applies to routines, commitments, and the sentences we let stay in a piece of writing. The book goes further into how this plays out across a project’s whole life, especially the moments when the pressure to add something is strongest and the reasons to resist are quietest. But the practice starts small, right here, with the next thing you’re about to add.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.