Editor's note: This post is adapted from a talk I prepared for the 24th session of the "AI Afternoon Tea" series hosted by the Henan Artificial Intelligence Association. "Natural language is the new programming language" is a metaphor — it means ordinary people can express requirements and take part in prototype validation more directly. It does not mean I have independent programming ability, and it definitely doesn't mean you can get a reliable production system out of a single sentence.
A lot of people hear an AI case study and think the scenario is interesting, but when they go back to their own work, they still don't know where to start.
Usually the problem isn't a lack of needs — it's not knowing whether a given need can actually be done, whether it's worth doing, and how to even put it into words clearly.
That's where I started too. As a non-technical user, I can't write a complete system myself, but I can break my day-to-day work down into concrete problems, and then use AI to turn ideas into testable prototypes.
That's why I say "natural language is the new programming language for ordinary people."
Don't look for tools first — look for things that keep happening
When I'm looking for AI opportunities, I start with three questions:
- What do I do repeatedly every week?
- What's the input for this task, and what's the output?
- If this got simplified or automated, what more important thing could I spend that time on instead?
For example:
- Compiling sales data every week — the input is data scattered across various places, the output is a summary report;
- Searching for competitor updates every day — the input is keywords and information sources, the output is a deduplicated brief;
- Explaining the business over and over to new inquiries — the input is customer questions, the output is basic answers and a record of the need.
Once you can answer these three questions, the scenario starts to become concrete.
Natural language can push a need forward to "testable"
In the past, if a non-technical person had an idea, they'd usually have to write a requirements doc, find a developer, coordinate a schedule, and then wait for a usable version. Now AI lowers the barrier at the prototype stage.
You can start by describing, in natural language:
- Who you are;
- What problem you want to solve;
- What the input is;
- What output you want;
- Where the result should go;
- What things absolutely must not happen.
For example:
I run a restaurant chain's stores. I want to compile daily revenue across all locations, generate a comparison report, flag unusual changes, and send the results to the person in charge. All numbers must come from the raw spreadsheets — if data is missing, it needs to be flagged clearly, not filled in on its own.
That's a lot clearer than just saying "help me build an operations analysis assistant."
AI can use this to help map out a workflow, generate a prototype, or propose an implementation approach. But getting from a prototype to something actually in use still requires testing, permissions, data security, error handling, and ongoing maintenance. Natural language lowers the barrier to participation — it doesn't lower the engineering bar.
Three common types of prototypes
Conversational requirements assistant
Have the AI proactively ask about the industry, pain points, current workflow, and constraints, then produce a structured requirements record at the end.
It's good for gathering information and doing an initial pass at organizing it. It can't replace a proper consultation, and it definitely shouldn't be inventing ROI figures, quotes, or implementation conclusions when there isn't enough information. The final recommendation still needs to be confirmed by someone who actually understands the business.
Content production pipeline
From gathering candidate material, to filtering it, generating a draft, sending it into Feishu (Lark) for review, and finally having a person decide whether to publish.
The valuable part here isn't "fully automatic article writing" — it's that people no longer have to start from a blank page, and there's still a review checkpoint built in. The opinions, facts, and final wording are still the person's responsibility.
Company intelligence brief
Around a fixed set of keywords and public information sources, regularly collect updates on competitors, the industry, and bids, then generate a brief using a template.
This kind of workflow works well for scenarios with a lot of frequently-updating information, but you need to pay attention to source reliability, scraping permissions, and duplicate information. AI's summaries can't replace checking the original sources.
A one-sentence formula for describing a need
If you don't know how to describe your need, you can start with this template:
I work in "some industry or role." I want to reduce "some repetitive task." The input is "data or information." The output is "results and format." It gets delivered to "a specific place." When "an exceptional or high-risk situation" comes up, it must be handed off to a person.
You probably won't get this right on the first try. Its value is that it forces you to turn a vague wish into conditions that can be discussed and tested.
What kinds of scenarios are worth doing first
I prioritize tasks that meet these conditions:
- Happens repeatedly, daily or weekly;
- Input and output are relatively well-defined;
- The result is easy to check;
- Doing it by hand is time-consuming or error-prone;
- If something goes wrong, it can be stopped and fixed quickly.
On the other hand, if a task heavily depends on trust, emotion, on-the-spot judgment, or creative decision-making, it's not a good candidate to try to automate right out of the gate.
AI is good at handling repetition, rules, and volume of information; people are better suited to judgment, relationships, and final decisions.
You don't need to know how to code to take part in creating things
Natural language makes it much easier for ordinary people to get involved in product and workflow design: you can describe the problem, add examples, test the results, point out what's wrong, and decide what to change next.
But it's worth being honest about the difference between two things:
- Using AI's help to turn a need into a prototype;
- Independently developing and maintaining a production system without AI.
Right now I'm closer to the former. My advantage isn't writing code — it's starting from real problems, being able to explain requirements clearly, and keeping up a steady loop of feedback while using the thing.
Natural language won't make engineering disappear, but it does give more people a chance to take part in creating things. What actually matters isn't how impressive a prompt you can write — it's whether you understand the problem you're trying to solve.