The bimodal developer — vibe coding and the team you didn't know you had

1. The first article was about the product. This one is about the people.

Earlier this year I wrote about what vibe coding had taught me about enterprise UX — the observation that our engineers had quietly stopped clicking, started articulating intent to the model, and that the same shift was coming for every other knowledge-work user including HR. That piece was outward-facing. It was about the product.

This one is the inward version. Two years into running a 40+ engineering organisation through the vibe coding transition, the more interesting story isn't what vibe coding did to the software we build. It's what it did to the people building it. And the most honest version of that story isn't a single line.

2. The new normal isn't optional

Claude. Cursor. The internal copilots we've built around our own platform. Two years ago they were a productivity experiment. Today they are how every engineer on the team writes code. There is no engineer in the organisation who builds production work without some form of model-assisted pairing happening in the editor, on the terminal, or in the design conversation that precedes either.

That isn't a soft claim. It's observable in every commit, every PR, every architectural design document, every retro. The competitive question is no longer should engineers use these tools. The competitive question is which engineers are getting more out of them than the rest.And the answer isn't what I expected when we started.

3. The bimodal pattern

Vibe coding doesn't change who an engineer is. It amplifies whatever they already bring to the work. And because the engineers on any reasonable team bring different things, the amplification produces a bimodal output distribution that wasn't obvious before the tools existed.

The clearest example I can give comes from a feature we shipped recently. Two engineers, two different modules, same brief: build an uploader. Template download. CSV upload with validation. Show success and failure on the same screen. Standard enterprise utility.

One engineer shipped exactly that. The feature was clean. It met the spec. It passed code review on the first pass. A competent professional output that did what the brief said.

The other engineer shipped the same — and then kept going. The upload ran in the background so users didn't have to wait at the screen. Every upload wrote a detailed audit row naming who uploaded what and when, with each row of the input file marked success or failed and a reason captured for every failure. When a user came back to a partly-failed upload, they could resume from the failed row instead of restarting from scratch. The feature behaved the way a real customer who runs payroll for ten thousand employees actually needs an uploader to behave.

Neither output was wrong. The first engineer built what was asked for. The second engineer built what the user would eventually have asked for. Both used the same vibe coding tools. Both got it shipped in comparable time. And the gap between them, which would have been a two-week-versus-six-week conversation a few years ago, was instead a same-week conversation with a very different shape on what landed.

That's the bimodal pattern. The tool amplified both engineers — but in different directions, and the amplification made a latent difference between them visible in a way it wasn't before.

4. The thinker compounds. The literalist sprints.

The engineer who instinctively asks what should this really handle compounds with vibe coding. Each question they bring to the model is sharper than the last. They use the model to expand the surface area of what they think about, not to shorten the path to a shipped feature. Their output gets more production-grade over time, not just faster.

The engineer who interprets a spec literally and ships exactly what was asked for sprints with vibe coding. Their output is what was requested, delivered in less time than before. They're not getting worse. They're doing what they always did, faster.

Both are useful. A team that's only thinkers misses delivery dates because every uploader becomes a six-month productionalisation project. A team that's only literalists ships exactly what was asked for and rebuilds it three months later when the customer discovers what they actually needed. The healthy team has both, knows which it has on each engagement, and staffs accordingly.

The shift vibe coding caused isn't creating these two profiles. It's making them legible. Before the tools existed, the literalist and the thinker often shipped on roughly the same timeline because the cost of thinking deeply was high enough that the thinker paid it sparingly. With the cost of exploration collapsed, the thinker thinks at a wider perimeter on every feature. The gap shows up everywhere now.

5. The obsession risk

The other end of the bimodal isn't literalism. It is obsession. Some engineers, given a tool that responds the moment they ask, can't stop asking. The session goes on for hours. The questions get smaller. The model patches one surface, then the next, then the next. The engineer feels productive because they're generating output every few minutes. The code that lands is a stack of local fixes that don't cohere.

The shape is recognisable when you see it from outside. It is much harder to recognise when you're the one in the session. The model never tells you to stop. The tool is, by design, infinitely patient with the next question.

The single biggest hidden cost of vibe coding inside an engineering team isn't the token bill. It's the engineer who spent ten hours patching symptoms because the actual problem was one architectural question they never paused to write down.

6. The end-the-session skill — the PDF page-size story

A real example, lightly anonymised because the engineer is on my team and good enough to recognise the pattern. A customer reported that letters generated by the system were rendering in different page sizes across different users — some came out A4, some came out Letter, some came out a weird truncated middle size. Reproducible enough to be annoying, not reproducible enough to be obvious.

The engineer spent a full day on it. The session was productive in the way a long vibe coding session looks productive: questions to the model, suggested fixes, tests, more questions, more fixes. By the end of the day there were a dozen small patches to client-side rendering code, none of which solved the actual problem.

The actual problem was that PDF generation had been left on the client. Browser-side PDF rendering depends on the browser's print settings, default paper size, font metrics, and a dozen other things that vary between machines. The fix was a five-minute architectural pivot: move PDF rendering to the server. Same library, same template, same output, just rendered in a controlled environment.

