He’s had a lot of vantage points to think about it from. “It seems like there’s no technology I’m not somehow attracted to, as long as it’s got something to do with tech,” he told me, and the record backs him up: Cisco, because “I recognized there was a shift coming, going from essentially the TDM world to the packet world,” then Polycom, Juniper, Proofpoint, a stretch in long-haul optical. A few months before we spoke he became CTO of New Relic: “It is the company that sort of created the whole observability space. And what I say to people, now we get to recreate it.”

The fast versus the slow

He is not ambivalent about the acceleration. “Many years ago, I worked for a CEO who said, ‘You know what? It’s not about the big versus the small. It’s about the fast versus the slow.’ And in tech, the fast almost always beats the slow.” AI, in his view, is speed you don’t decline: “Any company that’s going forward now that doesn’t embrace AI and understand what it’s capable of, and use the skill sets that are there to accelerate our ability to develop within the boundaries of making sure that it does it correctly, will fall behind.”

The numbers he sees inside his own teams: “depending on the project and depending on the stage that it’s at, two times, three times, five times productivity improvements in certain aspects of the task.” Secondhand, wilder: “I’ve heard anything from conservatively 2X to bold statements around 10 to 15X, and this is from people who are regularly putting technology into production.” And the gains spread beyond the code itself. “Developing technology is not just writing code,” he said, “although writing code is a significant part of it. But AI doesn’t just help with the writing of the code, it helps with developing the spec. It helps with creating the test case. It helps with creating the documentation. It helps with getting you the compliance that you need.”

One example he offered sits upstream of engineering entirely. “There’s always been this interesting sort of tension between product management and engineering, where product management has an idea and they sort of throw it over the wall to engineering,” and the requirements dribble in as everyone figures out what was meant. “Now you put vibe coding in the hands of a product manager and they prototype the whole thing out. It’s not production, but they prototype it out.” They demo it to a customer, collect feedback, and engineering gets “a set of requirements at the beginning that’s so much more complete and so much better defined.” Software, as he put it, is now being developed “at a speed that’s never, ever been seen before.”

True engineering

So when I raised the fear making the rounds, that we won’t need to think anymore, I expected the standard reassurance. What I got was sharper. “I would take some exception to the comment, ‘We don’t need to think anymore.’” His teams use AI everywhere, and “it has not removed the need to do true engineering, to break the problem down into consumable pieces to make sure that those pieces work.”

The failure mode is specific. “If you give an AI coding tool too large a task, it will fail. It doesn’t break it down. It doesn’t necessarily know what’s right and what’s wrong.” Overload it and “you’re pretty much guaranteed it’s gonna hallucinate and make mistakes.” As for why: “Because it gets, I don’t know, confused, I guess, is a way to put it. I don’t know if that’s an accurate way of describing it.” He’s collected the cautionary tales, including “a recent example where AI wiped out the databases of a particular company, which I’ll stay away from names.”

The discipline that survives is old: decompose, give “enough context,” then verify. “You have to make sure that the code it generates is correct, that it is doing what you expect it to do.” Some of that is testing; some is the spec-driven school, where “the spec really becomes the source of truth as opposed to source code.” And none of it holds still: “If you wanna be successful in this environment, you need to keep up with the fact that the models are getting better.”

Ninety-seven-ish percent

Late in the conversation I asked whether this era belongs to the startups or to the incumbents.

“Both. I mean, they’re both true.”

He’s seen this movie. Of the dot-com boom: “It is also true that the biggest companies that exist today came out of that era. But it’s also true that probably ninety-seven-ish percent of the companies disappeared.” Of the current field: “We’ve already seen some of the AI frontier companies have already sort of faded... it’s come down to, in the US at least, mostly about Anthropic and OpenAI,” both “being valued around a trillion dollars, which is kind of amazing as well.”

And then, instead of talking about companies at all, he swerved to the tool everyone is holding. “You have to think about the frontier model as being a sledgehammer. And not every problem needs a sledgehammer. While a frontier model may be applicable to solve a lot of these problems, it’s unlikely to be financially viable to solve a lot of these problems.”

He runs a business inside that asymmetry: “We have about a billion dollars in revenue, which is not small, but it’s not the forty-four billion that our friends at Anthropic are running at today.” He doesn’t expect the tool to get cheaper on its own. When I asked what happens if the labs stop subsidizing usage: “At some point they have to, right? Because they have to be in the business of making money as well. We all remember the early days of the big search engine and everyone saying, ‘Well, it’s never gonna make any money. They can’t figure out how to make money.’ Who knew that clicking on a link was a valuable thing to do?”

So: “If we’re not making decent margins, we won’t be here tomorrow. Doesn’t matter how cool our tech is.” He thinks this discipline is the sorting function for the whole field, the thing that “will separate those who are successful from those who might build something cool but can’t make a business out of it.”

All of which was the setup for the sentence he actually runs his organization by:

“What I tell my team is if we can solve something deterministically, we should, because the cost is lower and because determinism in observability is important.”

Strong signals

The rule has a second half: “If we wanna derive insights and actions and potentially self-healing to that, and we need a broader knowledge base, and the probabilistic nature of it is real, then we will use AI.” Between the two halves sits the decomposition skill from earlier: “As you break the problem down into consumable chunks, you may actually have different models deal with different parts of the problem.” Some chunks get the frontier model. Some get something smaller (”we will likely develop some of our own smaller AI models as well. It just makes sense”). Some get no model at all.

But why determinism, in his industry, beyond cost? “Observability historically has been about pretty strong signals. If a CPU is running at 100%, if memory runs out, if a disk drive fails, if a link fails, these are all very physical things that happen.” Every needle on the dashboards you page on was calibrated for failures like that: loud, physical, threshold-crossing. “Very different from an AI agent hallucinating. That requires a different kind of detection. AI models drift over time, and they start to make mistakes. They are inevitably probabilistic in their nature.” A hallucination pegs no CPU and fills no disk. And the million-line engineers are multiplying the surface area: “There’s just gonna be a lot more to observe. So the market itself will get bigger.”

A deterministic component is one you can make promises about. When your product is the thing that tells everyone else what’s wrong, the promises are the product.

The holy grail

He was specific about where he does want the sledgehammer. Today, when something breaks, a human triages the alerts, potentially across products from multiple companies, and hunts for root cause. With an SRE agent, “you’re going to be able to take more of that toil away from the individual human being who has to do it, and be able to analyze what’s coming in, gather those insights, determine what the action should be, and inevitably get to the holy grail of actually self-healing. That is coming and already happening in some cases.” Broad knowledge, genuine ambiguity, insight and action derived from mess: a problem shaped exactly like the tool. That’s the sledgehammer swung at something that is actually a boulder, and one he’ll pay the token bill for.

The stakes of getting the matching wrong aren’t abstract to him. “The first company I worked for doesn’t exist anymore. They never made that transition.”

The question Michael left me with is cheaper to ask than the alternative. A million lines in six months means the swings are already happening. The next time a problem crosses your team’s desk, the question isn’t whether the model can solve it. It almost certainly can. It’s whether this problem is worth a sledgehammer, and what you’ll be able to promise about the answer.

High Output is brought to you by Maestro AI. Michael’s rule is to solve problems deterministically when you can and save frontier models for the work that actually needs a sledgehammer. But across a real engineering organization, those choices disappear into thousands of conversations between engineers and coding agents. A PR can show you what shipped. It can’t show you which model did the work, where the tokens went, or how much correction and rework happened along the way. That context doesn’t live in tickets or dashboards either. Your Anthropic bill tells you something is happening. Maestro tells you what. Maestro plugs into Claude Code, Codex, and Cursor and turns that hidden work into an honest ledger: model and token spend per person, per category, and per PR, alongside what the work produced. Now you can see whether the sledgehammer earned its cost.

Visit https://getmaestro.ai to see spend by category and output per dollar: an honest ROI ledger for AI-assisted engineering.

His summary: “Potentially more incidents, and also less help when you have to troubleshoot something.”

Sylvain has been on the receiving end of that pager for most of his career. He started out building private clouds in France before public cloud was really a thing (“crawling in data center floors, passing cables”), then joined SlideShare as the SRE practice was first emerging, and rode the acquisition into LinkedIn, where he spent three-plus years as a senior SRE. Along the way he co-founded Holberton School, an engineering school with no teachers and no lectures that has trained thousands of engineers across more than 25 countries. Now he runs AI Labs at Rootly, the incident-response platform, where his job is to prototype what AI can do for reliability. “It’s kind of a constant hackathon,” he told me. Sylvain hedges everything he hasn’t verified, flags his theories as theories, and, as it turns out, will happily tell you about the time his own conference talk fell apart on him.

The bummer

Last October, Sylvain gave a talk at SREcon, the conference where the reliability community compares notes. When he sat down to prepare it, the plan was to catalog all the novel ways generative AI breaks production: have some fun with AI slop, watch the LLMs fail, name the new failure modes the industry needed to worry about. The plan didn’t survive the preparation. “I was really trying hard to find new failure cases,” he admitted. “To be honest, I didn’t find them, which was a bummer, because my entire talk was about that.”

It’s not that he found nothing. If you ask a coding assistant to write a unit test for code it just wrote, “it will write a unit test replicating the already broken code.” There’s slopsquatting, an attack that at least sounds brand new: LLMs hallucinate package names, attackers register those names and fill them with malicious code. In one experiment, a researcher registered a hallucinated package name with a dummy library, and it was downloaded thousands of times in a matter of months and cited in README files across GitHub.

Then he showed the list to a friend, an SRE leader at Airbnb. The reaction he got back: “Boy, I’m pretty sure that humans do the same type of mistake.”

So Sylvain checked. Slopsquatting is blindly pulling in a package you’ve never inspected, and we already do that: it’s curl | bash, which we’ve been piping into our shells for decades and which, he pointed out, is still how Docker recommends you install it. AI agents hallucinating their way into deleting someone’s files? “We’vebeen ding rm -rf by mistake, using root.” One by one, the novel failures paired off with old habits, and what he was left with was the opposite of the talk he’d planned: “The way that LLMs are failing is stuff we’ve been doing for the longest time as humans.”

On cats and LLMs

The strangest example he brought up involved cats. Researchers gave an LLM a problem statement with one irrelevant sentence appended: cats sleep for most of their life. With the cat fact in the prompt, the model was something like 40% less likely to solve the task correctly. The machine gets distracted — and nobody needs a study to prove that humans do too. “As you know, you also get distracted,” he said. “Cats are the most important thing on the internet.”

By this point it was all starting to sound a little too tidy, so I pushed on the example that seemed most machine-shaped: the lazy unit test. A human could write a test that just ratifies their own broken code, but a human who generally likes their job mostly doesn’t. Isn’t that a class of failure that’s simply more prevalent in the machines? Sylvain didn’t defend the thesis. “I think what you described is absolutely true, but I’m not sure if the issue is the LLM or the prompt.” The chaos of LLMs, he pointed out, is that they’ll produce something no matter what you give them: “whatever prompt you give them, it’s gonna work.” And the gap between a good prompt and a bad one is enormous. His own benchmark project found that prompt optimization alone could double some models’ performance on SRE tasks. So maybe it’s a new failure class, or maybe it’s an old one: garbage instructions, confidently executed. He wasn’t sure, and he said so.

V times P

What he is sure about is the arithmetic. For the talk, he deconstructed incident rate into two numbers: V, the volume of changes to a system per unit of time, and P, the probability that any one change breaks something. AI is driving V up dramatically; that’s the whole point of it. Hold P anywhere near constant and the conclusion writes itself: “The incident rate will drastically grow.” Then he immediately fenced it in: “That’s actually the theory on paper. I’m not saying this is happening.”

The concern survives the hedge, though. Even if AI’s mistakes are our mistakes, “it’s doing it at least 10 times faster.” The failure modes are reruns; the throughput is new. The guardrails SREs have spent the last ten or fifteen years building (test coverage, deployment gates, observability, chaos testing, capacity planning) were designed to catch mistakes made by unpredictable humans, and in Sylvain’s telling that work is “not becoming obsolete, but more important than ever.”

He also thinks the same force pushing V up can push P down. Mutation testing has been around for years without much adoption; throw an LLM at it and it scales. He pointed to Meta’s published work on LLM-powered mutation testing: roughly 10,000 mutants generated across the Facebook, Instagram, and WhatsApp codebases, around 500 generated test cases, three quarters of them approved by engineers. Run the two effects against each other and “it might equalize, or we might even end up with better reliability at the end of the day.”

The dream machine

There’s a portion of his community that wants nothing to do with any of this, and he role-played them too: “I’m not touching systems that are non-deterministic. It’s absolutely against everything I’ve been doing. And now you’re telling me to use this dream machine.”

His answer to the skeptics was the closest thing the conversation had to a thesis. “Humans are unpredictable. We’re non-deterministic.” Every guardrail in the SRE canon exists because the industry already learned to run reliable systems on top of unreliable authors. The blameless postmortem, trust-but-verify, defense in depth. None of it assumed the code’s author was trustworthy. “We’ve already been doing this with humans,” he said. “It’s trust but verify. Make sure that whatever they do is fine.”

That’s why the failure mode he’s actually worried about is cultural, not technical. He told me about a consultancy that surveyed engineers at a bank about their outages. The answer that came back: “It’s not my fault. GenAI wrote that.” One survey, one company, he cautioned. But if one engineer says it out loud, others are thinking it. “There is an erosion of the ownership of the code base, which I think is totally wrong. And I think engineers need to start thinking more as SREs.” His suggestion is concrete: don’t just accept what your assistant writes. “How about using another model to judge your code?” The blameless culture survives the agents fine. What can’t survive is blameless sliding into ownerless.

SEV2, maybe SEV1

Fifteen years ago at LinkedIn, annoyed by repetitive incident work, Sylvain wrote up a concept for a system that would learn from logs and signals and heal itself. “We have all these signals, all these logs, all this data — we should be able to learn from that and correlate.” Machine learning wasn’t good enough to build it. His employer patented it anyway (“that was not really my goal, but my company was like, hey, we need to patent stuff”), and he moved on to found a school.

Now he’s at Rootly watching the industry build the thing. The tools are called AI SREs (he knows people hate the name — Rootly wrote a whole post about it), and the first thing they do isn’t even intelligence, it’s logistics: pulling context from Slack, postmortems, Git, and observability tools into one window in minutes, work that used to mean tab-hopping between Grafana dashboards mid-outage. The second thing is the intelligence: developing the intuition a tenured SRE has, the “when this service breaks, it’s usually that database” sense, and investigating on its own. For simple incidents, the SEV2s and SEV3s, “we are seeing customers where the incidents are no longer handled by humans.” Complex distributed failures, not yet. There, it “kickstarts your investigation, gets some context going, and then the human can take over.”

Nobody’s job disappears in his telling; it relocates. “We’re all becoming managers in some ways — or maybe not managers, but team leads.” Engineers move “away from the manual work of typing lines of code to directing,” closer to the business, further from the craft of typing. And the incidents themselves? He loves the thrill, he admitted, just not at night. “I think that’s definitely something we want to solve, and not say, hey, let’s keep this problem for humans.”

Sylvain went looking for proof that the machines fail in ways we’ve never seen, and found a mirror instead. That’s the reassuring part. We know how to build for unreliable authors; we’ve never had any other kind. The uncomfortable part is the other thing he found: the guardrails we built for mistakes made at human speed now have to hold at machine speed. When did you last check that yours would?

High Output is brought to you by Maestro AI. Sylvain’s prescription for AI-written code is trust but verify: don’t blindly accept what the agent produces, put a second set of eyes on it, even a second model. But verification is a habit, and it happens (or doesn’t) inside the working session between an engineer and an agent, where a PR count can’t see it. Your Anthropic bill tells you something is happening. Maestro tells you what. Maestro plugs into Claude Code and Codex and turns agent sessions into an honest record of the work: where the tokens went, what kind of work they bought, and whether anyone verified the result before it shipped.

Visit https://getmaestro.ai to see how we help engineering leaders calibrate AI sessions against shipped outcomes.

“This can be the start of a great joke,” he said. “A product manager and a designer and an engineer walk into a room, and then jam on the idea together. And they come out with a working prototype instead of coming out with a spec.”

What’s missing is the handoffs. No PRD for a designer to interpret. No mockups for an engineer to build from. No ticket waiting to be picked up. The session ends with a thing that runs, not a document describing the thing that should run. He kept returning to that image, and most of our conversation was about the distance between that room and the one his teams actually work in.

