Higher value work isn't a vibe.

It has a shape.

And if you want to know whether AI has actually moved you up or just made you faster at standing still, you have to be able to see the shape clearly enough to find yourself inside it.

Think about your work week as three layers stacked on top of each other.

The Three Layers

"Execution" is the bottom layer

It's the doing, drafting the deck, writing the status update, running the standard analysis, formatting the report, summarising the meeting, and working through the checklist. Anything where "done" is definable in advance and the steps could, in principle, be written down for someone else to follow.

This is the layer where the floor has dropped out.

Not because AI does Execution work perfectly, it doesn't, and anyone who tells you otherwise hasn't shipped anything important recently, but because the time cost has collapsed far enough that nobody pays a premium for execution alone anymore.

What used to take three hours of competent effort now takes twenty minutes of competent direction.

The work still happens. It's just no longer scarce, and value tracks scarcity, not effort.

If most of your week is Execution hours, you're standing on the layer that's being commoditised under your feet, in real time. The discomfort of that sentence is the point.

"Judgement" is the layer above Execution

It's the two questions, both of which AI cannot answer for you, no matter how good the model gets.

The Upstream Question

Of all the things you could point or ask this machine at, which one actually matters here? For this stakeholder, in this situation, given everything you know that isn't written down anywhere, the history, the politics, the thing the last project taught you that nobody documented.

Choosing the right problem is a different skill from solving it, and AI helps with the second much more than the first.

The Downstream Question

Now that the output exists, is it right?

Not "does it look right", does it hold up?

Against reality, against context, against what could actually go wrong if someone acts on it?

Verification isn't checking grammar; it's the harder act of catching fluent wrongness, which is the defining failure mode of AI-assisted work.

AI doesn't shrink the Judgement layer, it expands it.

There's now ten times more output flying around than there used to be, and the people who can decide what's worth producing and whether the result holds up are in shorter supply, not longer.

The premium on Judgement is going up, not down, and it will keep rising as models become more fluent without becoming more accountable.

"Creativity" is the Top Layer

The smallest of the three, the one most often misunderstood, and the one where AI is least dangerous and least useful at the same time.

Creativity here doesn't mean "being creative" in the art-class sense.

It means the move that reframes the problem

• Noticing that the question everyone is answering is the wrong question.

• Seeing the connection between two things that nobody put together.

• Producing the option that wasn't on the list because nobody knew the list was incomplete.

AI is a strong assistant to creativity. It can generate variations, surface adjacent ideas, break you out of a rut, give you ten bad options so the eleventh good one becomes visible.

But the originating spark, the wait, what if we're solving the wrong problem entirely, still comes from a human with context and stakes.

AI expands within the frame you give it

It does not hand you a new frame, and it does not know when the old frame has become useless.

The reframing is yours.

AI eats the bottom, the upper layers get more valuable, and you climb. This is the version of the story everyone is telling each other, and it's directionally correct, but it's also incomplete in a way that matters.

The Part that isn't told

AI makes Execution-layer work feel like Judgement-layer work.

The output is comprehensive, confident and well-structured. You read it, and your brain quietly files it under I thought this.

You didn't, you recognised it.

Those are two different operations, and only one of them is yours, but the interface gives you no way to tell them apart from the inside.

There's no indicator, no warning.

No little icon that lights up when you've stopped thinking and started just nodding along to fluent prose.

There's a name for what happens to people in this situation.

Metacognitive decoupling

Your confidence in your own work rises faster than your actual capability, and there is no internal alarm, because the outputs keep getting better.

The thing producing the outputs is improving; you are not. But because the only signal you can see is the output, you experience the improvement as your own.

The feeling of having climbed the stack is real; the climbing is not.

This isn't a hypothetical risk.

In 2025, researchers studied experienced gastroenterologists at four endoscopy centres in Poland after AI polyp-detection tools were introduced into their daily practice. The study tracked the doctors' ability to find polyps without the AI assistance.

After a few months of routine use, their unaided detection rate had dropped measurably by around six per cent compared with the pre-AI baseline.

These were experienced physicians. The tool adopted to make them better had quietly made them worse. Nobody noticed in real time, because the AI-assisted numbers looked great.

