Engineers are no longer the first people to write code.

Shift-left used to be about testing, security, and quality earlier in the lifecycle. That’s done. The real shift now happens before engineers even touch the keyboard.

AI is writing the first drafts, prototyping the ideas, and even shipping experiments. Welcome to shift-coding-left.

Shift-coding-left

AI is shifting the actual act of coding left. Writing code is no longer the exclusive domain of engineers. Product Managers, Designers, and other non-technical stakeholders can now create working code in minutes.

Whenever this topic comes up, engineers shout “AI-slop” and scoff at “vibe coding.” They’re not entirely wrong. Without the right constraints and tools in place AI output can be messy, inconsistent, and sometimes just plain wrong.

But here’s the thing they’re missing, done right it surfaces problems faster, prototypes ideas before anyone writes production code, and accelerates learning in ways no human could alone.

The goal isn’t to silence the critics, it’s to channel the chaos. Put guardrails and processes in place that let teams embrace the speed AI offers, without breaking things.

The Traditional Bottleneck

In the traditional model, a Product Manager or Designer has a vision for a new feature or an experiment. The process usually looks like this:

  • Design: High-fidelity mocks are created in Figma.
  • Handover: A ticket is created in Jira.
  • The Queue: The idea waits until it can be prioritised.
  • Development: A developer builds a “throwaway” prototype to test the hypothesis.

This cycle can take weeks, or even months. By the time the non-technical stakeholder sees a working version, the initial spark of the idea may have faded, or the market window has closed.

Coding at the Speed of Thought

As teams implement AI-assisted engineering into their workflows, something interesting is happening. Not only does AI speed up developers, but it allows non-technical staff to generate functional, interactive code that works as part of real applications. This isn’t just “No-Code” drag-and-drop; this is generating real code that works within our existing apps.

This is the real shift, prototyping is no longer gated by engineering. Non-technical stakeholders can build:

  • Experimental UIs: A designer can prompt an AI to turn a static mock into a functional UI with real states to test with users immediately.
  • Interactive POCs: A PM can build a functional Proof of Concept that fetches real data from an API to prove value before asking for engineering resources.
  • Internal Tools: Ops teams can build custom dashboards without waiting for a full sprint cycle.

Why This is a Win for Engineering

At first glance, developers might worry about messy code. However, shifting-coding-left fundamentally changes the role of the engineer for the better.

  1. Reduced “Throwaway” Work: Engineers hate building things that get scrapped after one user test. If a product manager builds the “disposable” prototype, the engineer only steps in for the “durable” production version.
  2. Higher Fidelity Requirements: Instead of a static image, engineers receive a functional prototype. They see exactly how the logic is intended to flow, reducing ambiguity.
  3. Focus on the “Hard Problems”: With the “UI shim” handled by stakeholders, engineers can focus on architecture, security, and scalability.

The Two Flavours of Shift-Left Coding

When non-technical staff “write code,” it falls into two buckets. Understanding the difference determines the level of engineering oversight required.

Disposable Code

This is for the “Can we even do this?” phase. It is our AI-Developed Proof of Concept.

  • Goal: Internal validation and testing core logic.
  • The Guardrail: This code lives in a sandbox and never touches production. If it works, the learnings are handed to Engineering to be rebuilt properly.

Ephemeral Code

This is for the “Which works best?” phase. It is our AI-Developed Experiments.

  • Goal: A/B testing a new component or CTA.
  • The Guardrail: This is “Short-Lived Code” designed to be deleted.
    • Engineering provides a “Component Library” to ensure the AI-generated UI stays on-brand and safe.
    • Engineering code-reviews the changes

Another visual: DevOps with “Fast Tracks”

Another way to think of this is that the Shift-Coding-Left model adds two “Fast-Tracks” to the traditional loop.

  • AI-Developed Proof of Concept Fast Track
    • Non-technical stakeholders can build proof of concepts that can be used for internal review or user testing.
    • Engineering then receive a fully formed, proven idea ready to be turned into reliable production quality code.
    • This is our Disposable Code
  • AI-Developed Experiment Fast Track
    • These are small code changes (like testing two CTA versions).
    • They skip straight to testing and CI pipelines.
    • Results from production flow back to the “Plan” stage for final production implementation of the winning experiment.
    • This is our Ephemeral Code

Why Engineers Should Embrace “Shipping” Experiments

If you have a robust feature flag system, a modern CI/CD pipeline, and a well configured workflow for creating AI-generated UI experiments, then they become no more dangerous than a manual CSS change. By letting PMs ship their own split-tests, you remove Engineering from the “can you change this button colour?” business and put them back into the “how do we scale this to 10 million users?” business.

In this model, the engineer’s job evolves into a “Park Ranger.” They build the fences (Sandboxes), maintain the trails (CI Pipelines), and ensure the environment is healthy so others can explore safely.

The Future

We are entering an era where the barrier between “having an idea” and “building an idea” is paper-thin. When PMs and designers can “shift-left” into the coding phase, the feedback loop shrinks from weeks to minutes.

The question is no longer about engineering capacity, but Governance. The teams that win will be those that create the safest “Playgrounds”.

The teams that win won’t write the most code — they’ll create the safest environments for everyone to build in.

Further reading

If you enjoyed this post then be sure to check out my other posts on Engineering Leadership.

Join the flock

Subscribe to get the latest posts on the messy reality of software delivery sent directly to your mailbox. I regularly share new thoughts on leadership and strategy —zero spam, just value.