Muddassar is the SVP of Engineering at GoodRx, with two decades behind him — Ticketmaster, where he grew the app install base to 42 million users, then Beachbody, now GoodRx. He’s led the kind of multi-year migrations that reshape an org chart, and so his first instinct about AI is that it’s familiar. “I would say this is part of my playbook,” he said. “I’ve led technology transformation and organizational transformation at a number of companies.” Cloud was one. Monolith to microservices was another. AI, in his telling, is just the next. Hold onto that, because by the end he complicates it himself.

Leakage

When I asked him to walk through how software actually gets made at GoodRx, the answer ran long. A PM talks to a business stakeholder. The ideas become product specs. The specs get handed to a designer, who makes visual artifacts. Those go to an architect or tech lead, who writes the technical diagrams. Then a team builds it.

Business intent into PRD. PRD into wireframes. Wireframes into architecture. Every arrow is a person reading what the last person produced and trying to figure out what they meant.

There’s “a lot of potential of leakage,” he said, as “these handoffs are happening between different roles.” Leakage is the right word for it. Each handoff is a lossy compression: the stakeholder had something in their head, the PM wrote down a version of it, the designer drew a version of that, the engineer built a version of that, and what ships is four translations downstream of the original intent. No single handoff is broken in a way you can name. But by the time the thing reaches production, some real fraction of what the business actually wanted has been quietly washed out of it.

Muddassar’s read is that AI’s real leverage is on the chain itself, not on the code at the end of it. “What AI will do, already doing, is diffusing these different roles. So one person can play multiple roles. We can also find ways to reduce the leakage as handoffs go on. Or we can completely eliminate certain handoffs.” Most productivity tools just speed handoffs up. He’s saying some of those handoffs shouldn’t exist in the first place.

Collapsing the chain

That room from the joke — GoodRx isn’t in it yet. “We are not there yet,” he said. So he’s working toward it one handoff at a time. He gave me three examples, each killing a different translation step.

JIRA automation closes the gap between a ticket and a branch: “add a label, or add a bot. It’ll read the JIRA specification. It’ll recognize what parts of the code need to change. It’ll go make the changes.” A tool his team open-sourced, called Lifecycle, shortens the engineer-to-QA loop by spinning up an ephemeral environment for every PR and posting the test link back to the ticket. And the third handoff isn’t technical at all: “We’ve had a lot of product managers starting to deploy quick fixes. AI has truly enabled me to democratize access to code.” For a copy change, the PM just ships it. The handoff to engineering disappears.

Each one cuts out a step that used to be just how work moved through the org. You make progress by subtracting, and the subtractions stack. His last transformation cut cycle time from “13 days or so to about six days,” and “that took us about two and a half years.” Since adopting AI: “the cycle time has again reduced by half in the last eight months.” Same size of gain, a quarter of the time.

Two workforces

This is where his just-another-transformation framing breaks, and he knew it.

“Previous transformations were primarily human driven. And now you have to manage humans, and you have to manage non-humans — the agents.” There’s a second workforce in the org now. It doesn’t attend standup, isn’t bound by morale or meeting culture, and runs at a pace no migration ever did. A cloud migration never made anyone manage a fleet of teammates that don’t sleep — and it never made the human teammates wonder, as Muddassar put it, whether “this role is even going to be around two years or five years from now.”

So a leader now runs two workforces at once, and can see neither clearly. The pace is the part that surprised me — Muddassar told me he used to read a daily brief on the AI world and had to give it up for a weekly one, because there was too much shipping in any given day to keep up with. And the humans? Their most important work has moved to a place the old dashboards don’t look. When the act of coding gets cheaper, the value moves upstream of the code: into how an engineer scopes a problem, what they ask the model, whether they catch it when it’s wrong. As Muddassar put it, “the act of coding itself will become less and less important.” What survives is “system thinking” and “your ability to give really clear specs.” That work happens before a single line is committed — and none of it shows up in a PR count.

The one handoff you can’t collapse

For all the acceleration, the thing he was most insistent on was the part that doesn’t speed up. With more code generated by models — and then read and changed by models — the old review process strains. But the answer isn’t a lower bar. “The bar for product quality cannot reduce. So we have to have stronger harnesses to test the changes.” He’s seen the cautionary tales: “changes at much bigger companies being rolled out with AI that have caused business impact.”

His reframe is that the code itself stops being the artifact you guard. “The quality of code will matter less and less. The outcome that comes out of the coding session, the final output — that’s gonna matter. If you’re able to write a well-defined spec, and if you have well-architected harnesses to evaluate the output of the prompt, then how the code is actually written matters less and less.” Not how it’s written. Whether it does the thing, and whether you can prove it.

If the leverage is in collapsing handoffs, the one handoff you can’t collapse is between “the model produced something” and “we know it’s right.” That one you have to build deliberately, stronger than before.

High Output is brought to you by Maestro AI. High Output is brought to you by Maestro AI. Muddassar described leaders running two workforces at once — the humans and the agents — and being able to se neither clearly. The agents are the newer blind spot. Teams are all-in on AI with almost no view into how it’s actually being used: what’s working, what’s wasted effort, and which engineers have learned to direct an agent well.

Maestro plugs into Claude Code and Codex and gives you that view. The point isn’t to grade your engineers — it’s to help every one of them get better at directing AI. We see what your strongest AI users actually do differently and turn it into patterns the rest of the team can learn from, so every engineer on your team can master AI.

Your team adopted AI. Maestro helps you see how it’s really going — and helps every engineer learn to direct an agent well.

“God, I don’t fucking know.”

She apologized, then doubled back. “Sorry. Excuse me. You do need them. They’re not hard to find.”

That answer is the whole interview in miniature. How a junior breaks into engineering today, Charity will tell you, is genuinely unresolved. None of the paths that worked for her exist anymore. How an engineering org builds a healthy pipeline, on the other hand, is not particularly hard. The two questions sit next to each other, and she refused to collapse them into a tidy answer.

Charity is the co-founder and CTO of Honeycomb, twenty years into the industry, two O’Reilly books behind her and the second edition of one in progress. Her career has been built on distributed systems — production engineering at Parse, then Linden Lab, then founding an observability company. But most of what she said over the next half hour was about people, and she came back to one idea four or five times: engineering teams are not social systems and they are not technical systems. They’re sociotechnical systems, and the way you reason about one shapes the way you have to reason about the other.

Idaho

Charity grew up in the backwoods of Idaho. No computers, no phone line for most of her childhood. She got to college on a classical piano scholarship and noticed something there. “People who studied music were still hanging out working minimum-wage jobs in their thirties, forties, and fifties. And I was like, I grew up being poor. I am not going to be a poor adult. And so I switched lanes.”

She got into tech in the late nineties. “Any smart kid who is willing to work weird hours and try a lot of stuff could make a go of it.” She doesn’t romanticize that. Tech was a toy then, she said, and now powers nuclear power plants, so the bar going up is correct. But twenty years on, she’s worried about what’s happened to the door behind her. “I think we really risk it becoming the sort of ivory tower where we keep out anyone who has a non-traditional background. You need to think harder about crafting paths into technology to meet the moment.”

I asked how she got into management. “I was a reluctant manager.” She drew a line between management and leadership before I could follow up. These are sociotechnical systems, she said, “they’re not social or technical, or we could just take the great managers from Starbucks and put them in charge of engineering teams.” The reason she ended up doing the job at all was anger. “I got into people management the same way a lot of people do, which was enraged, because I didn’t like the way it was being done. And I was like, *god damn it, I guess I will do it differently. I will not make any of these mistakes.* So I made different mistakes, of course.”

The self-correction is constant in conversation with her. She said something close to it three more times over the next half hour.

The freeze

When I brought up the AI-killing-the-junior-pipeline discourse, she pointed to something specific. She’d just read a piece by Annie Lowrey in the Atlantic that morning. The Job Market Is Hell. Unemployment is around 4.7%, which is historically fine, but nobody is leaving their jobs and nobody is hiring. On both sides of the resume, AI is doing the talking. Recruiters feed inbound applications into screening tools. Candidates feed job listings into chatbots. “The result is there are no people talking to people. Nobody’s figured out how to do this.”

The framing she rejected was the one that treats this as inevitable.

“What I don’t like about the way people talk about bringing juniors into tech is they talk about it like it’s some force of nature that we have no control over, which is absolute horseshit. This is a world we create. It’s a world that we reinforce.”

It’s a sequence of decisions made by people in rooms. And the people most responsible for those decisions, she would argue later, aren’t the ones the org chart suggests.

Make friends with the discomfort

Before she got to the operational claims, she walked me through what she thinks her generation of managers got wrong, because the failure mode shapes everything else.

“My generation swung the other way and was like very rigorous about, *you should have work-life balance. Nobody should be pinging you after hours.*” The intent was correct. She was managing in reaction to the era of people sleeping under their desks. But she watched it overcorrect. “I see some managers being like, *you’re working more than 40 hours, stop.* And honestly, we live in a very complex, fast-changing world, and if you’re intrinsically motivated to be working, if you’re learning, if you’re having fun, nobody should be stopping you, because that really is the path to success.”

She isn’t arguing for the swing back, either. I brought up 996, the Chinese nine-to-nine, six-days-a-week framing that’s been making the rounds on Hacker News. She had nothing nice to say about the swing-back. “It all swings back. It all swings back, doesn’t it?” Then, more bluntly: “That’s bullshit.” She read the cycle as a generational pattern, and she was harder on her own generation than on either pole. “If anyone had told me that, if I had followed that advice, I would not be where I am.”

The piece of this that connects to junior hiring is the part most management writing skips. “You need to learn to make friends with the discomfort. You need to learn to find joy in the pain.” None of us, she said, evolved to handle data structures and algorithms, and the early years of an engineering career are genuinely agonizing. The juniors who make it through are the ones who learn to like the agony. A lot of senior engineers, looking back, have forgotten that they once lived through it.

It’s a humanistic argument, not just an operational one. She talked for a while about school stamping out the curiosity children are born with. Twelve, twenty, twenty-five years of report cards, conditioning us to associate learning with extrinsic reward. What she loves about adulthood is the chance to rediscover the original instinct. Engineering is one of the few careers that pays you for it.

50 to 1

Her first operational claim was about team composition.

“For every staff engineer that you have, let alone principal engineer, you need 50 intermediate engineers.”

The number is a gesture. The shape of the argument is specific. Most companies have over-corrected toward senior hiring on the theory that they’ll get more leverage per dollar. The people who actually ship the bulk of features, she said, aren’t seniors. They’re intermediates. “Some of the most productive engineers that I’ve ever worked with have been intermediate engineers. They can just put on their headphones, beginning of the day, go deep, and just pound out the features and the bug fixes.” Heads down, pattern matching, finishing things. “Nobody who’s been in engineering for seven, ten years wants to do that. They’re sick of that.”

The bored staff engineer is not a leverage win. “When people get bored, you do not get great work out of them. You get the best work out of people when they are working at that place that’s right on the edge of their ability.”

And the supply chain only runs one direction. “Nobody stays a junior engineer for long, two years at most. So you’ve gotta keep feeding the system. You’ve gotta keep bringing new blood in.”

Opening the barn door

I asked what she’d recommend to companies that are paranoid about hiring right now.

“I would advocate for opening the barn door a bit wider, giving more people a shot. Understanding that it means you will have to fire more of them. You will have to let more of them go. But I feel like it’s worse to never give people a shot.”

The second half is the part she emphasized. A wider door costs you in faster, more honest performance management, and most engineering managers are bad at that part. “Nothing demoralizes a team more than when someone that they work with every day, who’s not pulling their weight, just hangs around forever.” The unsalvageable cases weren’t the ones that escalated. They were the ones that drifted. “Some of the most heartbreaking situations I’ve ever been in as a manager are when a person’s being let go after years of them doing exactly the same thing, and they’re legitimately dumbstruck.”

There’s a side benefit she pointed out that I hadn’t considered. Junior engineers audit your systems in a way nobody else can. “If you’re an engineer joining a team where there is very low turnover, where people never join, where people never leave, that is not likely to be a very high functioning team either.” Old docs. Idiosyncratic mental models locked in three people’s heads. A dev environment that takes a month to set up because nobody’s tried in six. “If you’re used to bringing on junior engineers, oh boy, those kids will audit your systems like no one else.”

That’s the sociotechnical argument in plain language. The team isn’t separable from the systems it owns, and the hiring policy isn’t separable from the operational health of the codebase. Both improve together or neither does.

What she watches for in a junior

The most optimistic moment came when I asked what she watches for in her own juniors.

“Some of our junior engineers talk about how they are in conversation with Claude all day long. By the time they bring a question to their senior engineer, which they do very often, they have tried all the low-hanging fruit, they’ve tried a bunch of stuff, they’ve asked a lot of questions. So it is very well worth that senior engineer’s time.”

That’s not the threatened-junior story most engineering leaders are telling right now. The juniors she described are using the model to exhaust the obvious before they ask, and arriving at the senior with the harder version of the question.

I asked what the leading indicator is for a junior who’s going to make it.

“Are they asking good questions? Are their questions getting better? Do they have a good sense of how to use their time and how to use their mentor’s time? That is the best leading indicator.”

Not output. Not commit volume. Question quality, over time. She added, almost in passing, that her management chain handles the day-to-day evaluation. “I really trust Emily and all of them.” The broader discipline she described combines two things engineers tend to mistrust: the data, and the conversations. “It’s actually really important that there be data in addition to conversations, because the data and the conversations are bookends. They help you understand each other.” Lean on either alone, she said, and you get either a “people manager” with no technical judgment, or a manager who reads PR counts as a personality assessment. Both fail in different ways.

Consent of the governed

Near the end, I asked who she thought was actually responsible for fixing the junior pipeline. The pattern she described is counterintuitive.

“The places that I know of that actually are successfully recruiting, hiring, bringing in junior engineers, and making them successful, it was *not* the engineering managers who pushed for that program. It was the senior engineers. They were the ones who were like: *we know what it takes to have a healthy, high-performing team. It takes a steady influx of new blood, and we feel this conviction so strongly that we’re gonna go make it happen ourselves.*”

The senior ICs went to bat. The managers ran the mechanics afterward. Then the line that anchored the whole conversation:

“There is no engineering leadership without the consent of the governed.”

Charity has been an executive long enough to watch a lot of decisions get made about engineers, by engineers, with or around engineering management’s input. “If there’s anything that I have learned being in senior management, it’s how much power individual ICs have when they choose to flex it.”

I asked whether she meant it literally. Were the senior ICs really the deciding force? She walked through the pattern again. The companies hiring juniors successfully are the ones where the senior engineers made it their problem. The ones not hiring are the ones where they didn’t.

I came in expecting a programs-and-processes answer. Recruiting funnels, intern conversions, the mechanics of a pipeline. What I got back was about consent. The senior ICs in your org, the ones who don’t have manager in their title but have weight in every staffing conversation, are the people who decide whether the next generation gets in. Without their buy-in, no pipeline exists. With it, almost any pipeline works.

The feedback loop of feedback loops

I asked at the end what she’s working on now. She’s writing the second edition of *Observability Engineering*, and she was honest about how it’s going. “It’s not going super great.” She read the first edition recently and found it embarrassing, which is not how most authors I’ve talked to describe their own work. “But now I think my co-authors and I, we know who we’re writing for and we know what they need to hear.”

Then she connected the book to the show in a way I wasn’t expecting.

“It’s a true fact reality that high-performing engineering teams are about fast feedback loops, and observability is the feedback loop of feedback loops. It is the sense-making apparatus of engineering teams.”

That landed for me. A lot of what she’d argued for over the prior half hour started looking like a feedback-loop argument. Open the barn door, but tighten the loop on managing out, so performance information moves fast. Watch question quality, because it’s a faster signal than output. Bring juniors in, because they shorten the loop on every undocumented assumption your team has accumulated. The senior ICs are the deciding force because they’re the only people positioned to keep all those loops short.

A team is a sociotechnical system. The systems that team owns are sociotechnical systems too. The discipline of running both well is the same: short feedback, an honest signal, and the willingness to look at uncomfortable data.

Charity’s question, the one I’ve been sitting with since we hung up: in your engineering org, who is actually deciding whether the next generation gets in?

High Output is brought to you by Maestro AI. The thing Charity said that stuck with me most was about leading indicators. The junior worth investing in isn’t the one shipping the most code. It’s the one whose questions are getting better. The juniors using Claude well at Honeycomb are showing up to their senior engineers having already exhausted the obvious. That’s a different trajectory than the one most dashboards see.

PR counts and cycle time can’t pick that distinction up. The work that builds judgment, or fails to, happens in the back-and-forth between an engineer and an AI agent, before any PR is opened. Your Anthropic bill tells you something is happening. Maestro tells you what.