The decay was invisible until somebody specifically looked for it.

The same pattern shows up in legal work, software engineering, financial analysis, and strategic planning, wherever AI is used routinely for tasks that humans used to develop and maintain skills.

The domain changes, but the pattern doesn't.

People who use AI a lot get better at using AI and worse at the underlying judgment, and they almost always think it's the other way around.

Call it Sleeping Driver mode.

The car is moving. You're in it, but you're just not the one driving - you're monitoring, occasionally, when something feels off, and the rest of the time the automation is doing the thinking for you.

From the outside, it looks identical to driving. From the inside, when nothing has gone wrong yet, it feels identical too.

The difference only becomes visible the moment you're asked to take the wheel, and by then, it's information about something you can't undo.

What naming it does and doesn't do

Be suspicious of any blog post that names a problem and implies the naming is half the solution.

It isn't.

Knowing about Sleeping Driver mode is like knowing about confirmation bias. You can name it, you can explain it to someone else, and you'll still fall into it tomorrow.

Naming a habit doesn't change the habit.

The trap lives in the small choices you make when nobody's watching: whether you read the AI output carefully or just skim it, whether you check the statistic or trust it, whether you ask the model to argue against your own instinct or take its first answer and move on.

So I won't pretend reading this has fixed it. It hasn't.

What you have, if any of this landed, is a sharper question to carry into next week.

Of the AI-assisted hours you put in, how many were actually Judgement hours, and how many were Execution hours wearing Judgement's clothes? You won't know in the moment. You'll only know later, when you try to reconstruct what you were thinking — without the document in front of you.

If you can reconstruct it, you were driving.

If you can't, the car was.

For most people who use AI a lot, the honest answer is some of both, and more of the second than I'd like.

That's not a verdict, it's a baseline.

Once you can see it, you can do something about it, and that's a longer conversation than this post can hold. I'll come back to it in the next blog.

For now, the work is just noticing.

Over the next week, when you finish a piece of AI-assisted work and feel that small flush of satisfaction at how good it looks, pause for the length of a breath and ask yourself which layer you were actually on while you were producing it.

Not which layer you wish you were on, which one were you actually on?

The answer will be more honest than you expect, and more useful.

From a book I'm writing on the five skills that separate people who use AI from people who think with it. If this landed, that's the gap it's about.

Reference

Budzyń K, Romańczyk M, Kitala D, et al. Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy: a multicentre, observational study. The Lancet Gastroenterology & Hepatology, 2025;10(10):896–903. https://www.thelancet.com/journals/langas/article/PIIS2468-1253(25)00133-5/abstract

If it hurts, do it more frequently, and bring the pain forward.

— Jez Humble & Dave Farley, Continuous Delivery (2010)

Shift left and continuous testing are two of the most misunderstood terms in software engineering. Not because they're complex, but because everyone thinks that they're already doing them.

They are not.

In the last post on the traditional quality model, the math was clear. A defect caught in requirements costs \(1, but the same defect in production costs \)10,000 or more.

The Traditional quality model will always have these problems unless the development workflow ensures that defects can be detected as early as possible.

Shift Left Testing and Continuous Testing are the exact two disciplines that directly address everything broken about the traditional model.

But there are a lot of misconceptions and wrong implementations of it.

Let's clear each of them and see what they actually mean in practice.

Shift Left Is Not about Moving Testers Earlier

Most teams hear "shift left" and immediately think,

" Let's get QA involved in sprint planning. Have testers review stories earlier. Write test cases before code."

That's a start. But it's not shift left. That's just earlier QA.

Shift left is a fundamentally different relationship between quality and the development process. It's the recognition that quality decisions are made throughout the entire lifecycle, in requirements, in architecture, in design, in code review, and that the people making those decisions need quality thinking, not just quality checking at the end.

The difference matters enormously.

Checking quality at the end means someone inspects what has already been built and flags the problems. Shifting quality left means quality constraints shape what gets built in the first place.

One is reactive. The other is preventive. And prevention, as we established, is cheaper by orders of magnitude.

What Shift Left Actually Looks Like

