How Software Companies Die
in the Age of A.I.

Every engineer knows the feeling.

You enter deep hack mode and the rest of the world disappears. The problem becomes the only thing that exists. You follow it through the codebase, remove everything unnecessary, find the design that makes the pieces fit, and keep working until the system feels inevitable.

The code is tight, the model is clear, and the machine behaves exactly as you intended. Nothing else matters.

In How Software Companies Die, Orson Scott Card calls programming the Great Game. The programmer becomes consumed by building something intricate, fast, and intelligent.

Money matters, but it is rarely what produces the best work. The deeper reward is making the thing work and earning the respect of people capable of understanding why it works.

This engineering spirit creates software companies.

A small group becomes obsessed with a problem. They understand the customer, the architecture, and the strange limits collected along the way. They move quickly because decisions, implementation, and responsibility stay close together.

The company succeeds because these people care more about the product than the process around it.

Then the company grows, and A.I. makes what happens next much faster.

Dax Raad and the missing bottleneck

Dax Raad's post about A.I. inside software companies challenges the main story companies tell themselves about A.I.

That story assumes engineering teams were already working at their highest possible level. The only remaining problem was how quickly engineers could produce code.

The fantasy looks like this:

Great ideas enter the company → engineers take too long to build them → A.I. removes the delay → the company produces ten times more value.

Raad describes something closer to reality:

The company rarely has good ideas → implementation cost filters some of them out → A.I. removes that filter → mediocre ideas become software at incredible speed.

His sharpest line is:

Ideas being expensive to implement was actually helping.

This does not mean expensive software development was good. Useful improvements were ignored because nobody had time. Small teams could not afford to test promising ideas. Repetitive work consumed energy that could have been spent thinking.

But limited engineering time forced a conversation.

Is this worth building? What problem does it solve? What should we stop doing to make room for it? Who will own it? What happens when it fails? Does it belong in the product?

A.I. can create an implementation before the company answers any of those questions.

The cost of producing code falls, but the cost of owning software does not.

A.I. speeds up the old death spiral

The old software company died slowly:

Engineers build something great → the company grows → managers and processes multiply → authority moves away from technical knowledge → the strongest engineers leave → the product gets worse → nobody understands why.

The A.I. version has an accelerator:

Engineers build something great → the company grows → management loses contact with the product → A.I. makes implementation cheap → weak ideas flood the codebase → experienced engineers become cleanup workers → they burn out or leave → the company loses its technical memory → management demands even more A.I. productivity.

A.I. did not create the mediocre company. It removed the last physical limit on how much mediocre work the company could produce.

The prototype arrives before the thinking

Before A.I., a weak feature request still had to reach an engineer.

The engineer could ask what the request meant, point out conflicts, identify an existing feature, reduce the scope, or explain why the proposed solution would create a larger problem.

Managers often described this resistance as engineers being difficult.

Sometimes engineers were being difficult. But sometimes that friction was the company thinking.

Now a manager can turn a rough idea into a convincing prototype before the people responsible for running it have examined the idea.

The prototype looks real. It has an interface, generated tests, a deployment file, documentation, and a polished demonstration. It may even work under demonstration conditions.

Once executives or customers see it, the prototype becomes a promise.

The engineer no longer receives a problem to solve. The engineer receives something described as almost finished and is asked to make it safe for production.

A.I. has allowed the software to arrive before the thinking.

Rough idea → generated prototype → executive promise → engineers inherit production risk.

More code creates more hidden work

Generated software must still be understood, reviewed, secured, deployed, observed, supported, upgraded, and eventually removed.

It creates dependencies. It adds new states the product can enter. Customers begin relying on it. Other teams connect their systems to it. What started as a cheap experiment becomes permanent work for the company.

The first version may take an afternoon, while ownership lasts for years.

This moves work from the person generating code to the people checking and running it.