Maestro plugs into Claude Code and Cursor and looks at the work itself: how engineers scope a problem before they prompt, what they verify, what they accept on faith. Scored against shipped outcomes, not vibes. You can see which engineers are leveling up and which are accumulating comprehension debt.

Visit https://getmaestro.ai to see how we help engineering leaders spot which engineers are developing real AI craft, and which are just generating more output.

Then they added AI. And for the first time, they were shipping something they couldn’t fully control.

The feeling that built a company

“Every single interaction needs to be below 100 milliseconds, because this is when you feel that things are instantaneous,” Loic says. The number didn’t come from a product spec. It came from game design. Rahul Vohra, Superhuman’s CEO, studied how games create the feeling of flow, and bet that people hate email because of how email works, not because email is email.

The architecture follows from that constraint. Superhuman assumes the network will slow you down, so they build as if the network isn’t there — local-first, syncing in the background, optimistic UI throughout. “You need to build without a backend. How do you do that across multiple devices and make it crazy fast?”

People pay $40 a month for email and feel it’s worth it. Their users — mostly executives and salespeople who average three hours a day in their inboxes — describe the experience the way people describe good tools: the software stops mattering and the work takes over.

How taste becomes infrastructure

Loic joined at the beginning of 2025 as an outsider. “I came in with genuine curiosity. I was blown away.” What surprised him wasn’t the rule but how thoroughly it had been internalized. “Even a backend engineer will think about the latency of their API and how this will reflect in the experience.” In most engineering organizations, backend engineers think about correctness and throughput. At Superhuman, they think about how the user will feel.

It starts in hiring — product sense is a criterion for every role, not just product and design. The finance team applies the same scrutiny to the email a customer gets when they’re being told what they owe as the product team applies to the inbox. The offer letter is a product experience. “The offer is a ceremony. It’s not transactional — it’s already an experience.” Candidates who got that treatment show up acting like it.

Rahul reviews everything going into production. “Within the organization, this is building a muscle in every single engineer, designer, product manager — everyone knows the bond is that high.” You can’t work at Superhuman long without developing an eye for when something feels off — a slightly slow animation, a misaligned pixel, an API call that’s a few milliseconds slower than it ought to be.

Loic calls it sensation transference. Packaging changes how you experience the product inside. They take that idea seriously enough that the bill you get from the finance team is treated like part of the product.

The part they can’t control

For ten years, everything in Superhuman’s stack was deterministic. Same input, same output. That’s what made the 100ms promise keepable: you could engineer to it, measure it, hold it.

AI broke that.

“The consistency we were used to is not there anymore,” Loic says. “We all face the surprising change of behavior of a model that is technically not changing its version.” A model API doesn’t update its version number, but its outputs shift. The same query returns different results this week than last week.

For most products, this is annoying. For Superhuman, it’s a more serious problem, because their users aren’t tolerant of inconsistency. “We are similar to Apple in the sense that people expect the best. They pay a bunch, so they always expect the best.”

The specific problem is what happens when AI meets user-generated input. Superhuman can engineer every designed interaction. They cannot engineer how users phrase search queries. “We were controlling every single part of the interaction — feels fast, feels right, feels correct — and all of a sudden, the outcome of the search box is not what I was looking for. Garbage in, garbage out. But how do you control the garbage in?”

There’s no bug to fix and no perf target to chase. The product was built on consistency, and now consistency is the thing they can’t fully promise.

What the numbers don’t say

Superhuman’s AI adoption numbers look good: 90% of engineers using AI daily, 70% of PRs AI-augmented, 90% of those interactions net positive, some engineers claiming 40% velocity gains.

Loic is careful about how he explains this. The numbers work partly because of who their engineers are. “We have a very senior team — over-optimized on seniority. Those people tend to use AI with care. They know the outcome they want, and they just use AI to get faster to that outcome.”

The 40% gains aren’t coming from code generation. They’re coming from everything before the code. “Coming into a new codebase, trying to understand what this library is doing — before, you had to find the entry point, map the dependencies, build your own mental model. Now Claude Code does that so much faster.” The win is in comprehension and orientation, not typing speed.

But the same playbook doesn’t transfer automatically. “If you have a lot of junior engineers, vibe coding’s impact on code quality might be real. It’s not a problem for us — it’s not part of our DNA.” Taste filters the output. Senior engineers with strong judgment about what “right” looks like can catch what the model gets wrong. Engineers without that judgment can’t.

Teams celebrating big AI velocity gains may be doing so because they have enough experienced judgment to catch the mistakes. Teams where most of the engineers are still building that judgment may be accumulating comprehension debt they don’t know about yet.

The acquisition test

The Grammarly acquisition tests the same question at a different scale: can Superhuman’s taste survive contact with mass distribution?

Grammarly has the opposite profile. They’re embedded in Google Docs, Word, email clients, browsers. They have AI capabilities built over years of NLP work. What they’ve optimized for is breadth: supporting every kind of user, every context. Superhuman has been doing the opposite, going deep on one persona and refusing to compromise.

Loic frames the challenge clearly: “How do we make Superhuman not this niche, very fancy application, but something brought to the mass — while keeping our identity?” He reaches for Apple as the reference point. “Learning from Grammarly’s scale and AI capabilities, keeping our culture and taste, and bringing that to the mass — that would be really interesting.”

It’s a genuinely hard problem. Making things simple is hard. Linear built something delightful for small engineering teams, then got successful, then came the bigger companies, the feature requests, the complexity. The focus that made it work is what success makes hardest to maintain.

What this means for you

Superhuman is hitting a wall any product with a quality bar will hit. Three things their experience suggests are worth borrowing.

Make your implicit promises explicit. Superhuman’s was 100ms and determinism — they had ten years of architecture built around it before AI made determinism optional. Most teams have a similar promise they’ve never said out loud: accuracy, consistency, availability, something. Find yours before the model finds it for you, because you can’t defend a contract you haven’t named.

Treat the prompt box as a UX surface, not a backend problem. The moment that surprised Loic wasn’t a model bug — it was the search box. Users phrase queries badly. Prompts are now part of the interface the user sees, and “garbage in, garbage out” is no longer an engineering excuse. Better prompts and evals matter, but if the search box returns the wrong thing, the design team owns that, not the ML team.

Don’t credit the tools for what your senior engineers are doing. Superhuman’s 40% velocity gains work because the people using AI know what right looks like and catch what the model gets wrong. If your team is junior, the same playbook will produce comprehension debt instead of speed. Once you can’t tell the tool’s contribution from the engineer’s, you’re not measuring AI productivity. You’re measuring how much taste you happened to hire.

Loic spent time before tech in contexts where craft standards weren’t optional and the feedback was immediate — a French Navy vessel that had to be back at sea in six weeks, no extensions. The discipline from that kind of constraint is different from the kind you get from a style guide. You learn it because you have no choice, and then it doesn’t really leave. He thinks that’s what Superhuman has built. He’s been there less than a year. Whether the taste travels at Grammarly scale is the thing he’s actually being paid to find out.

High Output is brought to you by Maestro AI. Loic’s AI numbers look good — 90% daily adoption, 40% velocity gains — but he’s the first to say the metrics don’t explain themselves. They work because his senior engineers have the judgment to catch what the model gets wrong. Most engineering leaders have no way to see that layer. You can see PR counts and cycle time. You can’t see whether your engineers are using AI well or just generating output faster. Maestro’s daily briefings reveal where your team’s time and energy actually go — not just what shipped, but the quality of the judgment behind it.

Visit https://getmaestro.ai to see how we help engineering leaders understand what their AI adoption numbers actually mean.

Steve Yegge has been VP or head of engineering at four companies. He keeps stepping down on purpose.

Not because things went wrong — his organizations were doing well. He’s the kind of leader whose reputation travels through a company; at Amazon, at Google, engineers lined up to transfer onto his teams. He stepped down each time because he noticed the same thing: the moment he stopped being able to code alongside his engineers, conversations started requiring translation. Once you’re in translation mode, Yegge figured out, you’re not leading anymore. You’re triangulating toward an answer you don’t fully understand.

In the AI era, he thinks this problem just got much more expensive.

The translation layer

When Yegge handed over the engineering org at Sourcegraph — his fourth deliberate step-down in a career that spans Amazon, Google, and Grab — he gave a specific reason. “I was going through a translation layer with my engineers where they’d be like, ‘Well, you see the AI does this, and then I do that, and then the AI does that, and then there’s a gateway’ — and I’m like, what?”

It wasn’t that he didn’t trust his engineers. It was that he’d lost the ability to sense-check them. And he’d noticed what happened to leaders who stayed in that position too long: “That’s a technique that non-technical leaders use. People who’ve lost their technical chops, they can still be effective leaders, but they have to be very good at triangulating, almost like a GPS on the right answer by going to different technical people and getting it.”

Triangulation is better than nothing. But it’s slow, and it requires your engineers to speak in executive-friendly summaries, which means you’re always one abstraction layer removed from what’s actually happening.

Yegge’s response has been consistent across his career: hand the org to someone ready to take it, go back to IC, get his hands back in the code. At Sourcegraph that meant 18 months as an individual contributor during the period when AI coding changed the most — which is exactly when he made the predictions that got Anthropic’s attention.

His observation about himself is worth sitting with: his most accurate forecasts came during IC phases, not executive phases. Proximity to the work makes the signal cleaner.

The “Otherwise” has arrived

The case for technical proximity isn’t just philosophical anymore. Yegge has data.

Andrew Glover, Director of Productivity at OpenAI, shared findings with Yegge and his co-author Gene Kim: at OpenAI itself, engineers who adopted Codex — their fully agentic CLI coding tool — are producing pull requests that, even accounting for higher rejection rates, “dwarf the contributions of the people who aren’t doing agentic coding by an order of magnitude. Ten times as many commits.”

The interesting part isn’t the 10x number. It’s where the 10x is and isn’t happening.

“The ones who are successful with agentic coding were the ones living in the microservices world, where there’s lots of small, well-factored bits of software. The ones who are struggling are the folks in ChatGPT Land, which is one of the world’s largest monoliths.”

For a decade, engineers warned that monolithic codebases would become a liability — every warning came with an implicit otherwise at the end: refactor now, or else. But the or-else never arrived. You could run with a monolith indefinitely; deployment was easier, QA was simpler, everything just “floated off and got deployed somewhere.” The warning was technically correct but operationally optional.

“You didn’t refactor it. And so what we’re faced with right now is this rat race where first of all, everyone who’s already in microservices land is just being pigs. They can use all the tokens they want. AI is working for them beautifully. The ones with monoliths — and you just point at any company and they have a monolith — it is time to break them up.”

The otherwise, he says, has finally arrived. A 2025 METR study found that experienced developers were 19% slower when using AI tools on large, real-world repositories — the kind of environments where monoliths live.

What Bezos actually understood about services

Yegge built some of the original infrastructure that justified Amazon’s service-oriented architecture, so he has a view on why Bezos pushed it so hard in the early 2000s that most people don’t know about.

It wasn’t primarily an engineering decision. “I heard this later from a colleague at Amazon. Jeff had come from D.E. Shaw on Wall Street, and D.E. Shaw is a company that buys companies and breaks them up and sells the pieces off for a huge profit. He was worried that Amazon was gonna die because of the dot-com bust. And so what he wanted to do, as a last resort, was I’m gonna bust Amazon up and sell the pieces. Which means every one of them has to have a service interface.”

An exit strategy for a dying company accidentally created the architecture for a trillion-dollar one.

Bezos wasn’t playing chess when everyone else was playing checkers — he was scared. The mandate came from a Wall Street M&A playbook, not a software architecture philosophy. Modular design was a byproduct of an exit strategy. The companies that invested in microservices over the past decade for code organization reasons are now discovering they got AI compatibility for free. The companies that didn’t are discovering the bill is coming due.

The “Dial”

Yegge has a name for the decision every engineering leader is quietly making right now: the Dial.

“Every company has been given a dial that goes from zero to a hundred, and it is the number of engineers that you’re gonna fire in order to pay for the rest of them to have AI.”

He’s not being glib. If a subset of your engineers can produce 10x the output with agentic tooling, and those tools require meaningful investment in compute and licensing, the question of headcount allocation is already embedded in your budget decisions. You’re turning the dial whether you’re thinking about it explicitly or not.

Most companies aren’t thinking about it explicitly. Yegge thinks that’s a mistake. “Once you finally figure out how coding is done today — with Codex, with Claude Code, with Sourcegraph Amp — you switched into that world. You are playing in the big leagues and everyone else is falling behind.”

The dial isn’t just about AI spending. It’s about what you believe your engineers will be doing in 18 months.

Writing code is for agents

Which brings Yegge to his single most concrete piece of advice: stop spending your energy on writing code. Start spending it on reading code.

“You’re gonna be generating 10 to 100 times as much code as you ever did before, and you’re gonna need to read it at some point because you need to own it.” , VP of Engineering at Google Chrome, calls the alternative “comprehension debt” — the accumulation of plausible-looking code you’ve approved without truly understanding, a debt that comes due when something breaks at 2am and you can’t trace why.

The shift is real and immediate. Yegge has already made it. He describes his current workflow as watching his agents code — actually sitting there, following the diffs, paying attention to what they produce — rather than writing much himself. “Turn off permission checks so you don’t have to hit enter all the time and just watch it. Watch it code. Pay attention to the diffs.”

The skill of reading code fast and evaluating it accurately — is this correct? Does this make sense architecturally? Would I defend this in a code review? — is what separates a developer who’s a good director of agents from one who’s just vibe coding at scale and hoping for the best.

Yegge’s analogy: a musician who practices sight reading every day for 10 minutes compounds that skill faster than someone who only practices composition. The reading muscle and the writing muscle are different. For most developers, the writing muscle is heavily developed and the reading muscle isn’t, because historically writing was the job. That’s the ratio that’s inverting.

What this means to you

If you’re a leader who has drifted from direct technical work, the cost of that drift just increased. AI coding is changing fast enough that managing by summary will leave you making decisions you don’t understand. You don’t need to write the code — but you need to be able to read the diffs.

Ask whether your codebase is AI-ready. Not “are we using AI tools?” but “can an agent work effectively in our codebase?” The answer is mostly a function of modularity. If your engineers are struggling to adopt agentic coding, the problem is probably architectural, not motivational.

Have an explicit conversation with your leadership team about how AI changes the headcount math. Not as a cost-cutting exercise, but as a forcing function for getting clarity on what you believe your engineering team will look like in two years. Leaving this implicit means it gets decided by budget pressure instead.

And if you’re an engineer: watch your agent work. Follow the diffs. Treat it like sight reading practice. The engineers who can evaluate agent output quickly — who own what the agent ships — will be the ones who remain indispensable as the generation overhead approaches zero.

High Output is brought to you by Maestro AI. Steve Yegge talked about the “translation layer” that forms when leaders drift from the code — but there’s a deeper version of that problem right now. Every engineering leader knows AI adoption is happening. What they can’t see is whether it’s working. Token counts and PR velocity tell you who’s generating more. They don’t tell you who’s actually using AI well.

Maestro analyzes the AI sessions themselves, scoring how effectively each engineer is working with their tools — so you can see who’s genuinely leveling up and who’s just generating noise. Visit https://getmaestro.ai to see how we help engineering leaders measure AI effectiveness, not just AI activity.

How are you thinking about the difference between AI adoption and AI effectiveness on your team? We’d love to hear your story. Schedule a chat with our team → https://cal.com/team/maestro-ai/chat-with-maestro

There’s already been a lot written about how the moats around software are deteriorating. Here’s my take on it, with a specific case study on Granola (the meeting note app). It turns out that you can build something functionally similar over a weekend, but Granola still has some interesting moats.

A while ago, I was talking to Collin Stewart about meeting note software, and the discussion turned to Granola. I like Granola quite a bit, and thought that they might have a bit more of a moat than other in-meeting meeting apps like Fireflies. After all, you need to run a local app that records audio. It’s at least more technically challenging than hooking up to a meeting app API like Recall.ai. Collin challenged me and said that you could probably vibe code something similar very quickly... so I tried it. And now I have my own app that I use daily after about a weekend’s worth of work.

Some notes on the implementation: I did the project entirely with Claude Code. And for fun, I decided to have Claude write the majority of the code in Rust, a language I have never worked with before. I started by writing out a spec for what I wanted: a Mac application that records local audio (both output and input) to a file, then runs that output through a local transcription service, and then sends the transcript into Anthropic or OpenAI to get transcribed. After the spec, I had Claude create a detailed implementation plan, which I reviewed. And then I hit go.

