"Give me six hours to chop down a tree and I will spend the first four sharpening the axe." Lincoln said that. We've known this for centuries.
The priority is always to deliver faster. So controls come after. More scanners. More gates. More reactive measures bolted on once the code already exists.
But what if you had those guardrails at the beginning? What if security, quality, and compliance were inputs to planning and building rather than reviews of the output?
That's "shift left" in a nutshell. And most teams are missing it.
The Build Phase is Now Basically Free
Not long ago, building software meant planning the implementation, splitting the work across a team, coordinating merges, resolving conflicts, and hoping everyone's assumptions aligned. The build phase had weight to it.
Simple implementations now? A prompt or two. Maybe an afternoon.
Complex implementations still take real effort. The back and forth, the context setting, the course correcting. But even then, what used to take a team a week now takes one person a day.
The code still needs to be reviewed. But let's be honest about what actually happens when a PR lands with 1200 lines generated in 40 minutes.
That gap between "code was created" and "code was understood" is where the SDLC started breaking.
Speed Exposed a Problem That Was Always There
The SDLC didn't break because of AI. AI just made it impossible to ignore.
PR backlogs aren't new. Neither is the pressure that comes with them. When reviews pile up, the timeline to merge shrinks. And when the timeline shrinks, reviews get shallower. Not because engineers are careless. Because there are only so many hours and the queue doesn't care.
The person who wrote the code is always more invested in it than the reviewer. They architected it. They know every decision. The reviewer is coming in cold, under time pressure, with their name on the approval. That dynamic existed long before any AI wrote a single line.
What AI did was pour gasoline on it. A backlog that used to build over days now builds in hours. A PR that used to represent a few days of work now represents an afternoon of generation. The reviewer's context didn't scale with the output. The expectation to merge still did.
We didn't create a new problem. We accelerated an old one past the point where we could pretend it wasn't there.
Code Scanners Are Reactive by Definition. Their Knowledge Isn't.
Code scanning tools, the ones that analyze your code for security vulnerabilities and flag risky dependencies, are reactive by definition. They need code to exist before they can analyze it. CVE databases flag vulnerabilities after a version is released, not before. That's not a flaw in the tooling. That's just how SAST and CVE scanning works.
But the knowledge behind those tools doesn't have to wait.
Before a single line gets written, whether by a developer or an agent, there's a planning phase. And that planning phase is where the real shift left happens. What does this feature need? What are the corporate coding standards? What compliance requirements apply? What dependencies are in or out of bounds?
That context needs to be an input to the build, not a review of its output. Agentic tools have mechanisms for this. Vendors still haven't agreed on a name. Shocking, I know. But the concept is the same. You encode your expectations before the agent starts, not after it finishes.
Dependencies are a good example. The knee jerk rule is "use maintained libraries." But that's too blunt. A utility library that does one thing well and hasn't needed to change in five years isn't a risk. What matters is whether there are known CVEs, whether the library is end of life (EOL), whether it fits within corporate policy, whether pulling it in creates a compliance problem. Developers and agents both need that context before they reach for a package, not after a scanner flags it three sprints later.
SAST knowledge, dependency policies, corporate coding standards. These can all shift left as inputs. The scanner becomes verification, not discovery.
Same Fix for Humans and Agents
The fix isn't new. It's just overdue.
Smaller PRs. Meaningful test coverage. Better planning before the first line gets written. These aren't agent-specific best practices. They're engineering best practices. The difference is that agents need them made explicit. A senior engineer absorbs corporate culture over time. An agent needs it written down every single time.
And not everything gets written down at the same level. Security standards and compliance requirements live at the corporate level. Architecture patterns at the team level. Implementation decisions within that. The hierarchy already exists for human developers. Agents just make it impossible to ignore when it isn't there.
This is where corporate policy becomes rules. The same expectations that govern how a developer writes code need to be encoded as context before an agent starts building. Not as an afterthought. As an input.
Here's the uncomfortable part. If you can't write your standards down clearly enough for an agent to follow, ask yourself if a new engineer joining your team would fare any better. Teams that have clear, written, maintained standards will get good output from agents. Teams that run on tribal knowledge and institutional memory will get chaos. The agent didn't create that problem. It just made it visible.
What It Actually Looks Like
Start with the rules. Not the agent. Not the tooling. The rules.
An SDLC or agent without rules is just a fast way to produce code that doesn't meet your standards. The rules are the work.
When building them for the first time, start with security. Not coding style. Not architecture preferences. Security first. CVE policies, approved dependency lists, SAST expectations, compliance requirements. These are the non-negotiables. Get those written down before anything else.
Then corporate policy. Coding standards, test coverage thresholds, the things that apply across every team in the organization. Then team level decisions. Architecture patterns, framework choices, style preferences within those corporate bounds.
That hierarchy matters. Security sets the floor. Corporate policy sets the walls. Teams work within them.
And don't treat this as a one time setup. These rules are living documents. When corporate policy updates, the rules need to follow. The best way to make that manageable is to link your rules back to the source of truth rather than copying them. A rule that drifts out of sync is worse than no rule at all.
The goal isn't a perfect set of rules on day one. It's a system that stays current and gets more specific over time.
The Work Is Worth It
The build phase is cheap now. That's not changing.
What isn't cheap is building poorly at speed. Technical debt, security vulnerabilities, compliance failures. Those costs didn't go down when the build phase did. They just arrive faster.
If you're a tech lead, architect, or sitting in a CISO or CTO seat, this is the work on your plate. Not picking the right agentic tool. Getting your standards written down clearly enough that a human or an agent can follow them without guessing.
The build is cheap. The discipline isn't. But it's the only thing that makes the speed worth having.
