There is a type of software that shouldn’t exist anymore.
Not because it was badly built. Because the thing it did (aggregate menus, transcribe meetings, extract text from photographs, look up whether a whale is a mammal) is now handled by a model in a single call. The app was always just a wrapper around a workflow. The workflow has collapsed.
Andrej Karpathy described a version of this: take a photo of a restaurant menu, extract every dish, generate images for each one. A few years ago, that was an app. A pipeline of discrete steps, each one a small engineering problem. Now it’s a prompt.
We sat down to talk about where that logic ends. About which categories of software are genuinely collapsing, where the pendulum on chat-first interfaces is headed, and what it means to hire a developer in 2026. What came out was less a set of answers than a clearer picture of where the actual hard problems are.
The short version: speed is solved. Judgment isn’t. And by making construction this fast, we’ve made the judgment layer both more important and harder to develop.
What AI actually collapses
The clearest examples are the ones that were always pipelines.
OCR: solved. Bounding box detection: solved. Meeting transcription and summary: solved. The common thread is that each of these was a series of steps that required discrete engineering decisions at every joint. Now a model handles the whole thing in one pass.
Achal put it directly:
“Think of ideas the model can actually directly eradicate. Not just accelerate. Not just simplify. Eradicate.”
The distinction matters, because it changes what you should be building.
The counterargument is that this is less about eradication and more about what sits on top. A model can summarize Wikipedia, but Wikipedia still has to exist somewhere. What’s gone is the interface layer — the need to navigate to it, search it, browse it. The model becomes the front door. The source material shifts down the stack.
Both readings are probably right, depending on the category. For historical, static content, the interface is irrelevant. For anything that changes frequently — developer documentation, live data, recent research — the source still matters. The model is faster than search. It isn’t fresher than the thing it’s summarizing.
What this means practically: if you’re building a product right now, the first question isn’t whether you can build it. It’s whether it should exist. Some apps are pipelines with a UI. The pipeline is gone. The UI doesn’t save it.
We’ve overcorrected on chat
Everyone said AI meant chat-first. Put the model at the center, give users a conversational interface, let them talk to the software instead of clicking through it.
That’s too far.
Achal said it plainly: “I completely disagree. I think it’s not just chat. We’ll go back to traditional interfaces.” Not because chat is useless — it isn’t. Because chat is the wrong medium for a lot of what people actually need to do. You can’t plan your month in a conversation. You can’t manage work-in-progress from a list of messages. You can’t see your whole calendar in a prompt response. Sometimes you need to move pixels. Sometimes you need a space to think before you even know what to ask.
The real interface challenge isn’t replacing UI with chat. It’s figuring out the right ratio. Where does the conversational layer end and the interactive layer begin? Some workflows belong in chat. Most don’t. The products that will win are the ones that know the difference.
Sid’s version of this is different but compatible. Traditional interfaces won’t go away. They’ll become more generative. A dashboard stops being static and becomes contextual — it knows what you care about this week and surfaces it without you asking. The interface evolves. It doesn’t disappear into a text box.
What’s coming isn’t a chat-first world. It’s a world where the right interface for each task finally gets built, and AI makes those interfaces dramatically more responsive to the person using them.
“We’ve gone too far by saying everything is just chat. Sometimes you need a space to work in — not just a model to talk at.”
— Achal, CPO
The job shift nobody’s named correctly
Sid asked a question midway through the conversation: “Would you say the role of a developer has evolved from constructing software to orchestrating it?”
Achal said yes immediately.
Sid said yes, but here’s the problem.
Orchestration requires judgment. And judgment is something that only comes with time — with having built things wrong, with having felt the weight of a bad architectural decision six months after you made it, with knowing what a production system under real load actually behaves like. The kind of knowledge that doesn’t come from exposure. It comes from experience.
If the construction layer is increasingly delegated to models, where does the next generation of developers get the experience that builds that judgment? You can’t shortcut it with faster tools. For the developers being hired today, that friction was part of the point.
Achal’s counter is worth taking seriously. Some of that judgment is already in the model. Ask it to build a Kanban board and it will build an optimized version — not because it invented the Kanban board, but because it has absorbed every implementation that came before. The model carries accumulated engineering wisdom in a way a junior developer can’t, yet.
Sid’s follow-up is the harder question: who invented the Kanban board? What’s the next thing that replaces it? Innovation doesn’t come from absorbing what already exists. It comes from people who understand the problem deeply enough to see what’s missing. If you’re delegating construction and absorbing judgment from models, where does the new thinking come from?
Neither of them had a clean answer. Achal is more confident that the industry corrects itself, that a new kind of practitioner emerges. Sid is less sure. What they agreed on: the judgment layer is now the whole job, and it’s the part that can’t be prompted.
“Orchestration requires judgment. And judgment only comes with time — no matter how smart you are.”
— Sid, CTO
The prototype trap
Here’s a problem that’s getting worse.
AI lets you build a working demo in 48 hours. A functional prototype, real UI, plausible data flows, something you can click through and show. The kind of thing that would have taken four weeks of back-and-forth, written documentation, and design reviews.
Now it’s a two-day sprint.
The problem isn’t the prototype. The problem is what the prototype does to the conversation after. Once someone sees something working, the gap between “demo” and “production-ready” becomes very hard to explain. They saw it work. The mental model is set. Every subsequent conversation about compliance layers, edge cases, scalability, and security runs uphill.
This isn’t a new dynamic. It’s an older one, compressed. Before, you had four weeks of friction that forced you to articulate what you were actually building. The questions got asked because you had to ask them before anyone would write a line of code. Now the code comes first and the questions come after — if they come at all.
Uber’s product team put it well: “Two hours of prototyping unblocked four weeks of discussion.” That’s the upside. The fix for the downside is pairing prototype speed with the discipline of a PRD running in parallel. The prototype shows what’s possible. The document forces you to articulate why it’s worth building and what it actually needs to do. One without the other is faster but worse.
Achal thinks clients are increasingly sophisticated enough to understand this distinction. They have access to the same tools now. They can build prototypes themselves. That changes what they’re hiring for — they want judgment, not just build velocity.
Sid thinks that sophistication is still the exception.
Both are probably right, depending on your client. The question worth asking before your next demo: does the person in the room know what they’re looking at?
“Once you show the demo, explaining why it’s not done has never been harder.”
— Sid, CTO
Who you’re hiring in 2026
We asked the room: given all of this, has what you’re looking for in a hire actually changed?
For mid-to-senior engineers, the short answer is yes but not dramatically. Familiarity with agentic workflows matters now — you want someone who understands how to work with models, not just alongside them. But the assumption is still that they’re coming from a strong implementation background. They’ve written code by hand long enough to have the judgment layer Sid was describing. That foundation still matters. Maybe more than ever, since construction is increasingly handled by the model.
The harder question is junior engineers.
Achal’s signal for a new hire: do they know how a large language model actually works? Not how to use it. How it’s built. What’s the architecture? Why it behaves the way it does. He made the comparison to compiler design — when he learned to write a compiler in school, it unlocked how he thought about programs at a fundamental level. Understanding model architecture does the same thing for AI. Surface-level utility isn’t a skill. Curiosity about the internals is.
Rishav said something honest near the end: “I’m still figuring out how a junior engineer in this industry is going to gain that understanding.” That’s the real problem. The tools are capable enough that it’s easy to feel competent without developing depth. The friction that used to force understanding — having to build something hard, slowly, and feel it fail — is largely gone.
The same problem is playing out in design.
Xenia pointed out that large tech companies have mostly stopped hiring junior designers. Not because junior designers can’t contribute, but because the economics of training don’t justify it when AI handles so much of the production work. The bar for a junior hire now includes visual design, motion, UX principles, and the judgment to know when the AI output is wrong. That’s a lot to ask of someone with no track record.
“You still need a great eye,” she said. “And that only comes from experience.” The tools that made design more accessible are simultaneously making it harder to break in.
“Don’t just know how to use it. Know how it works. That’s the signal I’m looking for.”
— Achal, CPO
Is this bigger than the internet?
Someone asked near the end of the conversation whether AI feels as exciting as the early internet.
Achal said yes, and described being ten years old, hearing the modem sounds, getting onto a bulletin board for the first time. It felt like that again. The same sense that the rules hadn’t been written yet. That everyone had access to something new and nobody knew what to do with it.
Sid’s distinction is worth sitting with: the internet was about information. This is about intelligence. That’s a different category. The internet reorganized access to what humans already knew. This is closer to reorganizing what intelligence itself looks like — how it’s distributed, how it compounds, what it means for a person or a company to be capable of something.
The honest position, which everyone in the room arrived at eventually: nobody knows what comes next. The confident predictions are mostly wrong. The people paying the closest attention are the ones willing to say so.
Karpathy said something near the end of his Sequoia talk that stuck with us: “You can outsource your thinking, but you can’t outsource your understanding.” The people directing agents still have to understand what they’re building and why. That bottleneck doesn’t compress.
What we do know: the construction problem is largely solved. What’s left is figuring out what to build, whether it’s right, and whether the people building it have the judgment to tell the difference. That part is harder than ever. And it doesn’t get easier by building faster.
Speed is solved; judgment isn't.
If you’re building software and finding that the construction layer is the easiest part, we’re glad to compare notes on what comes next. Book a 15-minute intro