Fast forward a couple of days, and the app was ready for use. The workflow is simple: you hit record at the start of a meeting, and it starts recording locally. Then, after the meeting, you hit Stop and it transcribes the meeting audio using an on-device model, so the audio never leaves your machine. Then, if you desire, you can optionally generate notes by pressing a button. The meeting notes prompt is saved and editable so you can tweak everything until you’re satisfied with the note output. The transcript and notes are all written to a local folder for storage, and you can set up automations to send the notes to cloud services.

This app has worked so well for me that I usually use it instead of alternatives at this point. It’s simple, doesn’t consume many system resources, and also doesn’t send my audio to the cloud to transcribe.

Does this mean that Granola is dead? Are there no moats anymore? I don’t think that’s true. Here are some of the reasons why it’d be hard to just package up my app today and capture Granola’s market share:

1. Transforming a prototype into a tested, general product is hard. There are a lot of edge cases that I haven’t covered with my application. My application is Mac specific, for example. The model I selected works well for English, and I haven’t tested it for other languages. The UI isn’t fully polished yet; it’s good enough for me but I could see people wanting something more snazzy. In order to address all of the edge cases and other permutations of the problem, I’d need to spend a substantial amount of time to iron things out.

2. Distribution is king, and building a brand is difficult. Even if you were able to make a great application, you still need people to know that it exists. Building a brand is really hard, and Granola has a great one. Most of the founders and VCs that I talk to have at least heard of Granola. It’s incredibly difficult to break through in this market, because there are tons of meeting notes apps in the market. If you’re shipping this from scratch, do you have the right messaging, and can you get your app in front of the right people?

3. Support is a real moat. B2B is looking more and more like consumer. If you want people to stick around, customer support is essential. Do you want to file a bug against an open source project and hope that someone responds, or do you want to contact support and get a solution immediately? Companies are going to be built on their customer experience: support and fast turnaround times will be moats.

4. And finally, technical moats still exist. If this were a slightly more tricky technical project, or if I didn’t have enough domain expertise, this project would not have gone well. For example, coding models don’t always work well with specific technologies, such as with functional languages.
   There are also cases where you need very novel technical approaches to solve a problem, and it’s not immediately apparent what those approaches should be. As an example, Figma had a problem around speed and latency: they needed to make a web experience feel fas fast as a native one. Their solution was to go all in with WebAssembly, and they did that at a time when WebAssembly was not very widely used. If Claude Code or Cursor were around at that time, there’s no way way they would have picked WebAssembly as the right approach.

So Granola is still safe, at least for today. Even as coding agents continue to improve, there are still some interesting moats for businesses.

What do you think? What other moats do companies have in this new era?

By the way, if you’re interested in the actual development process of this app and the gotchas involved, part 2 is coming soon.

has come to believe the opposite. Get the principles right, and the process can flex.

Gaurav is VP of Engineering at Confluent, where he runs their Security Products and Cloud Platform powering their cloud-native data streaming ecosystem. He joined when the business was sub-$100 million; today it’s $1.1 billion. Before Confluent, he spent seven years at Box and six years at Microsoft. And before any of that, he started his career at a 15-person startup in India — “Didn’t know what we were doing, but it was fun.”

Across all of those environments—from a scrappy team of 15 to a billion-dollar enterprise—one pattern has held: the organizations that thrive are rigid about their principles and flexible about everything else. The ones that struggle have it backwards.

The Agile Dogma Aha Moment

Gaurav has a specific story about when this clicked. Early in his career, he was a believer in classical agile—sprints, scrums, the full playbook. He thought it was the way to run engineering projects.

Then he hired a leader who was completely aligned on the principles: execution pays the bills, work needs visibility and traceability, quality gates matter. But the process? Different.

“Look, I don’t necessarily care about the book process, whether you call it agile or you call it scrum or something else. I would love to have the agency to ensure I manage and track my work. My engineers feel like they’re actually doing the best work of their life and there is quality gate and accountability.”

Gaurav calls this a strong aha moment. “I realized I was being unnecessarily dogmatic in my approach. And actually this additional way of doing it opened up so many gates.”

The lesson wasn’t that agile is bad. It was that confusing a specific process with the underlying principle is a trap. The principle—visible, accountable, high-quality execution—can be achieved multiple ways. Insisting on one process locks out people who could deliver the same outcomes through a different path. It closes doors you didn’t know existed.

The constraint is real, though. “You don’t wanna have 30 teams have 30 different innovative ways.” There’s a phase where letting a thousand flowers bloom is the right move, and there’s a point where you need to converge on five or six archetypes. The art is knowing when you’re in which phase.

Culture Add Over Culture Fit

The same logic applies to hiring. Early in his career, Gaurav screened for culture fit—people who matched the team’s existing style. Over time, he realized this was the same mistake as the agile dogma, applied to people instead of methodology.

“It’s actually a bad idea to have a very closed door—only follow this culture and nothing else.”

When you hire exclusively for fit, you get a team that reinforces its own assumptions. The same instincts. The same blind spots. The culture calcifies instead of evolving.

His alternative: hire for culture add. Find people who share your principles and values, but bring their own approaches and experiences. “New people join in, people grow in their roles, people from different companies and backgrounds and experiences come together—the beauty is that an evolving culture being held strong on the principles of the company actually makes it a success story.”

The distinction is subtle but important: principles are fixed, culture is not. Values are the foundation. Everything built on top should be allowed to shift.

Share the Why, Trust the How

Gaurav applies the same framework to day-to-day management, and he sums it up bluntly: “The fundamental principle is to treat people like adults and they will behave like adults.”

In practice, that means sharing context aggressively—where the business is going, how decisions get made, what the company needs right now—and then stepping back. “Enable them, let them have that agency to make those micro decisions as much as possible.”

He’s not flexible about everything. Collaboration, one-team attitude, flat hierarchy, open communication—these are non-negotiable. “There are certain principles which I’m actually not ready to compromise on.”

But beyond those fixed points, he lets leaders find their own style. “Ultimately what every strong individual or leader wants is to be held accountable for the outcomes and the results they deliver. And nobody likes to be micromanaged on how they get there.”

Rigid on values. Flexible on methods. The same pattern, applied to management instead of hiring or methodology.

The SDLC Tree

Where this gets most interesting is how Gaurav applies the framework to AI adoption. His approach is different from the typical “push coding copilots” playbook—and the principle underneath it is the same one driving everything else.

The principle: engineers should spend their time on high-value, creative work. The process for achieving that? That’s what changes.

Gaurav looks at the entire software development lifecycle as a tree of workflows and targets the branches no engineer enjoys. “Especially as a cloud infrastructure company, there is a ton of work in operating, managing, keeping your infrastructure secure, scaling the business. There are a lot of things that AI can generally do well.”

Confluent handles security patches and vulnerability management across three clouds and roughly a hundred regions. Infrastructure gets set up, tested, and torn down constantly. These are the branches AI is taking over completely—with engineers administering and managing rather than doing the work by hand.

“Engineers actually love to do the innovation. They love to do the new problem solving. They love to have that ability to write new code in a way they feel is appropriate.”

His conclusion follows directly: “I would love my engineers to actually have that mental space to invest their time in that high value work and let all the undifferentiated work be taken over completely by AI.”

This is a fundamentally different framing from “AI makes engineers faster.” It’s not about speed. It’s about expanding what engineering teams can accomplish. “The pie is getting bigger. We gotta look at AI as a way to expand the pie of work that an engineer can do, not necessarily just what they were doing last year.”

He invokes Jevons’ paradox—the idea that when something becomes more efficient, total consumption increases rather than decreases. Because it’s easier to build, more will get built. More demand, more opportunity, more roles. And his take on whether AI threatens engineering jobs is unequivocal: “Every role, every job category is going to change because of AI.” But change isn’t elimination. It’s the same transition the industry went through when cloud replaced data center ops. The people who understood first principles learned the new layer and kept going.

The Fundamentals Don’t Change

This is the thread that ties everything together. Principles endure. Process shifts.

When Gaurav joined Microsoft, people questioned whether he was a real engineer because he didn’t write device drivers. “The previous generation did something at a lot lower level, and then the next generation is doing something at a different layer. That’s always been happening for decades.”

But through those decades of transformation, the fundamentals haven’t changed. Understanding operating systems, databases, memory management—”the fundamental understanding of these core principles is what allows a great engineer to learn and pick up new things.”

His advice to new graduates is the same advice he’d have given five years ago: focus on the fundamentals. “Learning new things has become easier. Building and experimenting has become a lot easier than before. If people can really spend time understanding the core fundamental building blocks of computer science, applying them to learn and build new things is actually gonna be easier going ahead.”

The career lesson mirrors the organizational one. The engineers who thrive across generational shifts are the ones grounded in principles, not attached to any particular layer or tool. The organizations that scale from startup to $1.1 billion are the ones that hold their values tight and let everything else evolve. The leaders who get the most from AI are the ones who know which work matters and which work is just process.

Same pattern. Every level.

What This Means for You

First, separate your principles from your processes. Gaurav’s agile aha moment came when he realized he was treating a specific methodology as a principle. Identify which of your team’s practices are genuinely non-negotiable values and which are just comfortable habits dressed up as requirements.

Second, audit your hiring for culture fit vs. culture add. Are you screening for people who share your principles, or people who share your habits? The first builds a team that evolves. The second builds one that calcifies.

Third, when deploying AI, map your SDLC and target the work nobody wants. Instead of asking “how do we code faster,” ask “which branches of our workflow tree drain engineers without engaging them?” Security patches, infrastructure provisioning, repetitive operations—these are the high-ROI AI targets that also free engineers to do the work that drew them to the field.

Fourth, give context instead of instructions. If you want people to make good micro-decisions without being micromanaged, they need the same information you have. Share the why and how you measure the what—then trust them to figure out the how.

The question worth asking your team: Are the things you’re rigid about actually principles—or are they processes you’ve held onto so long they just feel like principles?

High Output is brought to you by Maestro AI. Gaurav talked about giving teams the room to deliver their own way. But when you stop prescribing process, you lose the visibility that process used to provide. You’re no longer watching how the work happens—so you need a way to see whether the work is landing. That’s what Maestro does. Maestro is engineering intelligence for AI-first teams: AI-powered analysis that measures the true impact of your team’s work, from code changes to review quality to team health. Stop flying blind. Start leading with signal.

Visit https://getmaestro.ai to learn more.

Building a team where autonomy and accountability coexist? We’d love to hear how. Schedule a chat with our team → https://getmaestro.ai/book

In 1982, Tom DeMarco wrote what became one of the field’s most quoted maxims: “You can’t control what you can’t measure.” Twenty-seven years later, he retracted it. Was the advice correct at the time? Is it still relevant? Do you still believe metrics are a must for successful software development?

“My answers are no, no, and no,” he wrote in IEEE Software. The statement, he admitted, may have “distracted us from the real point of computing.”

The pattern since then is striking: each generation of metrics gets critiqued by its own creators. Lines of code, function points, story points, velocity—all were reasonable responses to the previous approach’s failures, and all eventually revealed the same fundamental problem. We keep measuring what’s easy to count rather than what actually matters.

And now AI has arrived—both accelerating the crisis and, paradoxically, offering the first realistic path through it.

A brief history of counting code

IBM and other mainframe-era organizations measured lines of code (LOC). Barry Boehm’s COCOMO model (1981) formalized this by correlating development effort with source lines. The problems became apparent almost immediately. Capers Jones (1986) documented that LOC metrics “make requirements and design invisible” and “penalize high-level languages.” He eventually declared that using LOC for productivity measurement “should be regarded as professional malpractice.”

Allan Albrecht’s function point analysis (1979) attempted to fix this by measuring user-visible functionality rather than implementation. It was a genuine conceptual advance—but Albrecht himself observed that function points remained “highly correlated to lines of code.”

The Agile movement brought story points and velocity. Kent Beck introduced stories as “an antidote to requirements”—deliberately abstract units meant to facilitate conversation, not enable measurement. Ron Jeffries (2019), one of XP’s founders and a probable inventor of story points, now expresses regret: “I may have invented story points, and if I did, I’m sorry now.”

The most sophisticated recent framework is DORA, developed by Nicole Forsgren, Jez Humble, and Gene Kim. Their four metrics—deployment frequency, lead time, change failure rate, and mean time to recovery—emerged from rigorous statistical analysis across thousands of organizations. DORA represents a genuine advance: it measures delivery capability rather than activity volume. But Forsgren herself warns against misuse. DORA measures system flow, not individual productivity—one slice of engineering work that says nothing about what commits actually accomplish for users.

Why this problem is genuinely hard

Three fundamental challenges explain why measurement keeps failing.

The output is non-fungible. A 10-line fix to an authentication vulnerability isn’t “less” than a 500-line UI component—it might be worth considerably more. Fred Brooks identified this in The Mythical Man-Month (1975): the best programmers can be 5-10x more productive than mediocre ones, a variation that simple metrics cannot capture.

Context dominates. Deleting 5,000 lines of technical debt might be the most valuable work done all quarter, but it shows up as negative “productivity” in any volume-based metric. A one-line change to a critical system might require days of careful analysis, while a thousand lines of generated boilerplate takes minutes.

Gaming is trivially easy. Anthropologist Marilyn Strathern simplified Goodhart’s Law to its canonical form: “When a measure becomes a target, it ceases to be a good measure.” Software metrics are particularly vulnerable because the relationship between metric and goal is so loose. Write more code, split work into smaller tickets, inflate estimates, approve pull requests faster—the numbers go up while actual value stays flat.

Robert Austin’s Carnegie Mellon dissertation, Measuring and Managing Performance in Organizations (1996), proved mathematically that measurement-based management becomes dysfunctional when not all critical dimensions are measured. When managers can only observe one of two job dimensions, workers rationally shift effort toward the measured dimension at the expense of unmeasured value. DeMarco wrote the foreword, calling it a book that “needs to be on the desk of just about anyone who manages anything.”

What would good measurement require?

Rather than proposing another metric, it’s worth asking what any genuine solution would need.

Understanding semantic change, not syntactic artifacts. Current metrics count what happened (lines changed, PRs merged) without understanding what it meant. A meaningful measure would need to comprehend what actually changed—whether a modification fixed a critical bug, introduced a new capability, or improved maintainability.

Deep context about codebase and architecture. The same diff has different significance in different contexts. A change to a payments module carries different risk than a change to a logging utility.

Distinguishing different forms of value. Engineers create value in many ways: writing code, reviewing others’ code, mentoring, designing systems, debugging production issues. Senior engineers often have outsized impact through review and design work that produces few commits. Traditional metrics make these contributions invisible.

Resistance to gaming. Goodhart’s Law suggests this requires measuring something close to the actual goal—the semantic value of changes—rather than proxies that can be optimized independently.

This describes a very sophisticated judge: one capable of reading code, understanding its context, and making nuanced assessments about value. For most of software engineering’s history, only humans could do this—and humans can’t do it at scale. A VP of Engineering can’t personally read every pull request across a 200-person organization. The information asymmetry between the people doing the work and the people making resource decisions has seemed insurmountable.

AI makes the problem worse

Just as the measurement problem seemed intractable, AI coding assistants arrived—and made everything more complicated.

The productivity gains are real but deeply asymmetric. Microsoft and GitHub’s 2024 field experiment across 4,867 developers found a 26% increase in completed pull requests with Copilot. But the METR randomized controlled trial (July 2025) found AI tools made experienced developers 19% slower on real-world tasks in mature repositories. The most striking finding: developers predicted a 24% speedup beforehand and estimated 20% faster completion afterward—a massive perception gap that persisted despite objective measurement.

The quality picture is troubling. GitClear’s analysis of 211 million changed lines found that code churn—code reverted or updated within two weeks—doubled after AI adoption. Uplevel Data Labs found developers with AI access showed a 41% increase in bug rate. Google’s DORA 2024 report found every 25% increase in AI adoption correlated with a 7.2% drop in system stability.

Here’s the fundamental problem: when a developer can generate 5,000 lines of code in an instant, lines of code stops meaning anything at all. Traditional metrics assumed that code output required human effort. AI breaks that assumption completely. A developer who thoughtfully reviews and refines AI-generated code might produce fewer commits than one who accepts suggestions uncritically. The first is creating more value; the second looks more productive.

AI also opens a path forward

Here’s the irony: the same technology that broke traditional metrics might be the first thing capable of replacing them.

Large language models can read code. They can understand what a diff actually does—whether it fixes a security vulnerability, introduces a new feature, or just adds boilerplate. They can distinguish a 10-line change that prevents a production outage from a 1,000-line change that reorganizes imports. They can do this at scale, across every commit in an organization, continuously.

