The "I've Been Doing This Since '98" Problem: Why Great Developer Tools Still Matter

I'll write substantive content about:

• What Overplane represents in the AI coding space

• The "verified" claims in AI coding (formal verification vs. heuristic approaches)

• The build vs. buy decision for developer tooling

• How this fits into the broader AI-assisted development ecosystem

• My take on whether tools like this are worth it

There's a particular kind of comment that shows up in developer communities that goes something like this: "Oh, you built a tool to solve X? I had a bash script that did that in 1998." This week, that energy came for Overplane, an AI-assisted coding pipeline that reads Markdown specs, verifies them with formal methods, and uses AI agents to generate code—all with the sort of self-assurance that only comes from decades of shipping software.

Dan, the reviewer, wasn't wrong. Strip away the modern vocabulary—containers, LLMs, SMT solvers—and the core idea is indeed decades old: write a specification, verify it makes sense, generate code from it. The fact that we now have elegant Go binaries instead of Makefiles and shell scripts doesn't change the fundamental shape of the problem.

But here's where I think the "I had this working in the 90s" crowd misses something crucial: packaging matters.

The Packaging Premium

Dan's forty lines of bash plus a Z3 invocation is impressive. Truly. But forty lines of bash that only Dan understands doesn't scale across a team. It doesn't come with normalized agent abstraction. It doesn't ship with content-addressed outputs that make builds reproducible. It doesn't have documentation that lets a new engineer understand the system in an afternoon rather than reverse-engineering someone's 1998-era assumptions.

Overplane's "boring" architecture—the part Dan correctly identifies as the real value proposition—is exactly what makes it useful. The tool isn't trying to be clever. It's trying to be comprehensible. And comprehensible tools get adopted.

This is a lesson that keeps repeating in our industry. Yes, you could run your own DNS servers. You could manage your own SSL certificates with manual renewals. You could host everything on bare metal you maintain in a closet. But the teams that ship fast are usually the ones that know when to stop reinventing and start building.

The "Verified" Problem

The review's most interesting technical point is about verification. Overplane uses Z3 to check spec consistency—ensuring your requirements don't contradict each other before code generation begins. Dan correctly notes this is checking the formalization, not the original intent. A perfectly verified formalization of the wrong thing is still the wrong thing.

This is the fundamental limitation of formal methods in practice. TLA+, Alloy, Z3—they're tools for checking consistency, not correctness in the broader sense. You still need human judgment to know if your model actually captures what users need.

But here's the thing: checking consistency is still valuable. The alternative— specs that quietly contradict each other, leading to code that "works" in testing and fails in production—has killed more projects than formal verification ever has. Getting engineers to write specs at all is a win. Getting them to write specs rigorous enough for a solver to check? That's practically revolutionary.

The Real Question: Build or Buy?

Dan's implicit argument is that if you're technically capable, you should build your own. And he's right that the components are all available and have been for years. But "technically possible" and "strategically wise" are different things.

The modern AI coding landscape is evolving at a pace that's genuinely hard to keep up with. Claude Code, Cursor, Copilot, and tools like Overplane are all moving targets. The question isn't just "can I build this?" but "should I spend engineering time maintaining this while the landscape shifts underneath me?"

For a startup with limited runway, the answer is usually no. Pay for the tool. Let someone else maintain the plumbing. Focus your energy on the thing that makes your product unique.

For a large organization with specific requirements? Sure, build your own. But plan to spend real time maintaining it, and budget for the engineers who'll own that maintenance.

The Boring Parts Are the Point

Dan's final note is the most underrated observation in the whole piece: "The tool is deliberately boring; the decisions that matter are in your specs."

This is the insight that separates useful tools from clever ones. Boring tools get used. Clever tools get blog posts written about them and then abandoned when the original author stops maintaining them.

The boring parts—sandboxed execution, reproducible builds, a clean interface for multiple AI agents—are where Overplane's real value lives. Not in the AI itself, which is commodity at this point, but in the reliable scaffolding around it.

If you're evaluating AI coding tools for your team, ask yourself: what's the maintenance burden? How quickly can a new engineer understand the system? Does the tool make the boring parts easier, or does it just add more complexity in a new wrapper?

The best tooling doesn't make you feel clever. It makes you feel productive.

Where This Leaves Us

Overplane isn't revolutionary. Dan's right about that. It's a well-packaged combination of existing ideas with a few thoughtful additions. The content-addressed outputs, the multi-agent abstraction, the spec-to-verification pipeline—none of these are novel, but together they form something usable.

That's actually the highest praise you can give software. Not "this invented something new" but "this made something useful more accessible."

If you've been writing formal specs and running solvers since the 90s, you probably don't need Overplane. But if you're on a team trying to bring those practices into your workflow for the first time, a tool that handles the boring parts while you focus on writing better specs might be exactly what you need.

Sometimes the 40-line bash script isn't the answer. Sometimes the answer is the tool that does it in a way that doesn't require institutional knowledge to maintain.

That's not a knock on skill. It's just the reality of building software at scale.

What do you think? Are modern AI coding tools worth it, or should every team roll their own? Drop your thoughts below—and if you're setting up infrastructure for your next project, NameOcean's got you covered with domains, hosting, and the tooling you need to ship.