AI agents didn't make the SDLC faster. They killed it.

I keep hearing people talk about AI as a "10x developer tool." That framing is wrong. It assumes the workflow stays the same and the speed goes up. That's not what's happening. The entire lifecycle, the one we've built careers around, the one that spawned a multi-billion dollar tooling industry, is collapsing in on itself.

And most people haven't noticed yet.

The SDLC you learned is a relic

Here's the classic software development lifecycle most of us were taught:

graph TD
    A[Requirements] --> B[System Design]
    B --> C[Implementation]
    C --> D[Testing]
    D --> E[Code Review]
    E --> F[Deployment]
    F --> G[Monitoring]
    G --> A

Every stage has its own tools, its own rituals, its own cottage industry. Jira for requirements. Figma for design. VS Code for implementation. Jest for testing. GitHub for code review. AWS for deployment. Datadog for monitoring.

Each step is discrete. Sequential. Handoffs everywhere.

Now here's what actually happens when an engineer works with a coding agent:

graph TD
    A[Intent] --> B[Agent]
    B --> C[Code + Tests + Deployment]
    C --> D{Does it work?}
    D -->|No| B
    D -->|Yes| E[Ship]
    style E fill:#d1fae5,stroke:#6ee7b7,color:#065f46

The stages collapsed. They didn't get faster. They merged. The agent doesn't know what step it's on because there are no steps. There's just intent, context, and iteration.

AI-native engineers don't know what the SDLC is

I spent a lot of time speaking with engineers who started their career after Cursor launched. They don't know what the software development lifecycle is. They don't know what's DevOps or what's an SRE. Not because they're bad engineers. Because they never needed it. They've never sat through sprint planning. They've never estimated story points. They've never waited three days for a PR review.

They just build things.

You describe what you want. The agent writes the code. You look at it. You iterate. You ship. Everything simultaneously.

These engineers aren't worse for skipping the ceremony. They're unencumbered by it. Sprint planning, code review workflows, release trains, estimation rituals. None of it. They skipped the entire orthodoxy and went straight to building.

And honestly? I'm jealous.

Every stage is collapsing

Let me walk through the SDLC and show you what's left of it.

Requirements gathering: fluid, not dictated

Requirements used to be handed down. A PM writes a PRD, engineers estimate it, and the spec gets frozen before a line of code is written. That made sense when building was expensive. When every feature took weeks, you had to decide upfront what to build.

That constraint is gone. When an agent can generate a complete version of a feature in minutes, you don't need to specify every detail in advance. You provide the direction, the agent builds a version, you look at it, you adjust, you try a different approach. You can generate ten versions and pick the best one. Requirements aren't a phase anymore. They're a byproduct of iteration.

Now, what is Jira when the audience isn't humans coordinating across a pipeline? What is Jira when it's agents consuming context? Jira was built to track work through stages that no longer exist. If your "requirements" are just context for an agent, then the ticketing system isn't a project management tool anymore. It's a context store. And it's a terrible one.

System Design: discovered, not dictated

System design still matters. But the way it happens is fundamentally shifting.

Design used to be something you did before writing code. You'd whiteboard the architecture, debate trade-offs, draw boxes and arrows, then go implement it. The gap between the design and the code was days or weeks.

That gap is closing. Design is becoming something you discover by giving the agent the right context, not something you dictate ahead of time. The model has seen more systems, more architectures, more patterns than any individual engineer. When you describe a problem, the agent doesn't just implement your design, it suggests architectures that are often superior to what you'd have come up with on your own. You're having a design conversation in real-time, and the output is working code.

You still need to know when an agent is over-engineering or missing a constraint. But you're collaborating on design, not prescribing it.

Implementation: this is the agent's job now

This one is obvious. The agent writes the code. Whole features. Complete solutions with error handling, types, edge cases.

I don't personally know anyone who still types lines of code. We review what agents write, feed them context, steer direction, and focus on the problems that actually require human judgment.

Testing: simultaneous, not sequential

Agents write tests alongside the code. Not as an afterthought. Not in a separate "testing phase." The test is part of the generation. TDD isn't a methodology anymore, it's just how agents work by default.

The entire QA function as a separate stage is gone. When code and tests are generated together, verified together, and iterated together, there's no handoff. No "throw it over the wall to QA.". The agent can do the QA itself.

Code review: give it up

The pull request flow needs to go. I was never a fan, but now it's just a relic of the past.

I know that's uncomfortable. Code review is sacred. It's how you catch bugs, share knowledge, maintain standards. It's also an identity thing. We're engineers, and reviewing code is what engineers do. But clinging to the PR workflow in an agent-driven world isn't rigor. It's an identity crisis.

Think about it. An agent generates 500 PRs a day. Your team can review maybe 10. The review queue backs up. This isn't a bottleneck worth optimising. It's a fake bottleneck, one that only exists because we're forcing a human ritual onto a machine workflow.

graph TD
    A[Agent generates PR] --> B[Waits for human review]
    B --> C{Reviewer available?}
    C -->|No| D[Sits in queue for hours/days]
    C -->|Yes| E[Review + Comments]
    E --> F[Agent addresses feedback]
    F --> B
    D --> B
    style B fill:#fee2e2,stroke:#fca5a5,color:#991b1b
    style D fill:#fee2e2,stroke:#fca5a5,color:#991b1b

This diagram shouldn't exist. The entire flow is wrong.

The review has to be rethought from scratch. Either it becomes part of the code generation itself, the agent verifies its own work against the plan document, runs the tests, checks for regressions, validates against architectural constraints, or a second agent reviews the first agent's output. Adversarial agents plough through the proposed changes, try to break it in every dimension. We already have the tools for this. Human-in-the-loop review becomes exception-based, triggered only when automated verification can't resolve a conflict or when the change touches something genuinely novel.

What does a world without pull requests look like? Agents commit to main. Automated checks, tests, type checks, security scans, behavioral diffs, validate the change. If everything passes, it ships, automatically. If something fails, the agent fixes it. A human only gets involved when the system genuinely doesn't know what to do.

graph TD
    A[Agent generates code] --> B[Agent self-verifies]
    B --> C[Second agent reviews]
    C --> D[Automated checks]
    D --> E{All clear?}
    E -->|Yes| F[Ship]
    E -->|No - resolvable| A
    E -->|No - novel issue| G[Human review]
    G --> A
    style F fill:#d1fae5,stroke:#6ee7b7,color:#065f46

We're spending our review cycles reading diffs that an agent could verify in seconds. That's not quality assurance. That's luddism.

Deployment: decoupled and continuous

Agents are already writing deployment pipelines that are more intricate and more specialised than what most teams would ever bother building by hand. Feature flags, canary releases, progressive rollouts, automatic rollback triggers, the kind of release engineering that used to require a dedicated platform team.