This isn’t speculative. Google’s AutoCommenter research (2024) demonstrated LLM-backed systems that understand code semantically well enough to identify best-practice violations and provide actionable feedback. The same capability that enables “this code has a potential null pointer exception” also enables “this change fixes a critical bug in the authentication flow.”

But semantic understanding of individual changes is only half the problem. The other half is synthesis: turning thousands of assessments into something leaders can act on.

Traditional metrics cope with overwhelming activity by reducing everything to numbers: 47 PRs merged, 12,000 lines added, velocity up 15%. The numbers are digestible but meaningless. AI enables a different approach: understanding work at the atomic level, then synthesizing it into narrative. Not “the platform team merged 23 PRs” but “the platform team completed the Kubernetes migration and resolved three critical performance bottlenecks.” Not “this engineer’s commit count is down” but “this engineer spent the sprint on architectural review and mentoring, with high-impact contributions across six projects.”

This is what leadership actually needs—not more numbers, but genuine understanding of what their organization is accomplishing.

The limits

This path has real constraints. AI can’t see everything that matters: the conversation that prevented a bad architectural decision, the mentoring that accelerated a junior engineer’s growth, the relationship-building that enabled cross-team collaboration.

And Goodhart’s Law doesn’t disappear just because measurement is more sophisticated. But semantic measurement has an advantage: it’s closer to the actual goal. Gaming lines of code is trivial because lines of code have no intrinsic relationship to value. Gaming a system that evaluates actual significance is harder—you’d have to create actual significance, which is the point.

Where this leaves us

Martin Fowler wrote in 2003 that software productivity “cannot be measured” because output cannot be measured—and even if it could, “true output” is business value delivered, which varies enormously and manifests over years. Kent Beck and Gergely Orosz, responding to McKinsey in 2023, called the consultancy’s measurement framework “absurdly naive” and warned it would “do far more harm than good to organizations.”

I’ve spent years working on this problem, and I don’t have clean answers. But I’ve become convinced of a few things.

Traditional proxy metrics—lines of code, velocity, PR counts—were always flawed. In the age of AI-generated code, they’re actively misleading. They measure what’s easy rather than what matters, they’re trivially gamed, and they corrupt the processes they’re meant to monitor.

Any serious path forward requires understanding what code actually does, not counting artifacts of work. This is a semantic problem, not a syntactic one. And for the first time, we have tools capable of semantic understanding at scale.

The goal isn’t perfect measurement—that’s neither achievable nor necessary. It’s measurement good enough to recognize that a 10-line security fix can be more valuable than 5,000 lines of AI-generated boilerplate. Good enough to make visible the engineers who create value through code review, debugging, and the unglamorous work that keeps systems running. Good enough to give leaders genuine insight into what their organizations are accomplishing, not just how busy they look.

Whether we can build systems that see work clearly—that understand what software actually accomplishes, synthesize detail into insight, and resist the gaming dynamics that have corrupted every previous approach—remains an open question.

That’s the question I’ve spent years working on.

I work on tools in this space at Maestro AI.

But not everyone’s seeing the same results.

Raju Matta runs engineering for Cambridge Mobile Telematics—200+ engineers, three countries, petabytes of real-time sensor data processing driver safety. Six months ago, he formed a tiger team to systematically track AI tool adoption. Status reports every two weeks. Multiple tools tested: Copilot, Cursor, PR review bots.

His finding? “I’ve not seen the measurable velocity increase that people are saying out in the market—but that doesn’t mean I have totally written off LLMs yet.”

This isn’t skepticism. It’s measured evaluation. And the pattern Raju’s seeing reveals something important about when AI tools deliver and when they don’t.

Where AI Tools Excel

As part of their evaluation, CMT ran an internal hackathon to see what AI tools could do in practice. The results told a clear story. Eighteen projects, all using AI. Teams built fully working web apps—complete with datasets—in 2-4 hours.

“For that purpose, it’s great. It’s not bad at all,” he says.

The pattern: AI coding tools work brilliantly for rapid prototyping with established patterns, web development using well-documented frameworks, mechanical coding tasks like boilerplate and test generation, and quick experiments to validate product ideas.

These are real productivity gains. The people claiming 2x-3x aren’t exaggerating—they’re working in contexts where AI capabilities align perfectly with task requirements. When your bottleneck is writing React components or generating CRUD endpoints, AI tools deliver measurable acceleration.

But CMT’s production systems are different.

The Complexity Multiplier

They’re processing petabytes of data from gyroscopes, accelerometers, GPS sensors, video streams. They’re distinguishing potholes from crashes, sharp corners from reckless driving. They’ve been using AI and machine learning for this work for 13 years—long before LLMs became everyone’s productivity obsession.

The engineering challenge isn’t writing code. It’s architecting systems that handle sensor fusion at scale, debugging why clusters fail under load, ensuring accuracy when lives depend on your classifications, and managing tech debt across distributed teams in six countries.

“You can outsource your engineering and coding with AI tools, but not your thinking,” Raju explains.

In complex production systems, the thinking is where the time goes. Code generation helps, but it’s not the bottleneck. The productivity multiplier drops from 3x to “incrementally helpful” because the constraint isn’t in the typing—it’s in the architectural decisions, the system design, the understanding of how everything fits together.

This doesn’t make AI tools useless. They still catch bugs in PRs. They still help prototype solutions. They still accelerate certain tasks. But the overall velocity gain is modest because code generation often isn’t the long pole.

The Tiger Team Approach

Here’s what makes Raju’s perspective valuable: he’s not guessing. Six months ago, CMT’s CTO gathered the engineering leaders. “How are you guys thinking of AI?” The response: treat it like a first-class citizen.

They formed a dedicated tiger team. Three people producing status reports every two weeks on tool adoption, usage patterns, and measurable impact. “We have about three or four tools that we are using all the way from PR review tools to tools like Copilot, Cursor.”

This is systematic evaluation, not anecdotal impressions. And the data shows results that differ from the market narrative: “My general experience is that it’s good, it’s doing its job, but I haven’t seen the measurable velocity increase as much as what people are saying out in the market.”

His peer conversations confirm the pattern isn’t unique to CMT: “Even other leaders and my peers that I speak with, who are working at big tech companies, have said similar things. So it’s not uncommon.”

But Raju’s not dismissing the technology. “The tools are progressing at a very fast pace. I wouldn’t be surprised if it’s another six months or a year where we get to exhaust more pieces of the tool and get more done.”

That “yet” matters. He’s still tracking, still evaluating, still expecting improvement.

When Mistakes Have Consequences

When Raju says “we have to save people’s lives,” he’s not being dramatic. CMT’s technology directly impacts driver safety. Their telematics platform processes sensor data to detect dangerous driving, assess risk, and potentially prevent accidents.

This creates a different bar for “move fast and break things.”

“We are a little bit more diligent because at the end of the day, we have to save people’s lives. So for us, we’d rather spend the time beforehand than reactively trying to address it.”

The stakes are high—both financially and ethically. When your technology directly impacts human safety, you can’t afford to ship fast and fix later.

The constraint isn’t just technical complexity—it’s consequence of failure. “AI tools can take you north, but with the same speed, they can take you south.”

In safety-critical systems, the review time, the testing time, the verification time doesn’t compress even if code generation does. You can’t ship and iterate rapidly when mistakes could harm people. The overall productivity gain shrinks accordingly because the non-coding portions of the development cycle remain unchanged.

This applies beyond telematics. Financial systems. Healthcare platforms. Infrastructure control. Any domain where errors have serious consequences faces the same limitation: AI can accelerate code generation, but it can’t compress the necessary validation and testing cycles.

Where AI Struggles

AI’s limitations show up in unexpected places. CMT uses AI to filter thousands of resumes for each job opening. The results? “50% makes sense. And 50% don’t make sense.”

This split illustrates a broader pattern. AI works brilliantly for well-defined, repeatable tasks. It struggles with judgment calls, context-dependent decisions, and situations requiring nuanced understanding.

The tool saves time on mechanical filtering. But the judgment about who’s actually right for the role? Still human. And critically, the humans can immediately spot when AI recommendations miss the mark—they don’t trust it blindly.

This mirrors the coding experience. AI generates boilerplate quickly. But understanding whether the generated code fits the broader system architecture, handles edge cases properly, and follows team conventions? That requires human judgment that doesn’t compress.

Where This Leaves Engineering Leaders

The mistake isn’t believing AI tools work—they demonstrably do in many contexts. The mistake is assuming your context will see the same gains as someone in a completely different situation.

Raju’s systematic evaluation reveals the variables that matter:

Your problem domain determines gains. Web apps and prototypes with established patterns can see significant productivity improvements. Complex distributed systems with unique requirements tend to see incremental improvements. The difference isn’t the tool quality—it’s how much of your bottleneck typically sits in code generation versus system design.

Your constraint defines the impact. If implementing features is your rate-limiting step, AI delivers massive value. If architectural decisions and system design are your constraint, AI helps less. Most production systems fall into the second category after the initial prototyping phase.

Your risk tolerance changes the math. If you can ship and iterate rapidly, AI accelerates that cycle. If mistakes have serious consequences, the review and testing time doesn’t compress proportionally. The overall velocity gain depends heavily on how much of your process can safely be accelerated.

Your system complexity matters. Greenfield projects with established patterns see huge gains. Legacy systems with unique constraints and interconnected dependencies see modest gains. The complexity of your codebase directly impacts how useful AI-generated code becomes.

The Honest Assessment

Raju isn’t claiming AI tools are overhyped. He’s providing the nuanced reality: they work extremely well for specific contexts and deliver modest improvements in others.

His 6-month tiger team experiment with dedicated tracking hasn’t found a productivity revolution. They’ve found incremental gains with clear constraints. That’s the honest number engineering leaders need for planning.

“LLMs can help us experiment and prototype features faster. They can help developers catch mistakes in our pull requests. They can help us find answers faster, and we are constantly evaluating,” he explains. “But I’ve not seen the impact that people are saying out there.”

This doesn’t mean ignore AI tools. It means understand your context, measure systematically, and set realistic expectations.

For rapid prototyping and web development? The 2-3x gains are real. For complex production systems with safety requirements? The gains exist but are much more modest. Both can be true simultaneously—the difference is context.

What This Means for You

First, measure systematically rather than relying on anecdotes. Set up dedicated tracking like Raju’s tiger team—assign ownership, establish regular reporting, and gather actual usage data. The hype cycle around AI tools means everyone has an opinion, but data reveals what actually works in your specific context.

Second, understand where your bottleneck actually sits. If architectural decisions and system design consume most of your time, AI tools will help less than if code generation is your constraint. Be honest about what’s actually slowing you down before expecting AI to solve it.

Third, adjust expectations based on risk profile. If your domain allows rapid iteration and tolerable failure rates, AI tools can deliver significant acceleration. If mistakes have serious consequences, the non-compressible validation cycles will limit overall gains regardless of how fast code gets generated.

Fourth, keep evaluating as tools improve. Raju expects capabilities to expand significantly over the next 6-12 months. Today’s limitations may not be tomorrow’s. But base your current planning on current capabilities, not projected future states.

The question every engineering leader should ask: What’s actually constraining my team’s velocity—code generation or everything else? Because if it’s everything else, AI coding tools will help incrementally, not transformationally. And that’s okay—incremental gains compound over time.

Raju’s measured approach provides the reality check the market needs. AI tools deliver real value, but the magnitude depends entirely on your specific context. Understanding that context is how you set realistic expectations and make smart adoption decisions.

High Output is brought to you by Maestro AI. Raju talked about forming a tiger team to systematically track AI tool adoption with biweekly status reports—but that measurement challenge extends beyond just AI tools. When your 200+ person engineering team is distributed across four countries and multiple tools, it becomes impossible to see what’s actually happening without systematic tracking. Maestro cuts through that complexity with automated reporting and metrics and show where' your team’s time and energy actually go, so you can spot patterns and make data-driven decisions about everything from AI adoption to resource allocation.

Visit https://getmaestro.ai to see how we help engineering leaders get actually useful insights into their teams.

Running systematic evaluations of new tools and processes? We’d love to hear your approach. Schedule a chat with our team → https://getmaestro.ai/book

Muhammad Atif, President and CTO of PureLogics, recently deployed an on-prem AI model that hits 70% of the accuracy of their original cloud-based prototype. That 30% accuracy gap represents the tradeoff required for HIPAA compliance. The cloud-based prototype couldn’t be deployed—patient data can’t touch external APIs under their client’s compliance requirements.

This is the reality healthcare engineering leaders face: you’re building for the best model that meets your compliance requirements, not just the highest-performing model in isolation.

Since co-founding Pure Logics in 2007, Muhammad has grown it from 2 people coding in a room to a 500-person global engineering firm. They build on-prem models that achieve 60-70% of cloud-based prototype accuracy while meeting the strict data security requirements that healthcare demands.

The Compliance Wall Everyone Hits

Muhammad’s team was prototyping an AI feature using OpenAI’s API. Fast iteration, impressive results. Then the client’s compliance team saw the architecture diagram.

“When the customer said they need to have on-prem AI, we changed the entire paradigm,” Muhammad explains. The entire approach had to be rethought.

The paradigm shift required rethinking four critical areas. First, hardware specification: what GPU specifications, how much RAM, what storage architecture. These decisions determine whether your model trains in days or weeks, whether inference is real-time or batch. Second, model selection: which open source model fits your domain? Healthcare has different requirements than generic NLP—you need models that work for medical terminology, clinical workflows, provider documentation patterns.

Third, and most challenging, training data acquisition. You need millions of records to train effectively, but healthcare data is protected. “We need to have millions of records of data to train that model to bring up to that accuracy,” Muhammad explains. Where do you get training data that doesn’t violate HIPAA?

Fourth, compliance layers: NIST AI RMF compliance, HSS trustworthy AI practices, OSAP LLM practices, HIPAA audit trails. “We need to make sure that we have all these security and safety guardrails implemented, especially when dealing with live patient data,” Muhammad says.

“We have deployed an onsite model. It’s almost 70% accurate compared to the one we used to have in the initial POC,” Muhammad says.

That 30% accuracy gap represents the tradeoff for meeting compliance requirements. The on-prem model that meets HIPAA requirements ships. The cloud-based prototype doesn’t.

This is the reality healthcare leaders face. The question isn’t “what’s the highest-performing model?” It’s “what’s the best model we can deploy within our regulatory constraints?”

What Compliance Expertise Enables

Pure Logics’ on-prem AI capabilities unlock healthcare applications that wouldn’t be possible without deep compliance knowledge.

Take their diabetic foot monitoring project. Diabetic patients often can’t feel temperature changes in their feet—a dangerous condition that can lead to undetected injuries and infections. Pure Logics is building algorithms that analyze thermal images of patients’ feet to detect temperature anomalies, giving providers early warning signs before problems escalate.

Or their women’s health platform, which helps women track and manage their health throughout hormonal and menstrual cycles. These aren’t trivial consumer apps—they’re handling protected health information that requires the full compliance framework Pure Logics has built.

“We have also been working with few startups who are working on like diagnostics and disease detection kind of algorithms, and we are really proud that we are going to be part of those teams,” Muhammad says.

This is the payoff for solving the hard problems. Teams that can’t navigate HIPAA constraints can’t build these applications. Teams that can navigate HIPAA but can’t achieve reasonable AI model performance on-prem can’t make them useful. Pure Logics’ expertise in both areas—compliance frameworks and on-prem AI deployment—creates the foundation for meaningful healthcare innovation.

The Hidden Cost of Moving Fast

Muhammad sees a pattern with technical debt. “Tech debt is mostly built due to business pressure—’keep delivering, I need this thing or that thing’—or it can be due to poor planning or prioritization.”

Add AI to the mix, and the pressure intensifies. Your CEO reads about companies shipping 4x faster with AI. Your board asks why you’re not seeing similar gains. Your competitors claim massive productivity jumps.

But in healthcare, you can’t just vibe-code a system into production. “You can keep building things, but especially with AI—we are generating code through AI as well—we wanted to make sure we’re not building a product that reaches a certain level where we can’t add any further features, or it’s not scalable.”

Pure Logics’ solution: quarterly audits. Load testing. Security reviews. Code quality checks. Database design reviews. Access audits—who has credentials to which systems. And version upgrade planning—if you’re on Python version X but version Z is stable, what’s the migration path?

This sounds expensive. It is. But Muhammad has watched what happens without it: systems that need complete rebuilds after two years. Technical debt that makes simple features take weeks. Security vulnerabilities that surface during compliance audits.

