Experts as Developers in the Age of The Vibe

For decades, software development operated with a fundamental divide. Not just between teams or departments, but between technical and non-technical people. Domain experts wrote specifications. Developers turned those into code. Product managers translated between worlds. The system relied on maintaining this separation—and on clean handoffs across the technical divide.

But today, that structure is breaking down. And not because of a new methodology—but because of a new capability.

A new approach—what some call vibe coding—is emerging, where domain expertise and software implementation happen in the same breath. AI is making it possible for domain experts to build. Not just wireframes or prototypes, but working systems. And in doing so, it is collapsing one of the longest-standing separations in software: the distance between those who build and those who need something built.

The Technical/Non-Technical Divide

The traditional software industry was built on a premise: that building software required specialized technical knowledge that most people couldn't or shouldn't acquire. This created a world where the people who understood the problem (domain experts, end users, business stakeholders) were fundamentally separated from the people who could implement solutions (developers, engineers, technical teams).

This divide shaped everything: organizational structures, project methodologies, communication patterns, and career paths. It also created an inevitable translation layer—requirements documents, user stories, acceptance criteria, user avatars, empathy boards, journey maps—all attempts to bridge the gap between what non-technical people needed and what technical people could (or would) build.

The consequences of maintaining this divide have been profound. Open source software, despite its technical excellence, has consistently struggled to create first-class experiences for non-technical users—a direct result of developers building primarily for other developers.

Don’t find customers for your products, find products for your customers.
- Seth Godin

Meanwhile, the startup world is littered with failed companies that began with technical hypotheses rather than real-world problems grounded in the actual experiences of their target users. These failures stem from the same root cause: the separation between those who understand problems and those who can implement solutions.

When User and Developer Are the Same

Interestingly, open source, for the most part, has long operated outside this divide. In most open source projects, developers build tools for themselves—unifying the roles of user and creator. Eric Raymond captured this in his seminal essay The Cathedral and the Bazaar, describing the dominant model as “itch-to-scratch”: developers solving their own problems through code. This approach bypassed the builder/user split entirely, because the person who needed the tool was also the one building it.

Every good work of software starts by scratching a developer’s personal itch.
- Eric Raymond

The Itch-to-Scratch (ITS) method represents a fundamentally different methodology where:

• Requirements emerge from personal need, not translation
• The builder is the primary user
• Feedback loops are immediate and direct
• No handoffs exist between problem and solution

This methodology succeeded precisely because it eliminated the distance between technical and non-technical perspectives—not by moving people closer together, but by making them the same person.

Forward Deployment: Collaboration and Extraction

However, the software industry's attempts to address the builder/user divide have historically focused on proximity rather than convergence. This has taken two distinct forms, with very different intentions.

The Collaborative Model

Code for America pioneered the hopeful version in civic tech, embedding developers directly within government departments to understand processes from the inside.

The model proved that placing technical talent where the actual work happened revealed inefficiencies invisible through traditional requirements gathering. This forward deployment philosophy spread to companies like Palantir and Anduril, popularizing embedded engineers who solved problems in real time with deep contextual understanding.

The pattern was consistent: proximity to the domain yielded better solutions through genuine collaboration between technical and domain expertise.

The Extractive Model

But in the age of AI, this proximity model has taken a darker turn. Financial stakeholders in commercial operations see the opportunity to increase profits by reducing expenses (i.e., salaries), so they deploy forward-deployed engineers to follow team members in order to encode their work into AI workflows—essentially using proximity to automate away the very people they're studying.

Here, proximity serves extraction rather than collaboration. Together, domain knowledge and implementation skill create solutions neither group could envision alone—but that potential is squandered when proximity becomes a tool for replacement rather than empowerment.

The Stakes

AI brings both models closer together in capability, but the outcome depends entirely on power and intent. The technology that enables collaborative augmentation also enables systematic replacement. Whether proximity leads to empowerment or elimination comes down to who controls the tools and how they choose to deploy them.

