Back to blog
·10 min read

The Future of Software Development

What will the future of developing software look like?

Software DevelopmentAIAgentic Coding
View Markdown

TLDR

The barrier to entry for building software is lower than ever and is only continuing to get lower. Many trends are converging towards a future product where users will create and maintain software using plain English as the "programming language" and the "source of truth" for how the product works will shift from source code to English. The underlying source code and technology will be completely abstracted away.

Intro

I have been developing websites for 15+ years. There is a lot to do to build and launch a website. At every layer of the stack, there are many decisions to be made and technologies to choose from. The learning curve can be steep, and historically this has created a fairly substantial barrier to entry for non-technical folks to build websites.

But during this same time, tooling at each layer of the stack has drastically evolved to abstract away the monotonous parts of building websites, if you choose. Today it only takes a couple of seconds to integrate your GitHub account with hosting providers like Vercel and Netlify, abstracting away that concern. Opinionated frameworks make decisions on your behalf to ease the cognitive load and allow you to focus on what matters the most: building the unique features that differentiate your product. Again, this kind of innovation has been happening at every layer of the stack for a long time.

The Evolution of Programming Languages

When you consider that we went from machine code -> assembly -> high level languages, there has been a clear trend towards making code read more like English. Why? It's simple. The source code is the source of truth of **how the software works**. It is advantageous to humans (and now AI systems) to make the source of truth as easy to understand and reason about as possible. The easier it is to _quickly_ understand how the product works, the faster we can make changes. The more the code reads like English, the faster the development speed. Speed to market is a significant competitive advantage in today's world.

The Source of Truth Problem

The real source of truth for how software works has always been the source code. This is why we've designed the source code to read more like English over time. But even with modern languages, accurately reasoning about how the software works still requires a significant amount of time and effort. So we've come up with band aid solutions to help with this problem. **We derive English from the source code.** We add code comments because we can write them in plain English. We write layers of documentation in plain English. We create diagrams and flow charts to visually represent how the software works. All of this in an effort to help the maintainers better understand the code. The problem is, the source code is still the source of truth of how the software actually works, so as it changes over time, we've now introduced the "tech debt" of maintaining all of these additional artifacts. Humans have historically been bad at remembering to keep these derived artifacts in sync with the source code changes.

The historical pattern looks like this:

> source code -> English (comments, documentation, diagrams) -> understanding of how the software works

The takeaway is: the source code is the source of truth, but because it's not easy to reason about, we've created additional "sources of truth" to describe how the software works. The intention is good, but this solution has led to additional problems.

The Tipping Point

It undeniable that AI coding tools have dramatically changed the biggest bottleneck in software development. Creating the product (writing the code) used to be **slow** and **expensive**. Now it's **fast** and **cheap**. It cannot be overstated how monumental this shift truly is. The bottleneck is now our ability to generate quality ideas and to effectively communicate those ideas to the AI coding tools to build the software.

Agentic Coding

We are seeing solutions from OpenAI, Anthropic, and open source projects that are all focusing on long running agents and agentic loops. The Ralph Wiggums concept was all over Twitter in late 2025. Matt Pocock has <a href="https://www.aihero.dev/getting-started-with-ralph" target="_blank">a great article</a> describing this concept and how to implement it. I've been using this system for my own projects for a few months and I've found that it works VERY well.

The PRD.json File

I think the groundbreaking concept in all of this is the prd.json file. The idea is that your features are contained in single file, written in plain English. This is a living file that changes as your requirements change. The prd.json file defines the source code instead of the source code defining what is in the comments, documentation, etc. I really think this is a fundamental shift in how we think about software development. Although the source code is technically still the source of truth of how the software works, from the human perspective, we are now treating the prd.json file as the source of truth and leveraging AI coding tools to ensure the source code aligns with the prd.json file.

The key features of the prd.json file are:

  1. A single file that defines all of the requirements/features of the software
  2. Defines how each feature should be tested
  3. Defines the state of each feature (passing boolean)
  4. Since source code is derived from this file, every iteration of our software begins with an update to this file

Businesses Don't Care About Technology Decisions

So long as humans have been writing software, we've been having debates about every little technical decision. Engineers have become opinionated based on their experience and preferences. We have spent a lot of time making technology decisions, nitpicking in code review, and so on. All of this was justified and productive in the age of human coding.

But at the end of the day, a business doesn't care about any of this. They want to bring a product to market. The business really only cares about a few main things:

  1. Does it function the way we want it to function?
  2. Does it look the way we want it to look?
  3. Does it perform well enough to provide a good user experience?
  4. Is it reliable?

The business doesn't care if you use React or Vue, Tailwind or plain CSS, PostgreSQL or MySQL. Engineers care about these things; the business does not. Businesses have to hire engineers to build software, and engineers care about these things, so we've spent a lot of time focusing on these things over the years and businesses have foot the bill.

But with the evolution of tooling at every layer of the stack, combined with increasing abilities of agentic coding tools, these technology decisions are becoming less and less relevant when the goal is bring a product to market as quickly as possible.

The truth is, the technology decisions that we spent so much time debating in the past are becoming less important in the future of software development. So long as the product functions the way we want, looks the way we want, meets some basic performance requirements, and is reliable, why does anything else really matter?

Demand for Software

Software powers our digital world. I don't see any signs of this demand slowing down. In fact, I think it's clear the demand for software is only increasing. And now we are in the age where building truly custom software for your specific needs has become fast and cheap. I don't see how this doesn't also increase the future demand for software.

The Future of Creating and Maintaining Software

We are at a point in time where these trends are all converging. When you put it all together, I see a future product where users will create and maintain software using plain English as the "programming language" and the "source of truth" for how the product works will shift from source code to English.

Maintaining software will be simply managing a list of features over time (a prd.json file) and letting the AI coding tools take care of translating those features into source code.

I think the future pattern will look like this:

> Requirements in English via UI + underlying prd.json file (source of truth from human perspective) -> source code (still real source of truth) -> working software product

This is the key insight: **we are now deriving the source code from the English requirements.** This is a fundamental shift in how we think about software development. The source code is still the real source of truth, but from the human perspective, we are treating the prd.json file as the source of truth and leveraging AI coding tools to ensure the source code aligns with the prd.json file.

If we can successfully accomplish this:

- English becomes the programming language of the future.

- The source of truth shifts from source code to English (hypothetically).

- The underlying source code and technology is completely abstracted away.

- Anyone can create and maintain custom software without needing to learn how to code.

Conclusion

In this article I've focused specifically on web development, but the same is true for all areas of software development.