Or why the software industry will keep faililng as long as it treats software as an industry
What is good engineering?
Short answer: it's good when it's not bad.
And I'm not even kidding, it's really that simple. Good engineering is engineering that does not get in the way, it is essentially invisible.
That's why minimalism is an essential part of good engineering: the less you have, the less gets in the way. As long as the goal is achieved you're all set. I use "goal" to its widest possible extent: I include all constraints, requirements, desirable features... And absence of undesirable characteristics.
A missing feature is always less problematic than a bug. That should be obvious to anyone. Anybody who pilots a flying vehicle knows that: regreting not taking off is always better than regreting taking off.
What is reverse engineering
From Wiktionary: The process of analyzing the construction and operation of a product in order to manufacture a similar one.
Hmm... okay... the first part looks all right but "in order to manufacture a similar one" looks restrictive. Many people think "decompiling a binary" or something like that when they think "reverse-engineering", so here is my definition:
The process of analyzing the construction and operation of a finished product in order to copy or modify it.
So what's the catch? It doesn't seem to be related to creating new products and being innovative, right? right? Right?
Sir Isaac Newton: If I have seen further it is by standing on the shoulders of Giants.
Engineering is always about analyzing the construction and operation of something in order to copy or modify it. At various scales. All the time.
Let's stretch that idea to its maximum: planes were built by reverse-engineering birds, bold but miserable attempts at first but they were getting somewhere, and now we can fly using anything from a few square meters of fabric all the way to gigantic machines that can reliably fly up to the stratosphere with ease.
But software is different right?
No it's not. First analog computers modeled ballistic missile trajectories, first digital computers ran mathematical models that were born by nothing more than reverse-engineering the real world, and desktop computing evolved by mimicing paper handling by sorting stacks of punched cards first, then digitizing everything.
... And don't even get me started on weaving looms that had a significant impact on all that.
Then what's the common pattern?
Bad software engineering treats software like producing goods: once a feature is finished, it never looks back. Deviations between the intent and the end-result (bugs) are treated as annoyances that must be quickly brushed away. And software is supposed to be an accumulation of features: the pattern repeats. Good engineering was renamed software architecture: architects are the only people allowed to alter existing parts, when they are given the time and budget to do that, and time and budget are disappearing.
And there you go: enshittification at its peak. The product accumulates unfinished features that are developed in isolation instead of deriving from a common reused base. It's not a programming language issue, it's not even a software design issue, it's a project management issue and ultimately a management issue. Management by pressure or management by panic are obvious red flags indicating that you are in that model: you need to get out of this quickly.
BUT you still didn't fully prove your point: writing software looks nothing like reverse engineering.
Any software developer that experienced the world before the big AI shift will tell you: they read code more than they write code. Ignore people that disagree, they either don't realize they do (which is fine) or really never read their code (which is not fine).
When you read code, you do one thing: you reverse-engineer the code you read, you reform the idea conveyed by source code in your mind. Proof: that's why good comments are so valuable, perhaps more valuable than the code itself, and why good design documents help tremendously. You never work on the project itself, you work on a reverse-engineered version of it sitting in your mind.
And you know the feeling: you get interrupted, your mental model evaporates, and you're back to square one: what just evaporated is the reverse engineered model sitting in your mind.
In a nutshell: you treat your own product as something foreign each time you stop thinking about it.
Then what do we do?
You use that mindset when evaluating software tools, development practices and (both project & people) management practices. Good questions you can ask:
- Is it applicable on an unknown code base or an unknown product? If it is, it's good for reverse-engineering, so it's good for engineering.
- Can I switch to something else and it still works? If it does, good! Corrolary: customer captivity is never good engineering.
- Once something is considered finished, do we still keep reviewing and challenging it? If you do, you are all set. Code dies when nobody use it anymore, not when it starts working.
- Does it push toward removing stuff? If not, it's problematic.
- More generally: is accurate and honest feedback a first class citizen? It has to be.
Using that mindset to maintain code
- Just like you organize test campaigns to remove bugs, organize review campaigns to reverse engineer code: rewrite parts to be smarter and smaller.
- Review code even when it was not modified recently. You own the whole product, not just the latest diff or pull request.
- Whenever you can, remove bugs by removing the code that contains them. You will need reverse engineering techniques to do that: "how can I design software that achieves the set goal without doing that problematic part?"
- Remove bugs by reverse engineering then rewriting the code: the probability that you repeat the same error twice is low now that you know it can happen.
- Use that mindset to write documentation: documentation is the result of a reverse engineering pass. It saves time by providing shortcuts toward the end result: a fresh and complete mental model. Of course, documentation lies if it's not up to date, and a wrong model is worse than no model at all.
Can AI help?
Yes, but not how you might think.
First, frontier models are excellent at reverse engineering. Due to the way current models work (2026, this will age poorly), they are much better at reading and building a mental model than producing output. The mental model is their context and that's what is important. They reverse engineer all the time, and that's what costs the least amount of tokens: decision models like jev push that assymetry to its extreme. So we can obviously take advantage of LLMs to help us.
Ask for reviews but don't read the report: AIs are bad at writing, they produce text that is difficult to read (especially technical text), they abuse stylistic figures, they make sentences where finding adjective/subject/verb/object is not always clear, they introduce jargon from foreign corporate cultures...
Instead: build a context with all the info, and use context forks or /btw to ask targeted questions that lead to short answers. That's how you evaluate your code, not by reading but by challenging the reverse engineered model in the AI's mind. It takes a toll on yourself: you need to be able to "sense" what your mind is doing and what it needs to know to continue thinking, and that level of self-awareness and introspection is hard to maintain on long prompting sessions.
But isn't AI autonomous?
No it's not. And the quality of the outcome is tied to one main factor: the amount of feedback. And we're back to reverse engineering again: looking at the end result and trying to find how it works and how it does not work, rather than why it does not work.
SDD (spec driven development) is the pinnacle of bad engineering: it never gets feedback when pushed to the extreme, or the feedback loop is too long when applied partially so it slows you down more than it helps. If you reduce the scope of your SDD iterations you solve the problem partially, and when pushed to the extreme of "each prompt is a new spec" you are basically vibe coding. And if you try to find the correct equilibrium, you are back to do the exact same thing as what you were doing before AI arrived: humanly supervised iterations with real-world feedback, which is good engineering but not SDD anymore.
Because no, considering markdown specs as another level of programming language sitting about high level languages is NOT a license to stop looking at what's under it. While it happens very rarely, I sometimes need to read a few lines of assembly to really understand what's happening, even in 2026, even with AI. And that's basically a reverse engineering technique. So leave SDD where it sits: a rapid prototyping tool, whose outcome must be fully reverse engineered before being fully rewritten for production use, with proper engineer supervision this time, down to the lowest level, down to hardware.
Use AI for its strength
Use the AI to help you do the reverse engineering part: make it read the outcome and explain it to you, so you get a better mental model of what you have, so you (not the AI) can better evaluate the distance between what you have and what you need and in which direction you need to go. What happens after that point matters much less, as long as the feedback loop is painless.