Founders should think about themselves as being the forward deployed engineers of their own company.
Garry Tan, Y Combinator CEO,

Whether used for collaboration or replacement, these approaches were/are cultural innovations that reduced the gap between technical and non-technical worlds. But they still maintained the fundamental divide—they just made the translation more efficient.

Vibe Coding Extends Open Source's Itch-to-Scratch Model to Non-Developers

Now AI is enabling something different entirely. Where open source succeeded through developer-users, AI now enables domain experts to become functional developers without needing traditional technical training.

In fact, expert-driven projects have existed before—but with serious constraints. The notion of expert-driven development, where domain experts tell developers what to build, has existed in some open source projects: experts in healthcare, finance, and education initiate projects and hire technical teams to build their vision. But this approach faces significant barriers. It required substantial resources because non-technical users had to hire technical teams to implement their vision—when you need someone else to scratch your itch, it becomes an expensive game. It also still involved handoffs between expert and implementer.

More fundamentally, most development houses resist this way of working, feeling that understanding requirements and defining solutions—"knowing what to build"—despite their lack of domain expertise, is part of their core skillset. This professional resistance meant expert-driven development remained rare, even when resources were available.

The term "vibe coding" describes the breakthrough that changes this dynamic entirely: conversational, iterative development where you describe intent and AI proposes implementation. It's programming aligned with expertise rather than engineering—you need domain fluency and the ability to iterate, not computer science training.

Where domain experts previously had to convince developers of their vision and wait for implementation, they can now build directly. A climate scientist can now directly implement a data visualization tool. A policy analyst can build a legislative tracking system. A teacher can create an interactive assessment platform. They're not collaborating with developers—they are developing.

This represents a return to the itch-to-scratch model, but extended beyond technical domains. The climate scientist doesn't need to learn software architecture to run models and visualize results. The lawyer doesn't need to understand databases to cross-reference legislation. The teacher doesn't need to know JavaScript to build interactive worksheets.

In each case, the expert becomes both user and developer—merged identities that mirror the convergence that made open source successful, now available to non-technical domain experts.

What Happens When the Distance Collapses?

This convergence fundamentally changes team dynamics. Where traditional projects required researchers, product managers, and developers—each representing different sides of the technical divide—now a single expert can fill all roles.

The benefits mirror what we see in successful open source projects:

Immediate feedback loops: No translation between user need and developer implementation because they're the same person.

Perfect requirement fidelity: No specification documents that lose nuance—the builder directly experiences the problem.

Contextual solutions: Tools emerge from actual use cases rather than abstract requirements.

Rapid iteration: Changes happen at the speed of thought rather than sprint cycles.

This won't replace all software engineering—complex systems still need architects and infrastructure specialists. But it renders traditional development processes unnecessary for a huge class of problems where the primary constraint was the technical/non-technical divide.

We Are All Devs Now

We're witnessing a methodological revolution comparable to the shift from waterfall to agile, but more fundamental. Where agile changed how we manage development processes, AI-assisted expert development eliminates entire categories of process. The Itch-to-Scratch methodology that made open source the dominant force in software infrastructure is now available to every domain expert.

While this shift empowers solo expert-builders, it also redefines how teams collaborate—less about translation, more about alignment.

The consequences extend beyond efficiency gains. When domain experts can build their own tools, innovation happens faster and more precisely. Solutions emerge that developers without domain knowledge would never conceive. The pace of progress in every field accelerates when the barriers between problem identification and solution implementation disappear.

The technical/non-technical divide that shaped decades of software development is finally collapsing. This separation limited who could participate in building the digital world. The future belongs to domain experts who can think computationally about their fields.

In this new paradigm, many more people can become developers—not by learning to code, but by learning to build. The collapse of distance isn't just about efficiency. It's about imagination—about who gets to build, and what they build next.