The key shift is that agents naturally decouple deployment from release. Code gets deployed continuously, every change, as soon as it's generated and verified, produces an artifact that lands in production behind a gate. Release is a separate decision, driven by feature flags or traffic rules.

Some teams are already approaching true continuous deployment and release. Code is generated, tests pass, artifacts are built, and the change is live, all in a single automated flow with no human in the loop between intent and production.

Where this goes next is even more interesting. Imagine agents that don't just deploy code but manage the entire release lifecycle, monitoring the rollout, adjusting traffic percentages based on error rates, automatically rolling back if latency spikes, and only notifying a human when something genuinely novel goes wrong. The deployment "stage" doesn't just get automated. It becomes an ongoing, self-adjusting process that never really ends.

graph TD
    A[Agent generates code] --> B[Automated verification]
    B --> C[Artifact produced]
    C --> D[Deploy behind feature flag]
    D --> E[Progressive rollout]
    E --> F{Healthy?}
    F -->|Yes| G[Full release]
    F -->|No| H[Auto-rollback]
    H --> I[Agent investigates]
    I --> A
    style G fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style H fill:#fee2e2,stroke:#fca5a5,color:#991b1b

Monitoring: the last stage standing, and it needs to evolve

Monitoring is the only stage of the SDLC that survives. And it doesn't just survive, it becomes the foundation everything else rests on.

When agents ship code faster than humans can review it, observability is no longer a nice-to-have dashboarding layer. It's the primary safety mechanism for the entire collapsed lifecycle. Every other safeguard, the design review, the code review, the QA phase, the release sign-off, has been absorbed or eliminated. Monitoring is what's left. It's the last line of defense.

But most observability platforms were built for humans. Alerts, log search, dashboard, etc. all designed for a person to look at, interpret, and act on. That model breaks when the volume of changes outpaces human attention. If an agent ships 500 changes a day and your observability setup requires a human to investigate each anomaly, you've created a new bottleneck. You've just moved it from code review to incident response.

Observability without action is just expensive storage. The future of observability isn't dashboards, it's closed-loop systems where telemetry data becomes context for the agent that shipped the code, so it can detect the regression and fix it.

The observability layer becomes the feedback mechanism that drives the entire loop. Not a stage at the end. The connective tissue of the whole system.

graph TD
    A[Intent] --> B[Agent builds, tests, deploys]
    B --> C[Production]
    C --> D[Observability layer]
    D -->|Anomaly detected| E[Agent investigates + fixes]
    E --> B
    D -->|Healthy| F[Next intent]
    F --> A
    style D fill:#dbeafe,stroke:#93c5fd,color:#1e40af

The teams that figure this out first, observability that feeds directly back into the agent loop, not into a human's pager, will ship faster and safer than everyone else. The teams that don't will drown in alerts.

The new lifecycle is tighter loop

The SDLC was a wide loop. Requirements → Design → Code → Test → Review → Deploy → Monitor. Linear. Sequential. Full of handoffs and waiting.

The new lifecycle is a tight loop.

graph TD
    A[Human Intent + Context] --> B[AI Agent]
    B --> C[Build + Test + Deploy]
    C --> D[Observe]
    D -->|Problem| B
    D -->|Fine| E[Next Intent]
    E --> B
    style B fill:#ede9fe,stroke:#c4b5fd,color:#5b21b6

Intent. Build. Observe. Repeat.

No tickets. No sprints. No story points. No PRs sitting in a queue. No separate QA phase. No release trains.

Just a human with intent and an agent that executes.

So what is left?

Context. That's it.

The quality of what you build with agents is directly proportional to the quality of context you give them. Not the process. Not the ceremony. The context.

The SDLC is dead. The new skill is context engineering. The new safety net is observability.

And most of the industry is still configuring Datadog dashboards no one looks at.

I've been using Claude Code as my primary development tool for approx 9 months, and the workflow I've settled into is radically different from what most people do with AI coding tools. Most developers type a prompt, sometimes use plan mode, fix the errors, repeat. The more terminally online are stitching together ralph loops, mcps, gas towns (remember those?), etc. The results in both cases are a mess that completely falls apart for anything non-trivial.

The workflow I'm going to describe has one core principle: never let Claude write code until you've reviewed and approved a written plan. This separation of planning and execution is the single most important thing I do. It prevents wasted effort, keeps me in control of architecture decisions, and produces significantly better results with minimal token usage than jumping straight to code.

flowchart LR
    R[Research] --> P[Plan]
    P --> A[Annotate]
    A -->|repeat 1-6x| A
    A --> T[Todo List]
    T --> I[Implement]
    I --> F[Feedback & Iterate]

Phase 1: Research

Every meaningful task starts with a deep-read directive. I ask Claude to thoroughly understand the relevant part of the codebase before doing anything else. And I always require the findings to be written into a persistent markdown file, never just a verbal summary in the chat.

read this folder in depth, understand how it works deeply, what it does and all its specificities. when that's done, write a detailed report of your learnings and findings in research.md

study the notification system in great details, understand the intricacies of it and write a detailed research.md document with everything there is to know about how notifications work

go through the task scheduling flow, understand it deeply and look for potential bugs. there definitely are bugs in the system as it sometimes runs tasks that should have been cancelled. keep researching the flow until you find all the bugs, don't stop until all the bugs are found. when you're done, write a detailed report of your findings in research.md

Notice the language: "deeply", "in great details", "intricacies", "go through everything". This isn't fluff. Without these words, Claude will skim. It'll read a file, see what a function does at the signature level, and move on. You need to signal that surface-level reading is not acceptable.

The written artifact (research.md) is critical. It's not about making Claude do homework. It's my review surface. I can read it, verify Claude actually understood the system, and correct misunderstandings before any planning happens. If the research is wrong, the plan will be wrong, and the implementation will be wrong. Garbage in, garbage out.

This is the most expensive failure mode with AI-assisted coding, and it's not wrong syntax or bad logic. It's implementations that work in isolation but break the surrounding system. A function that ignores an existing caching layer. A migration that doesn't account for the ORM's conventions. An API endpoint that duplicates logic that already exists elsewhere. The research phase prevents all of this.

Phase 2: Planning

Once I've reviewed the research, I ask for a detailed implementation plan in a separate markdown file.

I want to build a new feature <name and description> that extends the system to perform <business outcome>. write a detailed plan.md document outlining how to implement this. include code snippets

the list endpoint should support cursor-based pagination instead of offset. write a detailed plan.md for how to achieve this. read source files before suggesting changes, base the plan on the actual codebase

The generated plan always includes a detailed explanation of the approach, code snippets showing the actual changes, file paths that will be modified, and considerations and trade-offs.

