The Senior Engineer You Never Had in the Room

There’s a pattern emerging in software teams as AI-assisted development accelerates: the most experienced engineer in the room is finding it harder to be the voice that slows things down. Fewer objections in architecture reviews. Fewer moments where someone with a decade of production scars says we tried this before, here is what broke. The meetings still happen. The decisions still get made. The friction that used to slow bad ideas down has gone soft.

It isn’t that this person ran out of opinions. It’s that AI-assisted teams now move fast enough, and produce enough plausible output, that raising a hand to ask a hard question starts to feel like the thing that’s out of step with the room. So the senior engineer picks their battles, saving the pushback for what feels truly critical and letting smaller decisions slide. Multiply that across a team, and a company quietly loses a large share of its capacity to catch its own mistakes before they ship.

That’s a real and useful thing to notice about large teams. But it describes a problem that assumes an experienced engineer was in the room to begin with.

Most of the founders we talk to don’t have that problem. They have the one underneath it: there was never an experienced engineer in the room at all.

1. The value of the person who slows you down

It’s worth being precise about what that pushback actually does, because it’s easy to mistake it for obstruction.

The visible part of senior engineering is the hard technical work: the architecture decisions, the debugging, the code other people learn from. But the best senior engineers rarely operate inside that boundary. They understand that architecture decisions become product decisions very quickly. A data model can constrain a future feature. A technical shortcut can become a UX limitation. A complicated workflow can make a product harder to sell. A seemingly small engineering decision can determine whether a business can change direction six months later without rebuilding half the system.

The less visible part is the resistance. It’s the engineer who asks what happens when this assumption breaks, who recognises a familiar failure pattern in a new proposal because they’ve watched it happen before, whether the problem is a database schema, a checkout flow, or a pricing decision, and who is willing to be the one who says this isn’t ready in a room that wants to move on.

That resistance is institutional memory, made active in the moment a decision is still cheap to change. Remove it, and decisions move faster in exactly the window where they’re hardest to undo later.

2. The room most founders never had

A SaaS founder building with Cursor, Claude, Lovable, or Bolt isn’t managing a team where a senior engineer has gone quiet. There’s no design review where a seasoned engineer almost raised a concern and then didn’t. There’s a founder, an AI tool, and maybe a freelancer or a junior developer who is, reasonably, optimising for shipping what was asked for rather than questioning it.

The tools have gotten good enough to disguise this. AI can produce an authentication flow, a data model, an onboarding sequence, a pricing page, all of it running, all of it looking like the output of someone who knew what they were doing. What it doesn’t reliably do is sit back from the whole product and ask whether the data model will survive the third major feature, whether the onboarding actually matches how a new user thinks, whether the pricing holds up once real customers show up, or whether any of it is solving the actual problem or just the one that was easiest to describe in a prompt. That’s also where the limits of AI-assisted development become important: models are very good at local, well-specified tasks, but the questions a senior engineer actually asks, about architecture, about what it will cost to change later, about whether the thing being built is the right thing, require reasoning across the whole system, its future requirements, and its failure modes, exactly the gap a senior engineer fills by holding the whole system in their head rather than one file at a time.

So the gap in a large org is the senior engineer went quiet. The gap for most founders is there was never a senior engineer in the conversation to begin with. AI didn’t create that gap. It just made it possible to ship a product that looks finished, technically and commercially, without anyone ever noticing the gap was there.

3. Why it feels fine, until it doesn’t

This is the part that makes the pattern genuinely hard to see from inside it.

A 2025 randomized controlled trial by METR found something counterintuitive: experienced developers were slower with AI, but still believed they had been faster. Sixteen experienced open-source developers completed 246 real issues in codebases they knew well, some working in repositories with more than a million lines of code, randomly assigned to use or not use AI tools. When AI tools were allowed, they took 19% longer to complete the same tasks. Before the study, they expected AI to make them 24% faster. Afterward, they still believed it had made them 20% faster.

That’s the more interesting problem. The tool didn’t just fail to produce the expected productivity gain. It made the productivity loss difficult for the people experiencing it to perceive. A strong, real feeling of velocity is not the same thing as velocity, and it isn’t what tells you whether you’re moving toward a durable product.

The cost of missing judgment shows up on a different timeline than the benefit. The benefit, a working feature, a live demo, is visible this week. The cost shows up months later, in a different conversation, disconnected from the decision that caused it: an architecture that can’t absorb the next feature without a rewrite, a data model that held up fine for one user and breaks under real load.

By the time the cost is visible, nobody is thinking about the moment, fourteen months earlier, when a question should have been asked and wasn’t. The team just sees the problem in front of them and tries to solve it.

4. The question nobody is asking your product

If there’s one thing worth taking from what’s happening inside large engineering teams right now, it’s this: the real value sat in the questions the senior engineer was willing to ask before any of it got built, not in the code they wrote. Why are we building it this way. What happens when this assumption breaks. What did we learn the last time something looked like this.

AI has made “can we build this” a much less interesting question. What it still can’t tell you is whether you should build it this way. And as generating code keeps getting cheaper, that judgment is becoming the entire game.

A founder without that voice in the room isn’t doing anything wrong. Most founders are not, and should not be trying to be, senior software architects. But the problem is that senior engineering judgment rarely stops at software architecture. It’s also where a good engineer asks whether a feature is worth the complexity it adds, whether a workflow will survive real users behaving unpredictably, and whether today’s shortcut becomes next year’s rewrite. Without that voice in the room, none of those questions get asked anywhere, not quietly skipped in a meeting, just structurally absent from the process.

Google Cloud’s 2025 DORA State of AI-assisted Software Development report, based on survey responses from nearly 5,000 technology professionals, describes AI as an amplifier of an organisation’s existing strengths and weaknesses, rather than a substitute for them. That matters here. AI can accelerate an organisation that already has strong engineering practices in place. It can just as easily accelerate the production of problems those practices would otherwise have caught. A founder building solo with AI tools is running that second version of the experiment, with no one in the room to supply the judgment half of the equation.

5. Put the senior engineer in the room

At Pocket Dev, we use AI tools every day, for the same reason everyone else does: they remove friction from writing code. We’re not interested in typing boilerplate by hand when a model can produce it in seconds.

What we don’t outsource to the model is the part that was never really about typing speed. Before we generate a line of code inside a client’s product, we map the data model, the state ownership, the module boundaries, and the failure modes. We also pressure-test the decisions that sit on top of that architecture, because a good engineer never stops at the architecture: what the feature is actually for, whether the flow matches how a real user behaves, and whether the business decision underneath it survives contact with paying customers. We ask the questions a senior engineer would ask in a design review that most solo founders never get invited into. That’s the actual job: being the person in the room willing to say wait while the architecture is still cheap to change, before it and everything built on top of it locks in place.

If you’re building with AI tools right now and nobody has asked you those questions yet, that’s not a sign anything has gone wrong. It’s just the normal state of building without a senior engineer in the room.

So put one in the room, someone whose job is to sit in the seat that’s currently empty and ask the question while there’s still time to change the answer, not to slow you down for its own sake or write the code instead of the model. The room the large engineering orgs are worried about losing is one most founders never had. That’s the one worth building first.