Observability Never Really Shifted Left

We made software development faster. Now we need to make validation faster, too.

For the last decade we have shifted development left. Testing, security, performance, and CI/CD all moved closer to the developer. Observability mostly did not. It still starts after deployment (we covered the incident side of this in Your Observability Stack Found the Fire), which means the people writing the code rarely have meaningful production behavior to observe while they build.

Alan Mon walks through the argument in 36 seconds:

We shifted everything left except observability

A developer can run unit tests, security scans, and performance checks from a laptop or a development cluster. Observability is different. It is designed around what happens in production, and developers are expected to learn from production telemetry even though they are not running production workloads where they write code.

flowchart LR
    subgraph Left["Moved left"]
        A[Unit tests] --> B[Security scans]
        B --> C[Performance checks]
        C --> D[CI/CD]
    end
    subgraph Right["Still on the right"]
        E[Production telemetry]
    end
    D --> F[Deploy]
    F --> E

Why developers don’t use observability

It is easy to say developers don’t use observability. The reality is simpler: there is often nothing meaningful to observe.

A laptop or dev cluster has no real customer traffic, no production dependencies, and no production-scale behavior. You can’t run production traffic through a developer’s laptop and expect the same signals. Developers don’t need another dashboard. They need realistic application behavior they can work with.

AI shortened coding time and expanded validation time

AI is changing the economics of software development. Code that once took hours can now be generated in minutes, or seconds. That creates a new bottleneck: validation.

We are producing code faster than ever while the time and effort needed to decide whether that code works can grow. The answer is to keep coding fast and move testing and observability earlier in the development cycle.

Bring production behavior left

Observability can’t truly shift left unless the data shifts left with it. Capture real production behavior as production context, replay it safely in development, observe the results, and use that feedback to validate changes before they reach production.

flowchart LR
    A[Production traffic] -->|capture| B[Recorded requests and responses]
    B -->|replay| C[Dev environment or laptop]
    C -->|observe| D[Validation results]
    D -->|fix and repeat| C
    D -->|confident change| E[Ship]

The goal is to give developers realistic behavior they can use to build and validate with confidence, without recreating all of production on a laptop. With proxymock, that means recording traffic once and replaying it against your service, with its dependencies mocked, every time you change the code.

Try it with proxymock

Here is the smallest version of this loop. Install proxymock (see the installation guide), then record your service while you or your tests exercise it. Replace the last argument with however you start your app:

proxymock record --app-port 8080 -- ./mvnw spring-boot:run

Stop the recording and the requests and responses are saved as files in your repo. After you change code, replay that traffic against the new build and see what differs:

proxymock replay --in-dir ./proxymock/recorded --test-against http://localhost:8080

To work without live dependencies, serve the recorded downstream responses from a mock instead:

proxymock mock --in-dir ./proxymock/recorded

The quickstart walks through the full flow.

The bottom line

AI has made writing code faster. Now we need to make validation faster. That means bringing observability and testing into the development cycle, instead of waiting for production to tell us whether the code works.

Stop finding bugs in production. Catch them before they ship.