I use my own .md plan files rather than Claude Code's built-in plan mode. The built-in plan mode sucks. My markdown file gives me full control. I can edit it in my editor, add inline notes, and it persists as a real artifact in the project.

One trick I use constantly: for well-contained features where I've seen a good implementation in an open source repo, I'll share that code as a reference alongside the plan request. If I want to add sortable IDs, I paste the ID generation code from a project that does it well and say "this is how they do sortable IDs, write a plan.md explaining how we can adopt a similar approach." Claude works dramatically better when it has a concrete reference implementation to work from rather than designing from scratch.

But the plan document itself isn't the interesting part. The interesting part is what happens next.

The Annotation Cycle

This is the most distinctive part of my workflow, and the part where I add the most value.

flowchart TD
    W[Claude writes plan.md] --> R[I review in my editor]
    R --> N[I add inline notes]
    N --> S[Send Claude back to the document]
    S --> U[Claude updates plan]
    U --> D{Satisfied?}
    D -->|No| R
    D -->|Yes| T[Request todo list]

After Claude writes the plan, I open it in my editor and add inline notes directly into the document. These notes correct assumptions, reject approaches, add constraints, or provide domain knowledge that Claude doesn't have.

The notes vary wildly in length. Sometimes a note is two words: "not optional" next to a parameter Claude marked as optional. Other times it's a paragraph explaining a business constraint or pasting a code snippet showing the data shape I expect.

Some real examples of notes I'd add:

• "use drizzle:generate for migrations, not raw SQL" -- domain knowledge Claude doesn't have
• "no -- this should be a PATCH, not a PUT" -- correcting a wrong assumption
• "remove this section entirely, we don't need caching here" -- rejecting a proposed approach
• "the queue consumer already handles retries, so this retry logic is redundant. remove it and just let it fail" -- explaining why something should change
• "this is wrong, the visibility field needs to be on the list itself, not on individual items. when a list is public, all items are public. restructure the schema section accordingly" -- redirecting an entire section of the plan

Then I send Claude back to the document:

I added a few notes to the document, address all the notes and update the document accordingly. don't implement yet

This cycle repeats 1 to 6 times. The explicit "don't implement yet" guard is essential. Without it, Claude will jump to code the moment it thinks the plan is good enough. It's not good enough until I say it is.

Why This Works So Well

The markdown file acts as shared mutable state between me and Claude. I can think at my own pace, annotate precisely where something is wrong, and re-engage without losing context. I'm not trying to explain everything in a chat message. I'm pointing at the exact spot in the document where the issue is and writing my correction right there.

This is fundamentally different from trying to steer implementation through chat messages. The plan is a structured, complete specification I can review holistically. A chat conversation is something I'd have to scroll through to reconstruct decisions. The plan wins every time.

Three rounds of "I added notes, update the plan" can transform a generic implementation plan into one that fits perfectly into the existing system. Claude is excellent at understanding code, proposing solutions, and writing implementations. But it doesn't know my product priorities, my users' pain points, or the engineering trade-offs I'm willing to make. The annotation cycle is how I inject that judgement.

The Todo List

Before implementation starts, I always request a granular task breakdown:

add a detailed todo list to the plan, with all the phases and individual tasks necessary to complete the plan - don't implement yet

This creates a checklist that serves as a progress tracker during implementation. Claude marks items as completed as it goes, so I can glance at the plan at any point and see exactly where things stand. Especially valuable in sessions that run for hours.

Phase 3: Implementation

When the plan is ready, I issue the implementation command. I've refined this into a standard prompt I reuse across sessions:

implement it all. when you're done with a task or phase, mark it as completed in the plan document. do not stop until all tasks and phases are completed. do not add unnecessary comments or jsdocs, do not use any or unknown types. continuously run typecheck to make sure you're not introducing new issues.

This single prompt encodes everything that matters:

• "implement it all": do everything in the plan, don't cherry-pick
• "mark it as completed in the plan document": the plan is the source of truth for progress
• "do not stop until all tasks and phases are completed": don't pause for confirmation mid-flow
• "do not add unnecessary comments or jsdocs": keep the code clean
• "do not use any or unknown types": maintain strict typing
• "continuously run typecheck": catch problems early, not at the end

I use this exact phrasing (with minor variations) in virtually every implementation session. By the time I say "implement it all," every decision has been made and validated. The implementation becomes mechanical, not creative. This is deliberate. I want implementation to be boring. The creative work happened in the annotation cycles. Once the plan is right, execution should be straightforward.

Without the planning phase, what typically happens is Claude makes a reasonable-but-wrong assumption early on, builds on top of it for 15 minutes, and then I have to unwind a chain of changes. The "don't implement yet" guard eliminates this entirely.

Feedback During Implementation

Once Claude is executing the plan, my role shifts from architect to supervisor. My prompts become dramatically shorter.

flowchart LR
    I[Claude implements] --> R[I review / test]
    R --> C{Correct?}
    C -->|No| F[Terse correction]
    F --> I
    C -->|Yes| N{More tasks?}
    N -->|Yes| I
    N -->|No| D[Done]

Where a planning note might be a paragraph, an implementation correction is often a single sentence:

• "You didn't implement the deduplicateByTitle function."
• "You built the settings page in the main app when it should be in the admin app, move it."

Claude has the full context of the plan and the ongoing session, so terse corrections are enough.

Frontend work is the most iterative part. I test in the browser and fire off rapid corrections:

• "wider"
• "still cropped"
• "there's a 2px gap"

For visual issues, I sometimes attach screenshots. A screenshot of a misaligned table communicates the problem faster than describing it.

I also reference existing code constantly:

• "this table should look exactly like the users table, same header, same pagination, same row density."

This is far more precise than describing a design from scratch. Most features in a mature codebase are variations on existing patterns. A new settings page should look like the existing settings pages. Pointing to the reference communicates all the implicit requirements without spelling them out. Claude would typically read the reference file(s) before making the correction.

When something goes in a wrong direction, I don't try to patch it. I revert and re-scope by discarding the git changes:

• "I reverted everything. Now all I want is to make the list view more minimal -- nothing else."

Narrowing scope after a revert almost always produces better results than trying to incrementally fix a bad approach.

Staying in the Driver's Seat

Even though I delegate execution to Claude, I never give it total autonomy over what gets built. I do the vast majority of the active steering in the plan.md documents.

This matters because Claude will sometimes propose solutions that are technically correct but wrong for the project. Maybe the approach is over-engineered, or it changes a public API signature that other parts of the system depend on, or it picks a more complex option when a simpler one would do. I have context about the broader system, the product direction, and the engineering culture that Claude doesn't.