The paradox: moving slower with proper guardrails lets you move faster long-term.

The Twenty-Year View

Muhammad started Pure Logics in 2007 with one other person. They worked 12-14 hour days, went home at midnight, worked weekends. “The initial four to five months were quite challenging.”

By 2008, they landed Fortune 500 clients—Live Nation, where they managed web presence for Maria Carey and Taylor Swift. By now, they have 500 people across multiple countries.

This growth path offers a different model than the typical startup story. No VC funding. No blitzscaling. Just steady, sustainable growth by solving real problems for enterprise clients.

What does this teach about AI adoption? “We need to have people who are not just coders, but they are also thinking from an end-to-end problem solving mindset. And they are great at other areas like soft skills—communication, explaining and connecting with people and driving to a solution.”

The companies that win with AI won’t be the ones that generate the most code the fastest. They’ll be the ones that understand the complete problem: technical constraints, compliance requirements, security frameworks, and human workflows.

What This Means For You

If you’re building AI products in regulated industries, Muhammad’s framework offers a practical path:

First, map your constraints before you optimize. Don’t start with “what’s the best model?” Start with “what meets our compliance requirements?” An on-prem model that achieves 70% of your prototype’s accuracy but ships is more valuable than a cloud-based prototype that can’t be deployed.

Second, build security guardrails into your development workflow. Muhammad’s team achieves 20-25% productivity gains from AI coding tools while maintaining code quality through static analysis, peer review, and technical debt checks.

Third, audit regularly, not reactively. Quarterly reviews of code quality, security, database design, and access controls catch problems when they’re manageable, not when they’ve compounded into system-wide issues.

Fourth, choose tools for integration, not hype. The best AI tool isn’t the one with the most impressive demos. It’s the one that integrates with your existing quality processes and workflow.

Fifth, remember that constraints can become advantages. Pure Logics’ on-prem expertise differentiates them. Companies that need HIPAA-compliant AI need teams that understand both AI and compliance frameworks. Your constraints are your moat.

The critical question: are you building AI products that work within your industry’s reality, or are you trying to force approaches that only work for unrestricted consumer apps?

About PureLogics:

PureLogics is a global engineering firm specializing in healthcare software development with deep expertise in HIPAA compliance and on-prem AI deployment. Founded in 2007, they’ve grown from 2 engineers to a 500-person team serving Fortune 500 clients including Intel, Samsung, and Live Nation.

The company focuses on building compliant AI solutions for healthcare organizations, from e-prescription systems and EMR integrations to on-prem AI models for sensitive patient data. Their expertise in both AI implementation and healthcare compliance frameworks enables them to build applications that meet strict regulatory requirements while delivering meaningful clinical outcomes.

Learn more at purelogics.com.

About Maestro AI:

High Output is broght to you by Maestro AI. Maestro is an engineering visibility platform that helps leaders make data-driven decisions backed by narrative context. While most dashboards offer surface-level metrics, Maestro analyzes your team’s actual code, PRs, tickets, and communications to reveal not just what’s happening, but why.

The platform automatically synthesizes this activity into real-time feeds for every project, team, and individual—replacing subjective status meetings with objective truth. This allows you to identify blockers before they impact deadlines, de-risk key initiatives, and measure the true impact of tools like AI on your organization.

Visit https://getmaestro.ai to see how we help engineering leaders build more predictable and efficient organizations.

Leading distributed engineering teams? We’d love to hear your challenges. Schedule a chat with our team → https://getmaestro.ai/book

Jaikumar Ganesh would know. As Head of Engineering at Anyscale, he runs Ray—the distributed compute engine that powers production AI at scale. Ray sits in the stack between Kubernetes and the AI workloads, orchestrating the compute that makes everything run. When you’re that deep in everyone’s infrastructure, you see the convergence before anyone else does.

And what he sees right now? Companies are throwing money at GPU shortages while their GPUs sit idle half the time, waiting for CPUs to finish resizing images. It’s not a GPU problem. It’s a coordination problem. And it’s just one of several patterns everyone’s hitting—patterns most don’t even realize are shared.

🎧 Subscribe and listen now →

The bottlenecks everyone’s hitting

Here’s what actually happens in production. You need to process multimodal data—audio, video, robotics sensors, Zoom recordings. Reading images and resizing them? CPUs. LLM inference? GPUs. Writing results back? CPUs again. These are staged pipelines.

“In a lot of legacy systems, you read an image and you have to wait till all the images are read till you activate the GPU,” JK explains. “Now what happens is there’s a GPU shortage, but you have a GPU sitting there idle, and so your GPU utilization is low and your finance team is like, ‘Hey, you’re spending so much money.’”

This is the shift that sounds obvious but isn’t: we’ve moved from a CPU-centric world to a heterogeneous compute world—CPU plus GPU. Most frameworks were built for one or the other. Very few handle the handoff well. Ray Data solves this by handling the transitions without writing to disk at every stage. Different pipeline stages execute on the right resource, and nothing sits waiting.

The companies that figure this out have massive cost advantages. The ones that don’t keep throwing money at GPU clusters that spend half their time idle.

But here’s what’s remarkable: when you’re provisioning clusters at this scale, you see more than just the GPU coordination problem. You see the entire stack converging. Pull up any major AI company’s infrastructure and you’ll see the same architecture:

At the top: AI workloads (data processing, pre-training, post-training, model serving)

Below that: Training frameworks (PyTorch, JAX)

Then: LLM-specific engines (VLLM for serving, DeepSpeed and FSDP for parallelism)

Distributed compute: Ray

Container orchestration: Kubernetes

At the bottom: Cloud providers and GPU providers

“Across all the companies we have worked with, in open source as well as those who are Anyscale customers, this pattern is consistent,” JK explains.

Here are the four patterns driving convergence:

1. Heterogeneous compute coordination: CPU-centric thinking doesn’t work anymore. You need CPU and GPU working together efficiently. Most frameworks handle one or the other well, but the handoff between them is where money gets burned. Multimodal data processing—audio, video, sensor data—exposes this immediately.

2. Post-training infrastructure complexity: Everyone thinks pre-training is the hard part. Wrong. Post-training is where the real infrastructure complexity lives, and it’s where customization happens. Eight of the ten most popular open source post-training libraries are built on Ray. Why? Because you need inference stages mixed with training stages, all within the same workload. Someone has to orchestrate where each stage runs, whether to transfer model weights, how to handle the compute efficiently.

3. Multimodal data pipeline bottlenecks: It’s not a model problem—it’s an engineering problem. The bottleneck isn’t which model handles video best. It’s moving data between CPUs and GPUs efficiently without writing to disk at every stage. Fix the pipeline, not the model selection.

4. Domain-specific approaches returning: While everyone obsessed over LLMs, reinforcement learning quietly came back in gaming and simulation. Riot Games—one of Ray’s largest customers—uses RL to power the models behind their characters. When you have a physical world or game environment to model, RL still wins. Different problems need different approaches. They all need the same underlying infrastructure to scale.

The interesting part isn’t that everyone uses similar tools. It’s that the bottlenecks are identical. They’re all hitting the same walls—and most of them think they’re the only ones.

Where the real moat lives

Pre-training gets the headlines and the hype. Post-training is where the actual differentiation happens.

Think about it: pre-training is increasingly commoditized. You can use foundation models from OpenAI, Anthropic, or Meta. But post-training—fine-tuning models for your specific use case, your specific data, your specific product needs—that’s where you build something defensible.

And post-training infrastructure is brutally complex. You need inference stages mixed with training stages. You’re constantly moving between different compute resources. You’re orchestrating model weight transfers. You’re debugging why your pipeline breaks at 2am.

This is why eight of the ten most popular open source post-training libraries are built on Ray. Anthropic Claude uses them. Cursor’s agents use them. Not because Ray is magic, but because orchestrating this complexity requires infrastructure built specifically for heterogeneous compute.

“They all use post-training libraries, and someone has to orchestrate and handle compute efficiently,” JK explains. “You can have inference stage, your training stage within the post-training libraries itself, and there’ll be a lot of complexity around where each one of these stages runs.”

Your competitors are using the same foundation models. They’re reading the same papers. The differentiation isn’t in the base technology—it’s in how efficiently you can customize it for your needs. That’s an infrastructure problem, not a model problem.

The distance that creates the view

JK’s ability to see these patterns comes from somewhere specific. He grew up in a classroom with one other student—not a small private school, but a remote village in India where it took 10 days to receive a telegram about his grandmother’s death. The world had phones. His village didn’t.

Years later, visiting relatives in the city, he saw a two-line pager clipped to his uncle’s belt. “I was like, whoa, what the hell is this?” he recalls. He asked which company made it. Motorola. “That’s where I want to be.”

That distance from infrastructure—then getting close to it—shapes how you think about abstraction layers. He joined Motorola during its decline, then landed on the early Android team at Google when they were 10-15 people figuring out what they were building. Then co-started Uber’s AI group. Then Anyscale.

JK has been in this position before: seeing the platform-level patterns emerge while individual companies think they’re solving unique problems. The moment that crystallized it happened on a bus in Panama in 2012. A local spent the entire ride on WhatsApp. JK asked what he was doing for so long. “He kind of gave me this look saying, dude, what a stupid question,” JK remembers. “He just said that this has allowed me to keep in touch with my family in remote village.”

From Android enabling that Panama bus connection to Ray enabling AI at scale—JK’s entire career has been about building the infrastructure layer that lets others build. And that vantage point is what lets him see the convergence happening now.

The honest take on AI coding agents

Anyscale is targeting 30% productivity gains from AI coding tools. Not 10x. Not zero. Thirty percent.

That’s the honest number—and it’s harder to achieve than you’d think.

JK tried an experiment a year ago: fed Ray code to an AI agent without reviewing it, just to see what would happen. His cluster crashed. He spent the next two hours debugging why. The agent had written code that consumed too much memory, causing out-of-memory errors.

This is someone who runs production AI infrastructure at massive scale. Even he can’t blindly trust AI-generated code.

What works instead: spec-driven development. Detailed markdown files. Clear design documents. Tell the agent exactly what you want—function length limits, testing requirements, how to use specific libraries. Then review what it produces.

“You cannot just vibe-code a system into production,” he explains. “I’ve seen engineers who say, ‘Oh, I just used agents for this,’ and they’ll look at the crap it has produced and it’s caused me more problems.”

But here’s where it gets interesting. One of Anyscale’s senior engineers was firmly in the anti-LLM camp. Then he worked on a complicated problem with a distinguished member of the staff who used agents effectively. Two days later, JK got a Slack message: “Couldn’t have produced this code in three days. It would’ve taken me two weeks.”

The pattern? Senior engineers who’ve been through previous platform shifts (internet, mobile, cloud) adapt faster. They recognize tectonic change when they see it. Junior engineers coming in fresh adapt quickly too—they haven’t developed rigid workflows yet. It’s the engineers in the middle who struggle most.

The critical part: humans stay in the loop. “We do not want to be completely dependent on agents that we lose the critical thinking part,” JK emphasizes. “You need to understand your code at a deep level. You need to understand your design at a deep level and then let agents do their thing.”

That’s the realistic target: 30% productivity gains with spec-driven development, human review, and clear expectations. Anyone claiming 10x either hasn’t shipped to production or is starting from scratch.

What this actually means

AI coding agents can deliver 30%—if you do it right. Write detailed specs. Review everything. Keep humans in the loop. The mechanical coding work gets faster. The thinking work stays yours. Anyone claiming more is overselling.

The heterogeneous compute insight matters right now. If you’re still thinking “just rent more GPUs,” you’re going to blow your budget. The companies that figure out CPU+GPU orchestration will have massive cost advantages. Your finance team already sees the waste—idle GPUs waiting for CPU tasks. Fix the pipeline efficiency, not the GPU count.

Post-training is where the moat lives. Pre-training gets the headlines. Post-training is where customization happens. Eight of ten popular libraries are built on the same infrastructure because orchestrating mixed inference and training stages is brutally complex. If you’re building serious AI products, understand your post-training infrastructure.

Multimodal is an infrastructure problem, not a model problem. Everyone’s focused on which model handles video best. The real bottleneck is data pipeline efficiency—moving between CPUs and GPUs without writing to disk at every stage. This is an engineering challenge, not a model selection challenge.

Your competitors are converging on the same stack. The differentiation isn’t in the infrastructure layer—it’s in what you build on top of it. Don’t waste time reinventing distributed compute. Use the patterns that already work at scale.

What patterns are you seeing in your AI deployments? Are you burning budget on GPU utilization? Hitting data pipeline bottlenecks trying to process multimodal data? Reply to this email—I’m curious what matches these infrastructure-layer patterns.

About Anyscale:

Anyscale is the company behind Ray, the open-source distributed compute engine powering production AI at companies like OpenAI, Anthropic, Cursor, Apple, Spotify, Netflix, and Uber. Founded by the creators of Ray, Anyscale gives engineering teams a platform to scale ML and AI workloads—from data processing to training to inference—without manual infrastructure operations.

The platform helps companies deploy fault-tolerant clusters, optimize GPU utilization, and scale across CPUs, GPUs, and other accelerators. Whether you’re fine-tuning LLMs, running batch inference, or processing video at scale, Anyscale handles the distributed compute complexity so teams can focus on building AI products.

Learn more at anyscale.com.

High Output is brought to you by Maestro AI:

Maestro AI is an engineering visibility platform that helps leaders make data-driven decisions backed by narrative context. While most dashboards offer surface-level metrics, Maestro analyzes your team’s actual code, PRs, tickets, and communications to reveal not just what’s happening, but why.

The platform automatically synthesizes this activity into real-time feeds for every project, team, and individual—replacing subjective status meetings with objective truth. This allows you to identify blockers before they impact deadlines, de-risk key initiatives, and measure the true impact of tools like AI on your organization.

Visit https://getmaestro.ai to see how we help engineering leaders build more predictable and efficient organizations.

Leading distributed engineering teams? We’d love to hear your challenges. Schedule a chat with our team → https://getmaestro.ai/book

They get promoted from IC roles and suddenly find themselves managing people they used to work alongside. They default to command-and-control because that's what they've seen. They struggle with influence across teams they don't control. The transition is messy, stressful, and often unsuccessful.

Richard Ford took a different path. He's the VP of Engineering at CyberCube, with a resume that spans a PhD in Quantum Physics from Oxford, developing IBM's computer virus immune system, and building the world's largest web hosting system at Verio. But his most valuable leadership training came from an unexpected place: 10 years as a university department head.

This wasn't a detour from his tech career—it was the perfect laboratory for mastering engineering leadership.

🎧 Subscribe and Listen Now →

The Academic Leadership Laboratory

"Being a professor, being a department head specifically was the best training in the world for running engineering teams," Richard told me. "Because as a department head in a university, you have no carrot and you have no stick."

Think about this constraint. His biggest reward? "I can give you a slightly bigger office next year." His biggest punishment? "I will give you a bad review, but it won't make any difference to your raise and it won't make any difference to your employment because you're tenured."

This forced Richard to develop something most engineering leaders never master: pure influence without authority.

"What you learn to do is manage by influence, to get people on the boat and make them want to come with you, and to build consensus," he explained. "And I think there's a lot of parallels with engineering where it's all about the people and it's about having influence across groups that you don't control."

The academic constraint created the perfect training ground. No shortcuts. No positional power to fall back on. Just the fundamental skill of making people want to follow your vision.

The Influence Toolkit

Richard's academic experience gave him what he calls "a big grab bag of different techniques for getting people to come along, ranging all the way from 'Hey, let's try it your way' to really let them explore, give them a lot of freedom, all the way down to 'No, I'm calling the ball. This is getting done this week and this is what we're doing.'"

The key insight: "You shouldn't just default to a style. You should look at the personal group that you're working with. You should figure out what is the most effective approach to get the result that we need to get as a team."

This adaptability comes from understanding that "this sort of failure mode where we have a default style as a manager, as a leader, it is actually terrible. It's a snare."

Instead of one-size-fits-all leadership, Richard developed situational mastery. By nature, he's "much more of a consensus builder and a group builder, but that's not my only style, and I can pull in whatever style the situation requires."

The Partnership Mindset

Academic leadership taught Richard something else crucial: how to think about working relationships.

"I don't think of my employer as my overlord. They're my partner. We're doing this together," he said. "You want to find an employer and an environment that suits your skillset, that suits how you think about the world."

This partnership mindset extends to his team management. "If you're not in the right environment, you'll never do the best work of your career. And what are we here to do? We're here to do the best work of our career because it's so fulfilling to be at the top of your game."