The engineer never reached the five-minute fix because they never paused the session to write down the actual problem. Each question they asked the model was a surface-level question — why is this margin wrong, why does this font render differently, why does this work in Chrome but not in the test browser— and the model dutifully answered each surface-level question. The model couldn't see the question the engineer should have been asking — is rendering on the client the right architecture at all? — because the engineer never asked it.

Knowing when to end the session and rewrite the problem is the operational craft of vibe coding. It is not in any model's training data. It has to be built into the engineer.

7. Debugging at scale — both better and worse

Debugging splits along the same axis as everything else. When the problem is well-framed — a clear repro, a known surface, an isolated subsystem — vibe coding is a force multiplier. The model can read the stack trace, cross-reference the related code paths, and propose fixes faster than any human pair could.

When the problem is not well-framed — when the engineer doesn't yet know what the actual question is — the same tool becomes a trap. The model will fluently generate fixes for the surface symptom. The fixes are plausible. They pass review. They land in production. They don't solve the root cause.

The PDF story is one shape of this. There are others. An engineer chases a flaky test by adding retries instead of finding the race condition. An engineer patches a memory leak with a periodic process restart instead of finding the unbounded cache. An engineer catches an exception silently because the model suggested catching it, instead of asking why it was being thrown.

The discipline that matters isn't debugging. The discipline that matters is framing the problem cleanly before opening the editor.That used to be a senior-engineer skill applied a few times a week. With vibe coding it is a skill every engineer applies a few times an hour, and the ones who can't are the ones whose output slowly deteriorates without anyone catching it for quarters at a time.

8. How I'm tracking who's evolving

I wrote about this at more length in the Forward Deployed Engineers piece, but the short version is: I ask the AI tools themselves.

Every few weeks I prompt the model an engineer is working with and ask it directly — how has this engineer's thinking changed over the last month? Are they asking better questions, or more questions? Are they framing scope before code or going straight to code? Are they catching their own assumptions earlier in a conversation, or generating fixes for assumptions they never tested? The model has the long memory of every interaction. It has none of the social filters a human reviewer applies. It surfaces patterns I'd miss in a quarterly review.

The engineer who is starting to ask better questions of the model is the engineer who is evolving. The engineer who is asking more questions of the model without their shape changing is the engineer at risk. I have the same observation about engineers who used to write good code without these tools and engineers who used to write quick code without them — vibe coding didn't change the underlying instinct, it made the instinct visible.

9. What I'm doing about it

Three things, none of them complicated, all of them requiring direct CTO time I'm spending deliberately.

• Direct training, by me. Alternate-day calls with the highest-leverage cohort (the eight in the Forward Deployed Engineer program), one to two hours each, every class tied to the specific technical decision in front of us that day. No curriculum. The training material is the actual work.
• The “stop and rewrite the problem” protocol. Every engineer in the program knows the framing: when a session runs longer than ninety minutes without a clear path forward, close the editor, write down the actual problem statement in plain English, and only then open a new session. The discipline is more important than any specific fix.
• Measurement via the tools themselves.Asking the AI engines about each engineer's evolution over time. Patchy and directional, but it catches patterns a human review would miss.

The bigger play, which is still in early stages, is that the FDE program itself is a way of putting the thinker engineers in front of customers — where the amplification compounds against a real workflow rather than against a spec. That's in the FDE article if you want the depth.

10. Boon or fate

The honest answer is neither, and that's the article's real point.

Vibe coding isn't a boon — it doesn't make bad engineers good or average engineers great. The bimodal pattern proves that. It amplifies whatever was already there. A team that pretends the tool is uniform productivity multiplier is a team that will slowly lose its best engineers because the cost of not managing the amplification is paid by the engineers who think hardest.

Vibe coding isn't fate either. Thedevelopers can't write a single line without Claudeframing is exhausted, unhelpful, and inaccurate. They could write code without it. They'd write less code, slower, and on a smaller perimeter. The same was true about Stack Overflow ten years ago and IDE autocomplete twenty years ago. The dependency is real. The dependency is also a normal part of engineering culture absorbing a new substrate.

What it is, I think, is the moment a long-standing latent difference between engineers became a visible everyday one. Some of us were always thinkers. Some of us were always literalists. Some of us were always at risk of getting lost in a session. The tool didn't create any of those types. It put them on the whiteboard in front of the rest of the team.

The teams that learn to read what's on the whiteboard, and to staff and train accordingly, will compound. The teams that pretend everyone is using the tool the same way will not. That's not boon and it's not fate. It's a leadership problem with a leadership answer.

11. The honest open question

Whether the bimodal stays bimodal.

The optimistic version is that the literalists learn, slowly, to ask the wider questions, because they see the thinkers get more leverage from the same tool. The pessimistic version is that the gap widens because the thinkers compound faster than the literalists can catch up, and a team that started with two profiles ends with two castes.

I don't know which version is true. I'm running the first version, because the second is organisationally unstable and I'm not interested in finding out the hard way. But I'll know in two years whether the gap is closing or widening, and I'll write that article when I do.