Twenty-five years ago, I was at a startup making mobile apps for a chemical company. Their CTO explained the concept of Intrinsically Safe to me. The apps we made would run on devices that were custom built so that they could never cause an accident. This meant that if they were dropped, they wouldn’t spark and cause a fire. Only intrinsically safe objects could be brought inside the factory.

We (at the startup) loved this, so we adopted phrase “Intrinsically Safe” to describe our product (an SDK for making web/mobile applications) because it fit.

In our system, the programmer never wrote code that went to the client side, so it was always safe to run an app made with it. This is more than just a sandbox—it was intrinsically safe because app code only ran on the server. We need to apply this idea (separating system and application code) to vibe coding.

We need new applications and frameworks that are opinionated on the technical details and let non-coders specify the application logic only. When I look at vibed code, those ideas are conflated—you ask for some simple application logic, and the AI might accidentally open a security hole because that code is in the same file.

What would an intrinsically safe system look like? Something like:

For non-coders

1. More emphasis on visual manipulation. Learn from Excel, WebFlow, Notion, AirTable, etc about how to make things that can further be developed with point and click. Let them express themselves in no-code ways (which are intrinsically safe)

2. Full deployment support (like Replit)

3. Let them start with Figma-like tools? (See Kombai)

On the inside:

1. A programming language where you can’t express dangerous constructs. I would like some combo of the correctness spirit of Rust with the dynamism/immutability and system growth spirit of Clojure.

2. In my experience, AI seems to be a little better at code with Types. So, maybe Clojure/Spec and partial types

3. Or maybe something like Eve where your application is driven by (intrinsically safe) data constructs

4. A very opinionated auth, roles/responsibilities, multi-tenant user system that can be configured without code.

5. An API layer that implements everything we know about rate-limiting, security, etc.

If done right, anything the AI made would be ok to deploy because it’s not building the system. For sure, there will be problems, but whole classes of issues would go away.

I recently read an online debate between Bob Martin and John Ousterhout about the best way to write (or re-write) the prime number algorithm in The Art of Computer Programming by Donald Knuth. Having read the three implementations, I think Knuth’s original is the best version for this kind of code and the two rewrites lose a lot in translation.

My personal coding style is closer to Ousterhout’s, but that’s for application code. Algorithmic code, like a prime number generator is very different. For most application code, the runtime performance will be fine for anything reasonable, and the most important thing to ensure is that the code is easy to change, because it will change a lot. Algorithmic code rarely changes, and the most likely thing you would do is a total rewrite to a better algorithm.

I have had to maintain a giant codebase of algorithmic code. In the mid to late 2000’s, I worked at Atalasoft, which was a provider of .NET SDKs for Photo and Document Imaging. We had a lot of image processing algorithms written in C/C++.

In the six or so years I was there, this code rarely changed. It was extensively tested with a large database of images to make sure it didn’t when we updated dependencies or the compiler. The main two reasons why we would change this code was to (a) fix an edge case or (b) improve performance.

The most important thing that this code could have that would help is a lot of documentation. It was very unlikely that the coder would know what this code was doing. It probably would have been years since its last change, and unless it was our CTO making the change, there is no way anyone could understand it quickly just from reading the code. We needed this code to run as fast as possible, and so it probably used C performance optimization tricks that obfuscated the code.

Both Ousterhout and Martin rewrote the code in ways that would probably make it slower at the extremes, which is not what you want to do with algorithmic code. Martin’s penchant for decomposition is especially not useful here.

Worse than that, they both made the code much harder to understand by removing most of the documentation. I think they both admitted that they didn’t totally understand the algorithm, so I’m not sure why they think reducing documentation would be a good idea.

To be fair, this code is just not a good candidate to apply either Ousterhout’s or Martin’s techniques, which are more about API design. Knuth described the goal of his programming style this way:

If my claims for the advantages of literate programming have any merit, you should be able to understand the following description more easily than you could have understood the same program when presented in a more conventional way.

In general, I would not like to have to maintain code with Knuth’s style if the code needed to be changed a lot. But, for algorithmic code, like in his books or in an image processing library, it’s perfect.

In PR Authors Have a lot of Control on PR Idle Time, I made the argument that there is work the author could do before they PR their work that would get a PR review started faster. I followed up in A Good Pull Request Convinces You That it is Correct to show how to make the review faster once it started. The upshot is you do a code review on your own code first and fix problems you find. That work doesn’t take long (an hour?), but shaves off hours and days off the code review.

The same technique works for QA: Do your own testing and update the issue/bug/story/card in your work database to make it clear what the change was and how you have already tested it (with proof).

The worst case scenario for a code review and QA are the same: your code has a defect that you should have found. You can do work up-front to make sure this doesn’t happen, and that work is short compared to the wasted time that not doing it will cause.

I assume that you will test your code before you submit it. Hopefully you do that through automated unit-tests, which should include edge cases. You should go beyond that and anticipate what QA will check.

Like with code reviews, this extra work takes a couple of hours and potentially saves days of back-and-forth between your testers and you. If you don’t have any ideas of what to test then check with AI chatbots—they are pretty good at this and can even generate the test.

If you can’t automate the test, then you still need to manually test it when you write it, so it’s a good idea to make some record of this work. For example, for UI code, which is hard to unit test, create a document with before and after screenshots (or make a video showing what you changed).

These ideas also help with another source of QA feedback—that they don’t even understand what the issue/story/bug is. The way I head that off is by attaching a “Test Plan” document with a description of how to see the change in the application and what specifically was changed. A video works here too.

When QA finds a problem that I could not have found, then I am relieved. But, when they kick something back because it wasn’t explained well or I made a stupid mistake I could have easily found, I feel guilty that I wasted their time (and mine). I’ve never regretted taking a little time at the end of a task to help it go smoothly through the rest of the process.