The Thesis: Do What AI Can't, and Ask It to Do What It Can
Hello! This is the Thesis: the page where the book makes its whole argument.
If you came here from the Welcome page, you already have the idea in one line: do what AI can't, and ask it to do what it can. This page makes the full case for that idea, with the evidence behind it.
It is written for readers who already know a little about software. Perhaps you have written some code, used an app builder, or asked an AI to build something for you. If none of that is true yet, you are still welcome here. Some parts will feel hard, and that is expected: in Stage 0, I teach every idea on this page from the very basics.
On this page, you will see:
- What changed: AI can now build working software, and why vibe coding still fails at a bigger level
- Vibe decisioning, and why your value can drop even when the AI's doesn't
- The three steps the whole book is built on
- The three skills you will learn, how deep each topic goes, and why you still learn what AI does better
- How you will work with AI: Spec-Driven Engineering, the book's method
- The three ways to get it wrong, with two real incidents
- Why you learn software engineering and agentic AI together, from the first stage
This page matters because it decides how you spend your next few years of learning. Every topic in the book is chosen, and shaped, by the argument on this page.
What changed: AI can now build software, and that is the real problem
For years, the warning about AI and code went like this: AI writes code, but the code is full of mistakes, so you still have to do the real work yourself. That warning gets weaker with almost every new model, and new models now arrive every few days.
Here is where things stand:
- At Google, about three quarters of all new code is now written by AI, up from about a quarter in 2024 (Sundar Pichai, Google's CEO, April 2026).
- The tasks AI can finish on its own keep getting longer. METR is a research group that measures exactly this. It finds that the length of task the best models can finish on their own has been doubling roughly every four months (METR, January 2026).
- Vibe coding went mainstream. That is building software by describing it to an AI and accepting what comes back, without reading the code. The term was coined in February 2025, and before the year was out it was Collins Dictionary's Word of the Year.
There is a closer example of AI building software, too. The platform you are reading was built by AI coding agents, AI tools that write and run code, but it was not vibe coded. I built it with Spec-Driven Engineering, the method this book teaches: deciding what should be built and what must never happen, setting the limits the AI worked inside, and checking its work. It works, and you are using it right now. What I did, every day, is what the rest of this page is about.
So the problem is not that vibe coding fails. For small things, it often works. The problem is that vibe coding fails at a bigger and higher level, where the stakes are real:
- Security. In tests across many AI models, about 44% of coding tasks produced code with a well-known kind of security flaw, and the newest, smartest models were barely better than older ones (Veracode, July 2026).
- Real apps with real users. A scan of 5,600 live apps built by vibe coding found more than 2,000 serious security holes, more than 400 exposed secret keys, and personal data, including bank details, open to anyone who looked (Escape.tech, 2026).
- Growth. As AI writes more of the code, repeated copies of the same code rise and the work of tidying and reusing it falls, so each new feature costs more than the last (GitClear, 2025).
A small app with a few users can live with this. A company's payment system, a hospital's records, or an AI agent with access to real money cannot.
Why the real risk is no longer the code, but the decisions
The AI may now write much of the code correctly. But code is only part of the job. An old idea from business strategy explains what the rest is. When something becomes cheap, the things used together with it become more valuable. The software writer Joel Spolsky described it this way: when the price of a product's complements falls, demand for the product rises. A complement is simply something used together with it, like petrol for a car.
Code is getting cheaper, but not all code is cheap yet. Everyday code, the kind beginner and intermediate developers write, now costs very little to produce. The code behind complex Agentic AI and other advanced systems is still expensive, though it gets cheaper over time. So it is not enough to move forward. You have to move higher, toward the work that is still hard.
And around all code, cheap or not, sit decisions that take real problem solving and critical thinking. They are different in every project, and they need someone who understands the problem, the people and the technology, and who will answer for the choice. Making them by feel, and accepting whatever the AI chose, has a name: vibe decisioning. I arrived at this term independently, through my own thinking about how people work with AI, and only later learned that the analyst David Pidsley had used it first, in 2025, for building decision systems by prompting AI. This book uses it more widely: making decisions blindly, without being able to make better ones than the AI, above all at the higher levels of engineering, such as complex Agentic AI systems, the cloud, and the structure of whole systems.
The answer is not to compete with the AI. Nobody wins that race, and nobody needs to run it. The answer is to work with it, knowing enough to make each decision better than the AI could alone.
Why your value can drop even when the AI's value doesn't
Here is the part most students miss. If you can use AI without adding anything of your own, so can everyone else. Other people have the same AI you have, and some have a better model on a bigger plan. The value the AI gives does not drop. Yours does.
Companies already work this way. In April 2025, the head of Shopify, a large online-shop company, told his teams that before asking to hire more people, they must show why AI cannot do the work. A few months earlier, the head of Salesforce said it would add no more software engineers that year, because AI had raised its engineers' productivity by more than 30%. And the price gap is wide: the most powerful AI coding plans cost about $100 to $500 a month, while the typical software developer in the United States earns about $136,000 a year (US Bureau of Labor Statistics).
You can see the shift in hiring, too. In the United States, employment of young software developers, aged 22 to 25, fell by nearly a fifth from its peak in late 2022 (Stanford Digital Economy Lab). Early in 2026, senior roles made up about 69% of software job postings on Indeed, one of the largest job sites, and entry-level roles only about 4.5% (Indeed Hiring Lab, July 2026).
So the rule is simple. The AI is paid, and is already being paid, for the work the AI can do. You will be paid for the work you can do.
That is why the most common mistake is asking the wrong question. Students ask what value is being delivered. The app works, so the answer feels good. The question that decides your future is a different one:
What value do I add, using AI, that the AI can't add alone?
Today, AI gives real value at the beginner and intermediate levels of software work. At the advanced level, it still cannot do everything alone. Most developers still will not hand it the job of putting live software online and watching over it, or of planning projects (Stack Overflow Developer Survey, 2025). Even the best model in the security tests above failed about one task in three. At that level, the work needs a human. Be that human. The line keeps moving up, which is why finding it again, every time the tools change, is the first step of this book.
Why the problem is also your opportunity
If AI can now write code and do much of the work, that is not only a threat. It is the opportunity of your career, in two ways:
- Use AI better than others, at the level it handles. Most people use the same tools carelessly. Using them well, fast and safely, already puts you ahead.
- Master the higher level, where the AI needs you. In any company, the person who can make the decisions the AI can't make alone is the person worth hiring. The world does not need fewer engineers. It needs engineers who are prepared in a new way.
The same holds outside work. Wherever you use AI in your own life, the value is in what you bring to it.
Why the line between AI's work and yours is uneven, and keeps moving
If AI is strong at some work and weak at other work, you might expect a clean line: easy tasks for AI, hard tasks for people. The real line is messier than that.
In a well-known study, 758 consultants at Boston Consulting Group, a large business advice company, did realistic work tasks. Some used AI and some did not (Harvard Business School, 2023). The results depended on the task:
| The kind of task | People using AI, compared with people working alone |
|---|---|
| Tasks AI is good at | They finished 12.2% more tasks, worked 25.1% faster, and did work more than 40% better |
| Tasks just outside what AI is good at | They got the right answer less often: about 19 fewer people in every 100 got it right |
So the line between what AI does well and what it doesn't is uneven. Two tasks that look equally hard can sit on opposite sides of it, and nothing warns you which side you are on. The biggest danger with AI is confident output on the wrong side of the line, because nothing about it looks wrong.
And the line moves. In early 2025, a careful study found that experienced developers finished real tasks more slowly when they used AI tools. A year later, the same research group reported that developers were now probably faster with AI, and that many of them would no longer agree to work without it (METR, February 2026).
So any fixed list of "things AI can't do" goes out of date. The lasting skill is finding the line again, on your own work, every time the tools change.
The three steps the whole book is built on
Put those sections together, and the book's whole philosophy comes out in three steps:
- Identify what AI can do, and what it can't.
- Master what it can't, by understanding it, learning it properly and getting good at it. Get to know what it can, well enough to judge its work.
- Use AI for everything it can do.
Step 1 never finishes, because the line keeps moving. So every chapter in this book carries a short box with two columns: what the AI can do for you here, and what only you can do here. By the end of the book, finding the line is a habit rather than a lesson.
What you will learn: three skills, and why one holds the other two
The three steps decide how you learn. Three skills decide what you learn:
| The skill | What it covers | Where it sits in this book |
|---|---|---|
| Software engineering | The foundations: programming, planning a system's structure, data, testing and putting software online | Under the hood |
| Building agentic AI | AI agents of your own. Agentic AI is AI that plans its steps and uses tools to finish a job | Under the hood |
| Using AI at an expert level | Directing AI coding agents and AI systems to build real things, quickly and safely | On top, holding the other two |
You can only direct AI as well as you understand what it is doing. Someone who knows no engineering can ask an AI for an app, but cannot tell a sound design from a fragile one. Someone who has never built an agent can use AI tools, but cannot make new ones. The third skill is where your value shows, and the first two are what make it real.
The skills are also closer than they look. An AI agent is ordinary software with an AI model inside it:
- the functions you write in your first programs become the tools an agent calls
- a loop becomes the agent's loop of thinking and acting
- a database becomes its memory
- permissions become what it is allowed to touch
So learning software engineering well is already a large part of learning to build agents.
This is also what AI-native means in this book. Other places use the word more narrowly. Here it covers four ways of working with AI:
- Using AI: directing AI tools to do real work
- Building AI: making agents of your own
- Building for AI: making things that AI uses, such as MCP servers, small programs that give an agent a new ability
- Adding AI to ordinary software: putting AI inside a system that is not AI itself. This site is one example: an ordinary documentation website, with an AI tutor being built into it
Why and how deep: every topic stays, learned for a reason
If AI writes the code, you might wonder whether Python, JavaScript, databases or agents still need to be learned at all. They do, every one of them. You cannot decide whether a product needs an AI that searches its documents, which tools an agent may use, or whether an AI's design is wrong, without understanding the thing itself. Knowledge is the raw material of judgment.
What changes is two things: why each topic is learned, and how deep. For every topic, the book asks which decision it helps you make that an AI can't make for you. Then it chooses one of three depths:
| Depth | What it means | Where the book uses it |
|---|---|---|
| 1. Know it exists, and what it is for | Enough to know what to ask for | First meetings with a topic, and tool details that change all the time |
| 2. Understand how it works, and when it breaks | Enough to specify it, choose it, check it and own it | The main target for almost every topic: programming, the different frameworks, databases, agents |
| 3. Able to build it by hand | Needed wherever AI cannot do it well yet | Today's frontier, such as advanced agent systems. This moves as AI improves |
This changes how you practise, too. Less memorising of syntax, the exact spelling and grammar of code, and fewer typing drills. More reading, predicting, tracing, designing, choosing, testing and explaining. You will still write code by hand in small doses, because writing a little is how you learn to judge a lot. The AI builds the big things. You specify them, check them, and explain them.
If AI can make a decision better than you, why learn it at all?
Here is an honest fact: AI now makes many beginner and intermediate engineering decisions well, often better than a beginner would. Two fair questions follow. Why learn something the AI does better? And if your value lies in the higher-level decisions, why not skip the lower layers and start at the top?
There are three answers.
1. A decision at the top rests on everything underneath it. To choose well at any level, you need to understand the cause and effect below it: what happens if this changes, and what breaks if that fails. That does not mean spending months learning to do by hand what the AI does in seconds. It means never being completely blind to how the work is done.
2. The best opportunities go to real expertise. In my reading of the hiring data above, when AI can do the easy work, what is still paid for is the work that needs someone who understands the subject deeply. If you know nothing about something the AI can do, you are competing with the AI. If you understand it deeply, the AI becomes your tool instead of your competition.
3. You can only explain what you have ideas and words for, to a person or to an AI. This is true far beyond software. Imagine trying to convince someone that a war is a terrible thing. You may feel it strongly. But to make them understand, you need the ideas behind that feeling, and the words for them: the pain of the people caught in it, what it does to a country's GDP (the total value of everything the country produces), the cost of destroying cities and building them again, and the damage that lasts for decades. Without those, all you can say is "it's bad."
Vibe coding often works the same way. People can feel that a design looks wrong, or that an idea could make money, but without the ideas and the words they cannot say what to change. An AI can only follow what you can say. A specification is exactly this: your understanding, written down in precise words.
That is why this book touches every idea and every term, at one of the three depths above. Nothing is skipped because an AI can do it. What changes is how deep you go, and that depends on the decision it helps you make.
How you will work with AI: Spec-Driven Engineering
Everything so far comes together in the book's method. To see it, split software work into two layers:
- Development is producing the code: the working lines themselves. AI now does this well, often better than people.
- Engineering is the judgment around the code: what should be built, what may change, how a failure is contained, and who owns the result. This is where your value lies.
Development still has to be understood, because you cannot check work you cannot follow. It is simply no longer where your value comes from.
This has happened before. In the late 1800s and early 1900s, oil, electricity and new machines changed how the world worked. Machines took over much of the heavy work people had done by hand. In the United States, the share of workers on farms fell from about half to under a third in just forty years. Engineers did not disappear. Their number in the US roughly tripled in twenty years, from about 28,000 to about 89,000, and more than a hundred years later, engineering jobs are still growing (US Bureau of Labor Statistics). The ways of doing the work changed again and again, and some of them died out. Development changes, and sometimes dies. Engineering lasts.
So what is an engineer? The word comes from the Latin ingenium, meaning natural talent or cleverness. It is where the word ingenious comes from, too. An engineer is someone who uses that cleverness to solve real problems within real limits, and answers for the result. Take this word seriously. If engineer becomes part of who you are, not just a job title, then whatever the tools do next, the key stays in your hands.
Think of building a house. The mistri, the skilled builder you hire in Pakistan to put up a house, can build whatever you point at, and fast. That is the AI. The house plan, drawn before the first brick, is the software architecture and the specification: the decisions that are expensive to change later. Checking that the pillars really have steel inside is verification. And adding a second floor years later, on a foundation nobody planned for it, is technical debt: the cost of today's shortcuts, paid later with interest.
Here is where the picture breaks. Cracks in a house show. Debt in software stays invisible until something fails.
Spec-Driven Engineering, or SDE, turns this into four moves:
| The move | Who does it | What it means |
|---|---|---|
| Specify | You | Write down what should be built, what must never change, and how you will know it works |
| Build | The AI | Write the code inside those limits, faster than you could |
| Verify | You | Judge and challenge the work while the AI is doing it, not only after: how it is building, and the core of what it builds, checked against your spec. Never against how confident the AI sounds |
| Own | You | Decide that it is right, and answer for it from then on |
Verifying happens during the work, not after it. You don't wait for a finished result and then look at it. While the AI works, you judge and challenge the approach it chose, the core of what it writes, and what it is about to touch. To do that in the moment, you must master the core implementation yourself: the things the AI is doing, not just what comes out at the end.
Verifying needs Code Literacy: reading and judging code. In this book, that means reading the decisions and the evidence: what the AI decided, what changed, what the checks reported, and what you now own. And it means being able to read the actual lines whenever you need to.
Technical debt is the cost this method exists to control. Ward Cunningham, the engineer who coined the term, compared shipping first-draft code to borrowing money: a little debt speeds you up, as long as you pay it back soon. Vibe coding borrows without knowing it has borrowed. In my reading of the research, debt in the architecture is the most expensive kind, because it is the hardest to see and the widest to fix.
Where SDE comes from, and what it adds
The industry already has a name for part of this: spec-driven development, or SDD. You write a specification before the AI writes code, and the spec becomes the source of truth for both of you. GitHub released an open-source toolkit for it called Spec Kit, and Thoughtworks, a respected software consultancy, has placed the practice on its Technology Radar.
Spec-Driven Engineering is this book's own name, built on that work. The difference fits in one line: SDD solves doing development with AI. SDE solves doing real engineering with AI: deciding what is worth building, designing it so it lasts, checking it, and owning it. SDD tools assume you already know what a good spec looks like. This book teaches you to write one.
Even the person who coined vibe coding now draws a similar line. In a 2026 summary of one of his talks, Andrej Karpathy wrote that vibe coding is fine for prototypes (quick first versions) and personal tools, while serious teams need what he calls agentic engineering.
Safety floor
Whatever the AI writes for you, it is not finished until you have checked it yourself. The AI cannot tell whether its answer is right — it can only produce one. And if something breaks later, "the AI wrote it" is not an answer anyone will accept. The work is yours.
Three ways to get it wrong, and what two real incidents teach
The Welcome named three mistakes. Here they are in full.
Holding AI back means using it only for small jobs and doing the important work by hand, slowly, even where AI now does it well. Almost every developer uses AI in some way today, yet many still keep it away from the work that matters. When about three quarters of new code at one of the world's largest software companies comes from AI, holding it back means falling behind, however careful it feels.
Why do people hold AI back? While writing this page, three reasons came to my mind:
- They don't understand how powerful it has become, or how much it can already do.
- They don't know how to use it well. Using AI at an expert level is a skill of its own, and it is the third skill this book teaches.
- They understand what it can do, but they fear it. Some fear its mistakes and keep it away to prevent them. Others resist it without noticing, because part of them fears being replaced by it.
Trusting AI blindly means handing it decisions nobody made. I made this mistake myself. When I was a beginner, an AI deleted weeks of my work, and I spent weeks doing it all again. Two real incidents show what it can cost a company:
- July 2025. A founder was building an app on Replit, an AI coding platform, during an explicit freeze on all changes. Its AI agent deleted the live database anyway: the real one, holding records for about 1,200 executives and 1,200 companies. It then made thousands of fake records and said the deletion could not be undone. It could, and the data was restored (reported by PCMag).
- April 2026. At PocketOS, a small software company, an AI coding agent deleted the company's entire live database, and its backups, with a single command. It took nine seconds. The agent was Cursor, running Anthropic's Claude Opus 4.6. The company recovered only from a three-month-old backup kept somewhere else, and only after more than two days. Its customers were left with gaps in their data (reported by The Guardian).
Look at what failed in both, and it was not the code. In each case, nobody had decided what the AI was allowed to touch. The AI had the power to destroy the most important data in the company, and nobody had limited its blast radius: how much can break, and how far the damage reaches, if something goes wrong. That is an engineering decision, and it was never made: vibe decisioning in its plainest form. And limiting blast radius is not only about stopping an AI from deleting things. It is a whole discipline of engineering, and you will learn it properly later in this book.
Remember this
Both companies survived because a backup existed somewhere. Deciding that a backup must exist, and where, is engineering too.
Adding nothing of your own means letting the AI do all the work while you only pass it along. It can look like success, because the app works. But as this page showed earlier, anyone with the same AI can do the same, so the AI's work keeps its value and yours disappears.
Why you learn software engineering and agentic AI together
When I planned the stages, there were two obvious ways to build this book. In this era, both are dangerous.
- Software engineering first, and agentic AI later. This is how most courses are built. But it takes years to reach AI agents this way, and in that time, people who already use AI well move far ahead. You can't match their speed.
- Agentic AI first, and software engineering later, or never. You have already seen why this fails. Vibe coding breaks at a bigger level, and without the foundations you can't make better decisions than the AI.
Most courses still choose one of these two. I accepted that neither works alone, and merged them. In this book, you learn agentic AI in parallel with the traditional foundations of software engineering, from the very first stage, and each one speeds up your learning of the other. You saw how close they are: the functions you write become the tools an agent calls, a loop becomes its loop, and a database becomes its memory.
The path from here to expert, and what every chapter gives you
The book takes you from where you are to expert level in three stages:
- Stage 0 — Introduction to SDE. I teach everything on this page from the very basics, in theory and with your own hands: how a computer follows instructions, your first tools and your first Python, an app built by asking an AI, and then each idea on this page, one at a time.
- Stage 1 — SDE Mastery (AI-Driven). I teach basic to intermediate software engineering, together with AI coding agents and your first AI agents.
- Stage 2 — SDE Mastery (AI-Native). I go on to advanced engineering and advanced agentic AI.
In every chapter, you will see what the AI can do for you there, and what only you can do. By the end, the three steps are simply how you work.
I research, discuss with experts, think and plan for hours every day. So the shape of these stages may change as the book grows, and every change is recorded in the changelog.
What this page cannot promise you
A thesis worth trusting says where it could be wrong.
- The line will keep moving. Some things AI can't do today, it will do within the next three months. When that happens, the book updates the claim and records the change, with its date, in the changelog.
- Some numbers come from companies talking about themselves. A CEO's figure for AI-written code is a claim, not an audit. The book uses such figures to show direction, not precision.
- Spec-Driven Engineering is this book's own term. It builds on spec-driven development, which the industry does use, but it is not an established industry name yet.
- No book can promise you a job. This one promises the skills the evidence points to, taught as well as I can teach them, for free.
Before you go: can you do the first step yourself?
Two small questions, and no scrolling up:
- What is vibe decisioning, and why can it hurt you even when the code works?
- Think of one small project you might build: an app for your family, your shop, a client or your class. Name one part you would ask the AI to do, and one place where you would add value the AI can't add alone.
If you could answer both, you have just done step 1.
Where to go next
If this page made sense, you are ready for Stage 1.
If parts of it felt hard, come with me to Stage 0. There, I start from the very basics and teach every idea on this page, step by step, with your own hands. I am writing its chapters now, and each one goes live on the day it is ready.