No more coding vibes in the efficiency era

I hope you brought the receipts for your latest productivity initiative

A guest post from

James J. Boyer

of

Engineering Leadership Bites

There was a time (not that long ago) when engineering teams could run on vibes. 🌈 Growth-at-all-costs made hiring the solution to every problem. Feeling productive was good enough. If metrics looked soft: throw more developers at it, baby. If engagement was lagging: let's cram some more features into that homepage, fellas. If someone asked "What's your engineering strategy?", you could gesticulate wildly in the general direction of your open reqs and say "we're scaling, fam!"

That era is over.

From ZIRP to AI Whiplash

The ZIRP years (Zero Interest Rate Phenomenon, for the uninitiated) made many bad habits look like good strategy. But as the tide went out, we saw who was swimming naked. The pendulum swung hard. Post-ZIRP brought layoffs, a flattening of org charts, and, suddenly, every engineering manager needed to be coding again. Enter AI, the latest efficiency tonic on the market. Get back to ZIRP-level productivity with post-ZIRP spending.

This whiplash is exhausting. But here's the thing: for those of us who've always believed in focused and surgical teams, the moment we're in isn't a crisis. It's vindication.

Every achievement has a denominator

A senior leader recently handed me a "gift": a plan to hire more engineers. I paused. "Why?" I asked. "What problem do we have that hiring solves?" They looked at me like I had passed Go and didn't want my $200. But adding more people doesn't mean more progress. That's a ZIRP-era assumption. What matters now—and what should've always mattered—is leverage. Outcomes. Impact per engineer. Or as Charity Majors once wrote, “every achievement has a denominator”.

This, my friends, is the Efficiency Era (Did I coin that? I’m running with it). In this era, engineering leaders don't just need to feel productive; we need the receipts.

AI looks smart, but acts dumb

AI is incredible; I don’t argue here. Ask it to write some boilerplate code, generate some unit tests, or explain an obscure SQL function—it'll knock it out of the park. Hell, it might even open a PR or two. Add some doc comments while you’re at it, my robot friend.

But AI doesn't understand your business.

It doesn't know about that weird billing exception you coded three years ago,​​ what the CEO told the board last week, or how conversion decreased the last time you rebranded the site. It doesn't know which priorities are real and which you tossed out in Slack five minutes after being written.

AI doesn't pause to ask, "Why are we doing this?".

I once watched a team spin in circles for a week trying to build a system that could browse users' internal networks, only to find out, after a single Slack message, that none of that was even in scope. AI would've done the same thing, only faster. And now you're maintaining that mess. Building beautiful, irrelevant things.

Junior engineer energy

I like junior engineers, don't get me wrong. But just like junior engineers, AI flails without the full picture. It doesn't ask clarifying questions, it doesn't zoom out, it just... executes.

Maybe not that kind of “executes”

That's fine, but only if you give it the right constraints, guardrails, and context. In constrained solution spaces with high-quality inputs, AI is a powerful assistant. But in messy real-world systems, it's like setting a Roomba loose in a cluttered garage: it'll move fast and look busy, but it's going to smear motor oil all over the place and get stuck between your boxes of old collectibles that you're definitely going to be happy you kept for 20 years across three houses and an interstate move.

The real danger zone is where the context is implied, not provided. AI will fill in the blanks whether it should or not. Just like that junior dev we all know who was sure they "got it" after a five-minute handoff. Oh lord, they didn't. 😭

What's potentially even more dangerous is expecting junior engineers to become senior when they suddenly have access to AI. It just helps them make bigger mistakes, faster.

If we treat AI like an omniscient engineer, we're in trouble. But if we treat it like a force multiplier that still requires human judgement, business acumen, and context, we might get somewhere. Lightning in a bottle. All that jazz.

So yeah, use AI. But treat it like the power tool it is: deadly in the wrong hands, amazing when handled with care. 🥰 Otherwise? It just mirrors the mess.

The real productivity problem is context scarcity

We don't have a tooling problem; we have a context problem.

AI can lint your code. It can suggest a refactor. But it can't tell you why that ancient function exists in the first place. It doesn't know that you taped your entire reporting infrastructure together with a Perl script and a prayer. It has no clue what success looks like for this quarter's top initiative.

We call them "AI copilots", but that's generous. They're tourists. What's missing is local context and tacit, tribal knowledge. We need context copilots. This means tools—or hell, even people, god forbid—that help engineers see the full picture.: the architecture, the product strategy, the market pressures. What's real? What matters? What's noise?

Here’s something that doesn't get fixed with AI: dark work. The hidden toil. The hours spent trying to decode tribal knowledge, or divine what some now-departed engineer meant when they scribed:

// don't touch this.

This wastes time and potential.

Even the best and brightest engineers can't produce great outcomes if they're operating in the dark. If you give the latest LLM bad context, it'll confidently help you! It's really good at building the wrong thing faster than you!

The ugly truth is that whether it was your caffeine-fueled, furiously typing fingers or a vibe-coded LLM solution, a year from now, both are a liability. Write only the code you need to solve the problem at hand. Anything more is a maintenance burden.

If you want to move the needle on productivity, start with context. Make work visible, over-communicate priorities, and share the "why". Do your best to close the gap between business intent and engineering execution.

Clarity is the unlock; context is the accelerator. Until we solve for that, all the AI in the world won't save us from shipping those beautiful, irrelevant things.

Numbers don't care if you misinterpret them

Sprint velocity is up, more PRs have been merged, and the burndown chart looks healthy. Yeah, baby, we're cooking with fire now!

Maybe. Maybe not.