flowchart TD
    P[Claude proposes changes] --> E[I evaluate each item]
    E --> A[Accept as-is]
    E --> M[Modify approach]
    E --> S[Skip / remove]
    E --> O[Override technical choice]
    A & M & S & O --> R[Refined implementation scope]

Cherry-picking from proposals: When Claude identifies multiple issues, I go through them one by one: "for the first one, just use Promise.all, don't make it overly complicated; for the third one, extract it into a separate function for readability; ignore the fourth and fifth ones, they're not worth the complexity." I'm making item-level decisions based on my knowledge of what matters right now.

Trimming scope: When the plan includes nice-to-haves, I actively cut them. "remove the download feature from the plan, I don't want to implement this now." This prevents scope creep.

Protecting existing interfaces: I set hard constraints when I know something shouldn't change: "the signatures of these three functions should not change, the caller should adapt, not the library."

Overriding technical choices: Sometimes I have a specific preference Claude wouldn't know about: "use this model instead of that one" or "use this library's built-in method instead of writing a custom one." Fast, direct overrides.

Claude handles the mechanical execution, while I make the judgement calls. The plan captures the big decisions upfront, and selective guidance handles the smaller ones that emerge during implementation.

Single Long Sessions

I run research, planning, and implementation in a single long session rather than splitting them across separate sessions. A single session might start with deep-reading a folder, go through three rounds of plan annotation, then run the full implementation, all in one continuous conversation.

I am not seeing the performance degradation everyone talks about after 50% context window. Actually, by the time I say "implement it all," Claude has spent the entire session building understanding: reading files during research, refining its mental model during annotation cycles, absorbing my domain knowledge corrections.

When the context window fills up, Claude's auto-compaction maintains enough context to keep going. And the plan document, the persistent artifact, survives compaction in full fidelity. I can point Claude to it at any point in time.

The Workflow in One Sentence

Read deeply, write a plan, annotate the plan until it's right, then let Claude execute the whole thing without stopping, checking types along the way.

That's it. No magic prompts, no elaborate system instructions, no clever hacks. Just a disciplined pipeline that separates thinking from typing. The research prevents Claude from making ignorant changes. The plan prevents it from making wrong changes. The annotation cycle injects my judgement. And the implementation command lets it run without interruption once every decision has been made.

Try my workflow, you'll wonder how you ever shipped anything with coding agents without an annotated plan document sitting between you and the code.

External link to shiptypes.com

(corollary- pr descriptions are becoming the apprenticeship surface for remote teams and coding agents)

in my last post, where good ideas come from (for coding agents), I argued that agents don’t magically make engineering easy; they make implementation cheap, and then they amplify whatever you were already doing to keep work aligned with reality: constraints, context, an oracle, and a loop. this is the zoomed-in sequel.

after you’ve used coding agents for a bit, you start to notice something that feels a little backwards:

• code got cheaper.
• but review often feels harder.

not because the diffs are bigger (they’re often smaller). and definitely not because agents write unreadable code (they often write very clean code).

I think it’s because the hard part of the job moved (“shifted left”, one might say)

tl;dr: the scarce part of the workflow seems to be becoming context: intent, assumptions, constraints, trade-offs, and verification. and the place that ends up holding a lot of that is the pull request description. not just the diff.

a normal day now: one pr, one change, a lot of thinking

let’s reuse the same running example from the last post: webhook ingestion.

you have a handler that validates a signature, stores an event, and enqueues a job. and prod keeps reminding you that the world is adversarial:

• partners retry aggressively → duplicates
• downstream fails halfway → partial side effects
• p99 latency is creeping up → every “fix” risks making tails worse

you open a pr titled something like:

make webhook ingestion reliable (idempotency + retries)

you ask an agent to help.

it comes back fast with a plausible diff:

• adds an idempotency key
• prevents duplicate enqueue
• adds a retry wrapper in the worker
• improves logging

tests pass. the code is clean.

a few years ago, you might have merged this (or at least felt good about it).

today, the thing you feel is: unease.

because the question isn’t “does this compile?” and it isn’t even “does this pass tests?”; it’s:

• what does “idempotent” mean here, exactly? (partner id + event id? payload hash? something else?)
• where do retries live? (edge handler vs background worker)
• what is the p99 budget? (and did we just tax it)
• what’s the failure model? (fail closed? fail open? dlq?)
• what did we not change? (data model? queues? partner contract?)

and here’s the part that I keep bumping into: the agent can generate the diff in minutes, but you can still spend hours making sure it’s the right diff.

at least in my experience, that time doesn’t feel like overhead anymore, it feels like where the work actually went.

the inversion: the pr description starts carrying the engineering

the diff answers: what changed.

the pr description is supposed to answer:

• what did we mean?
• what constraints shaped this?
• how do we know it’s correct?
• what should reviewers focus on?

in the agent era, that list feels like it’s becoming the center of gravity.

a clean diff is only evidence of taste, or the lack of it. (taste matters, but it’s not the same thing.)

when codegen is cheap, “engineering” shifts toward:

• turning tribal knowledge into written constraints
• making trade-offs explicit
• choosing and running verification loops
• drawing scope boundaries

and the pr description becomes the place where all of that gets serialized.

I think this is why reviews can feel harder: the implementation “matters” less; you’re reviewing an interpretation, and the history that brought you there.

why “paste the transcript” is usually not the move

a predictable reaction to this shift is: “ok, so we should attach the entire agent chat log to the pr.”

I get the instinct, but in practice I don’t think it works that well.

full transcripts have the same problem as raw debug logs:

• they are high volume
• they mix signal and noise
• they contain false starts and vibe-driven tangents
• they’re optimized for getting to an answer, not making the answer auditable

reviewers need the plot points! they need to follow the story as you’ve told it (indeed, as you discovered it). so you want structured provenance to help them follow that story:

• what the goal was
• what constraints were non-negotiable
• what decision points existed
• what you chose, and why
• what you ran to validate it

(I’m sure a bunch of tools will try to automate this; ai-generated pr summaries, walkthroughs, session logs, etc. those are useful, but most of them are currently better at what changed than what constraints mattered. and that second part is still where correctness tends to live.)

this was always the interview signal

this is the part that made me feel less crazy: we’ve been here before.

think about coding interviews; the ones where the prompt is intentionally under-specified.

yes, you’re “solving a problem.” but the real signal isn’t whether you can type out a solution under time pressure. the real signal is usually:

• what clarifying questions you ask
• what constraints you surface
• what assumptions you state explicitly
• how you test the edges mentally before writing code

good interviewers, they watch how you construct the problem, and actually consider the code that you write to be a side effect of that process.

and agents, aha, they didn’t invent this skill! they just make the gap obvious when you skip it (I do wonder if having interview banks and tips in the training dataset influenced this, but that’s a digression for another day.)