The practical result: Richard gravitates toward environments that bring out his team's best work, not just maximum compensation. "There's such a thing as enough when it comes to comp. Money isn't my primary motivator. It's fulfillment."

Communication Across Differences

Academic leadership also taught Richard that "everyone's different, and so you have to take a variety of approaches to get your message across."

His communication strategy is deliberately multimodal: "There's physical—we're in the same room, one-on-ones or group meetings. There's presence going out to the satellite office. Then yes, I send out an email every few weeks to the team telling them what's up next. And we have all hands and we have smaller group meetings and I push stuff out in Slack."

The principle: "We shouldn't require the consumer to match our style. We should try and match the style of the consumer because that's gonna be most effective."

Even his meeting structure reflects this understanding. "It's always the last thing somebody says in the meeting that's the thing they actually set it up for," so he books 30-minute meetings for 25 minutes, knowing the real conversation happens when people feel they have time to bring up what's actually on their mind.

What This Means for Your Engineering Leadership

First, develop your influence toolkit beyond hierarchical authority. Practice getting alignment through understanding and motivation, not just positional power. The academic exercise: try leading a volunteer project where you have no formal authority.

Second, build situational leadership skills. Don't default to one style—develop approaches ranging from collaborative exploration to decisive direction-setting. Match the approach to the specific challenge and team dynamic, not your comfort zone.

Third, think partnership, not hierarchy. Optimize for environments that bring out your team's best work, not just maximum individual compensation. As Richard puts it: "There's such a thing as enough" when it comes to money, but no limit to fulfillment and growth.

Fourth, communicate multimodally. Different people consume information differently. Don't make your team adapt to your preferred communication style—adapt your communication to reach everyone effectively.

The leadership question: Before making any major team decision, ask yourself: "How can I get people to want to come with me on this?" The answer will usually produce better decisions and stronger team alignment than pure top-down directives.

Richard's academic detour wasn't a detour at all. It was deliberate preparation for the influence-based leadership that modern engineering teams actually need. The constraint of no authority forced him to master the skills that make authority effective when you have it.

About CyberCube:

CyberCube is the leading provider of cyber risk analytics for the insurance industry, delivering the data and modeling capabilities that power over 70% of global cyber insurance premiums. Founded in 2015 and now backed by over $180MM in recent funding from Spectrum Equity and others, CyberCube serves more than 130 clients across the insurance value chain—including 75% of the top 40 US and European cyber insurers.

The company’s engineering teams, led by VP of Engineering Richard Ford, build AI-powered software solutions that help insurers, reinsurers, and brokers quantify and manage one of the most complex risks facing organizations today. With a multidisciplinary team spanning San Francisco, New York, Chicago, London, and Tallinn, CyberCube is on a mission to build societal resilience to cyber risk by making it quantifiable, insurable, and manageable at scale.

Learn more at cybcube.com

High Output is brought to you by Maestro AI.

Richard talked about how academic leadership taught him to "get people on the boat and make them want to come with you"—but that influence-based approach creates a new challenge for engineering leaders. When your team is distributed across Slack, Jira, and GitHub, it becomes impossible to see who's actually engaged and where your influence is working. Maestro cuts through that chaos with daily briefings that reveal where your team's time and energy actually go, so you can spot when your leadership approach is building momentum or hitting resistance.

Visit https://getmaestro.ai to see how we help engineering leaders measure influence and team engagement beyond vanity metrics.

Leading through influence instead of authority? We'd love to hear your approach. Schedule a chat with our team → https://cal.com/team/maestro-ai/chat-with-maestro

Multiple coding rounds. Brain twisters on whiteboards. Engineers throwing their favorite puzzle at candidates. The whole process optimized for showing off interviewer cleverness rather than predicting job performance.

Ashwin Baskaran figured this out early. He's the VP of Engineering at Mercury, the fintech that more than 200,000 companies trust with their finances. Over his 20+ years in engineering leadership—from startups to Citrix to scaling Mercury—he's watched the industry slowly realize that technical depth alone doesn't predict success.

The companies still doing leetcode marathons are missing the point entirely.

🎧 Subscribe and Listen Now →

The Product Sense Revolution

"I would say interviews in the early part of when I became a manager tended to be very technical," Ashwin told me. "Multiple coding rounds. But simply doing more technical interviews doesn't necessarily give you more signal."

Here's what's interesting: a well-designed single coding interview gives you more signal than four or five ad hoc brain teasers. But that's not even the biggest shift.

The real evolution is recognizing that engineers need product sense. "I think the typical product company has more of an expectation that engineers will have ideas on the product and have product sense and not outsource their thinking."

At Mercury, Ashwin literally asks candidates: "Define the product." He leaves it vague on purpose. Whether it's infrastructure for databases or tools for general contractors, he's looking for people who understand boundaries—who built this, who experiences it, how they're experiencing it.

"I'm looking for people who have the sense like, there's a boundary and this boundary is being experienced by somebody."

The AI Testing Ground

But here's where it gets really interesting for the AI era. While everyone's debating productivity gains, Ashwin's team has been quietly experimenting across their 250+ engineer organization.

"Our general hypothesis is that it's gonna be a net positive," he said. "But it is going to be a bit of a journey."

The key insight: different types of problems benefit differently from AI assistance. Greenfield applications? AI shines. Legacy systems with complex context? Much harder. Python and TypeScript seem to get better results than other stacks, though the data is still anecdotal.

This creates a new interview challenge: "Do we change our interview structure and measure for proficiency with AI tools?"

Mercury is exploring screening processes that actually watch candidates use coding assistants in real-time. Not just prompting—sophisticated use of the tools integrated into VS Code. The question isn't whether someone can code, but how effectively they can collaborate with AI.

The Architecture Advantage

Ashwin's prediction for the future cuts through the hype: "I like this concept that this will actually drive extreme modularity."

His reasoning is compelling. Today, creating microservices means dealing with schemas, protocol buffers, gRPC boilerplate—all the toil that makes developers avoid proper boundaries. But AI excels at generating exactly this kind of repetitive infrastructure code.

"All of those things that are toil associated with building something that way could vanish. Those could be some of the early things that vanish."

The result? Systems with much better boundaries. Code that's easier for both humans and AI to understand and modify. The less context an AI needs to incorporate, the better outcomes you can expect.

Even more provocatively: "Prompts, or some variation of the prompt plus other contextual information could actually be the new code. And your code itself is like assembly code or machine code—the thing you produce whenever you need it, not the thing you version control."

What This Means for You

First, audit your current interview process. If you're still doing multiple coding rounds or whiteboard brain teasers, you're optimizing for the wrong signal. Design one well-calibrated coding interview and invest the saved time in assessing product sense and communication skills.

Second, start experimenting with AI-augmented interviews for appropriate roles. Not every position needs this, but for roles involving rapid prototyping or greenfield development, understanding how candidates collaborate with AI tools is becoming critical.

Third, prioritize modular architecture now. Whether AI reaches its full potential or not, better boundaries between systems will benefit your team. And if AI does deliver on code generation, you'll be perfectly positioned to take advantage.

Fourth, recognize that technical interviews are moving toward assessing judgment, not just implementation ability. In a world where AI can generate code, the premium is on engineers who understand what to build and how it fits into the larger context.

The question for your next hire: Are you screening for someone who can write algorithms on a whiteboard, or someone who can define product boundaries and collaborate effectively with both humans and AI?

The leaders who evolve their hiring practices now will build significantly stronger teams than those still stuck in 2004.

High Output is brought to you by Maestro AI. Ashwin talked about how "simply doing more technical interviews doesn't necessarily give you more signal"—the same principle applies to measuring your engineering team's performance. While most leaders rely on outdated metrics like story points, the real signals about velocity and blockers are hidden in your team's daily work. Maestro reveals which practices actually drive results and which just create noise.

Ready to move beyond surface-level metrics? Schedule a chat with our team → https://cal.com/team/maestro-ai/chat-with-maestro

They compromise on quality to fill seats, rationalize cultural misfits as "learning experiences," and spend months fixing the technical debt created by rushed hires. Adam Kirk took a different approach: he hired 35 engineers in 12 months and raised his quality bar with each hire.

Adam is co-founder and CTO of Jump, where they've built a note-taking platform specifically for financial advisors that grew from 4 people to 50 in one year. But here's what makes his story different: instead of the typical startup hiring playbook, he invented a process that lets him see how candidates actually work before making decisions.

The result? A team scaling at breakneck speed without the usual quality compromises. Here's how he did it—and why traditional hiring advice fails when you're moving this fast.

🎧 Subscribe and Listen Now →

The Extreme Ownership Filter

Traditional hiring advice says "hire for potential and train for skills." Adam learned this doesn't work when you're drowning in growth and can't afford hand-holding.

"As a matter of survival, I'm looking for somebody who can just, you know, I can say like, look, take this part of the product and own it,” and “make it so that I don't have to think about it anymore," he explained. "Make excellent decisions, build it really fast. Fix all the bugs. Deliver a ton of value to customers such that I don't really have to think about it anymore."

This isn't just preference—it's survival. When you're making 100 decisions per day and reading hundreds of Slack messages, you need people who can take complete ownership without ongoing guidance.

The contrast with most companies is stark: "One feedback I got from somebody was that most companies want engineers to constantly be asking for permission or getting validation on what they're doing. The way that we work is sort of like, no, I trust you. Just go get it done."

This filter eliminates 90% of candidates immediately. But for hypergrowth companies, hiring someone who needs constant direction is actually more expensive than not hiring at all.

The Trial Week Revolution

Here's where Adam's approach gets innovative: instead of trying to predict performance through interviews, he pays candidates to work for a week on real problems.

"We give them an actual real difficult challenge, like a ticket that we need built. We get to see them actually working on our code base, actually building something that we need," he said.

The process starts with a 30-minute coding exercise to screen basic proficiency, then moves directly to a paid trial week. No multi-round interviews, no theoretical problems, no whiteboarding sessions.

What this reveals that traditional interviews can't:

• How they handle ambiguity when requirements aren't perfectly defined

• How they communicate when they're stuck

• How they integrate with the existing team and codebase

• Whether they can actually deliver results in your specific environment

"Usually by halfway through the week, we know that this is somebody that we want to work with," Adam noted. The approach is intensive—"you're onboarding them, getting them set up, you're evaluating their work constantly"—but it dramatically reduces hiring mistakes.

Most importantly, it works for candidates too: "It's good for applicants because they get to see how's the team? Do they like the code? Do they like the tech stack? Working with us for a week, they're pretty sure whether or not it's a good fit for them."

When the CTO Can't Scale

Adam's honest about the personal cost of hypergrowth: the system that got them here isn't sustainable for him personally.

"I make too many decisions every day. I have too much context switching fatigue. I'm reading hundreds of messages in Slack every day. I am being asked to make a hundred decisions every day," he told me. "I wouldn't describe my state as sustainable right now."

The challenge isn't just volume—it's that the hardest problems naturally filter up: "All the crap kind of filters to the exec, up to the CEO or to the top. All engineering problems, the worst problems filter to me. And a lot of them are stuff that are not fun to deal with."

But here's his insight: there are only two "glass balls" he can't drop that will compound over time—code quality and hiring quality. Everything else can be managed or delegated, but these two mistakes get more expensive every day you don't fix them.

His solution is to hire people who can completely remove decision-making burden: "I need you to take one of these bricks that I'm holding and take it completely from me."

The AI Productivity Reality Check

While the industry debates whether AI will replace engineers, Adam has measured actual results in a hypergrowth environment where productivity matters immediately.

"For some things it makes you 10 times faster, like writing tests. AI is so good at writing tests you should never write your own tests anymore," he said. "Maybe it five Xs you while you're typing out the code, maybe it two Xs you answering questions about the codebase."

His measured assessment: "The effective increase over all those things combined is probably around 1.5 to 2x more productive."

But here's the strategic insight most leaders miss: this doesn't reduce hiring needs. "If you take your 10 engineers, give them AI, and now they're 20, your competitors are gonna hire 20 and double it to 40. You can't hire less engineers."

The competitive advantage isn't using AI to hire fewer people—it's using AI to make your existing team more capable while continuing to hire aggressively. Adam's team uses AI extensively during trial weeks to see how candidates leverage these tools in real work.

What This Means for Your Startup

First, design your hiring process around actual work, not theoretical scenarios. If you can't afford to pay someone for a week of real work, you probably can't afford to hire them full-time either.

Second, hire for extreme ownership when scaling fast. Hand-holding kills velocity when you're trying to move at hypergrowth speeds. Look for people who can take complete ownership of product areas without ongoing management overhead.

Third, accept that hypergrowth means accepting some unsustainability in exchange for speed. The question isn't whether you'll be overwhelmed—it's whether you're building systems that will eventually let you delegate the right decisions.

Fourth, use AI to amplify your best people, but don't expect it to replace hiring. The 1.5-2x productivity gains are real, but your competitors will use the same tools. The advantage goes to whoever can hire and scale the fastest while maintaining quality.

The trial week test: Before your next hire, ask yourself: "Would I be comfortable paying this person for a week to work on a real problem?" If not, keep looking. The cost of a failed trial week is much less than the cost of a bad hire.

This conversation with Adam Kirk originally appeared on the High Output podcast. For more from-the-trenches insights from engineering leaders navigating hypergrowth and AI transformation, subscribe here.

High Output is brought to you by Maestro AI. Adam talked about drowning in "hundreds of Slack messages every day" and making "a hundred decisions every day"—but that decision fatigue creates a visibility problem that most engineering leaders face. When your team is distributed across Slack, Jira, and GitHub, it becomes impossible to see who's actually delivering and where bottlenecks are forming. Maestro cuts through that chaos with daily briefings that reveal where your team's time and energy actually go, so you can spot the high performers worth promoting and the blockers slowing everyone down.

Visit https://getmaestro.ai to see how we help engineering leaders make better decisions about their teams and projects.

When LLMs started disrupting Replicant's voice automation platform, he did exactly what conventional wisdom dictates: "Let's incorporate it in parts of the product. Let's improve these parts of the experience." Keep the legacy system running, gradually migrate functionality, minimize risk.

But months into this approach, Mike hit the wall every engineering leader knows: "The way that story always seems to end is the new one never launched."

That's when Mike discovered something that changed everything. AI coding tools had fundamentally altered the economics of rebuilds. "The velocity you can move at with greenfield development is just preposterous," he realized. Instead of years-long migrations that typically fail, his team could rebuild Replicant's core platform in 90 days with 12 people.

The result? They "threw things away and started over"—successfully. This breakthrough demonstrates how AI fundamentally changes the strategic calculus for engineering leaders.

This reveals what most leaders are missing: AI fundamentally changes the strategic calculus of engineering decisions. Before AI coding tools, engineering leaders faced an impossible choice—keep maintaining legacy systems that block innovation, or attempt risky, years-long rebuilds that usually fail. AI creates a new strategic option: rebuilds that are both fast and low-risk, fundamentally shifting how leaders think about technical debt and resource allocation.

🎧 Subscribe and Listen Now →

The Demand Multiplier Nobody Talks About

Here's what Mike discovered at Replicant: AI doesn't reduce the need for engineers—it multiplies what's economically possible to build.

Mike started programming in the late '80s with BBSs, graduated during the dot-com boom, and learned hardcore C++ from "absolute badasses" who came out of Bell Labs. Over 16 years of engineering leadership, he's seen every technology wave—and this one is different.

"The overall need and desire for software in the world just seems to completely outstrip supply," he told me. "I just don't see” AI killing software jobs. “It'll just be more software."

"I was just talking to a guy today who runs this gym that I work at," Mike explained. "He says he cannot find any software anywhere that will do this biomechanics type analysis that he wants to do. They do motion capture on people who work out there to analyze all this stuff about how their performance is and create custom workout plans for them."

Mike's reaction: "How does that not exist? Like all that, none of that technology is like hard to do. Like the motion capture stuff's all figured out. It's just sort of a data munging application with like a UI and some ML in there."

The answer: "I think it's just 'cause the market's too small."

But here's the insight: "If you change the economics, maybe not."

This is the job creation mechanism nobody sees. AI isn't replacing engineers—it's making thousands of niche markets suddenly viable. Software that was too expensive to build for small markets becomes profitable when development costs drop 10x.

Why Companies Do More, Not Hire Less

Mike's experience challenges the conventional wisdom about AI-driven downsizing. When I asked if he thought people would still have engineering jobs, his response was immediate:

"I do, I do. I think there's this whole talk about companies will be smaller. I just think companies are just gonna do more."