I have implemented shift-left practices across five different industries — aviation, healthcare, government, fintech, and enterprise software.

The pattern is consistent across domains.

It begins with the Requirements.

Not with test cases, with the requirements themselves. Before a single line of code is written, the question is: how will we know this works?

Not "what tests will QA run," but "what does correct behaviour actually mean for this feature, in this context, for this user?"

This question sounds simple, but it is equally hard to answer well. Most teams skip it and discover the ambiguity later, in production, at 10x the cost.

It extends into architecture.

Quality-relevant decisions like how failures are handled, how the system degrades under load, and how errors are surfaced to users are architectural decisions.

If QA or quality thinking is not in the room when those decisions are made, it inherits their consequences without having influenced them.

It lives in code review.

Unit testing, defensive coding, meaningful error handling, and observable instrumentation are quality practices that developers own. Not because QA handed them a checklist, but because the team has a shared definition of what "done" actually means.

Done doesn't mean code merged.

Done means observable, testable, and deployable with confidence.

It changes who asks the hard questions.

In a shift left environment, the question "what could go wrong here?" isn't only asked by QA during test execution. It's asked by developers writing the story, architects designing the solution, and product managers defining the acceptance criteria.

Quality thinking becomes distributed. The defect detection surface moves left, toward the source.

Quality becomes everyone's responsibility

When it's said that "Quality is everyone's responsibility", that's where it becomes the uncomfortable part, but Shift Left is not only a QA initiative; it's an engineering culture change.

QA can advocate for it, QA can model it, but QA can't impose it.

If leadership doesn't understand that quality is everyone's responsibility, shift left remains a slogan.

It's clear now that shift left moves the defect detection surface earlier, but earlier is not enough on its own.

You also need faster, and that's where continuous testing comes in.

Continuous Testing Is Not Running More Tests

Here's the second common misunderstanding.

Teams adopt CI/CD pipelines and run their test suites automatically on every commit. They call this continuous testing.

It's not.

Running the same tests faster is "Automation".

Continuous testing is a different thing entirely; it's the integration of quality signals throughout the delivery pipeline in a way that makes the cost of a defect visible at the moment it's introduced.

The distinction is timing, again, but finer-grained.

In traditional testing, you find out about a defect when QA runs the test suite, usually at the end of a sprint, during a testing phase, or in UAT.

In automated regression, you find out faster, but still after the fact.

In Continuous Testing, you find out at the point of change, the commit, the build, the deployment- before the defect has had time to compound into something harder to unpick.

That 10,000x cost multiplier operates at every stage, not just between requirements and production. A bug caught at the commit level costs almost nothing. The same bug caught after it's merged into main and touched five other services costs significantly more, even if it's caught before production.

Continuous Testing compresses that timeline to the minimum.

What Continuous Testing Actually Looks Like

It starts with fast feedback loops

The test suite has to be fast enough that developers don't route around it.

A suite that takes forty minutes to run gets run at the end of the day, if at all.

According to DORA research, high-performing teams maintain test suites that provide feedback quickly enough to keep developers in flow. The moment that the loop breaks, developers treat the pipeline as an obstacle rather than a quality gate. Speed is a quality property of the test suite itself. Most teams treat it as an afterthought.

Speed is a quality property of the test suite itself

It requires the right distribution of tests - The Test Pyramid

The test pyramid isn't just a concept; it's an engineering constraint.

Fast unit tests at the base. Component in the middle using mocks without external dependencies. Contract tests at the integration boundary, verifying that services honour the agreements they make with each other without requiring full end-to-end execution. Then, integration tests are run after that for real user flow validation, and lastly, a small number of critical end-to-end tests at the top.

Too many slow, expensive end-to-end tests and your continuous testing pipeline crawls.

The distribution determines the speed, and the speed determines whether the pipeline is trusted.

• Write tests with different granularity

• The higher-level you get the fewer tests you should have

— Mike Cohn

It means testing at multiple levels simultaneously

Not sequentially.

Unit tests run at commit. Integration tests run at build. Performance baselines run at merge. Security scans run alongside. Production monitoring runs continuously. Each layer catches different failure modes at the appropriate cost.

