What is shift left?
Engineering culture and software practice
Shift left means moving testing, security, quality and compliance checks earlier in the delivery process, towards the left of a timeline, so that problems are caught when they are cheap to fix rather than after release. The term was coined by Larry Smith in a 2001 Dr. Dobb's Journal article on testing. It is now a slogan in security ("shift-left security") and increasingly in AI governance.
What this means
Picture a project as a timeline running left to right, from first idea through design and building to release and beyond. For decades, checking, testing, security review, compliance, was bolted on at the right-hand end, just before or after launch. That is the worst possible place to find a problem, because everything built on top of it has to be unpicked.
Shift left is the simple instruction to move those checks leftward, towards the start. Test as you design and build, not only at the end. Think about security while you are choosing how to build something, not after an incident. Do the compliance review at the beginning of a campaign, not the night before it goes live. The idea is that a problem found early is small, local and cheap, while the same problem found late is large, entangled and expensive.
It is one of the more intuitive ideas in software, which is part of why it spread so far beyond software. The catch, as we will see, is that the evidence for exactly how much cheaper early fixes are is weaker than the slogan suggests.
Why it matters
For any organisation that builds or commissions software, shift left is about where you spend attention. Catching a flawed requirement during a design conversation costs a meeting; catching it after launch can cost a rebuild, a breach or a regulatory problem. Moving checks earlier is one of the highest-leverage habits available, and it is largely a matter of sequencing rather than spending.
The idea generalises cleanly to work that is not software at all. A legal review at the start of a marketing campaign, rather than the night before it launches, is shift left. Data protection by design, where you assess privacy risks with an early data protection impact assessment before building a system rather than after complaints, is shift left for privacy. In each case the move is the same: bring the check forward to where the decision is still cheap to change.
It matters most for AI adoption right now. Evaluating whether an AI use case is appropriate, safe and worthwhile before building it, rather than after users complain, is the AI-governance version of shifting left. Reviewing a use case early, defining how you will test the system's behaviour, and checking data and privacy implications up front, saves the far greater cost of unwinding a deployment that should never have gone ahead.
But leaders should also understand the honest limits of the economic argument, because "shift left" is often sold with a precision the evidence does not support, and it can be misapplied in ways that make life worse rather than better.
How it works
Where the term came from
The phrase was coined by Larry Smith in an article titled "Shift-Left Testing", published in Dr. Dobb's Journal in September 2001. Smith described it as a better way of integrating quality assurance and development, so that testing starts early and runs continuously rather than being thrown "over the fence" to a separate QA team at the end. The original article is catalogued in the ACM Digital Library; the full text now survives mainly in archived copies, since Dr. Dobb's ceased publishing new material, so a reader chasing the primary text may only find it archived.
The economic case for shifting left rests on the older "cost-of-change curve" associated with Barry Boehm, whose 1981 book Software Engineering Economics popularised the observation that defects cost more to fix the later they are found. It is important to be honest about how strong that evidence is. Laurent Bossavit's The Leprechauns of Software Engineering is the best-known critique, arguing that the famous precise multipliers, the claim that a bug costs ten times more at each stage and a hundred times more in production, trace back to secondary sources without solid underlying data. The direction of the effect is well supported: Boehm and Basili's peer-reviewed "Software Defect Reduction Top 10 List", published in IEEE Computer in January 2001, states that finding and fixing a problem after delivery is often 100 times more expensive than during the requirements and design phase, but adds the caveat almost everyone drops, that on small, non-critical projects the ratio is closer to five to one. The granular chart is folklore; the general direction is sound.
How it spread
Shift left moved from testing into the mainstream through continuous integration, DevOps and then DevSecOps, where security is built into the pipeline rather than added at the end. It now underpins official guidance: the US Cybersecurity and Infrastructure Security Agency's Secure by Design initiative and the UK National Cyber Security Centre's secure development guidance both push security earlier in the lifecycle, urging that whole classes of vulnerability be designed out during development rather than patched after release.
What actually gets shifted
"Left" can absorb a lot of different checks. The common ones are automated testing, security scanning and threat modelling, accessibility checks, compliance and data protection review, and, increasingly, AI evaluations, structured tests of how an AI system behaves. The unifying principle is earliness: each of these is cheaper and more effective when done while the relevant decision is still being made, rather than as a gate at the very end.
Shift left and shift right
There is a counterpart called shift right: testing in production, observability and monitoring real behaviour after release. It sounds like the opposite of shift left but it is complementary, not opposed. Some problems, real-world load, genuine user behaviour, rare edge cases, only appear in production and cannot be found early however hard you try. Mature teams do both: shift left to catch what can be caught early and cheaply, and shift right to catch what only reality reveals.
Examples
A software team of eight keeps shipping features that fail in the first days after release, triggering stressful late-night fixes. They shift left by writing automated tests as they build and running them continuously, and by adding a short security and accessibility check to their definition of done. Defects that used to surface as production incidents now appear on a developer's screen minutes after being introduced, when they are trivial to fix. The work did not get bigger; it moved earlier.
A charity plans a fundraising campaign and, as usual, sends the creative for legal and data protection review the day before launch, forcing a scramble of last-minute changes. The next campaign, they shift the review to the very start, briefing legal and doing a data protection impact assessment while the concept is still on the whiteboard. The review now shapes the campaign cheaply instead of blocking it expensively, which is shift left applied entirely outside software.
A professional services firm wants to deploy an AI assistant to answer client queries. Instead of building it and waiting for complaints, it shifts governance left: it reviews the use case up front, defines evaluations for the assistant's answers against real examples, and checks the privacy implications before a line of integration is written. The review concludes that one category of query is too sensitive to automate, a decision that costs an afternoon early on but would have cost a serious incident if discovered after launch.
Common misunderstandings
People treat the precise cost multipliers as established fact. They are not. The claim that fixing a defect costs ten times more at each successive stage, rising to a hundred or a thousand times in production, rests on weak primary evidence, as Bossavit's critique documents. The direction is sound, early is cheaper, but the exact numbers are folklore dressed as data, and leaders should not build business cases on the specific figures.
People think shift left means buying scanning tools. It does not. Purchasing a security scanner or a test-automation suite and running it is not the same as shifting the thinking earlier; without changing how and when people make decisions, the tools just automate a late-stage gate. Shift left is a change in sequence and mindset, not a procurement.
People confuse shift left with the "works on my machine" problem. They are different. "Works on my machine" is a developer waving away a defect because it does not appear in their own environment, a way of avoiding a problem late. Shift left is the opposite instinct: deliberately surfacing problems early, including the environment differences that "works on my machine" hides.
People assume shift left means dumping testing and security onto developers. That is a common misapplication, not the idea itself. "Shift left" too often becomes "make the development team responsible for everything, earlier", which overloads people and backfires. Done well, shifting left means giving teams the support, tools and time to do the earlier checks, not simply moving the burden and walking away.
People think shift left replaces testing in production. It does not. Shift right, monitoring and testing in the real environment, catches problems that only appear under real load and real use. The two are complementary, and mature teams need both.
Risks and boundaries
The first boundary is evidential honesty. Shift left is intuitively sensible and broadly supported in direction, but the precise economic claims attached to it are not well founded, and CISA itself has noted that the real question, how much to invest in shifting security left, remains genuinely hard to quantify. Treat shift left as a sound principle, not as a formula that yields exact savings.
The second is the developer-burden trap. Moving checks earlier can quietly become a way of offloading testing, security and compliance onto already-stretched delivery teams. If shifting left is not matched with tools, training and time, it degrades into "everything is now your problem, sooner", which harms morale and, ironically, quality. The point is to make early checks easy, not merely mandatory.
The third is the tooling trap: mistaking the purchase of scanners and automation for the cultural change the idea actually requires. A tool that runs late in the pipeline has not shifted anything left; it has just automated a late gate.
Finally, shift left has limits of reach. Some problems genuinely cannot be found early, no matter how much you invest, because they only emerge in production under real conditions. That is why shift right exists and why the sensible debate is not shift left versus shift right but how to balance the two. For a small firm, the practical version of all this is modest and achievable: bring the obvious checks forward, legal at the start of a campaign, a privacy assessment before building, a use-case review before deploying AI, without pretending it guarantees a precise return.
What to do next
Move your obvious checks to the front. Put legal and data protection review at the start of campaigns and projects, not the night before launch, and make an early review the default rather than the exception. This is the cheapest, highest-return version of shifting left and needs no technology at all.
For AI work, review the use case before building it. Decide early whether a use case is appropriate and worthwhile, define how you will evaluate the system's behaviour against real examples, and check the data and privacy implications up front, so you never build something that should have been stopped at the idea stage.
Resource the shift, do not just mandate it. If you ask teams to test, secure and check earlier, give them the tools, training and time to do it, or the burden will land on stretched people and the quality gain will evaporate.
Do not buy your way to shift left. Treat scanners and automation as helpers, not as the change itself; the real move is earlier thinking and earlier decisions, which is a matter of sequence and culture rather than procurement.
Keep some checks on the right. Invest in monitoring and observing real behaviour after release as well, because some problems only appear in production, and balancing early checks with real-world monitoring beats treating either as a complete answer.
FAQs
Who coined the term shift left?
Larry Smith, in an article titled "Shift-Left Testing" in Dr. Dobb's Journal in September 2001, describing a better way to integrate quality assurance with development so testing happens early and continuously.
What does shifting left actually mean?
Moving checks, testing, security, quality, compliance, earlier in the timeline so problems are found while they are small and cheap, rather than after release when they are large and expensive.
Is it true that late defects cost a hundred times more?
The direction is well supported, but the precise multipliers are not. Boehm and Basili's peer-reviewed work suggests roughly a hundred times on large projects but nearer five times on small ones, and the famous granular chart lacks solid evidence.
Does shift left mean buying security scanning tools?
No. Tools can help, but shifting left is a change in when and how decisions are made. A scanner running late in the process has not shifted anything earlier.
What is shift right, and is it the opposite?
Shift right means testing in production and monitoring real behaviour after release. It is complementary, not opposed, because some problems only appear under real use. Mature teams do both.
How does shift left apply to AI?
Review an AI use case before building it, define how you will evaluate the system, and check data and privacy implications up front, rather than waiting for complaints after deployment.
What is the main way shift left goes wrong?
Dumping the extra work on delivery teams without giving them tools, training and time. Done that way it overloads people and backfires; done well it makes early checks easy, not just mandatory.
What is the smallest useful version for a small firm?
Bring the obvious checks forward: legal at the start of a campaign, a data protection assessment before building, and a use-case review before deploying AI. No large investment is required.