The middle ground in software development is dead.

After a decade of building systems, reviewing code, and hunting vulnerabilities, I’ve found myself writing software in exactly two modes. There’s the fortress: ultra-secure, thoroughly tested, peer-reviewed, and bulletproof. Then there’s the sketch: completely disposable, built for speed, meant to break.

This approach eliminates the exhausting middle tier where projects hover in development purgatory. Those half-robust side projects that might work, might scale, might be worth the CI setup and security audit. The ones that consume mental energy without clarity of purpose.

The Two Extremes

Fortress Mode applies to anything handling sensitive data or critical workflows. These projects get the full treatment: linters cranked to maximum sensitivity, comprehensive test suites, security reviews, and deployment pipelines. Every dependency is audited. Every function is documented.

This rigor exists because most software frustrations stem from cutting corners. Web apps that constantly break, services that leak data, systems that crumble under load. When something matters, it deserves relentless attention.

This is how I code for work, or in any situation where someone is counting on me to do something properly.

Sketch Mode covers scripts, proof-of-concepts, and experimental tools. Here, I deliberately turn off the security reviewer part of my brain. No Rust type system enforcement, no memory safety concerns, no linting. The goal is pure velocity: get the idea out of your head and into working form.

These tools exist to answer a simple question: is this concept worth pursuing? Most aren’t. They’re incomplete, abandoned after the initial burst of curiosity, or require significant rework to become truly useful. Starting with heavy tooling would kill the experimentation entirely.

This goes all the way down to language choice. I won’t vibe-code Rust, and I won’t try to write secure, reliable software in an interpreted language. Getting clear on the actual use of the software allows one to play to the respective strengths of the tools used to build it.

The Excluded Middle

Even though both of the above approaches are extreme in their own ways, it’s actually the mid-tier projects that I find most exhausting to work with. Fortress-style should be lovely to read and should work every time. Sketch mode code should never, ever be read and is almost something close to an aesthetic, playful experience than to something like engineering.

Most of the software out there isn’t truly fortress-grade or unapologetically sketchy. Instead, it’s fragile code pretending to be robust—a proof-of-concept stretched far past its expiration date. Most software should be thought of as slop until proven otherwise, just because doing things right ends up being beyond the interest, ability, or resources of most people and organizations. Maybe all of the LLM-generated code will make more people realize and/or admit this.

Putting Out Slop

I treat the sketch projects like hazardous materials, clearly labeled from the start. The README gets a prominent warning: “This is vibe-coded software. Use at your own risk.” No security guarantees or reliability promises, just an idea I had that someone else might find interesting too.

More broadly, I’m sympathetic to the idea of FOSS as a gift economy rather than as an open-ended service contract. If I was stuck in that mindset, I wouldn’t be able to make and share these projects knowing that they almost certainly have ridiculous problems as well as security issues. It’s not even so much that I’m genuinely worried that someone will get hacked because of something that I wrote, but more that it takes more mental energy to write code securely, and that’s not the point of these projects.

Keeping these two mindsets totally separate has felt deeply liberating. I hope others do the same, so that we can all be a little bit more clear about what we’re getting ourselves into when we run something off of GitHub.