Listen to this episode on Spotify or Apple Podcasts
Yaron Schneider, CTO of Diagrid and creator of the Dapr open-source project, makes the case that technical design documents — upfront planning, architectural thinking, written specs — are now more valuable than programming. The engineers who figure this out first are going to look very different from the ones who don’t.
The best engineering team I ever worked with had a rule that drove everyone else crazy.
Before a single line of code got written — even for a small feature — you had to produce a technical design document. Not a ticket. Not a Slack summary. A written plan, down to the GraphQL queries, with architecture diagrams at level zero, level one, level two. The whole thing reviewed by staff engineers who would tear it apart and send you back to rethink your approach.
It added one to two weeks to every project. Sometimes a month for bigger features. As a product person, I wanted to scream. We could’ve just been coding this thing.
But when they shipped, it worked. Every time. Within tight timeframes. With almost no rework.
They moved slow to move fast. And at the time, that felt like a luxury — a high-performing team’s eccentricity that most organizations couldn’t afford because the opportunity cost of not shipping was too high. If we’re not building, what are we missing?
Then AI got good. And the thing I didn’t see coming is that it didn’t make that team’s approach obsolete. It made it universal.
I’m talking with Yaron Schneider about this — CTO and co-founder of Diagrid, creator of Dapr, five years at Microsoft building open-source infrastructure before starting his own company in 2022. He’s been watching the same shift from the other side, working with enterprises deploying AI agents at scale.
“Most software doesn’t work the way intended it to do because you skip the design stage or the architectural phase,” he says. “And so if you invest more in that, then it doesn’t matter who gets the job done, whether it’s AI or human, the job will be better.”
Whether it’s AI or human. That’s the line I keep replaying. Because the implication is that planning isn’t a step in the engineering process. It’s the engineering process. Everything after the plan is execution — and execution is increasingly something you delegate.
“This is now the central job of the software engineer,” Yaron says, “who hands over the work to an automated machine.”
He says it matter-of-factly. Like he’s describing something that’s already happened, not something that’s coming. And in the companies he works with, it has. The engineers who are thriving aren’t the fastest coders. They’re the clearest thinkers. The ones who can write a spec that an AI system — or a junior, or a contractor, or an offshore team — can execute without ambiguity.
But there’s a problem with this picture, and Yaron doesn’t shy away from it.
“Microsoft’s Mark Russinovich released a paper on it,” he tells me. “And what they’ve come up with is that junior developers are essentially no longer needed.” He lets that land. “And that’s a very harsh reality statement that came from them.”
I ask him to keep going.
“Well, now you need senior engineers to oversee AI because someone needs to write the prompt. Someone needs to guide it, someone needs to provide guardrails. And all of that is extremely needed.” He pauses. “But how are you gonna get senior engineers if there’s no junior engineers anymore?”
This is the question nobody has a satisfying answer to. The entire career ladder in software engineering was built on a progression: you start junior, you write a lot of code under supervision, you develop taste and judgment through repetition and mistakes, and eventually you become senior. The junior years aren’t a formality. They’re the training ground where the skills that matter — critical thinking, architectural intuition, the ability to foresee downstream consequences — get forged through thousands of small decisions.
If you remove the bottom rungs, the whole ladder collapses. Not immediately, but inevitably. You end up with a generation of senior engineers who age out and nobody behind them who learned the craft by doing it.
Yaron sees a path through it, but it requires rethinking what a junior engineer’s job actually is.
“I think historically we expected junior engineers to be able to churn out code really fast and produce a lot of it,” he says. “And now I think it’s gonna get flipped on its head where junior engineers are gonna be measured on their ability to adapt to new skills and learn really quickly.”
Less outputting and more inputting, he says. Juniors won’t be valued for how much code they produce. They’ll be valued for how quickly they can absorb context — reading documentation generated by both humans and AI, synthesizing it, building mental models of complex systems, and then translating that understanding into clear instructions for what they want to achieve.
“They have access to tools that can 20x what they do manually and also explain things to them in a very concise way,” he adds. And he’s right — the same AI tools that threaten to make juniors obsolete are also the best mentoring resources those juniors have ever had access to. In a world where team leaders are overloaded and senior engineers don’t have time to explain architecture decisions, an AI that has access to your entire codebase, your commit history, your past design documents, can drive context to a junior in minutes that would have taken weeks of hallway conversations and Slack threads.
The bar goes up for everyone. But the floor goes up too.
I’ve been living this shift myself. I started my career as a designer, moved into product management because the strategic work I wanted to do was too expensive to justify as a designer — the execution ate all the time. Then AI got good during my PM tenure, and everything inverted. The schlep work evaporated. Meeting notes wrote themselves. Decision docs assembled from context I fed in. I could plan at velocity for the first time.
And then I realized my job was constraining me. I could plan and execute now. So I went back to design.
The thing that changed isn’t that execution got easier — it’s that planning got cheaper. Not in quality, in friction. I used to rough out two or three concepts and pick the best one. Now I’ll do a hundred concepts because I have what amounts to a junior designer running variations while I think about the strategic framing. The idea I eventually hand off to engineers isn’t a guess anymore. It’s been stress-tested against a hundred alternatives.
“The idea that I’m handing off to engineers — it’s fucking proven,” I tell Yaron. “It’s steelmanned. We thought through everything at that point because I’ve had time to plan.”
He nods. “Resonates with me.”
And that’s what makes this moment different from every other wave of tooling that was supposed to change how software gets built. Low-code didn’t do it. Agile didn’t do it. DevOps didn’t do it. Those were all execution optimizations — ways to make the building part faster or cheaper or more predictable. But they never touched the planning part. They never shifted the identity of the engineer from someone who builds to someone who thinks.
AI does. Not because it’s a better tool, but because it makes the building so cheap that the only remaining competitive advantage is the quality of what you decide to build. The plan becomes the product. The spec becomes the artifact that matters. And the engineer who can write a plan so clear that any execution system — human or machine — can implement it without ambiguity becomes the most valuable person in the room.
Yaron’s company exists because he understood this at the infrastructure level. Diagrid doesn’t build agents. It builds the reliability layer that lets agents execute plans at enterprise scale without crashing, without losing state, without starting over. The whole business is predicated on the idea that execution is delegatable — and that what matters is the system that makes delegation trustworthy.
But the insight applies everywhere. Every engineering team, every design team, every product organization is going to have to answer the same question: if execution is no longer your bottleneck, what is?
The answer is the plan. It was always the plan. We just couldn’t afford to admit it when building was expensive.
Guest Bio
Yaron Schneider is the Founder and Chief Technology Officer at Diagrid, where he leads the development of distributed systems platforms that power durable workflows and AI agents for cloud-native teams worldwide. Rising to prominence in the late 2010s through his work on cloud infrastructure at Microsoft, he became known for co-creating the CNCF projects Dapr and KEDA, which today serve tens of thousands of organizations building microservices and event-driven applications. As Chair of the Workflows Working Group at the Agentic AI Foundation, he is widely regarded as an influential figure in defining how large-scale agentic systems are orchestrated and operated in production.
Previously, as Principal Software Engineer on Azure Container Apps at Microsoft, Schneider helped design and ship a serverless platform that enabled customers to run containerized microservices and event-driven workloads without managing Kubernetes directly, driving adoption across thousands of production clusters and multi-million-dollar cloud accounts. In earlier roles on the Azure CTO Incubations team, he focused on high-scale distributed systems and developer platforms, work that culminated in Dapr’s acceptance into the Cloud Native Computing Foundation in 2021 and its graduation to top-tier status in 2024, alongside Kubernetes and Prometheus. By 2025, the Dapr ecosystem was engaging over 40,000 companies across finance, healthcare, retail, and SaaS, and more than 90% of surveyed developers reported measurable time savings when building distributed applications with the runtime.
Schneider’s career highlights also include serving as Division CTO at ironSource from 2013 to 2015, where he led engineering for high-throughput advertising and monetization systems processing billions of events per day across mobile and desktop. Earlier, as a software architect at SuperDerivatives and a hands-on architect at Ness Technologies, he worked on low-latency, mission-critical platforms in financial technology and enterprise software, gaining the deep distributed-systems experience that later shaped his open-source work. Through Dapr, KEDA, and Diagrid’s Catalyst platform, Schneider’s contributions have helped standardize patterns such as workflow-as-code, event-driven autoscaling to and from zero, and durable agentic workflows across Kubernetes and multi-cloud environments.
Hey,
Thanks for reading this. I mean that. There's a lot of content out there competing for your attention, and you spent some of it here. I hope it was worth it. Even better, I hope it prompted you to think about something differently enough that you'd share it with someone who'd get something out of it too.
I started this podcast because tactics never stuck with me. What stuck were stories — business biographies, autobiographies, the decisions people made and why they made them. The principle only clicks once you know the story behind it.
So I built the thing I wanted to read. Every week I have two conversations with people who build in technology and product. Then I write the essay I wish I could find — one that puts you inside the conversation, through my eyes. What caught me off guard. What I kept thinking about after we hung up. Where the principle actually lives once you strip away the jargon.
I make this for myself first. If you read the way I do, you’ll want it too.
PS — If you want to pitch coming on the show, or you know someone I should talk to, shoot me an email at caden@hey.com with "January752" in the subject line so it gets past my filters. I'm not optimizing for famous guests. I'm optimizing for interesting conversations, even from people who aren't LinkedIn influencers.