A senior engineer who previously reviewed three careful changes may now receive fifteen generated ones. Every change looks complete enough to require serious attention.

Does it preserve the existing guarantees? What happens when two users act at the same time? Is the failure safe? Can the system recover? Is the dependency trustworthy? Does the company already have another system doing the same job?

The final question is whether the code should exist at all. A.I. increases implementation faster than companies can increase judgment, turning the best engineers into garbage collectors.

Cheap generation → more software to understand → review becomes the bottleneck → ownership compounds.

The people who care are buried under the output

Raad also points out that most employees will not use a fivefold productivity improvement to create five times as much value for their employer.

Many will use A.I. to finish their expected work with less effort and return to the rest of their lives.

That is not a moral failure. It is a reasonable response to a normal job.

The dangerous part is what happens to the small number of engineers who remain deeply invested in quality.

They are surrounded by more generated output, not more understanding. Their ability to care becomes a resource shared by the whole company.

They review the code. They repair the architecture. They handle incidents. They explain why a prototype cannot simply be deployed. They remember old failures that never made it into the documentation.

The person producing ten pull requests appears productive, while the person preventing those pull requests from damaging the product appears slow.

Eventually, the engineers who care stop building because their time is consumed by protecting the company from its own output. Then they leave.

More generated output → more cleanup → less time for real engineering → the people who care leave.

Management takes control of something it cannot understand

As a software company grows, it hires managers to make unpredictable creative work easier to control.

Schedules, performance ratings, delivery metrics, planning meetings, headcount models, and status reports give leadership a clearer picture of the company.

The problem begins when that picture replaces the real work.

A.I. produces extraordinary amounts of the first group while making the second group even harder to see.

This is why bad managers are naturally attracted to A.I. output. It makes engineering look measurable without requiring the manager to understand engineering.

Count visible output → reward visible output → invisible protective work disappears.

Boeing and the loss of engineering authority

Boeing shows what happens when leadership becomes separated from the act of building.

Historically, Boeing was led by people who understood aircraft. Engineers reached executive positions. Leadership stayed close to manufacturing, and technical judgment carried real authority.

After Boeing's 1997 merger with McDonnell Douglas, a finance-focused management culture increasingly replaced Boeing's engineering culture.

Leadership moved away from the factories. Important design and manufacturing work was outsourced. Short-term financial performance gained power over the people carrying the engineering knowledge of the aircraft.

Boeing kept its name while losing parts of its ability to understand how its own product came together.

The Atlantic's account of Boeing's decline describes a cycle familiar to software companies.

Outsourcing weakened Boeing's internal ability. The resulting problems made internal work appear more expensive. Management then used that expense to justify more outsourcing.

Remove technical ability → observe that the weakened company performs poorly → use the poor performance to justify removing more technical ability.

Boeing did not decline because managers existed. It declined because people far from the engineering work gained the power to overrule the people who understood it.

A.I. makes this separation easier to hide. A company can lose technical ability while continuing to produce convincing technical demonstrations.

Performance systems teach people to protect themselves

A recent Blind discussion summarized a complaint from a Meta employee: people were increasingly working for performance ratings instead of useful outcomes.

When taking a product risk can damage your review, avoiding risk becomes the sensible choice. This is an employee account rather than proof that every team at Meta works this way, but the incentive is familiar.

Blind framed the question clearly: what happens to innovation when avoiding failure is safer than trying to improve the product?

Ranking employees against one another turns coworkers into competitors for limited recognition.

Helping another engineer may improve the person you will later be ranked against. Sharing important work creates the risk that somebody else receives the credit. Attempting a difficult project creates visible evidence of failure. Joining a safe, highly visible project creates evidence of impact.

People adjust to the system, so the company ends up asking for teamwork while rewarding self-protection.

A 2025 study found that high-performing employees pushed down by a ranking cutoff were at least 34 percent more likely to leave voluntarily. Explanations, reassurance, and even additional money did not repair the feeling of unfair treatment.

