We're in the Over-engineering Game Now | From the computer of Peter Clark
↻ random | about Peter | projects | ⌗ caldave.ai
For my entire career I have prided myself at being really good at scoping projects to be the least amount of engineering work and yet also maximum versatility. Having studied computer science and grudgingly writing code at times, I could appreciate how engineering time is the most precious resource at a software company.
I became really really really good at versatile software that could be leveraged for all sorts of things. It's also why I became a Webhook, Zapier and Segment power user — build once, infinitely extensible without engineering.
At the same time, I also love product design and adore details and polish. This led me to a constant conflict — gosh I wanted to over-engineer this doohickey, but we mustn't waste engineering resources...
It was part of the reason why founding Journey in 2020 was so energizing, as CEO I could tweak the knob a bit towards "design and polish" that other companies may not want to do.
Fast forward a few years, and we're now in a very very very different world.
Let's over-engineer the fuck out of stuff
I have a confession to make — I am loving using Claude and Codex to over-engineer the fuck out of my side projects.
I'm sorry precious water resources but I am going to spend thousands of tokens over-engineering my blog with:
A dynamic changelog
A feeling-o-meter
an MCP that talks to my OpenClaw and creates a weekly automated post type of what OpenClaw did for me.
And literally hundreds of other ideas that I concoct and then many of which I just decide "eh nevermind" after playing with it for a bit.
No more barren MVPs
Now, when I build iOS apps they do not start as a barren MVP but as a fully fleshed out applications with integrated feedback loops (that kick off agentic workflows!)
As many readers will know, there is a fine line between over-engineering and simply finishing a project. Or is there? Before AI, it was a delightful dance — but now, it doesn't even matter.
Whereas before so many features would either fit in backlogs because they never became a P0, or improvements never even got documented because "eh, it's too small" now we can just endlessly iterate and iterate and polish and polish and tweak and refine.
Serious implications
I think that this culture shift is going to have massive implications in how we interact with software going forwards. Now, when I use clunky software I get so irritated because there is just no need! It's basically free to make great software. I'm looking at you FIFA World Cup Fantasy League.
Many people have written about how we're in the era of vibe coding, of slop coding, of apps-for-an-audience-of-one coding. But I think differently — I think we're actually moving towards a final form of engineering where the vision for an application is no longer constrained by resources.
If I want to build the most insanely over engineered podcasting app — I can. I can make that for myself, I can sell that on the app store, or open source it. It doesn't really matter. My podcasting app could be so outrageously esoteric and opinionated that no one else would ever want to use it! or it could be so sublimely simple. All that matters now is this question — what do you want to build?
May 28, 2026