Beyond Code
What AI can’t do—and what great engineers now must.
"Software is dead. Long live software!"
Software engineering isn’t dying. But the center of gravity is shifting.
AI can now scaffold apps, write integration code, summarize logs, and refactor boilerplate in seconds. The bottleneck used to be the ability to write working code at scale. Now, the bottleneck is something else entirely.
We’re entering an era of the great re-bundling of software creation—where the real advantage lies in the ability to synthesize across layers of abstraction, not just operate within one.
For the last two decades, software development has been trending toward unbundling. Engineering, product, design, data, DevOps—each became a distinct specialization. But as AI takes over the repetitive parts of each role, what's left is the work that spans disciplines. The parts that require context, coordination, and consequence.
The most valuable engineers today are no longer just “code jockeys” churning out 1,000 lines a day. They’re multidisciplinary thinkers—translators between product, users, data, infrastructure, and the real-world constraints of the domain they’re working in.
The core of engineering leverage is no longer found in typing faster. It’s in bridging problem and solution—carrying context from the messiness of the real world into the structure of the system.
Context is the new center of gravity
Not just "context" in the technical sense (environment variables, inputs, dependencies), but the broader context:
What is the actual workflow a user is trying to complete?
What are the organizational, physical, or regulatory constraints that shape the edge cases—and determine whether a product is even adoptable?
What downstream systems does this decision affect?
AI tools can help write a function to validate a medical billing code. But they can’t yet understand whether that product actually gets used—or why it might silently fail to be adopted. They can’t yet understand:
Why that code exists
How it relates to insurance claims processing
What mistake would cost someone their coverage
Or which physician’s workflow might quietly break if it changes
That’s the kind of context someone needs to carry—whether it’s the founder, the PM, or a technically curious operator. A context-less coder can build something impressive that no one ever wants to use. A great founder, in contrast, is in love with the context. They shape the product from within it. But when engineers carry it too, the loop gets tighter and the product gets better.
The best engineers I’ve worked with—especially in sectors like healthcare, fintech, logistics, and industrial automation—don’t start with the spec. They start with the user, the environment, and the failure cases. They build from the problem space out.
The shift from vertical to Venn diagram
In the past, engineering roles were often narrowly defined: backend, frontend, DevOps, data. But what AI is doing is compressing the work at the edges—boilerplate, glue code, integrations. What’s left in the center is where disciplines blur.
The most valuable engineers increasingly sit in overlapping territory:
Part systems thinker
Part product designer
Part workflow anthropologist
Part internal evangelist
They write fewer lines of code—but make each one count more. They often pair tightly with operators, designers, clinicians, or sales engineers. They might be the only ones on the team who can spot the disconnect between what’s technically possible and what the real world will actually tolerate.
Founders: who you hire matters more than how fast they ship
Founders often ask me, “How do I know if a technical hire is great?”
My answer has changed over the last few years.
Of course you want engineers who can ship. But the ones who really move the company forward are the ones who:
Ask how the workflow actually plays out in the field
Notice friction that product didn’t spec
Question why an integration exists in the first place
Understand how system boundaries evolve over time
In an AI-native team, these engineers will still use Copilot, GPT, and AI tooling—but they’ll use them with the judgment of someone who knows what matters.
There’s a reason YC reveres technical founders—and teaches them to test their ideas in the real world every day. That culture of multidisciplinary fluency is part of what makes those companies dangerous. My hope is that mindset spreads more broadly: that technical contributors across every stage and industry take responsibility not just for code, but for consequence.
Investors: look beyond the demo
It’s never been easier to demo something impressive. But the moat isn’t in the output—it’s in the alignment between product, data, and environment.
When evaluating a technical founding team, I now listen for clues about:
How they think about decision quality, not just velocity
Whether they’ve sat with users, or just assumed from afar
What happens when something breaks downstream
If a team can articulate the non-obvious risks or edge cases in their domain—and how they’ve encoded those into the system—I lean in.
The AI layer is real. It’s accelerating output. But it’s also revealing where our biggest gaps have always been: in judgment, understanding, and cross-disciplinary clarity.
The most valuable engineers of the next decade may not be the fastest coders. They may not even be the most "technical" in the traditional sense. They’ll be the ones who can synthesize across the stack—bridging real-world constraints and system architecture. They won’t just write code. They’ll encode understanding.
Stay tuned for post 2: Taste is the new 10x.