in day-to-day work with coding agents, the first five minutes often look like the best kind of interview:

before we write anything: what does “correct” mean here, and what would make this wrong?

the lost apprenticeship (and where it went)

there’s another shift here that I think we’re still metabolizing: remote work.

pre-remote (or even just pre-async), juniors learned the job by proximity:

• you sat next to seniors (like, literally, peering over their shoulder. it’s how even I learnt javascript 20 years ago)
• you overheard how they reasoned
• you watched how they decomposed work
• you saw what they worried about before they wrote code
• you learned the “how we do things here” stuff without anyone having to name it

that apprenticeship surface was always real, even if informal, and it was so fkin critical.

now, in remote teams, and especially with agents, most of that ambient learning doesn’t travel the same way.

you can’t really overhear judgment.

if you want it to transmit, you have to serialize it.

and where does that serialization most naturally happen?

• in pr descriptions
• in review comments
• in small design notes
• in decision logs

this is the part I care about for juniors: your future job is probably not to out-type the agent. it’s to learn the questions that make the work converge.

“knowing what questions to ask” becomes the job

I think juniors often feel like their job is “ship tickets.”

in an agent-heavy world, the more durable job description might be:

turn ambiguity into constraints, and make correctness legible.

some questions that almost always matter (and that you can learn to ask on purpose):

• goal: what outcome are we trying to produce? (not the mechanism)
• non-goals: what are we explicitly not doing?
• invariants: what would make this change wrong even if tests pass?
• failure modes: how does this fail in prod? what do we do then?
• verification: what did we run? what would convince us this works?
• rollout/rollback: how do we deploy safely, and how do we undo it?

I don’t think these are “soft skills.” they’re the mechanics of building correct systems.

seniors often have these questions in their head as scar tissue. agents make that scar tissue more visible because if you don’t write it down, the model will happily fill the gaps with a plausible completion.

the pr description as interface

the pr body feels like it’s becoming the interface between:

• fast, probabilistic agent work
• slow, accountable human judgment

and also between:

• seniors and juniors
• your team and the rest of the org
• present you and future you

what I think would work is a three-layer pr description. think of it as optimizing for three reader modes.

layer 1: executive intent (30 seconds)

answer:

• what changed?
• why now?
• what’s the user/system-visible outcome?

layer 2: reviewer guidance (3–7 minutes)

answer:

• where should I look?
• what invariants matter?
• what trade-offs did you make?
• what did you deliberately not change?

layer 3: provenance + replay (only if needed)

answer:

• what context did you use?
• what decisions were made?
• what commands/tests were run?

(this is the part that belongs in a collapsed <details> block. it’s there when you need it, but it doesn’t turn the pr into a novel.)

a concrete format (with one filled example)

here’s a format that reads well (imo). it’s intentionally similar to the “context packet” template from the last post, but aimed at review rather than prompting.

suggested pr body

• goal:
• non-goals:
• constraints / invariants:
• approach:
• what changed (walkthrough):
• verification:
• risks & rollback:
• context manifest (for audit / archeology, put this inside a <details> block)
  • prompt summary (not transcript): what we asked the agent to do, in intent/constraints form
  • repo anchors used: the handful of files/docs that defined “truth”
  • decision points: the 2–4 moments where options existed and we chose one
  • tools invoked: tests, linters, benchmarks, and outcomes

filled example (webhook reliability)

goal: prevent duplicate downstream effects when partners retry the same webhook delivery.

non-goals: no new datastore; no partner-facing contract changes; no retries inside the http handler; no large refactors.

constraints / invariants:

• idempotent under partner retries
• p99 handler latency must not regress
• no payload logging (pii)
• retries must be bounded + jittered (worker-side)

approach: implement ingestion idempotency keyed by (partner_id, event_id); keep edge path fast; move retries to worker; add dlq path for poison events.

what changed (walkthrough):

• added idempotency guard at ingestion to prevent duplicate enqueue
• reused existing retry policy helper for worker retries
• added dlq handling for permanent failures
• added metrics: duplicate rate, retry count, dlq depth

verification:

• added tests for duplicate deliveries → only one enqueue
• added tests for transient downstream failure → bounded retries
• ran: unit tests + integration tests

risks & rollback:

• risk: incorrect idempotency key choice could drop legitimate events
• rollout: feature flag at 1% for one partner, monitor duplicate rate + p99
• rollback: disable flag

• prompt summary: implement ingestion idempotency only; keep diff small; reuse retry policy; do not add new abstractions; add tests for duplicates and retries.
• repo anchors used: existing retry module; queue abstraction; error taxonomy types; logging/metrics helpers; prior ingestion endpoint pr.
• decision points:
  • key choice: (partner_id, event_id) vs payload hash → chose ids because hashes aren’t stable identifiers across real retries
  • retry placement: worker vs handler → chose worker to protect p99
• tools invoked: unit tests, integration tests (green)

how this relates to the “context packet” from seven-ways

in the last post I described a context packet as an input artifact: a small, curated bundle that stops the agent from guessing what “truth” is.

this post is about the corresponding output artifact:

• the context packet tells the agent what truth is.
• the pr description tells humans how we enforced it.

same discipline, different direction.

zooming out: prs are the smallest unit of org sense-making

once you take this seriously, it’s hard not to notice the scale effect.

pr descriptions are the “small” version of a bigger job:

• explaining what your team is doing
• explaining what you aren’t doing (and why)
• sequencing work so the org doesn’t invent a story for you

this sounds like “communication,” but I think it’s more precise to call it engineering judgment at larger radii.

the failure mode is the same as with agents:

• people fill in missing context with plausible completions
• you get misalignment that nobody intended
• and then you pay for it later

a good pr description starts by helping a reviewer, but then it helps your future teammate, your future oncall, your future self, and anyone trying to understand what changed and why. this is the job!

what this changes about onboarding and growth

in remote teams, onboarding is mostly archaeology.

people learn your system by:

• reading prs
• reading code
• reading runbooks
• reading incident docs

if those artifacts aren’t interrogable (i.e. - if they don’t encode intent and constraints) then onboarding turns into a game of telepathy.

for juniors, this can be weirdly good news:

• you don’t need to be the fastest typist
• you need to become fluent in constraints, verification, and failure modes

for seniors, it explains why the job can feel heavier:

• you may write less code
• but you’re responsible for coherence

so it seems to me that agents didn’t remove senior work, they mostly exposed it.

closing

we’ve said this before:agents make code cheaper; they don’t seem to make judgment cheap.

so the job shifts toward making your intent, constraints, and verification legible; first to the agent, then to your reviewer, then to your team, and eventually to the rest of the org.

if the future junior can’t sit next to you and absorb how you work, they’ll learn from what you actually wrote down.

