In March 2025, Replit founder Amjad Masad wrote on X: “I no longer think you should learn to code.” In a LinkedIn post at the end of October 2026, Masad looked back on it: “In 2025 I got canceled for saying you shouldn’t learn to code.” The post says the take wasn’t easy to share for someone who spent 15 years “getting people to learn to code, first through open source, then at Codecademy, then with Replit.”
The most useful part of the post isn’t the prediction. It’s the advice Masad gave instead:
“I thought the better advice was to learn how to think, how to break down problems, and how to communicate clearly with both people and machines.”
It’s the same answer Masad gave on the TBPN show in 2025, when asked what to learn instead: “learn how to think. Learn how to break down problems.” You don’t have to agree with the post that AI is now better than people at coding to take this advice. These three skills are what an employer can’t get from an AI alone, whoever types the code. Here’s what each one means in practice, and how to get better at it.
1. Learn how to think
Thinking here means two things: understanding a problem before you try to solve it, and being able to tell whether an answer is right. When an AI writes the code in seconds, those become the slow parts. Getting code is fast. Deciding what you want, and noticing when you didn’t get it, is not.
Three habits help:
- Predict before you run. Before you run any program, yours or an AI’s, say what it should print. When your guess is wrong, you’ve found the exact spot where your understanding is off.
- Work a tiny example by hand. Take three or four inputs and follow them on paper. Most mistakes show up on the small cases: an empty list, a single item, two equal items. We wrote more about finding those cases.
- Decide how you’ll check it before you ask for it. Write down two or three inputs and the outputs you expect. Whoever writes the code, those are your tests.
2. Learn how to break down problems
Breaking down a problem means turning a vague goal into steps small enough that each one can be built and checked on its own. “Build me a habit tracker” is too big to get right in one go, for a person or an AI. Split up, it looks like this:
- What is a habit? A name, and how often it should happen.
- What counts as done for today?
- When does a streak break? At midnight, but in whose time zone?
- What does the first screen show?
Each step can be checked in a minute. And the third one hides a question an AI won’t ask unless you do: should someone who travels lose a streak they kept? You find questions like that by splitting the problem up, not by reading the finished code.
Coding interviews test the same skill. Take merging overlapping intervals, like meetings at [1, 3], [2, 6] and [8, 10]. Broken down: sort the intervals by start time, walk through them in order, and if one overlaps the last merged interval, extend that one; otherwise add it as a new one. Three steps, each easy to check on a tiny example. Here the answer is [1, 6] and [8, 10]. Candidates who say the steps out loud before coding rarely get lost halfway. More in why problem decomposition is the most underrated interview skill.
A good rule for both: if you can’t check a step in about a minute, split it again.
3. Learn how to communicate clearly, with people and machines
Explaining a task to a person and asking an AI for it turned out to be the same skill: saying exactly what you want, what you’re starting from, and how you’ll know it’s right. Compare two requests to an AI:
Write a function that finds duplicates.
Write a Python function that takes a list of email addresses and returns the ones that appear more than once. Treat upper and lower case as the same, and return the addresses in lowercase, in the order they first appear. Example: [“Ana@x.com”, “bo@x.com”, “ana@x.com”] returns [“ana@x.com”]. An empty list returns [].
The second one takes thirty seconds longer to write. It can’t be misread, and its example is already a test: you can check the AI’s answer by running it, without reading the code.
With people, the habits are the same. Restate the problem in your own words, ask about the cases that aren’t clear, and explain your plan before the details. In a coding interview, that means describing your approach and its time complexity before you write a line. We go deeper in how to explain your thought process in an interview. A simple way to practice: explain your solution in three sentences before you write it, or ask the AI to explain its code and check whether you could explain it back.
So, should you still learn to code?
Masad’s post is about where the work is going, and the advice in it is good. But the three skills don’t come from reading about them. They come from practice on problems where a wrong answer is obvious, and programming is a good place for that. A program does exactly what you told it, not what you meant, so it shows you at once whether your thinking, your steps and your instructions were clear.
What has changed is the goal. Memorizing syntax matters less every year. Knowing what a program should do, splitting it into steps, saying each step clearly and checking the output matter more. That’s also where all four kinds of beginners we wrote about end up.
If you want to practice it, AlgoCademy breaks each problem into small steps you check one at a time, from your first line of code to coding interviews. In an AI mock interview, the interviewer asks you to explain your approach before you code, and your first one is free. And Build with AI lets you build your own app or game with an AI builder while you decide what it does and check every step.