It requires production to be part of the quality signal

This is where most teams stop short.

They treat production as outside the quality boundary, something that happens after QA signs off. But production is where real users encounter real failure modes under real conditions.

Feature flags, canary deployments, observability pipelines, anomaly detection, these are continuous testing practices. They extend quality visibility beyond the testing environment into the place where quality actually matters.

It changes how you think about test ownership

In a continuous testing environment, tests aren't only owned by QA.

They're also owned by the team that owns the functionality. QA sets the standards, defines the coverage criteria, and validates the approach. But the developer who writes the feature writes the unit tests. The team that owns the service, along with QA, maintains its integration tests.

QA then focuses on what requires QA-level expertise, exploratory testing, failure mode analysis, quality strategy, and the hard edge cases that automation can't anticipate.

You Cannot Test What You Cannot See

This is the insight most shift-left and continuous testing articles miss entirely, and it's the one that matters most.

Before a team invests in expanding test coverage, they need to be able to see their system behaving in production.

Logs that tell a story.

Metrics that surface anomalies before users notice them.

Traces that reveal what actually happened when something went wrong, not just that it went wrong.

Instrumentation has to come before automation, Not after.

Automation on top of a system you cannot observe just produces faster failures that are harder to diagnose. I've seen teams with 90% test coverage ship defects that took weeks to root-cause in production, not because their tests were wrong, but because they had no visibility into what the system was actually doing once it left the test environment.

The test suite tells you what the system does in the conditions you anticipated. Instrumentation tells you what it does in the conditions you didn't.

Both are necessary. The order matters.

Where Most Teams Get It Wrong

There's a failure mode I've seen consistently across organisations that attempt shift left and continuous testing without understanding what they're actually changing.

They treat it as a tooling problem.

They buy a CI/CD platform, adopt a test automation framework, mandate a shift left policy, and wonder why nothing changes. The bugs still pile up. Releases still slip. QA still becomes the bottleneck.

The tools are not the problem. The mental model is.

Shift left and continuous testing are not automation initiatives. They're quality philosophy changes that have technical implementations.

The philosophy has to come first.

What does quality mean for this system?

Who is responsible for it?

At what point in the workflow is a quality decision being made?

Where is the defect detection surface today, and what would it cost to move it left?

Until a team can answer those questions, adding more tools makes the situation more complicated without making it better.

The Pattern That Actually Works

Across fifteen years and multiple industries, the pattern that produces results looks the same everywhere.

It starts with a definition.

What does quality mean for this specific system, for these specific users, in this specific context?

That definition doesn't come from a template. It comes from engineering leadership understanding the product well enough to articulate what failure actually costs.

It continues with shared ownership. Not "QA is responsible for quality", that sentence is a trap.

Quality is a property of how the team works, not a function that gets delegated.

QA brings expertise. Everyone brings ownership.

It requires instrumentation before automation.

See the system first and then test it.

And it demands patience.

Shift left and continuous testing don't produce results in a sprint. The defect curve takes time to change. The cost curve takes time to visibly improve. Teams that abandon the approach after three months because they can't see the numbers move are making the same mistake as organisations that treat quality as a phase, optimising for the short term, paying for it in the long run.

The traditional model doesn't fail loudly. It fails slowly, invisibly, until the bill arrives all at once.

References & Further Reading

• Continuous Delivery — Jez Humble & Dave Farley — https://continuousdelivery.com

• Agile Testing: A Practical Guide for Testers and Agile Teams — Lisa Crispin & Janet Gregory — https://agiletester.ca

• Continuous Testing in DevOps — Dan Ashby — https://danashby.co.uk/2016/10/19/continuous-testing-in-devops

• The Test Pyramid — Martin Fowler — https://martinfowler.com/bliki/TestPyramid.html

• Shift Left Testing — IBM Developer — https://developer.ibm.com/articles/shift-left-and-shift-right-testing-strategies

• State of DevOps Report — DORA Research Program — https://dora.dev/research

• Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble, Gene Kim — https://itrevolution.com/product/accelerate