The best engineers often have the easiest time finding another job, so they leave first.

Rank people against one another → product risk threatens ratings → safe visible work wins.

Managers hire people who feel familiar

Managers working inside subjective performance systems naturally protect people whose success supports their own decisions.

Hiring begins to follow the same pattern.

Managers recruit former coworkers, friends of trusted employees, people from familiar professional groups, and candidates who communicate like the existing team.

Familiarity starts to feel like competence.

This is not limited to one country, culture, or community. Every group can reproduce itself when hiring and promotion depend on personal trust.

The result is a team filled with similar people.

They may share the same education, former employers, nationality, social network, management style, or way of communicating.

Candidates who could genuinely raise the engineering standard may never be hired. They seem less predictable, lack an internal supporter, or appear more likely to challenge existing decisions.

People inside the manager's circle are judged by their potential, while people outside it are judged by their risk.

The company continues describing itself as a meritocracy while repeatedly hiring people who feel safe to those already in power.

Hire familiar people → disagreement falls → the team reproduces itself → the engineering bar stops rising.

Airbnb's warning about manager mode

Paul Graham's Founder Mode came from a talk by Airbnb co-founder Brian Chesky.

The useful lesson is not that founders should control every small decision. It is that leaders cannot operate a company entirely through managers and reports.

The usual advice looks like this:

Hire good managers → give each manager a department → agree on goals → stay out of the details.

This turns the company into separate boxes.

A political manager can control what information leaves their box. Failures become dependency problems. Departures become performance problems. Weak results become staff shortages. Every report makes the manager appear necessary.

Leaders do not need to write every function or approve every button, but they must stay close enough to the work to know when a report is hiding a broken system. Authority must remain connected to reality.

A.I. makes the numbers look better

The product can still become worse.

Features multiply until the interface becomes confusing. Services multiply until nobody understands how they interact. Tests multiply while important behavior remains unsafe. Documentation multiplies while real understanding disappears.

The company measures production while customers experience the product, and the two slowly move apart.

When leadership finally notices the decline, it often decides that engineering needs more speed. More automation is purchased. More output is demanded. More generated code enters the system.

The company attacks the part of the system that is already moving fastest.

More code → better productivity numbers → more product complexity → worse customer experience.

The new death spiral

This is how software companies die in the age of A.I.:

The company does not run out of code. It drowns in code. It can still release software, but it loses the ability to know what should be released.

Lose technical memory → demand more speed → generate more software nobody fully understands.

Protect the engineering spirit

The companies that survive will not necessarily have the most A.I. or produce the most software.

They will protect the conditions that allow engineers to care.

They will give technical judgment real authority. They will keep leaders close to the work. They will treat disagreement as useful information rather than disloyalty. They will reward engineers who simplify systems and stop bad ideas, even when doing so produces nothing visible to count.

They will use A.I. to reduce the distance between a good decision and a working result, not to avoid making the decision.

The scarce resource is no longer code. It is understanding.

That understanding is created during the moments when an engineer disappears into a problem, removes everything false, and returns with something tight, clear, and alive.

That spirit built the company.

Once management destroys it, A.I. can keep producing code long after the software company has already died.

Keep technical authority close to the work → use A.I. to execute sound decisions → protect engineering judgment.

Further reading

1. The Wetware Crisis: The Dead Sea Effect by Bruce F. Webster
2. Founder Mode by Paul Graham
3. Maker's Schedule, Manager's Schedule by Paul Graham
4. Things You Should Never Do, Part I by Joel Spolsky
5. Choose Boring Technology by Dan McKinley
6. Programming as Theory Building by Peter Naur
7. Big Ball of Mud by Brian Foote and Joseph Yoder
8. The Cathedral and the Bazaar by Eric S. Raymond
9. Good Product Manager / Bad Product Manager by Ben Horowitz
10. Microservices by James Lewis and Martin Fowler