Code with Guardrails

Starting with four browser extensions. Two free, one for sale, and one sitting in a review queue that may well have cleared by the time you read this. That is everything I have shipped. It is not much of an empire. What I did not expect is the thing that arrived with them, which was not money and was not praise. It was a standing appointment. Firefox puts out a new version, so I go and test. Chrome puts out a new version, so I go and test. Safari the same. Nothing in my code changed on any of those days. The ground underneath it did. Nobody mentions this part. Shipping gets described as a finish line, and it is closer to a subscription: you keep paying for as long as the thing exists, and the bill arrives whenever a platform you do not control decides to move. So here is the honest version of where I stand, which is also the reason this post exists. My code has not turned against me. That is not because I am careful or good. It is because I kept every project small enough...

You will see errors. Not might. Will. VS Code will underline something in red. Xcode will refuse to build. Whatever you are working in will eventually stop and tell you something is wrong, usually in a sentence written for someone who already knows what it means. If you can read those fluently, you are ahead of most people reading this. If you can't, it looks like noise with a line number attached. The move is not to guess, and not to paste it back with "fix this" and hope. It is to ask, in plain words, without being embarrassed about it: What is this error, in language I would use? Why did it happen? Was it something I asked for, or a conflict with something we changed earlier? What is the smallest change that fixes it? The third question is the one that earns its keep. It separates "the model got this wrong" from "the model did exactly what I said," and those two need completely different responses. One is a correction. The other i...

One line. That is all you are looking at. python cleanup.py You asked for it. You read it. You asked the model whether it was safe, and it said yes. It said yes last time too, about the thing that turned out not to be. So you ask again, worded a little differently, hoping for a different answer. Then once more, because the third pass caught something real and maybe a fourth will. This is the part nobody warns you about. At some point, asking becomes a way of not running it. Review has a ceiling and you hit it early, because the model is guessing about the same code you are guessing about. The only thing that will actually tell you whether this works is running it. Which makes the useful question something other than is this correct . The useful question is: what does it cost me if it isn't? Foresters do not protect a forest by keeping fire out of it. They set fires on purpose, in a marked-off area, on a day they choose, when the wind is going the right way. The fire...

The code came back, and it looked right.  That is the part nobody warns you about. It was indented properly. The names made sense. There were comments. It had the confident shape of something written by a person who knew exactly what they were doing. I read it, I nodded, I kept it. And somewhere between three minutes and three weeks later I found out it had been wrong the whole time. The suspicion usually shows up before the evidence does. You get a feeling that something is off, and no vocabulary for what.  Also, you may never look at the code. You just look at the results. The app launches, but something feels off. It seems slow in opening on your brand new iPhone. The inspector isn't smarter than you Buying a house is the closest thing I can compare it to. The house is finished. Somebody built it. The home has walls and a roof, and the doors that close. You walk through, and it looks like a house, because it is one. Then the inspector walks through the same...

The whole pitch for vibe coding fits in one sentence: you describe what you want in plain English, and the machine writes the code. That sentence is true. It's also the most expensive true thing in this field, because it quietly implies that plain English is enough, and plain English is not the same as a clear description. I found this out the way I find out most things. The hard way. Trial, and then error Two methods have worked for me my whole life. The first is trial. The second is error, and it's the one that does the teaching. I can tell you how to make fire by rubbing two sticks together. You'll nod along, and you'll understand every word. Then you'll go outside and fail for two hours, because nobody mentioned how hard to press, or that the wood has to be bone dry, or that some wood won't light no matter how long you work at it. Maybe I said Look for a dark tan piece of wood, and dark tan to you is different than what it is to me. The error half ...

Welcome to the 2nd post in this series. I hope you find it useful. Vibe coding is here and is not going away. The biggest part of vibe coding, whether you're a decades-old coder or someone who started coding 5 minutes ago, is that you have to look at it as a manager, not a coder.  You are a manager, not a coder. You do not write the code. Sure, you may type some code now and then, but in the long term you will prompt the AI to do it. You manage a very smart coder. For example, somebody at work found out you vibe code. So now there's a request: a small internal tool, nothing fancy, something to replace the spreadsheet everyone complains about. You said yes. Also remember they asked you to do it because it cost nothing. Two weeks later, you finished, and guess what? It works. Four people use it every morning. Then one of them asks what happens if two of them hit save at the same instant. Of course you have no idea. You'd never thought about it. The AI never brought it up,...