• Testing in Production: the safe way — Cindy Sridharan — https://medium.com/@copyconstruct/testing-in-production-the-safe-way-18ca102d0ef1

Here's why that decision costs far more than anyone budgets for.

The Numbers Don't Lie

Most defects end up costing more than they would have cost to prevent them. Defects are expensive when they occur, both the direct costs of fixing the defects and the indirect costs because of damaged relationships, lost business and lost development time.

— Kent Beck, Extreme Programming Explained

This isn't abstract philosophy. The numbers are real.

To understand why the costs increase in this manner, consider what happens to a single requirements error depending on when it gets found:

• If you make a requirements error and find it during the requirements phase, it is inexpensive to fix. You merely change a portion of your requirements model. A change of this scope is on the order of $1

• If you do not find it until the design stage, it is more expensive to fix. Not only do you have to change your analysis, but you also have to reevaluate and potentially modify the sections of your design based on the faulty analysis. This change is on the order of $10.

• If you do not find the problem until programming, you need to update your analysis, design, and potentially scrap portions of your code, all because of a missed or misunderstood user requirement. This error is on the order of $100, because of all the wasted development time based on the faulty requirement.

• Furthermore, if you find the error during the traditional testing stage, it is on the order of $1,000 to fix (you need to update your documentation and scrap/rewrite large portions of code).

• Finally, if the error gets past you into production, you are looking at a repair cost on the order of $10,000+ to fix (you need to ship updated code, fix the database, restore old data, etc.).

That's a 10,000x cost multiplier from requirements to production. The same defect. Just found it later.

This isn't a testing problem. It's a timing problem.

The Traditional Quality Model — And Why It Fails

Most organisations I have seen operate with a version of the same model, and it looks something like this:

• QA members tend to be less involved in early stages like planning and design.

• Many architectural requirements and design flaws are not discovered and corrected until after a significant effort has been wasted on their implementation.

• Less time to fix defects.

• There is a great chance of “breaking” functionality due to last-minute fixes, jeopardising the release date.

• Testing time gets shrunk and usually becomes a bottleneck.

• Testing is a phase at the end of the development cycle.

Sound familiar? It should. This is the default in most organisations, and the consequences are entirely predictable every time. Bugs pile up, releases slip, teams burn out, and everyone points fingers at QA for "not catching it."

The uncomfortable truth is that QA can't catch what it was never involved in building. When testing is a phase at the end of a cycle, it inherits every bad decision made before it arrived.

Once you see these numbers clearly, the traditional model doesn't just look inefficient — it looks indefensible. That's what drives serious engineering organisations to rethink quality from the ground up.

The Questions This Forces Us to Ask

Once you accept the compounding cost of late defect detection, the right questions become obvious:

• How do we detect defects earlier — or better yet, prevent them entirely?

• How do we bring QA and testing activities into the earlier stages of the SDLC?

• How do we reduce the total cost of development and testing?

• How do we make the whole team — not just QA — responsible for quality?

These aren't QA questions. They are engineering leadership questions.

And the answers require more than better test coverage; they require a fundamentally different approach to how quality is embedded into the workflow.

So how do we actually achieve that?

Essentially, the development workflow should ensure that defects can be detected as early as possible. It is valuable to implement processes that enable the team to detect early and detect often.

Detect Early, Detect Often

In essence, processes and conventions should be designed around moving defect detection as early in the workflow and as close to the developer’s coding environment as possible.

This way, the same compounding effects which inflate the negative impacts of late defect detection work in favour of increasing software quality and resilience.

Knowing the problem is only half the equation. The practical answer lies in two disciplines that directly address everything broken about the traditional model: Shift Left Testing and Continuous Testing.

Shift Left And Continuous Testing

In the next post, I'll break down exactly what both mean in practice, not the buzzword definitions, but how to actually implement them in a real team environment, with real constraints and real delivery pressure.

Because understanding why the traditional model fails is step one. Knowing what to replace it with is where the real work begins.

References & Further Reading

• Cost Effective Software Test Metrics — ResearchGate

• Exponential Cost of Fixing Bugs — DeepSource

• Launchable — Reducing Slow Delivery Cycles Case Study