[{"data":1,"prerenderedAt":156},["ShallowReactive",2],{"\u002Ftlt-2026.02.22-modern-coding-discomfort-or-four-colors-suffice":3},{"id":4,"title":5,"body":6,"createdAt":144,"description":12,"draft":145,"extension":146,"image":147,"mastodonThread":147,"meta":148,"navigation":149,"path":150,"seo":151,"stem":152,"tags":153,"updatedAt":144,"__hash__":155},"content\u002FTLT - 2026.02.22 - Modern Coding Discomfort, or, Four Colors Suffice.md","Modern Coding Discomfort, or, Four Colors Suffice",{"type":7,"value":8,"toc":134},"minimark",[9,13,18,21,24,27,30,33,37,40,43,46,49,52,55,59,62,65,68,71,74,77,80,83,87,90,93,96,99,102,106,109,112,115,118,122,125,128,131],[10,11,12],"p",{},"Some thoughts on modern generative code discomfort and the Four Color Problem",[14,15,17],"h2",{"id":16},"four-colors-suffice","Four Colors Suffice",[10,19,20],{},"There is this little puzzle called the map coloring problem. If you have a map - let's say of countries - and you have some different colored crayons, you need to fill in each country so that no two countries touching each other share the same color.",[10,22,23],{},"In the 1970s, mathematicians finally worked out a proof that you only need four colors. The problem is that, unlike many proofs before it where you'd come up with some cool underlying pattern or elegant structure, the proof they came up with was to first enumerate all of the different possible equivalent configurations of a map. This is pretty cool - but it came out to something like just under 2,000 different combinations. Using 1970s computing technology, the proof was to get a computer to go through every single combination and demonstrate, for every single one, that you could color it with only four colors directly or through a simplifying transformation.",[10,25,26],{},"Mathematicians at the time found this very, very unsatisfying. The only way to understand the proof was to read through every possibility, which was kind of crazy. There was nothing special in the solution - it felt like a coincidence that four colors suffice. It boiled down to pages and pages of \"I tried combination one. That one worked. I tried combination two. That one worked.\" All the way through, with no underlying structure, no unique beauty, and nothing you could really build anything else on top of.",[10,28,29],{},"Here we are in 2026, and in software engineering people keep putting up pull requests which are not small and elegant. They solve the problem, and yet they are dissatisfying. They are too long to read. Submitting the pull request makes us feel like we have not provided meaning, only an answer. A maintainer trying to work through a flood of large pull requests is like looking for the pattern in the four color theorem. It is not there - because it turns out it doesn't need to be there in order to solve the problem.",[10,31,32],{},"In programming we've had this problem of unreviewable details before, but now we need a new way to build trust.",[14,34,36],{"id":35},"the-glass-box","The Glass Box",[10,38,39],{},"Software has always been a kind of layered glass box. You could peer inside, see what was happening, understand how the machine was doing what you asked of it.",[10,41,42],{},"When I first learned to program, I did it across multiple levels - high-level languages, medium-level languages, and assembly. I used to program on TI graphing calculators in assembly, often hand-translating the op codes to hexadecimal. I made a compiler that could take TI Basic and translate it down into assembly, which was pretty cool - though it would write assembly that wasn't as optimized as what I was writing by hand. It would spit out so much that I couldn't really read it, and that made me worry about inefficiency, about losing nuance, about the code losing the aesthetic of the system. Soon better hardware came into my life, more high-level systems, and I moved on.",[10,44,45],{},"After a while, you don't really want to constantly be thinking about whether memory is growing from the bottom up or the top down, where the stack and heap are, how to manage pointers. After a while, you don't even want to worry about garbage collection. You just want stuff to work.",[10,47,48],{},"As you move up these levels of abstraction, it's like you take each lower level and put it in a box. Maybe it's a semi-transparent box where you know roughly what's happening underneath, but you care less and less. Then you take that level and put it inside another box. You can squint through and sort of see, but you see less and less. You can open the boxes when you need to - you can get back inside and see what's going on. But for the most part, if it's a good box, you don't really care what's going on inside.",[10,50,51],{},"What makes people eventually stop worrying is that you build up trust. Your tools build up capability to where you can write a smaller, more abstract chunk of code, and it does what you need with less fiddling. Less control, but usually less control in dimensions you don't really care about - like where specifically the bytes are in memory. Sometimes it constrains you in ways you do care about, like vertically centering text in CSS being a real pain. But most of the time, you're able to build up trust in your higher level system because it lets you move faster, get your idea out on screen, let people interact with it faster than you could have before.",[10,53,54],{},"Less control in dimensions you don't really care about. That's the deal you keep making, one abstraction layer at a time.",[14,56,58],{"id":57},"whats-actually-happening-with-ai-generated-code","What's Actually Happening With AI-Generated Code",[10,60,61],{},"Here's the thing people get wrong about AI-generated code: it's still just code. You can look at it, peel it apart, figure out how it works, figure out what it's doing and what it's not doing. The issue isn't that it's mysterious or non-deterministic in any fundamental sense. The issue is quantity. There is simply more code than anyone can read.",[10,63,64],{},"This is exactly where the overlap with the four color theorem comes in. There were so many individual cases that the proof was more or less to enumerate all of them - and that made it too much to fit in a human brain. It doesn't take away from the fact that this is still ultimately deterministic. Things can be sloppy without losing determinism.",[10,66,67],{},"People get distracted because LLMs generate code somewhat non-deterministically - ask the same prompt three times and you'll get three different implementations. But if you judge the solutions based on their behavior, if you look at all three and pick the one that behaves most like what you want, you still have a system. You still have execution you can run and observe.",[10,69,70],{},"So when you have some monster pull request and you're a little nervous about merging it, what do you actually do? You pull it down and start treating it as a more opaque box. Check out the behavior. Check out whether it works, whether it does the original thing. Try out a few edge cases and see how it feels. I still sometimes scan the code looking for something obvious that's trying to escape its little box, a view page with SQL embedded or something - the more contained it is, the better. But for the most part, you treat it more like a found object than a beautifully constructed theorem.",[10,72,73],{},"This is also where a tempting instinct leads you astray. You might think: \"They generated that code through prompts, through some kind of English-level specification - let's hold on to that.\" The problem is that your prompts are already trying to account for your current situation, the capabilities of your model, the assumptions it has, the rest of the codebase at that time. Your prompt is not really something worth saving in the way source code is worth saving. If you run the same prompt multiple times, you get different results. Run it against different models, you get different results.",[10,75,76],{},"The prompt isn't like high-level JavaScript compared to assembly. If you take your high-level JavaScript and execute it, you end up with pretty much the same thing each time. Take your high-level prompt, and you could end up with something quite different. Your LLM is adding something to it - it's adding a snapshot of its current data and style, its taste based on the training and context.",[10,78,79],{},"This means the whole world is flipped on its head. Historically, you should not commit build artifacts - they don't belong in your tree. Now it feels like the opposite. There is no point in committing the construction; you're only committing the build artifact. Your version history becomes much more like a transaction log of your artifact than a journal of an engineer.",[10,81,82],{},"You might save a prompt as documentation, as inspiration if you ever wanted to start over - but it isn't an artifact. You can't validate behavior at the prompt level. You have to validate it at the resulting code level, at the behavior level.",[14,84,86],{"id":85},"rigor-doesnt-disappear-it-relocates","Rigor Doesn't Disappear - It Relocates",[10,88,89],{},"So where does that leave us? We have these generated artifacts and throw-away prompts, and we need to start shifting how we think about the whole situation. We need to treat the artifacts as found pieces - things generated more like material science than traditional engineering. We can't depend on the underlying construction since we did not construct anything ourselves. We need to pressure test the actual thing, the actual result.",[10,91,92],{},"We can look to other disciplines for guidance here. Material science? Structural engineering? Folks who do testing on things to see how well they work. You can still gain a lot of insight if you understand how something works - that knowledge should give you better ideas about how to break it, how to pressure test it, how to make sure it fits your actual goals, and even what compromises you might be making. But even without that knowledge you can hit something a few times with a hammer to see if it breaks.",[10,94,95],{},"In practical terms: you might observe through real usage that a piece of AI-generated code isn't going to scale because of memory constraints, or you hit it with more than a couple dozen concurrent users and it falls apart. That might then lead you to find out exactly when it does fall apart, and to spend more of your time prodding at the outside of the black box rather than trying to comprehend it and build it up from first principles on the inside. More of a behavioral science than a dissection or construction.",[10,97,98],{},"Like the Four Color Problem, we must give up elegance and embrace observation.",[10,100,101],{},"The rigor applied toward validation has always been in service of building trust. If you can build trust through behavioral evidence instead of through reading the source, the rigor hasn't gone away - it's just relocated. The person who understands crystalline structures doesn't run the stress test any differently than someone who doesn't, but they know which stress tests to run. Deep knowledge of how things work still gives you an advantage. It just expresses itself differently now.",[14,103,105],{"id":104},"the-new-practitioner","The New Practitioner",[10,107,108],{},"I think about how much it actually matters that I know how a NAND gate works at the transistor level. It's genuinely fun to know. I can draw inspiration from it for higher-level concepts. But I can build a lot of things without ever having lifted a soldering iron.",[10,110,111],{},"A lot of people new to building software haven't had the background and traditional skills that would let them peer inside these boxes. Up until now, they could operate as QAs, as users, as people able to judge results - but generating the artifact itself was hard to do without years of accumulated knowledge. That's changing.",[10,113,114],{},"Someone coming to coding now should use tools like Claude Code to generate artifacts. They need to be technical, working through details on top of their creative prompting. They'll still need to think about how things fit together. But they can start from the other end, from the imagined outcome, more extremely than ever before. They can generate, magic-wand an artifact into existence, and then push on it with interactive and even real-world testing.",[10,116,117],{},"As they do this, the more they scratch into it - thinking about edges, failure modes, how other people are going to interact with it - the better they'll get. If they can get all the way down into the fundamentals, down into the black box a bit, they'll have more powerful techniques. But they might not need that. They will be able to trial-and-error their way into some really amazing things.",[14,119,121],{"id":120},"the-invitation","The Invitation",[10,123,124],{},"In the end, Four Colors Suffice.",[10,126,127],{},"We don't need to understand why from first principles; we can convince ourselves via other means. Grab a couple maps, a couple crayons. Give it a try. You might not be able to get through all 2,000-ish combinations, but you can get through a few and build up your faith that it's probably fine. You end up with some very beautiful little maps.",[10,129,130],{},"You might not be able to see all the way through these layers of abstraction, these boxes inside of boxes. But you can build some amazing things. You can share some amazing things. You can make ideas and visions come to life that never could have made it through before - not because the tools are magic, but because the barrier to making something real has changed.",[10,132,133],{},"And if you do have the ability to get down into the details, you can still help other folks out when they get stuck. You can design better experiments, ask smarter questions, push on edges in ways that matter.",{"title":135,"searchDepth":136,"depth":136,"links":137},"",2,[138,139,140,141,142,143],{"id":16,"depth":136,"text":17},{"id":35,"depth":136,"text":36},{"id":57,"depth":136,"text":58},{"id":85,"depth":136,"text":86},{"id":104,"depth":136,"text":105},{"id":120,"depth":136,"text":121},"2026-02-22",false,"md",null,{},true,"\u002Ftlt-2026.02.22-modern-coding-discomfort-or-four-colors-suffice",{"title":5,"description":12},"TLT - 2026.02.22 - Modern Coding Discomfort, or, Four Colors Suffice",[154],"blog","UHdZ2HPCzp46Ppn3C-8mmasz9f9gK0anufFdAiJlqgo",1778988316165]