AI software, properly.

Software engineering was already broken before AI showed up.

Thirty years in this trade, this year. I've worked on startups and corporate behemoths, on greenfield and legacy, on teams of three and teams of twenty. The patterns rhyme. Requirements that nobody owns. Acceptance criteria written by the developer at the last minute because the product owner has gone quiet again. TDD and BDD always promised, never afforded, because the next feature is always more important than the last one. A bag of tech debt accepted as the cost of moving fast. And, near the top of the stack, upper management lying about the state of completion. To customers, to investors, and, more often than they'd admit, to themselves.

This isn't an attack on the people. Most of them are doing the best they can inside a structure that's quietly rigged against them. It's the structure that's broken.

Humans scale terribly

The other thing thirty years teaches you. Adding more people doesn't add more output. It adds friction.

Bring on another engineer and you'll be lucky to get fifty percent more done. Bring on five and the picture starts to slide backwards. More humans means more communication, more meetings, more documents that are wrong by the time they're written, more handovers where the context falls on the floor between rooms.

At enterprise scale this compounds into something close to comedy. Most of what those huge software teams actually do, day to day, is collate information, distribute it, and then pick up the pieces from the bits of comms that didn't quite get through. The actual building is a side hustle.

And then AI showed up

Two years of working with this stuff has clarified the picture, and complicated it.

The first year I built a corporate chatbot, like everyone else, and spent it learning where the boundaries actually were. Where the genuine capability is, where the appearance of capability is doing the work that the actual capability isn't.

The second year, I went all-in. Stopped writing code by hand. Stopped writing tech docs by hand. Forced myself to use AI for everything I do. And in doing that, made myself deal with the part the demos skip past. The last twenty percent.

The first eighty percent of any build is now astonishingly fast. Things that used to take a week now take an afternoon. Mind-blowing, if you've been writing software long enough to remember the alternative.

The last twenty percent is where it bites. That's the part where the AI's output stops being convincing and starts being subtly wrong. Where it builds you something that compiles, runs, and looks right in the demo, but quietly carries decisions you never made. Decisions about edge cases. Scaling assumptions. Security posture. Schema design. The hardest part of software engineering was always that last twenty percent. AI hasn't changed that. It's just made it easier to think you've already done it.

Which leads directly into the dangerous bit, the one already happening in the wild. Product owners and CEOs can spring up a working-ish prototype themselves now, in an afternoon. The smart ones know that's a prototype. The rest convince themselves the hard work is done, then toss it over the fence to an already-overworked engineering team to "just check it and productionise it." After all, the AI built it. How hard can the rest be? Eighty percent of the work was done in an afternoon.

This is going to be a sizeable problem for the industry over the next year or two. Most companies have no real plan for how AI-built software actually gets shipped, paid for, and supported. McKinsey's State of AI work consistently finds that despite near-universal adoption, only a small minority of organisations report material business value from it, and most are still figuring out how to scale beyond pilots. So companies act out of a quiet desperation, push prototypes into production with the engineering effectively skipped, and discover the hard way that "the AI built it" is the easy eighty percent. The hard twenty percent is still sitting there, untouched. They'll meet it in production.

We already know how to do this

Most of the industry talks around this, but I'll say it directly. We have spent decades figuring out how to build software properly. The knowledge exists. It's in TDD and BDD, in proper requirements work, in honest planning, in mature deployment, in real test architecture. It isn't new. It isn't exotic. It isn't behind a paywall.

The reason we don't see it more often is that it's almost always buried under layers of human-centric process and corporate confusion. The right decisions get made by the wrong people for the wrong reasons. The good practices get shoved aside because they don't fit this quarter's feature-mania.

From what I've seen over thirty years, almost every corporate software project I've watched comes in over budget AND under-delivers on scope. The numbers back this up. The Standish CHAOS reports put corporate software project success rates around a third or worse. McKinsey's large-IT-projects study found large IT projects ran 45% over budget on average, 7% over schedule, and delivered 56% less value than predicted. That isn't a deficit of knowledge. It's a deficit of discipline.

So now what

The labour situation has flipped. The thing that used to cost the most, the actual writing of code, is now the cheapest part of the stack. Which means, for the first time in my career, there is real room to focus on the parts that were always the actual problem.

The thinking. The structure. The discipline. The engineering, as distinct from the coding.

There's an old British army saying I've carried around for years. The Rule of 7 P's. Prior Planning and Preparation Prevents Piss-Poor Performance. It sounds glib until you watch the alternative for thirty years.

What this site is for

Stravica is where I work out how to do it properly, in public. Three lanes.

The methodology. Right now that's RCF, the Requirements Confidence Framework. The first piece of the puzzle.

The Operator PA. A digital, self-learning version of a human operator role, built on the methodology. Engineering today, more roles to come.

And the products. Whatever the methodology and the PA build, when they get pointed at a real problem.

And this writing, which is where I work the rest out in between.

Software engineering was already broken before AI. AI didn't fix it. It sped up the broken bits, and bought back the time to fix the engineering. This site is where I'm doing that. RSS in the header if you want it as it comes.