The short answer
Yes, genuinely. Describe what you want in plain English and today's AI tools will produce working code, and for small self-contained things a non-programmer can get a real, useful result without learning to program first. That part is not hype.
What AI cannot do is tell you whether the result is correct, secure or maintainable. That judgement is the part that needs the knowledge you do not have, which is why this works beautifully when being wrong is cheap, and badly when it is not.
This whole category is moving quickly. Tools appear, get renamed, change what they include and change where they are available. Nothing here names a specific product as the answer for that reason. Check what any tool currently offers, and where it offers it, before you build anything on top of it.
What actually works today
Be clear on the scale involved. The following are not toy examples, they are the honest sweet spot, and the sweet spot is bigger than most people expect.
Small scripts that do one boring thing. Rename four hundred files according to a pattern. Pull the totals out of thirty spreadsheets into one. Convert a folder of documents into another format. These take a professional twenty minutes and take you an afternoon of asking, running and fixing, and then you have it forever.
Spreadsheet formulas. Describe what you want the cell to work out and paste the formula back in. This is possibly the single highest-value use of AI for non-programmers, because the result is visible immediately: you can see the number it produces and check it against one you worked out yourself.
Single-purpose tools for you alone. A calculator for your specific pricing model. A page that reformats text the way your team needs it. Something with one job, one user, and no consequences if it breaks.
Prototypes to think with. A rough working version of an idea is far better than a document describing it, both for your own thinking and for showing someone else what you mean. Nobody expects a prototype to be robust, which removes most of the danger.
Websites, through builders made for the purpose. Tools that turn a description into a real site are a genuine route to something live and public without writing code yourself. Our free courses on ChatGPT Sites and Build with Lovable both cover this, and each is honest about where the tool stops.
Notice the pattern running through all five. Small. Self-contained. Fast to check. Cheap to be wrong about.
In plain English
- Code:
- Written instructions telling a computer what to do. AI can now write these from a plain English description.
- Script:
- A small program that does one specific job, usually run when you want it rather than left running.
- Edge case:
- The unusual input nobody thought about: the empty field, the name with an apostrophe, the date in February.
- Silent failure:
- When something goes wrong without producing any error, so the only sign is a wrong answer that looks right.
- Maintainable:
- Written in a way that lets someone come back in six months and change it without breaking everything.
The checking problem
Here is the crux, and it is worth reading twice.
A programmer's real skill was never typing. It is knowing what could go wrong. When an experienced developer reads code, they are running a background process that asks: what happens if this list is empty, what happens if two people do this at once, what happens if the date is the 29th of February, what happens if someone types their name in a field expecting a number. That process is built from years of watching things break in exactly those ways.
AI has now taken over the typing, which was the visible part of the job, and left you with the invisible part. This is why the experience of building with AI feels so strange. You get to a working result astonishingly fast, and then you are standing in front of something you cannot evaluate, with nothing to do except run it and hope.
You are not helpless. You can test the thing. You can compare its answer against one you worked out by hand. You can ask a second AI to critique the first one's work, which catches a surprising amount. What you cannot do is know what you did not think to test, and that gap does not close by asking better questions.
โ Weak prompt
Prompt
Write me a script that renames all the photos in this folder by date.
Output
A working script that renames the files. You run it, the names change, it looks correct.
It probably is correct, for the files you happened to test it on. You have no idea what it does to a file with no date information, or two photos taken in the same second, or the one file in the folder that is not a photo. And it has already overwritten the originals.
โ Good prompt
Prompt
Write me a script that renames all the photos in a folder by the date they were taken. Before you write it, list every case where this could go wrong or lose data. Then write it so it copies into a new folder rather than renaming in place, prints what it is about to do before doing it, and stops with a clear message on anything it cannot handle.
Output
The same script, plus a list of the failure cases you had not considered, and a version that shows its working and cannot destroy your originals.
You still cannot fully evaluate the code. But you have made being wrong cheap, which is the move actually available to you.
The failure that should worry you
Broken code is the good outcome. It stops, it complains, you paste the error back in and it gets fixed. Beginners fear this and they should not.
The thing to fear is code that runs perfectly and does the wrong thing. It produces a number. The number is plausible. Nothing anywhere indicates a problem. You put it in a report, or send it to a client, or make a decision with it, and the error only surfaces months later when someone asks why two figures do not agree.
This is precisely the failure mode a non-programmer is least equipped to catch, because every visible signal says success. The defence is not technical, it is procedural: never trust a result you have not checked against something you already know. Run it on data where you know the answer. Do the first three rows by hand. If it processes a thousand records, check five of them properly, and pick the weird ones.
Before you write any code, do this instead:
List everything that could go wrong with what I have asked for.
Include unusual inputs, missing information, and anything that
could produce a wrong answer without showing an error.
Then tell me how I would check the result is correct, given that
I cannot read the code. Be specific about what to test, not general.
Where the line is
There is a point where "I will check it carefully" stops being an adequate plan, and it is not a matter of how complicated the thing is. It is about who pays when you are wrong.
Get a real developer involved the moment your project touches money, personal data about anybody else, or anything other people depend on. Payments, customer records, medical or financial information, health and safety, anything with a legal obligation attached, anything that would be a serious problem for someone who is not you.
The reason is specific rather than snobbish. Security failures are silent by design. A site that leaks its entire customer list looks and behaves exactly like one that does not, right up until it appears somewhere it should not. There is no test you can run from the outside that reveals it, and the AI that wrote the code will tell you it looks fine, because it is not lying, it simply has the same blind spot you do.
The rule that survives contact with reality: build anything you like for yourself, and get someone qualified to look before it touches another person's money or information. If you want to go deeper on the general habit of checking AI output, that is what our free AI Safety and Verification course is for.
If you want to go further
You do not have to become a programmer. But there is a middle path that is genuinely worth walking, and it is shorter than it looks.
Learn to read code rather than write it. Ask the AI to explain each part of what it wrote, in plain English, line by line. Do that fifty times and you will start recognising shapes, which is most of the way to catching an obvious mistake.
Build the habit of asking for the failure cases before asking for the code. It costs one extra message and it changes what you receive.
Start with things where the answer is checkable. Then work outwards to things that are harder to check, deliberately, rather than by accident.
And take the tools seriously rather than magically. Our free No-Code Automation course covers the category built specifically for people in your position, and if you would rather just find the right starting point, start here.
The honest summary: AI has made building software possible for far more people, and it has not made judgement optional. It moved the hard part rather than removing it. Knowing which part is now hard is most of what you need.