Gergely Orosz posted a thread on September 26 that put a clean label on something the industry has been circling: there is the engineering mindset and the hacker mindset, and AI did not invent the distinction. What AI did was make the hacker path faster and the resulting gap harder to see from the outside.
His point: what we used to call “blindly copying from StackOverflow” is now the vibe coding mindset. It produces something that looks like software, moves fast, and works until it doesn’t. Production systems — anything that needs to work at scale, under load, with real edge cases — still require engineering. And it is now harder than ever to distinguish the two from output alone, even when looking over a developer’s shoulder.
flowchart TD S[Developer starts building] S --> V[Vibe coding path] S --> E[Engineering path] V --> VD[Fast to demo] VD --> VH[Hidden coupling<br/>minimal tests] VH --> VS[Scale event or edge case] VS --> VF[Expensive rework<br/>or production failure] E --> EL[Slower initial ship] EL --> EF[Architecture<br/>test coverage<br/>ownership clarity] EF --> ES[Scale event or edge case] ES --> EH[System holds] class VF bad class EH good class VS warn classDef good fill:#163a26,stroke:#44cc77,color:#d7ffe6; classDef bad fill:#3a1620,stroke:#ff5555,color:#ffd9d9; classDef warn fill:#3a2e16,stroke:#ffaa33,color:#ffe9c7; classDef accent fill:#15233b,stroke:#4488ff,color:#dce9ff;
The rundown
Orosz’s September 26 thread drew a distinction that has existed in software for decades but has become newly urgent. The engineering mindset and what he calls the hacker mindset — formerly “copying from StackOverflow,” now vibe coding — produce code that can look identical from the outside in the short run. Both ship features, pass demos, and get positive user feedback in controlled conditions. The divergence shows up when conditions are uncontrolled.
His follow-up tweet extends the point: production systems and mission-critical systems that need to “just work” at scale absolutely require engineering. This is not a sentimental preference for traditional craftsmanship. It is an observation about what the properties of reliable software actually are and where they come from.
The timing of the observation matters. AI tools have made the hacker path faster and more convincing. They have not changed what production systems require. If anything, they have widened the gap between what looks like working software and what actually is.
For the working software engineer
AI tools change the leverage available to each approach, not the approaches themselves. A disciplined engineer with AI tools can produce more engineered output per unit of time. A developer operating in the hacker mindset with AI tools can produce more hacked output per unit of time. The gap between what each produces in the short run has narrowed. The gap between what survives production has not.
What this means day-to-day: your judgment about architecture, ownership, test coverage, and integration contracts is now the primary constraint on software quality — not your typing speed or code-generation ability. The work that AI does not replace is the determination of what to build, in what structure, with what interfaces to the systems around it. That is where the engineering mindset lives.
The harder personal challenge: if you are primarily vibe coding, you are moving faster in the short run and accumulating a rework obligation that you will eventually pay. The developers who build durable careers in the AI era will be the ones who learn to use AI tools in service of engineering discipline, not in place of it.
For business owners and operators
The business implications are direct. If your development team operates primarily in the hacker mindset — fast builds, minimal tests, architecture that lives in one person’s head — you have a production tax coming. It arrives when the system hits scale, when a key developer leaves, or when an edge case appears that the original build never accounted for. Those are not hypotheticals. They are recurring events in every technology organization, regardless of how polished the demos looked.
The harder problem is that hacked systems and engineered systems look identical from the outside in the short run. This is why technical diligence matters in M&A, in fundraising, and in any transition where someone who didn’t build the system has to rely on it. A hacked system’s surface and an engineered system’s surface look the same until you open the architecture.
The additional risk now: if your team is using AI tools to produce code faster, the volume of code accumulating in your codebase has increased. The question of whether that code was produced with engineering discipline or not has become more consequential, not less.
My take
At LERETA, I spent five years inside a system that had accumulated decades of mainframe decisions that made sense at the time and compounded into a critical path that was nearly impossible to see clearly. What changed the trajectory of the engagement was not a technical fix. It was a wall-sized enterprise architecture diagram — what the team came to call “the Livermore Report” — that made the full scope of the legacy critical path visible to the CTO and board.
That diagram earned its name because it made the engineering reality legible to people who hadn’t built the system. And that legibility was what unlocked a $20 million, multi-year modernization commitment from the board. Not because the architecture was impressive on paper, but because it was honest — it showed exactly what engineering discipline would require to fix what decades of shortcuts had created.
That is the production tax Orosz is describing. It does not always arrive as a dramatic outage. Sometimes it arrives as a diagram on a conference room wall that shows precisely what the shortcuts cost and how many years it will take to unwind them. The companies that navigate that transition well are the ones that built with engineering discipline from the start — or at least recognized early enough that they hadn’t.
AI tools raise the stakes of this choice, not lower them. The demo window is cheaper to pass than it has ever been. The production tax is more expensive to pay. Engineering discipline is still the thing that determines which side of that line your system ends up on.