which means pr descriptions probably can’t be a formality anymore. they might be the actual apprenticeship surface.

epilogue: what it might mean to “review” context

there’s a follow-on idea I can’t stop thinking about.

in the past, review wasn’t just reading:

• you checked the branch out
• you ran tests
• you poked at it in a repl
• you wrote a quick harness

that was a way of interrogating the work.

if the pr description now carries a meaningful chunk of the engineering judgment, we might need an equivalent way to interrogate that too.

maybe that looks like:

• linking a pr to the coding session that produced it
• replaying the session in a sandbox
• branching the session to ask your own “what if…” questions
• and (somehow) merging the results back, just like we used to merge commits from multiple humans into one pr

this opens a bunch of weird questions:

• what’s the “diff” for reasoning?
• what’s a merge conflict between two interpretations?
• what does it mean to rebase intent?

we invented branches, diffs, and reviews to collaborate on code.

if context is now the work, we’ll need equally good ways to collaborate on reasoning. who’s building this?

(and the part where users have to level up)

I’ve been thinking about why some people absolutely cook with coding agents, and some people bounce off them hard. I had a thought last week: if llms are “next token predictors” in the small (i.e., sentence finishers) then in the large they’re closer to “thought completers.” you give them a few crumbs of context, they infer the genre, then they sprint down the most likely path in idea-space. which makes “good prompting” feel less like magic words and more like navigation: you’re steering the model toward a region of the space where the next steps are both plausible and useful. I wanted a better map for that, so i used steven johnson’s “where good ideas come from” as a rubric, the seven patterns that reliably produce interesting ideas, and tried applying it to coding agents: where they’re naturally strong, where they reliably drift, and what a user has to supply (constraints, context, oracles, loops) to make the whole thing converge.

tl;dr: a plausible “week in the life” you can map onto your own codebase. the point is to make the user-adaptation story concrete: agents are excellent at adjacent-possible work, but they only become reliably useful when you supply constraints, context, an oracle, and a loop.

the idea-space metaphor (and what the seven ways add to it)

it’s tempting to picture an llm as navigating a huge multidimensional “idea-space”: your prompt lights up certain internal features, which reshapes the probability landscape of what comes next, and generation is basically a trajectory through that landscape. in that framing, context engineering is just steering - adding constraints, examples, and relevant artifacts so the model’s “next steps” stay in the neighborhood you care about. johnson’s seven ways are useful here because they explain which kinds of trajectories llms find naturally, and which ones require help: models are natively strong at smooth, local moves like the adjacent possible (small diffs, incremental refinements) and at platforms (interfaces, scaffolds, reusable primitives), and they can do exaptation well when you explicitly state affordances and constraints. they’re weaker where progress depends on reality pushing back - error and serendipity - unless you give them feedback channels like tests, benchmarks, traces, and experiments that create a gradient toward truth. and they only approximate liquid networks and slow hunches when you supply diverse “voices” (prior art, docs, debates) and persist ideas long enough to recombine later. the point isn’t that llms can’t roam the space; it’s that they need mechanisms that select and validate the paths worth taking.

quick sidequest: the seven ways

steven johnson’s “where good ideas come from” is one of those lists that sounds like it belongs on a poster until you use it as a diagnostic tool. here’s the version that matters for engineering:

1. the adjacent possible - most “new” ideas are the next reachable step from what already exists. stairs, not teleportation.
2. liquid networks - ideas show up when partial thoughts collide: people, yes, but also artifacts (docs, code, past debates).
3. the slow hunch - many good ideas start half-baked. you keep them around until they meet the missing piece.
4. serendipity - luck plus recognition; you notice the useful anomaly when it appears.
5. error - failure is information; feedback turns wandering into convergence.
6. exaptation - repurpose a thing built for one job into a different job. reuse as invention.
7. platforms - stable primitives and standards let lots of people build lots of things faster and safer.

now: drop an llm coding agent into this picture. what changes?

my take: the seven patterns don’t go away. agents just amplify some of them and brutally expose where you’ve been relying on implicit human context for the others.

let’s walk through that with one running example.

the running example: “make webhook ingestion reliable” (totally plausible, not actually shipped)

imagine a webhook ingestion service:

• handler validates signature
• stores event
• enqueues downstream job

and prod keeps reminding you that the world is adversarial:

• partners retry aggressively → duplicates
• downstream sometimes fails halfway → partial side effects
• p99 latency is creeping up → every “fix” risks making tail worse

the goal, as a human would say it: reliable ingestion with idempotency and bounded retries, without making latency worse.

the goal, as an agent hears it: “write some code that sounds like reliability.”

that mismatch is the whole story.

so here’s the one-week simulation.

day 1: I ask for “reliability.” the agent gives me plausible nonsense.

the naive prompt is basically:

make webhook ingestion reliable. handle duplicates and retries. keep latency reasonable.

the agent does what continuation machines do when you hand them vibes: it fills in the blanks with the most likely reliability narrative it has seen before.

so it might invent a new “reliability module,” add a retry helper (even if your repo already has one), choose a payload-hash idempotency key because it sounds right, and sprinkle logging everywhere like it’s free.

and the code might be clean! which is the annoying part. because it can be clean and still wrong.

in this simulation, you catch three problems quickly:

• payload hashes aren’t stable identifiers for retries in the real world
• retries in the request handler are a p99 tax (and can trigger more retries, which is a fun kind of circular misery)
• duplicating retry logic is how you end up with a repo that has “one retry policy per mood”

so you don’t merge it. you don’t argue with it. you just learn the lesson: if you ask an agent for a vibe, it will give you a vibe-shaped completion.

day 2: adjacent possible - I stop asking for outcomes and start asking for stairs.

this is the first user adaptation: take the big thing and turn it into rungs small enough to verify.

the staircase looks like:

• step 1: idempotency at ingestion (no duplicate enqueue)
• step 2: bounded retries in the worker (not the handler)
• step 3: dead-letter path + replay
• step 4: metrics that tell us if it’s working

then you create an oracle for step 1. not a paragraph. an actual check.

maybe it’s a test that says:

• same (partner_id, event_id) arrives twice → only one enqueue happens
• second request returns quickly and doesn’t redo expensive work
• storage failure behavior is explicit (fail closed vs fail open is a choice, not an accident)

then the prompt becomes boring on purpose:

implement step 1 only. keep the diff small. don’t invent new abstractions. make these tests pass.

suddenly the agent looks competent again, because this is its strength: incremental diffs along a well-lit path.

the “adjacent possible” isn’t just a creativity concept; it’s also a safety concept. small rungs are harder to misunderstand.

day 3: liquid networks - I build a context packet so it stops inventing my codebase.

