“Move fast and break things” was a product development philosophy. It was never an engineering philosophy, and it was certainly never a data philosophy. But somewhere along the way, it became the default operating mode for AI teams, and the results have been predictable.
When you break a social media feature, users see a broken button. When you break an AI system, users see a wrong answer, and they often cannot tell it is wrong. The failure mode is fundamentally different, and the speed-at-all-costs mindset does not account for the difference.
The asymmetry of AI failures
Software failures are usually visible. A page does not load. An error message appears. A transaction fails. The user knows something went wrong, and the engineering team gets a clear signal to fix it.
AI failures are usually invisible. A model returns a plausible but incorrect result. A recommendation is subtly biased. A prediction is confidently wrong. The user does not know. The engineering team does not get a signal. The failure propagates silently into decisions, reports, and downstream systems.
This asymmetry means that the cost of moving fast in AI is not just the cost of fixing bugs. It is the cost of acting on bad outputs without knowing they are bad. A hiring model that encodes bias does not produce an error message. It produces rejected candidates. A forecasting model that overfits to a seasonal pattern does not crash. It produces optimistic revenue projections that lead to bad spending decisions.
Moving fast in a system with invisible failure modes is not bold. It is reckless.
Speed creates compounding technical debt
In traditional software, technical debt is visible and relatively contained. A poorly written function can be refactored. A bad API design can be versioned. The debt is in the code, and the code can be changed.
In AI systems, technical debt extends into the data, the model behaviour, and the organisational trust in the system. A model trained on a hastily assembled dataset encodes the quality issues of that dataset into its behaviour. Retraining does not fix the problem if the data pipeline that feeds the model has not been fixed. The debt is not in the code. It is in the system’s understanding of the world.
We have seen organisations that built AI systems in six weeks spend six months fixing the consequences. The six-week build skipped data validation, used whatever features were available, deployed without monitoring, and shipped without a rollback plan. Every shortcut became a liability. The system worked in the demo. It did not work in production, and the fixes required rebuilding significant portions of the system.
The irony is that moving fast did not save time. It borrowed time from the future at a high interest rate.
The regulatory environment has changed
When “move fast and break things” was coined, the regulatory environment for software was minimal. You could ship a broken product, fix it quickly, and face no consequences beyond user frustration.
AI systems now operate in a different regulatory landscape. The EU AI Act classifies AI systems by risk level and imposes requirements for documentation, testing, monitoring, and human oversight. Financial regulators require model explainability. Healthcare regulators require validation against clinical standards. Hiring algorithms face anti-discrimination scrutiny.
Moving fast and breaking things in this environment does not just produce technical debt. It produces legal liability. A model that was deployed without proper bias testing becomes a lawsuit. A system that lacks documentation becomes a compliance violation. The cost of speed has changed because the consequences of failure have changed.
What “move fast” should mean for AI
The answer is not to move slowly. AI teams need to ship, iterate, and learn from production. The answer is to move fast on the right things.
Move fast on experimentation. Try new model architectures. Test new feature ideas. Evaluate different approaches. Speed in exploration is valuable because the cost of a failed experiment is low.
Do not move fast on deployment. Deploying a model to production is not an experiment. It is a commitment. Users will act on its outputs. Downstream systems will depend on its behaviour. The cost of a failed deployment is high because the failure is invisible and the blast radius is large.
The discipline is in separating the two. Experiment rapidly in sandboxes. Deploy carefully to production. The teams that get this right have fast iteration cycles and slow, deliberate deployment gates. They do not choose between speed and quality. They apply speed where it helps and rigour where it matters.
The heuristic
If you cannot explain how your AI system will fail, you are not ready to ship it. Moving fast without understanding the failure modes is not innovation. It is negligence with a startup vocabulary.
The teams that build durable AI systems are not the fastest. They are the ones who know exactly where the speed limits are and why.