Measuring output without understanding the context is like flying a plane by staring at the altimeter. Have you seen the cockpit of a 737? If you binged The Rehearsal like I did, you probably have—all those gauges, switches, and blinking lights. You might think you're climbing when in reality you're headed straight for a mountain. What's the opposite of the Miracle Over the Mojave?

We've all seen teams hit their sprint goals, merge code, and deliver features while the business is flailing. Churn is up. Revenue goals come and go. New executives stay long enough to update their email signatures before their Slack profiles are deactivated.

You cannot measure productivity in isolation. You have to ask: Are we building the right thing? Is it solving the right problem? Are we even aiming at the right outcome?

In this Efficiency Era, leadership wants proof. And proof is good! But bad metrics are worse than no metrics at all. They give the illusion of insight while steering you straight into disaster.

We love to measure what's easy: number of commits, cycle time, and issues closed. But we're wandering in the desert if we don't pair that with qualitative understanding and business context. We're spotting an oasis. We're sprinting towards the mirage. We're drinking sand and hurling obscenities because our senses deceived us.

Measurement should bring context, not confusion

At their best, engineering metrics focus on the denominator. More output isn't inherently better if the input increases proportionally. Great measurement shows efficiency, not just activity.

I've been part of a painful offshoring operation that doubled the size of the engineering org and still had us delivering all the wrong things. We had more people doing more things, but revenue was tanking, morale was cratering, and product strategy was a mess. No one stopped to ask, "What does success look like?"

Balance results with retention

The best engineering leaders I've worked with knew that good metrics are only half the equation. You also need to measure the cost: burnout, turnover, and the slow decay of a team's ability to think deeply and solve complex problems.

In his interview, one of my favorite bosses said something that stuck with me all these years. He said, "My job is to balance results with retention". Deliver positive business outcomes and take care of your people. If your metrics don't reflect that dual mission, they're incomplete and harmful at worst. Thanks for that lesson, Hal! 💗

You're not a senior engineer if you're drowning in toil

Here’s a hot take, but it shouldn't be: Senior engineers don't get pulled into low-leverage tasks. That's literally what makes them senior.

They know when something is risky, complex, or a stretch, and they take it on themselves! They know when to delegate. They also know when something is noise or a distraction. The edge case that's out of scope? The low-priority bug that's been open for a year and affects three users? They know how to say "not worth it" and move on.

This 👏 is 👏 the 👏 bar! Not negotiable!

Not "knows the internals of every system". Not "writes the cleanest code". Senior engineers understand the business. They raise their head from the keyboard and ask: What are we trying to achieve? Is this the highest-leverage use of my time?. They ship the right thing quickly. If you can't do that? You are not ready yet.

Don't want to "gatekeep the title"? Shove off. This is the job.

High-leverage work isn't writing more code

As a leader, high-leverage work doesn't mean tracking PRs or counting points. It means giving my team context, helping them understand how their work connects to the company strategy and the competitive landscape, and their own career growth. This is how you get people doing the best work of their careers. Remove blockers. Protect focus time. Create systems and processes that scale.

Writing code is only for sharpening my own understanding or tightening a feedback loop, not because I think it's the best use of my time.

High-leverage work is the stuff that only you can do well. The same is true for engineers. Sure, use AI to write the boilerplate. Delegate low-stakes tasks to others who are learning. But save your energy for the things that matter: thinking clearly, building leverage, and driving outcomes.

Don't delegate thinking to AI

You can (and should) delegate tasks. But you can't delegate thinking. You can't outsource understanding. And you definitely shouldn't let ChatGPT write your Slack messages.

I've seen people use AI to draft all of their internal communication. Folks, hear me out: It's obvious. It's a mistake. You don't build trust with your team or peers by sounding like a generic thought-leader bot. If you want to influence and build mutual trust and respect with your teams, use your voice.

This also applies to Strategy, tradeoffs, and decision-making. Don't abdicate those to AI. Use it to speed up your research, bounce ideas around, but keep the knowledge work. That's what separates the truly exceptional performers from the folks playing one on TV.

You need a productivity strategy with real outcomes

If you lead an engineering org today, someone has probably asked you some version of this:

• What's your AI strategy?

• How are you measuring productivity?

• What are you doing to make your teams more efficient?

Gone are the days of "trust me." The ZIRP money dried up, and the vibe checks have bounced. Now, everyone wants proof: board members, executives, and investors. And honestly, that's a good thing. We should show that the money we spend is returning value.

But here's the kicker: AI isn't the strategy. It's a tool. Your strategy is how your org creates leverage, removes friction, and delivers outcomes. AI can help. But if your systems are broken, it will help you break them even faster! If your product vision is lacking, it will hold the blindfold tighter! If your teams can't connect their work to positive business outcomes, neither can AI. How's that for strategy?

Context is the productivity unlock

Want your AI investment to pay off? Start by making your systems legible. Make context flow through your organization like oxygen. Write things down. Share what's in your head. Help your teams understand what to build and why it all matters.

I've written about this before: My weekly "working in the open" habit; the value of metrics with context; the breakthrough moment when technical leaders realize they need to look up from their IDEs. This is all part of the same thing: building a system that enables engineers to do great work. AI can accelerate that. But it won't replace it.

The efficiency era is just getting started

We're not going back to the old way. There's no safety net of endless hiring. No free pass for "engineering as a black box". The companies that thrive in this new era will be the ones who get serious about focus, leverage, and results. That doesn't mean burning people out. It means finally getting smarter about how we work.

Use AI, leverage your metrics, and use whatever tools give your teams superpowers. But stop pretending that vibes and velocity are enough.

The future belongs to teams that understand the why, not just the what.