even with good decomposition, agents have a habit: they’ll “helpfully” create new mini-frameworks unless you force them to collide with your existing ones.

so you manufacture a liquid network.

not by dumping the whole repo, but by curating the collision points.

in this simulation, you assemble a tiny context packet:

• the canonical retry policy already used elsewhere
• your error taxonomy types
• logging/metrics rules (especially what not to log)
• the queue abstraction you must use
• one prior PR that did retries correctly in your house style

and you tell the agent, explicitly, to reuse what exists:

for step 2, reuse <retry_policy_file>, follow <error_types_file>, and cite the prior art you’re copying. do not add new abstractions unless you justify them.

this is one of the weirdly satisfying moments in agent work: the output starts to look like it came from someone who has actually been in your codebase for a while.

liquid networks aren’t just social. they’re documentary. agents need the documentary version.

day 4: slow hunch - a real design question appears, and we don’t pretend it’s settled.

around now you hit the question you can’t solve with a patch:

do you ack the webhook only after downstream succeeds, or ack on ingestion and process asynchronously?

there are real trade-offs here: partner timeouts, retry behavior, your p99 budget, operational complexity, and what “correctness” means for side effects.

in this simulation you have a hunch, but not certainty:

ack quickly, but make downstream idempotent and observable; add replay; make partial failure survivable.

so you do the “slow hunch” move: you write that hypothesis down and you refuse to force closure yet.

then you ask the agent to help refine it without floating off into generic advice:

given our constraints (partner retries within ~5s, p99 target X, current failure modes), lay out the trade-offs. then propose one small experiment that reduces uncertainty.

the useful output isn’t the prose. it’s the experiment. you want something that creates evidence.

slow hunch becomes a workflow: capture partial ideas, propose tests, run tiny experiments, update the hunch log.

agents won’t incubate for you. but they’re quite good at helping you tend incubation.

day 5: serendipity - I feed it anomalies instead of asking it to “be creative.”

serendipity in software is rarely “brainstorming.” it’s “something weird happened in prod, and someone noticed.”

agents can help with the noticing part if you give them the weirdness.

so in this simulation you bring:

• slow traces
• error logs (sanitized)
• a couple incident summaries
• maybe support-ticket clusters

and you ask for something constrained:

cluster failure modes. tell me the weirdest pattern that might matter. for the top 3, propose a hypothesis and one targeted change or experiment to confirm/deny it.

now you’re engineering serendipity: exposure plus recognition.

you’re not asking for originality in a vacuum. you’re asking for hypotheses anchored in reality signals.

day 6: error - we make the feedback loop the main character.

this is the turning point where the whole thing stops feeling like promptcraft and starts feeling like engineering again.

the user imposes workflow constraints that force convergence:

• no patch unless it serves an oracle (test, benchmark, lint rule, property check)
• diffs must be small enough for a human to review in one sitting
• after each change: run the suite
• for reliability changes: add at least one failure-mode test, not just happy path

the agent’s job becomes a loop:

• propose patch
• run tests
• observe failure
• patch
• repeat until green

this is where people’s experiences diverge dramatically. teams with solid verification culture feel like they’ve gained leverage. teams without it feel like they’ve gained a chaos multiplier.

error isn’t a tax. it’s steering.

day 7: exaptation + platforms - we stop patching and extract primitives.

by day 7 you could plausibly have “fixed the problem” locally. fewer duplicates, bounded retries, DLQ, metrics.

but the meta-problem remains: you’ll build ingestion endpoints again. and you don’t want to rediscover the same lessons every time.

so you ask the platform question:

what are the smallest primitives we wish existed at the start of this week?

in this simulation you extract a small substrate:

• an idempotency_guard(partner_id, event_id) helper with crisp semantics
• one canonical retry policy implementation (and a rule: don’t invent another)
• DLQ + replay workflow that’s operable by humans
• a metrics schema that makes reliability legible (duplicate rate, retry rate, dlq depth, replay success)

then you do exaptation on purpose: reuse an existing outbox-ish or backoff-ish pattern already in the repo, but only after stating the affordances like physics:

• we can tolerate at-least-once delivery, but side effects must be idempotent
• we cannot add a new datastore
• p99 at the edge is non-negotiable
• no payload logging
• rollback must be safe

with affordances named, reuse becomes safe and boring (the best kind). without them, reuse becomes clever and fragile.

finally you ask for the interface before the implementation:

design the primitives first. show how a future engineer adds a new handler using them. then implement one reference handler. keep APIs small. document invariants.

agents tend to do well here. scaffolding and boundary drawing are structured composition problems, and models are oddly strong at those… as long as you force them to respect your local laws.

what changed across the week wasn’t the model. it was the user.

in the simulation, the agent didn’t become smarter. the user became more explicit.

• constraints moved from tribal knowledge to written laws
• oracles became the interface (“make this test pass without breaking these invariants”)
• context became curated rather than dumped
• the loop became non-negotiable: small diffs, run checks, iterate

and once you do that, the seven ways start working with the agent rather than against you:

• adjacent possible: stairs, not leaps
• liquid networks: curated collisions with repo truth
• slow hunch: persistent hypotheses, refined by evidence
• serendipity: anomaly feeds turned into hypotheses
• error: tests and checks as steering surfaces
• exaptation: reuse, but only after affordances are named
• platforms: extract primitives so next week is easier than this week

the practical punchline

agents make code cheaper. they do not make judgment cheap.

so the scarce skill becomes: expressing constraints, designing oracles, curating context, and running tight feedback loops. if you can do that, agents feel like leverage. if you can’t, they feel like accelerating into fog: fast, smooth, and directly toward the cliff.

epilogue: ok, but doesn’t this mostly work for seniors?

yeah, mostly.

this flow works particularly well for experienced engineers because they already carry the “implicit spec” in their heads:

• the constraints you didn’t write down
• the failure modes you only learn after being paged
• the trade-offs you can smell
• the verification reflex that turns “looks right” into “is right”

agents don’t supply that for free. they amplify whatever objective you actually manage to encode, which means seniors get outsized value early because they can encode better objectives, pick better oracles, and notice plausible-but-wrong output before it ships.

but juniors can gain the missing “context” faster in this world… if you restructure learning on purpose.

have them own the spec + constraints + non-goals + acceptance tests. let the agent draft implementation. then require them to:

• iterate through the error loop (run ci, fix failures, explain what invariant broke)
• support changes with “citations” to existing repo patterns
• write a short “how this fails in prod + what to watch” note

the exact guardrails vary by company:

• startups: keep it lightweight (small diffs, a couple tests, basic observability)
• growth orgs: formalize playbooks and perf guardrails
• big tech: emphasize blessed primitives and rollout discipline
• regulated/safety-critical: shift juniors toward evidence and traceability with strong gates
• consultancies: focus juniors on rapid context extraction and runnable harnesses

