Writing a To-Do App in 2027
After watching the exponentially explosive events happening around OpenClaw and watching the spectacular discussions that agents are making on Moltbook in the last 60 days alone, I am almost convinced that by 2027 we will start building software in plain English language, radically changing the programming paradigms completely.
Out of pure curiosity, I wanted to imagine what that future of software engineering will look like with a fictional codebase for a simple to-do app that will be built in 2027 using the new paradigm, with possible tools, new architecture, and infrastructure.
Note: jump to the fictional codebase on GitHub if you want to skip the explanations and just see the codebase structure and contents.
This is not about using AI to write code, but rather about building software solutions in plain English, rather than writing any code at all.
Quick Overview and Terminology
Here are the fictional terms that I imagine that will be popular in 2027. After this we will see a sample codebase for the to-do app, along with the architecture and infrastructure details.
Agent Engineering: In 2027, a new discipline called "Agent Engineering" will start to replace traditional software engineering. Instead of building software with code, we will be building Agents in plain English instructions. Read a detailed post from LangChain on Agent Engineering.
Agents, Sub-Agents: Agent is already a known term — nothing but an AI tool that can perform tasks. Sub-Agents are like sub-modules in traditional software engineering. Like a dependency, or a library that you will add to your main project. For example, a "database agent" will require a "PostgreSQL sub-agent" to work. Note that everything is still in plain English, with optionally some parts in traditional code for specific tasks.
Main Application Agent: This is the main agent, in our case, the to-do app. It can have sub-agents as dependencies. Sub-agents may have further sub-agents. For example, our "to-do app" is a Main Application Agent, with a "database sub-agent" as a sub-agent. This database sub-agent will have a "MongoDB sub-agent". Everything is bundled in a single folder, starting with the main file,
app.agent.md.Agent Runtime (ART): A new, LLM-based execution environment/runtime that can start and run a Main Application Agent. Imagine how Docker runs Docker images. Or how JVM runs Java binaries. Or VirtualBox running Windows inside. Companies like OpenAI, Anthropic, Google, etc., will come up with their own Agent Runtimes. There will be fierce competition on this space. These runtimes can run any Application Agents, as long as they follow the same architecture and structure — just like we have V8, SpiderMonkey, Chakra, etc. for running JavaScript.
Agent Brain: The Agent Runtime loads a Main Application Agent from a folder, along with all their sub-agents and other documents, and it builds a "brain" image that is just built for running this particular use case. This "brain" becomes alive within the ART runtime. The brain can accept REST-like API calls, or CLI inputs from STDIO, and will execute the instructions and perform the tasks specified by the engineer. The Agent Brain "dies" when the Agent Runtime is stopped — just like Docker containers and images.
Project Structure
Everything is organized into a single folder, in our case, todo-app/, which will have the main Application Agent file (app.agent.md), and then sub-folders for the sub-agents. Each agent file will be in plain English instructions, with optionally some traditional code files for specific tasks.
Then we will have sub-folders with sub.<agent-name> name, which will have the instructions for the sub-agents. Further going deep, we can have sub-agents for the sub-agents, and so on. For example, we can have a "database agent" as a sub-agent for the main to-do app, and then we can have a "MongoDB sub-agent" as a sub-agent for the database agent.
There will be scenarios where we will need to write some traditional code for specific tasks, and there we can provide traditional code files as tools for the agents.
Here's a fictional codebase structure for the to-do app (remember, 2027):
todo-app/
├── app.agent.md # Main Application Agent file
├── sub.database/ # Database sub-agent
│ ├── agent.md # Database sub-agent instructions
│ └── sub.mongodb/ # MongoDB sub-agent for the database agent
│ └── agent.md
├── sub.auth/ # Authentication sub-agent
│ ├── agent.md # Authentication sub-agent instructions
│ ├── sub.oauth/ # OAuth sub-agent for OAuth authentication
│ │ ├── agent.md
│ │ └── tools/ # Tools for OAuth sub-agent (traditional code)
│ │ ├── oauth.py
│ │ ├── google_oauth.py
│ │ └── facebook_oauth.py
│ └── sub.otp/ # Sub-agent for OTP based authentication
│ ├── agent.md
│ └── tools/
│ └── twilio-sdk.ts # Can be in any language
├── sub.data/ # Sub-agent for data processing and validation
│ ├── agent.md
│ └── sub.validations/
│ ├── agent.md
│ ├── sub.html-sanitization/
│ │ └── agent.md
│ ├── sub.utf-transformation/
│ │ └── agent.md
│ └── sub.markdown-transformation/
│ └── agent.md
├── sub.ui/ # Sub-agent for rendering User Interface
│ ├── agent.md # UI sub-agent instructions - to render the UI based on the Figma design
│ ├── designs/ # Design documents in plain English
│ │ ├── figma-design-website.md # Details/link to the Figma design for website
│ │ └── figma-design-mobile.md # Details/link to the Figma design for mobile app
│ └── tools/ # Traditional code for UI rendering
│ ├── figma-to-react.ts
│ ├── figma-to-flutter.ts
│ └── figma-to-react-native.ts
└── test/ # Test cases for the to-do app
├── agent.md # Test cases in plain English
├── environment.md # Test environment setup instructions
└── sub.otp-mock-test/ # Sub-agent for OTP mock testing
├── agent.md
└── tools/
└── otp-mock.py # Traditional code for test mocks
Read the full code on GitHub.
Some sub-agents might be coming from public agent repositories. For example, the sub.mongodb/ sub-agent can be an agent published by the official MongoDB team, made available through a public repository like agents.npm.org that other agent engineers can use as a sub-agent.
The new discipline of Agent Engineering will be about building these agents and sub-agents in plain English, and then the Agent Runtime will be responsible for loading them, building the Agent Brain, and running it.
In future, there will be tools that help people with less technical knowledge to build these agents, probably with some visual or drag-and-drop interfaces. That will be a time where anyone with a good understanding of the problem domain can build software solutions without needing to learn traditional programming languages.
Running the Application Agent
First, we will need an Agent Runtime.
By 2027, companies like OpenAI and Anthropic will have their own Agent Runtimes. Install an Agent Runtime, and start our Application Agent like this (like we start Docker images):
$ openai-art run todo-app/
or
$ anthropic-art run todo-app/
The Agent Runtime will read the folder and contents, analyze it, understand the application, and build the Agent Brain for this to-do app. The runtime will start the Agent Brain and keep it alive. The Agent Brain will accept inputs from the instructed channel (REST, STDIO, etc.) and process it according to the instructions in the app.agent.md file, use the sub-agents and tools as needed, and respond back with the outputs.
Deployment and Infrastructure
Deployment will be easier than ever.
During this period, cloud companies like AWS will come up with simplified "Agent Runtime Servers", where you just need to upload your Application Agent folder (either manual or CI/CD), and they will take care of the rest.
Such Agent Runtime Servers will be runtime-agnostic: you can choose Microsoft Azure ART Server, and use OpenAI Agent Runtime, or Anthropic Agent Runtime, or any other runtime that you like.
Testing
One main challenge that I see with this new approach is with testing. Since this is natural language based, the outputs can be non-deterministic. I hope such challenges will be addressed by that time.
In our fictional to-do app codebase, we have a special test/ folder, which has the test cases in plain English instructions like:
- "Try to add a to-do item with embedded javascript, and expect the system to sanitize it properly"
- "Login as Alice, and try to access the to-do items of Bob, given Alice knows Bob's user ID. Expect an authorization error.".
Architecture
Here's a high-level architecture diagram for an Agent Engineering-based system: (click to see the full image)
The Paradigm Shift
Programming paradigms have evolved gradually over decades, but this time the transformation promises to be fundamentally different — a huge leap that will reshape the entire software engineering landscape in ways we've never experienced before.
First there was binary — the hardest way to build software. Then came Assembly language — making it easy to build software. Then came C — even easier. Then came Python — more English-like, and making it way easier. There was a paradigm shift at each step, but it still required professional software engineers to build software solutions.
Now computers understand just plain English.
This will make anyone with a good command over the English language and a good understanding of the problem domain to quickly set-up small-to-medium software solutions without learning any traditional programming languages, learn any tools, IDEs, or even knowing anything about infrastructure.
Prediction: The year 2030: Anyone with a good command over the English language and a good understanding of the problem domain can quickly set-up small-to-medium software solutions without learning any traditional programming languages, learn any tools, IDEs, or even knowing anything about infrastructure.
These are a few of the major changes that I see happening with this new paradigm:
New discipline to pick up — Agent Engineering: Traditional software engineers will need to upskill and learn how to build Agents in plain English, and how to use the Agent Runtimes. When it comes to building large and complex software solutions, we will still need professionals who can design the architecture, break down the problem into sub-agents, and write the instructions in a way that the Agent Runtime can understand and execute properly and efficiently.
No more "which tech-stack?" dilemma: Since everything is in plain English, nothing to worry about which programming language, framework, or database to use. The focus will be on the problem domain and the solution design, rather than the tech stack. The tools can be made of any traditional language, and the Agent Runtime will take care of running them.
Easier deployment and infrastructure: No more need to worry about servers, cloud providers, scaling, etc. Just upload your Application Agent to the Agent Runtime Server, and it will take care of the rest.
Sample Fictional Codebase on GitHub
Visit this GitHub repository to explore the sample codebase for the fictional to-do app to be written in 2027.