Shift Left

When the software development workflow is represented as a timeline from left to right, shift-left is the idea of moving verification work—which was traditionally done all at once just before release (on the right)—to the design and coding stages (on the left). ### Where the Concept Comes From The concept originally spread through the context of DevOps and agile development. In waterfall-style development, testing was conducted as a separate phase after coding was complete. However, the later a bug is discovered, the more its remediation cost grows exponentially. Something that could be resolved with a specification change if caught at the design stage can trigger rework across multiple modules if discovered during integration testing. Shift-left is the formalization of this empirical lesson into organizational practice. ### Practical Applications Shift-left is not just about testing. In the security context, it has evolved into the practice of "conducting threat modeling from the design stage" under the name DevSecOps, and in the quality assurance context, it is implemented as a CI pipeline that "automatically runs static analysis and unit tests for every PR." Running formatters and linters via pre-commit hooks also falls under shift-left in the broader sense. The same principle is being applied in AI agent development. In harness engineering, rather than reviewing an agent's output after the fact, the goal is to create a state where "incorrect changes simply cannot be committed in the first place" through linters and type checkers. The further left the point of detection is shifted, the lower the cost of human intervention becomes.