He made it concrete: "If you're at a startup right now. How long is your to-do list? Like if I double the size of your engineering team tomorrow, would you have stuff for them to do? Yes."

This matches what Mike saw at Replicant. With AI tools like Cursor, his team rebuilt their entire conversation automation platform in 90 days—something that would have taken two years before. The result wasn't fewer engineers. It was more ambitious product goals and rapid team growth.

"There's so many parts of the business world, the industrial world, that have not really been penetrated by technology," Mike observed. "Those are all ripe for people to go in there and do it."

The Skills That Matter More

Mike sees the real challenge differently than most. It's not about AI replacing engineers—it's about engineers adapting to work effectively with AI tools.

"Experienced engineers who can use those tools, have experience with the tools as well—'cause I think it takes, there's some learning curve to get the most out of them—can just produce an enormous quantity of reasonable quality software very, very quickly."

But the bigger shift is social, not technical. "As you become a more senior engineer, I see it's all about communication," Mike explained. "There's only so much you can get done as an individual. And then you need to go outside yourself."

With AI handling more routine coding, human coordination becomes the bottleneck. "If everyone can produce code at four times the rate they used to, it's like, okay, well now, there are no more solo projects. You're gonna have to coordinate."

What This Means for You

Mike's experience reveals four principles for engineering leaders preparing for the AI-driven future:

First, stop asking whether AI will replace engineers. Start asking what becomes possible when engineering costs drop dramatically. The constraint isn't demand for software—it's our ability to build it economically. AI removes that constraint.

Second, embrace the rebuild option. Mike's 90-day platform rebuild would have been impossible before AI coding tools. If you're carrying technical debt from pre-AI architectures, the cost-benefit analysis of rebuilds has fundamentally changed.

Third, invest in communication skills across your team. "I think the only challenge junior engineers are gonna have is that their expectations will be higher, quicker," Mike noted. When AI handles routine coding, human coordination becomes the new bottleneck.

Fourth, think about untapped markets, not just optimization. Mike's gym example illustrates thousands of niche applications that were previously uneconomical. The next decade belongs to engineers who can identify and serve these newly viable markets.

The question for your next strategic decision: Instead of asking "How do we stay competitive?" ask "What becomes possible now that wasn't possible before?"

High Output is brought to you by Maestro AI. Mike talked about how AI tools let his team "produce an enormous quantity of reasonable quality software very, very quickly"—but that speed creates a new challenge. When your team can build 4x faster, staying aligned on what you're actually building becomes critical. Maestro cuts through the noise with daily briefings that reveal where your team's time and energy actually go, so you can spot when that increased velocity is pointing in the wrong direction.

Visit https://getmaestro.ai to see how we help engineering leaders maintain alignment in the age of acceleration.

Have your own story about AI changing your engineering strategy? We'd love to hear it. Schedule a chat with our team → https://cal.com/team/maestro-ai/chat-with-maestro

When they see a new model, they ask: "How fast can we ship this?" But the interesting question is: "Where will this break?"

figured this out early. He's the CTO of PicnicHealth, and they've built something remarkable: an 8 billion parameter model that beats much larger frontier models at medical tasks. Because Troy understood exactly where large, general models fall short—and he engineered around those constraints.

His company built what might be the world's best LLM for medical records—working with 7 out of 10 largest pharma companies and collecting 350 million clinician annotations over a decade. But Troy's most valuable insight isn't about AI's capabilities. It's about the immovable constraints that determine whether your AI implementation succeeds or becomes expensive theater.

The Filing Cabinet Problem

Troy grew up around medicine. Both his parents were doctors. As a kid, he worked in their offices and was "horrified by walls of filing cabinets."

When the government spent $40 billion digitizing medical records, Troy thought: finally. Software will fix this mess.

It didn't. Most EMR systems made doctors less efficient, not more. This taught Troy something important: you can't just layer technology onto broken processes. The process has to change too.

This insight shaped everything that came after.

🎧 Subscribe and Listen Now →

When Leaders Need to Code Again

Here's what's interesting about leadership during technological shifts: engineering leaders may need to get more technical, not less.

Troy started PicnicHealth in 2014, writing code all day. As the company grew, he did what every engineering leader does: stepped back from implementation to focus on team building. "The highest leverage way for me to work is less building everything directly and more building out the team."

But when LLMs emerged, Troy had to reverse course. "The ability to understand where opportunity is requires more direct hands-on experience," he told me.

Why? Because understanding real constraints requires hands-on experience. Where does fine-tuning actually help? Which domains are narrow enough for reliable automation? You can't evaluate these opportunities from team status reports, because the technology is changing too fast.

Troy recognized that during periods of rapid technological change, engineering leaders need deeper technical fluency to make good decisions. He had to balance staying close enough to the technology to spot constraints while still enabling his teams to do their best work.

This isn't micromanaging. It's strategic intelligence gathering about what's actually possible.

The Data Moat

PicnicHealth's advantage isn't the size of their models. It's their data.

They have 350 million annotations from real doctors using their system over a decade. Every time a doctor corrects the AI, the model gets better. "That kind of medical record data is not in the public training corpus," Troy explains.

This creates something interesting: a feedback loop that gets stronger over time. The more doctors use the system, the better it gets. The better it gets, the more doctors want to use it.

Most AI companies focus on building more powerful models. PicnicHealth focused on building better data collection systems.

The Application Layer Surprise

In 2022, everyone thought AI value would flow primarily to model creators—OpenAI, Anthropic, Google. The reasoning seemed sound: models are the hardest part to build, so they should capture the most value.

This turned out to be incomplete.

"I'm very glad that we live in a world where a lot of value is delivered and captured by the application layer," Troy says. Here's why: foundation models are commoditizing, but domain expertise isn't.

A general-purpose model might have broad knowledge, but it doesn't know the specific workflows of clinical trials, or how doctors actually review patient records, or which edge cases matter most in your domain.

This is where constraints become advantages. By focusing on medical records exclusively, PicnicHealth could optimize for things that matter in healthcare but nowhere else.

The Narrow Domain Strategy

Most AI implementations fail because they try to solve everything at once. Picnic Health builds AI agents that operate within their integrated clinical trial system. This sounds limiting, but it's actually powerful.

When you control the entire workflow—from data ingestion to final output—you can build in validation loops, human oversight, and error correction at every step. You can define clear success metrics and create tight feedback cycles.

General-purpose AI tools can't do this. They have to work for everyone, which means they're optimized for no one.

Bottlenecks Don't Disappear

Here's the thing about technological progress: it doesn't eliminate bottlenecks, it just moves them.

AI accelerates drug discovery, but regulatory approval still takes 7-10 years. "Even if there's way more potential assets," Troy observes, "you're still 10 years away from people actually being able to use that."

This pattern repeats everywhere. Technical capabilities advance at an amazing pace, but distribution into real industries and workflows takes much longer. It requires changing human behavior, not just building better software.

The leadership lesson: don't assume AI will solve your bottlenecks. Assume it will create new ones. Your job is figuring out where.

What This Means for You

If you're building with AI, Troy's approach offers a different path:

First, understand your constraints before you optimize for capabilities. Most processes have hidden bottlenecks that no amount of AI will fix. Find those first.

Second, build data flywheels, not just models. Look for workflows where user corrections create proprietary datasets. This is how you build moats in a world of commoditized models.

Third, go narrow before you go wide. Start with controlled environments where you can measure success precisely and iterate quickly. Reliable automation in a narrow domain beats unreliable automation everywhere.

Fourth, during technological shifts, technical leaders need to stay technical. You can't evaluate AI opportunities from conference rooms. You need to understand the constraints firsthand.

The question for your next AI decision: are you solving a real constraint, or just adding sophisticated automation to a broken process?

The difference determines whether you build a moat or just an expensive feature.

A Note About Maestro AI

Troy described a challenge most engineering leaders face: as you grow from writing code to leading teams, you lose visibility into what's actually happening. When the work is scattered across Slack, Jira, and GitHub and more, it becomes impossible to see where time goes or what's blocking progress.

Maestro AI solves this with daily insights that show where your team's energy actually goes, so you can spot problems before they compound.

If you're tired of guessing what's really happening with your team, visit getmaestro.ai or schedule a chat with us here: https://cal.com/team/maestro-ai/chat-with-maestro

While many engineering leaders are navigating AI adoption with a mix of top-down encouragement and bottom-up experimentation, Adil took a more structured path. He set a specific, measurable goal: 80% AI adoption across Fandom's engineering organization this year. Not 100%. Not "eventually." Exactly 80%—because he learned that successful technology adoption is about deliberate change management, not just wishful thinking.

Managing AI strategy for 350 million monthly users across 250,000 communities, Adil has discovered that the challenge isn't the technology itself—it's getting distributed teams to embrace it while maintaining the stability that massive scale demands.

🎧 Subscribe and Listen Now →

What's inside (34 min):

→ The 80% strategy. Why Fandom set a specific AI adoption goal rather than hoping it happens: "We've set a goal of AI adoption for our teams... we measure our usage." The framework includes enterprise licenses, internal champions, and treating it as deliberate change management, not a tech rollout.

→ Measuring what matters. How Fandom tracks adoption across different tools and teams: "We also bring in the right tool for the right thing. So if you're doing more front end development, you know, we have cursor that you can use... copilot is better for a bunch of other things."

→ The champion strategy. Instead of mandating from the top, finding internal advocates who can show others what works: "We try to find champions within our team who've had good experiences so that they can be the promoters of it for other team members."

→ Experimenting safely at scale. How Fandom balances AI adoption with stability for 350 million users: "You don't want to skip the code review part. You don't want to skip the automated test suites." The key is knowing what AI is good at—and what it's not.

→ The global content challenge. Why AI translation works perfectly for Shogun but breaks for Expedition 33: "Your translation may be factually correct, but if it doesn't actually match with how people are using it, it's not going to work out." Human oversight becomes critical at scale.

Why it matters

We're past the point of debating whether to adopt AI—the question now is how to do it effectively across entire engineering organizations. Most companies are taking one of two approaches: mandate it from the top or hope engineers adopt it naturally. Both strategies fail.

Adil's 80% goal reveals a third way: set specific, measurable targets and treat AI adoption like any other major organizational change. It requires champions, metrics, enterprise-grade tools, and deliberate change management.

His experience managing multiple company acquisitions (Twitter, Amazon, Intuit) taught him that successful technology adoption isn't about the technology—it's about people. The same principles that work for integrating acquired teams work for AI adoption: alignment, context-setting, and giving people time to internalize change.

At Fandom's scale, the stakes are higher. With 350 million users depending on platform stability, they can't afford to experiment recklessly. But they also can't afford to fall behind on AI capabilities. Adil's approach shows how to thread that needle.

Your turn

Adil's framework challenges us to be more deliberate. Here are two questions to consider:

1. Can you actually measure your team's AI adoption, or are you flying blind? What would change if you could see exactly how AI tools are impacting your team's velocity and output?

2. As AI creates more efficiency, where are you reinvesting that time—into your product, your platform, or your people?

If you're wrestling with AI adoption strategy for your engineering team, we'd love to hear your story. Schedule a chat with us → https://cal.com/team/maestro-ai/chat-with-maestro

High Output is brought to you by Maestro AI. As your teams adopt AI tools to ship faster, staying aligned on what you're actually building becomes the critical challenge. Maestro cuts through the noise with narrative status updates that digest every ticket, code change, and team discussion—because in a world where you can build anything, you need clarity on what you should build.

Visit https://getmaestro.ai to see how we help engineering leaders maintain alignment in the age of acceleration.

From landscape design to heavy machinery operation to leading engineering teams, Tacita's unconventional path taught her that management isn't about having all the answers. It's about asking better questions. Now, as AI transforms how we build software, she's applying that same principle to help teams navigate an overwhelming abundance of possibilities.

🎧 Subscribe and Listen Now →

What’s inside (34 min):

→ The brick wall moment. Tacita's transition from engineer to manager felt like "running full force into a brick wall." Her solution? Stop asking "what did I ship today?" and start asking "how are my people growing?"

→ The information fire hose problem. With AI breakthroughs arriving faster than anyone can absorb them, Tacita's filtering strategy: problems first, technology second. "What challenges am I trying to solve right now?"

→ AI as your most honest critic. Tacita uses AI to get the unvarnished feedback her team might be too polite to give: "These systems won't hold back—they'll tell you when you're missing something your colleagues might be too polite to mention."

→ The end of rigid roles. Her prediction: role boundaries between PM, engineering manager, and designer will collapse as AI gives everyone superpowers across disciplines.

→ The focus challenge. When you can build anything quickly, staying focused on user value becomes the critical leadership skill: "You can do so much now—that's not what they're trying to buy right now."

Why it matters

We're entering an era where the constraint isn't what we can build—it's what we should build. As Tacita puts it: AI will "unlock creativity and invention," but only if we resist the temptation to build everything just because we can.

The companies that win won't be those with the fastest AI-assisted development cycles. They'll be the ones whose leaders can cut through the noise of infinite possibilities to focus on real human problems. This requires a fundamentally different kind of engineering leadership—one that prioritizes strategic thinking over technical prowess.

Tacita's vision of "smaller teams" and "fluid roles" isn't about cutting headcount—it's about unlocking organizational agility. AI enables large companies to move like small ones, where people collaborate more intensely, ideate more rapidly, and cross-pollinate ideas across dissolving role boundaries. The focus becomes what machines can't replicate: critical thinking, user empathy, and business judgment.

Your turn

Tacita's approach raises the essential question: In an age where you can prototype ideas in minutes and ship features in hours, how are you maintaining focus on what actually matters to your users and business?

In this age of abundance, what are you saying no to?

If you're wrestling with these challenges, we'd love to hear your story. Schedule a chat with us → https://cal.com/team/maestro-ai/chat-with-maestro

High Output is brought to you by Maestro AI. When AI lets your team ship faster, staying focused on what matters becomes the critical leadership challenge. As your engineers become more productive, Maestro cuts through the noise with narrative status updates that digest every ticket, code change, and team discussion. Because in a world where you can build anything, you need clarity on what you're actually building.

Visit https://getmaestro.ai to see how we help engineering leaders maintain focus in the age of abundance.

This week on High Output, Glenn Veil, SVP of Engineering at Order.co, shares how three decades of unplanned leadership taught him the most important lesson of all: technology will always evolve—but people remain the constant.

Glenn didn't start out aiming to lead. One sudden promotion, a broken website, and a confused loft full of engineers later, he found himself in charge—and completely unprepared. What followed was a trial-by-fire journey from tech-first problem solver to people-first builder of teams, careers, and future leaders.

🎧 Subscribe and Listen Now →

What's inside (23 min):

→ The accidental promotion. Glenn thought he was getting fired when the VP was waiting for him at the front door. Instead: "Glen, you're director of technology." He had to tell his new team: "Hey, I think I'm in charge now."

→ The hard lesson: people over code. Glenn started by focusing on what he knew—the technology. But he learned that engineering leadership isn't about fixing code; it's about developing the people who write it.

→ The great wave of leaders. Glenn's mission today: leaving behind a generation of engineering leaders who know they can succeed by being authentically themselves.

→ Reading people, not trends. His secret to staying ahead isn't predicting the next great technology—it's anticipating how people and teams will evolve through change.

Why it matters

As AI handles more of the technical heavy lifting, a counterintuitive truth is emerging: the human side of engineering leadership becomes exponentially more valuable.

Glenn's prediction is already playing out—companies will operate at dramatically lower costs within five years as AI optimizes processes. But the real competitive advantage won't come from deploying the smartest AI tools. It'll come from using those tools to create space for deeper people development.

Smart engineering leaders aren't just automating code—they're choosing AI solutions that help them understand their teams better, spot growth opportunities faster, and develop the kind of human leadership capabilities that no algorithm can replace.

As Glenn puts it: "I don't think we'll ever not need software engineers. But we will be leaner. And we'll need stronger leaders to guide the way."

The question isn't whether to adopt AI tools. It's whether you're choosing the ones that multiply your people's potential—not just their productivity.

Your turn

Glenn's approach raises the critical question: How are you using AI's efficiency gains? Are you reinvesting that time and mental bandwidth into developing your people—or just pushing for faster delivery cycles?

If you're ready to move beyond productivity theater and start building the kind of human leadership capabilities that will define tomorrow's engineering orgs, we'd love to hear your story.

Schedule a chat with us → https://cal.com/team/maestro-ai/chat-with-maestro

High Output is brought to you by Maestro AI. If you're an engineering leader looking to improve velocity while using AI efficiency gains to develop stronger teams, visit https://getmaestro.ai to learn how we help teams navigate the future of software development.