but the core idea is consistent: let agents accelerate implementation, while juniors are trained (and evaluated) on objective engineering, verification, and operational judgment, not keystrokes.

appendix: the context packet (a tight template)

a context packet is a small artifact that stops the agent (and reviewers) from guessing. it pins the objective, establishes what “truth” is, and installs an oracle so the work converges instead of meandering.

use it for anything non-trivial: reliability, perf, migrations, refactors, cross-cutting changes.

template (copy/paste)

goal (1 sentence):
what outcome are we trying to produce? (not the mechanism)

non-goals:
what is explicitly out of scope? (the “helpful creativity” kill-switch)

constraints / invariants:
the laws of physics: budgets, safety properties, compatibility rules, forbidden actions.
examples: p99 < __, idempotent under retries, no retries at edge, no pii logs, no new deps, backwards compatible.

authority order:
when sources disagree, what wins?
default: tests/ci > current code behavior > current docs/runbooks > old docs/lore.

repo anchors (3–10 links):
the files that define truth for this change: entrypoints, core helpers, types, config, metrics.

prior art / blessed patterns:
where should we copy from? what must we reuse? what must we avoid reinventing?

oracle (definition of done):
the checks that decide success: tests to add, edge cases, benchmarks, static checks, canary signals.

examples (if tests aren’t ready yet):
3–5 concrete input → expected output cases, including failure/edge cases.

risk + rollout/rollback:
how could this fail, what do we watch, how do we deploy safely, how do we undo?

agent instructions (optional, procedural):
keep diffs small; cite anchors/prior art used; don’t add abstractions without justification; run tests each step; stop after step N.

a filled example (webhook reliability)

goal: prevent duplicate downstream effects when partners retry the same webhook delivery.

non-goals: no new datastore; no partner-facing response changes; no retries inside the http handler; no large refactors.

constraints: idempotent under retries; p99 handler latency < X; worker retries bounded with jitter; no payload logging; feature flag + safe rollback.

authority order: tests/ci > code > runbooks > old docs.

repo anchors: handler, queue abstraction, retry policy module, error taxonomy, metrics/logging helpers.

prior art: link to the existing bounded-retry implementation and any prior ingestion endpoint that’s “done right.”

oracle: add tests (duplicate enqueues once; retries bounded; poison → dlq); run ci; run handler benchmark; canary and watch duplicate rate/latency/queue depth.

examples: duplicate request; storage timeout; poison payload; downstream transient failure.

risk/rollout: flag on at 1%; monitor key metrics; rollback by disabling flag.

agent instructions: implement step 1 only; reuse retry policy; keep diff reviewable; run tests; summarize invariants preserved.

why it works: it turns “senior intuition” into explicit constraints and executable truth. agents stop guessing, juniors learn faster, reviews become about invariants instead of vibes.

import { LimeBikeSimulator } from './ssr-safe.js'; import './style.css'; import route from './blackfriars-to-oxford.json'

You're a cyclist at an intersection in London waiting for a red light. You're on a dockless hire bike. Every second you wait, you're paying for being conscientious.

Every junction you stop at, another cyclist chooses to run the light.

This isn't a bug. It's encoded into the design of the pricing. And it creates a dangerous incentive.

Try it yourself. The simulator below shows a route derived from Lime's own data of the most popular locations: Blackfriars Bridge to Oxford Street. Watch how much time is possibly spent waiting at lights, and how much that could cost.

<LimeBikeSimulator client:only="react" precomputedRoute={route} />

Lime charges by the minute. That's a reasonable business model for a service where time correlates with value, but actually we're focused on distance when thinking about a journey. Time spent waiting at a red light isn't valuable to you. It's time spent obeying traffic law. And unlike the same situation in a taxi, the legal consequences for skipping a red light are inconsequential most of the time, and self directed. It is far more now a social contract than it is perceived as a legal obligation.

Here's the problem: with this model, running a red light saves money. The longer the light, the more you save. You can feel it every time you approach a junction and the light turns amber. Do you brake and pay to wait? Or do you push harder?

Putting a monetary incentive for skipping that light is dangerous for pedestrians, for other cyclists, and for the riders themselves. And the danger multiplies with the weight of a 30kg electric bike underneath you.

Lime's billing model has turned riding safely into a premium feature you pay an extra 10-30% on your ride for.

A trivial fix?

Lime bikes have GPS. They track your speed in real-time. They know when you're moving and when you're not. The data exists. You can even download it from your account.

Pausing billing when a rider's speed drops below a threshold for more than a few seconds would be straightforward. No new hardware. No new data. Just a different calculation in the billing logic. It could even work as a refund if the calculation requires journey and bike telemetry data.

If Lime wanted to make this only work at lights, this demo shows how it's possible with open data to do that. If Lime wanted to make sure it wasn't abused, they could set a proportionate limit of 'free' stoppage time per trip, or change their model entirely to focus on a combination of distance and time.

The choice to charge for stop time isn't a technical limitation. It's a product decision that prioritises revenue over rider safety.

In a quote to The Times, Hal Stevenson, director of policy at Lime, said that the “pricing model had a very low impact on whether people did or didn’t stop at red lights. We don’t subscribe to the idea that people are making these decisions about their safety, for the basis of 10 or 20p.”

But this came from research that Lime commissioned themselves in July. They launched a 'Respect the Red' campaign to 'encourage riders to stop at red lights'. But surely a crucial part of that campaign would be looking at the behavioural effect of how they charge for time.

Hackney found a workaround

Hackney Council has partially addressed this. From October 2025, e-bike rides in the borough were capped at £1.75 for 30 minutes — the same price as a bus fare. The meter still runs, but the financial pressure disappears. You pay the same whether you sprint through junctions or wait patiently at every light, provided your journey is less than 30 minutes total.

It's a pragmatic fix that removes the incentive without requiring Lime to change their billing logic (they just sell 30-minute bundles for a cheaper price). But it only works within Hackney's boundaries, and it required council intervention to negotiate. The rest of London is still paying by the minute.[^1]

Try building your own commute and see how much Lime's tax on safety might cost you.

<LimeBikeSimulator client:only="react" height={600} />

<details class='mb-8 rounded bg-slate-400/10 p-4'> <summary>About this simulation</summary> This is a simplified model. Traffic lights are placed using OpenStreetMap data, which includes signals on main roads even where separate cycleways exist. Light timings are randomised and cycle predictably rather than responding to real-world factors like traffic density or time of day. The actual stop-time cost on your commute will vary. </details>

[^1]: All of the above also applies to Forest and Voi, who also charge per minute in most of London.

External link to loggingsucks.com