Two answers to this question are common, and both are wrong.
The first says nothing has really changed: you should learn to program properly, and anything else is a shortcut that will collapse. The second says the question is obsolete — describe what you want, the machine handles the rest, and understanding is a transitional requirement that is on its way out.
The first ignores what has actually happened. The second ignores what happens next.
What genuinely changed
Producing working code used to require knowing a language well enough to express an idea in it. That was a real barrier, and it kept a large number of people with sound ideas out of building anything at all.
That barrier has substantially fallen. Someone who can describe what they want clearly, in ordinary language, can now get working software — not a toy, not a mock-up, but something that runs and does the job. This is not a marginal improvement in developer productivity. It is a change in who is able to build.
It is worth being unambiguous about that, because the instinct among experienced developers is to qualify it into insignificance. It is significant. Dismissing it is as inaccurate as overselling it.
What did not change
Writing the code was never the whole job, and it was rarely the difficult part.
The difficult parts were deciding what should be built, working out how it should behave, noticing the questions nobody had answered, establishing whether the result was correct, and judging whether it was safe to rely on. None of those has been automated, because none of them is a translation problem. They are judgement problems, and they depend on knowing what you want and what it would cost to be wrong.
What has changed is where the effort sits. It used to be spread across thinking and typing. It is now concentrated almost entirely in the thinking, which is why people who assumed the thinking was the easy bit tend to find AI-assisted development frustrating.
Four kinds of understanding that still matter
These are not programming skills in the traditional sense. Several of them are harder to acquire than syntax, and none requires you to write code fluently.
Understanding what you actually want. Not the feature you imagine, but the outcome that would make the software worth having, and what it should visibly do. This is the most transferable of the four and the most commonly skipped: it is the difference between "build a booking system" and a description someone could check.
Understanding what would count as working. If you cannot say what you would look at to decide whether a change succeeded, you cannot evaluate the result, and judgement quietly collapses into whether the software started up. This is a habit of thought rather than a technical skill.
Understanding the shape of your own system. Not every line, but roughly: what the pieces are, which ones hold data, what depends on what. Enough to notice that a change to the total calculation might affect the invoices, or that touching login affects everyone. You can build this understanding by working on the system, and it is what makes it possible to bound a change sensibly.
Understanding where the risk is. Which parts of what you are building would be genuinely damaging to get wrong — because they hold personal data, move money, control access, or are relied on by people who cannot check the work themselves. This is the one most often absent, and it is the one where being wrong costs the most.
The line moves with the stakes
How much you need to understand is not a fixed quantity. It scales with what happens if you are wrong.
A tool that reformats text for your own use needs very little. If it misbehaves you will see it, and the cost is your own mild inconvenience. Building it by describing what you want and checking the result is a completely reasonable way to work, and adding ceremony would be waste — an argument made at length in vibe coding and what it costs you later.
Something a handful of colleagues rely on needs more: behaviour you have actually verified, some care about what happens when data is missing or wrong, and a way back if a change goes badly.
Something that holds other people's personal information, takes payments, or controls who can see what raises the requirement sharply — not because AI writes worse code in those areas, but because failures there are frequently silent, and the people affected are not you. At that point the honest answer is that no amount of careful description substitutes for someone who genuinely understands security, or payment handling, or whatever the specific domain is. Deciding when you have reached that point is the subject of when to get a professional to look at AI-generated software.
Recognising which of those situations you are in is itself one of the things you need to understand. It is also the judgement most likely to be skipped by someone enjoying how quickly the work is going.
What this means in practice
You do not need to learn a programming language before you begin. That advice, offered as a precondition, has kept people from building things they were perfectly capable of building.
You do need to be willing to think carefully about what you are asking for, to check what you get rather than trusting a description of it, and to be honest about when a project has moved past your ability to evaluate it. Those are the actual requirements, and they are not a lesser substitute for technical skill — the same requirements applied before AI, they were simply obscured by the effort of typing.
You will also, gradually, learn some technical things anyway. Reading changes you asked for, noticing patterns, working out why something failed — this accumulates whether you intend it to or not, and it makes the next project easier. That is a natural consequence of building, not a prerequisite for starting.
The uncomfortable version
The honest summary is less appealing than either of the confident answers.
Building useful software is genuinely more accessible than it was, and there is no need to be defensive about that. It is also still possible to build something that appears to work and is quietly wrong, and AI makes reaching that state faster than it used to be. The skill that matters is not writing code. It is knowing what you asked for, checking whether you got it, and recognising the point at which you should ask someone who knows more than you do.
If you want a practical way to work that keeps those three things in place, the repeatable workflow is the concrete version, and the full method it comes from is set out on the PDAID page. If you want the argument developed at length, with a worked application, it is the subject of Build Software Using AI.