I was chatting with some colleagues about AI today, and something in the conversation struck me. So I decided to write this down.
A while ago, one of my colleagues went to Hangzhou for a Google Ads event about AI-generated motion comics. As he told me about what was being discussed there, I suddenly realized something:
AI is no longer just a hot topic within the tech industry.
It has become one of the hottest topics in the world.
To many people, it even feels like the beginning of a fifth industrial revolution.
It was around the end of 2024 when I first started paying serious attention to the term "large language model."
At the time, DeepSeek had just released V2.5, and most people were still using GPT-4. I had not yet truly encountered the concept of deep reasoning.
Then DeepSeek R1 arrived.
That was the first time I developed an intuitive sense of what "reasoning" in an AI model could look like.
I still remember how absurdly popular DeepSeek became during that period. The website was often inaccessible, and even when you managed to get in, it frequently failed to answer your questions.
But it was also during that period that I saw, for the first time, what it looked like for a large model to "think" through a problem.
Even today, I still remember the shock of watching an AI output its reasoning line by line.
The first thought that crossed my mind was:
Does it have a soul?
Looking back now, that feeling is difficult to describe.
You knew perfectly well that it was ultimately just a model—a system, a technological artifact composed of complex code.
And yet, when its "thought process" appeared in front of you, it was hard not to experience a strange illusion:
as if there really were something on the other side of the screen understanding you and responding to you.
And how did we use AI back then?
It was simple.
We asked questions on a website.
The AI interface of that era was essentially just an input box: you typed in a question, and it gave you an answer.
Later, as multimodal capabilities emerged, a small "+" button appeared beneath the input box, allowing users to upload files.
More capabilities followed.
But if we go back to that moment, the core form of an AI product was still just a website.
I call that stage AI 1.0.
In the AI 1.0 era, the most important—and almost the only—skill users needed was knowing how to ask questions.
In other words, the entire methodology could almost be summarized in one sentence:
Prompt is all you need.
I still remember reading countless tutorials and articles about how to write better prompts.
There was even a rather "professional" name for it:
Prompt Engineering.
Looking back, the term now feels very much like a product of its time.
But at the time, it really was an important skill.
I suspect one of the first fixed prompting patterns many people learned when they started using large models looked something like this:
You are now an expert in xxx, specializing in xxxx.
And in the beginning, that approach genuinely worked.
Models were nowhere near as capable as they are today, and compute was far more limited.
You often had to define a role, narrow the scope, and provide enough context before the model could reliably produce the result you wanted.
In a sense, prompts were a form of manual parameter tuning.
The more specific your prompt was, the more closely the model's answer tended to match your expectations.
The more ambiguous you were, the more likely it was to drift away from what you wanted.
So people started studying how to assign roles, provide background information, and break problems into smaller pieces.
For many of us, that was the first time we truly realized that communicating with AI was becoming a new language of its own.
Back then, I mostly used AI for text-related tasks—polishing writing, translating content, things like that.
I did not use it much for programming.
Occasionally, I would paste an entire source file into the chat and ask it to modify something.
But the experience was hardly smooth.
Context would become confused. Copying and pasting code would introduce errors. After going back and forth several times, doing the work myself was often faster.
So at that stage, AI did not yet feel like an overwhelmingly powerful assistant.
What did it feel like?
More like driving a car with an automatic transmission.
It saved you from some basic operations and made certain things easier than before.
But it was still far from being able to genuinely take on complex work for you.
You found it useful, but not astonishing.
You were willing to use it, but you did not depend on it.
By 2026, I encountered Claude for the first time, along with a completely different way of using AI: local CLI tools.
AI was no longer confined to a web-based chat box.
It could enter the local development environment, directly read project files, understand code structures, and even participate in concrete implementation and modification work.
That was when I truly began learning how to integrate AI into my development workflow.
At first, I was still cautious.
I mostly asked it to write simple functions or handle small, isolated tasks.
I was reluctant to hand over an entire page—or even an entire module—and ask AI to build it in one go.
I was curious about what it could do, but I remained wary of giving it too much control.
Even with such limited usage, however, the improvement in my productivity was already transformative.
Because by this stage, AI was no longer merely a tool that answered questions.
It was becoming an assistant that could participate directly in real development workflows.
It no longer just told you what to do.
It could actually do the work with you.
If the previous stage of AI was like an automatic car—saving you from a few mechanical operations—this was the point when I first began to feel that AI was changing from a tool into a partner.
Gradually, prompts themselves seemed to matter less than they once had.
Prompts were moving into the background. Tokens were moving to center stage.
You could increasingly feel that AI was starting to "understand" you.
You no longer needed to explain every role, every piece of background information, every step, and every requirement in painstaking detail.
Even if your expression was incomplete, it could often understand roughly what you meant.
Even if your description contained gaps, it could frequently follow your train of thought and fill in the things you had left unsaid.
And with that, our concerns began to change.
In the early days, everyone cared about one question:
How do I write a better prompt?
Now, more and more people were asking something else:
How many tokens is this going to cost?
Tokens were no longer merely a technical parameter.
They were becoming one of the most concrete and direct units of cost in the AI era.
The longer the context you provide, the more complex the task, and the deeper the conversation becomes, the more tokens are consumed behind the scenes.
As a result, our focus began shifting from:
How do I make AI understand me better?
to:
How do I use AI more efficiently?
If Prompt was what mattered most in the AI 1.0 era, then by 2026, Token had moved to center stage.
At first, many people understood tokens simply as a billing unit.
You say something: tokens are consumed.
AI responds: more tokens are consumed.
Upload a document, attach context, read code, continue a long conversation—all of it consumes tokens.
But the significance of tokens goes far beyond billing.
Tokens fundamentally determine how much an AI can see, how much it can remember, how deeply it can understand a problem, and how much work it can perform in a single session.
In a sense, tokens are to AI what bandwidth was to the Internet, electricity was to the industrial age, and gasoline was to the automobile.
They determine not only cost, but also the boundaries of capability.
Why do some AI systems appear extremely intelligent, yet suddenly seem to forget what you were discussing earlier?
Why can two people use the same model for the same kind of task, yet one person's workflow feels effortless while the other's feels constrained at every step?
Quite often, the difference is not simply that one model is smarter than another.
Sometimes, the problem is simply that there are not enough tokens.
So at this stage, the challenge is no longer merely about saying the right thing.
It is about providing the right context.
We learn to filter information, compress descriptions, structure requirements, and control context length.
And we begin to understand that using AI efficiently is no longer just about knowing how to ask questions.
It is about knowing how to allocate tokens.
Prompt determines how you begin. Token determines how far you can go.
And in that sense,
Token is all you need
is becoming an increasingly realistic description of where we are today.
At the beginning, AI was little more than a chat box—a new tool that could answer questions, polish text, and translate content.
Today, it has already become far more than a "tool."
It is entering writing.
Programming.
Design.
Search.
Customer service.
Operations.
Video editing.
Analysis.
Decision-making.
What AI is replacing is not merely one specific action within one specific profession.
It is replacing large amounts of repetitive, standardized, process-driven work itself.
In the past, many capabilities depended on accumulated experience.
They depended on time.
They depended on someone spending years gradually sharpening a skill.
AI is now rapidly lowering those barriers.
It allows people who cannot write to begin writing.
People who cannot program can begin building products.
People without design training can quickly produce design concepts.
For the first time, many abilities that once required extensive professional training are being opened to ordinary people at unprecedented scale.
And work is far from the only thing AI is changing.
It is entering the way we express ourselves.
The way we learn.
The way we process emotions.
The way we live our everyday lives.
We use it to write emails, build spreadsheets, research information, create plans, modify code, and design strategies.
We also use it to organize our schedules, plan trips, ease anxiety, structure our thoughts, and even, in moments of loneliness, give a place to emotions that previously had nowhere to go.
Little by little, AI is entering the surface layers of our lives.
And step by step, it is moving deeper:
into our processes,
into our decisions,
into our collaboration,
into our habits,
and eventually,
into our dependencies.
That is precisely where we should be most careful.
AI will not necessarily replace you in one dramatic moment.
Instead, every time you think,
"This is so convenient,"
it becomes a little more deeply embedded in your life—
until one day, you realize you can no longer imagine working without it.
So when I look back at the past one or two years, I increasingly believe that what AI is truly changing is not merely one industry, one profession, or one category of tools.
It is changing the entire way human beings process information, organize capabilities, and get work done.
It replaces repetitive labor.
It lowers professional barriers.
It restructures how work is divided.
And it redefines the relationship between humans and tools.
In the past, tools were things we used.
Today, AI is increasingly becoming something that thinks with you, judges with you, and acts with you.
And so we have traveled from:
Prompt is all you need
to:
Token is all you need.
But as I reach the end of this article, I increasingly feel that the most important conclusion of this era may not be:
AI is all you need.
Because AI may determine your productivity.
It may determine how quickly you acquire information.
It may determine how you get your work done.
But it should never determine who you are.
The real question is this:
When AI can do more and more things for you, what remains uniquely yours?
When AI is taken away, do your judgment, your taste, your experience, and your choices still stand on their own?
AI may determine the productivity ceiling of most people in this era.
But more important than whether you know how to use AI is whether, after gaining access to it, you can still preserve the part of yourself that cannot be replaced.
AI determines how fast you can move.
But how far you can go is still determined by you.
Beyond AI, There Is You.
]]>Recently, I have been thinking about a fundamental question:
Should AI coding become more free, or should it become more controlled?
A while ago, I started introducing Codex internally at my company, just like I once introduced Node.js years ago.
When my colleagues first tried it, they were excited:
"I built a whole page in one hour."
"I created an entire app in three days."
This is exactly what makes AI coding so fascinating.
It dramatically compresses the distance between having an idea and turning that idea into reality.
AI can now generate pages, APIs, styles, tests, and even many details that developers previously postponed because they were too time-consuming.
However, speed also amplifies risk.
If the direction is wrong, requirements are misunderstood, or changes exceed the intended scope, AI can make mistakes much faster.
The first thing developers fall in love with is speed.
AI can modify UI, write APIs, fix bugs, generate SQL, and build prototypes.
But after using it longer, another problem appears:
AI does not only write code. It makes decisions.
It may misunderstand requirements, refactor unrelated modules, introduce dependencies, or remove logic it considers unnecessary.
The question becomes:
Should we give AI more restrictions?
The answer is not simply yes or no.
AI needs freedom during exploration.
But engineering requires discipline.
Experienced programmers are called engineers because engineering is not only about writing code.
Engineering means designing, building, and maintaining systems.
A production system requires:
Code affects users, revenue, data, and future maintenance.
Therefore, AI can be a creative partner, but in engineering execution it needs boundaries.
The question is not:
"Should AI be restricted?"
The real question is:
How do we organize AI inside an engineering process?
The biggest danger of AI is not that it cannot code.
The biggest danger is that it is too willing to make decisions.
A small request can become:
The generated code may work initially, but hidden costs appear later:
AI can save 30 minutes today and create 3 hours of debugging tomorrow.
Control is engineering.
Human engineering already uses:
These processes do not limit engineers.
They reduce risk.
AI is faster than humans, so it needs stronger engineering boundaries, not fewer.
CDF is my approach to AI-assisted engineering.
It is a workflow:
Understand Requirements
↓
Task Decomposition
↓
Risk Evaluation
↓
Implementation Plan
↓
Execution & Review
The goal is not to slow AI down.
The goal is to make AI understand:
Low-risk tasks can execute quickly.
Medium-risk tasks require planning first.
High-risk tasks require impact analysis and human approval.
CDF does not limit AI creativity.
During exploration, AI should still be free:
But production changes require more control:
The mature AI workflow is:
Let AI explore when exploration is needed.
Let AI follow engineering rules when execution matters.
Controlled workflows may reduce superficial speed.
But real efficiency is not how much code AI generates.
Real efficiency is:
How much AI-generated code can safely become part of the system.
Fast but unreliable code is not productivity.
The faster AI becomes, the more important brakes and steering become.
AI coding is not a magic lamp.
Engineering requires:
Powerful machines require better control.
A truck without direction can destroy a wall.
An excavator without boundaries can cause damage.
AI needs:
AI coding has changed software development.
It allows ideas to become reality faster than ever.
During creative exploration, AI should be free.
During engineering execution, AI must be controlled.
Because engineering is not about generating more code.
It is about building systems that are:
Creativity can expand freely.
Engineering must have control.
CDF is not about putting AI in chains.
It is about adding an intelligent braking system to AI development.
The future of AI engineering is not making AI run as fast as possible.
It is making sure AI arrives safely, every single time.
]]>I used to have trouble finishing my ChatGPT Plus quota in a week.
Now I can burn through it in three days.
That looks like a productivity win.
In some ways it is.
But the strange part is this: work hasn’t gotten easier. I’m more exhausted than I used to be.
I’m a developer who moved into iOS from another technical background. I use AI heavily every day.
When I first switched, almost everything was unfamiliar. Half a day could disappear digging through documentation for an API, tweaking a layout, or chasing a crash I’d never seen before.
I wasn’t fast, but the pace felt human.
I’d write some code, look something up, get a glass of water, come back, and let the problem sit for a while.
Then AI changed the rhythm.
Unfamiliar syntax? Ask AI.
Need a first pass at a UI? Have AI generate one and refine it.
Documentation, test notes, copy, small refactors—AI can help with all of it.
The gains are real. I’m not interested in pretending otherwise.
But the slower workflow had something the new one doesn’t: breathing room.
Now I can spend an entire day in a loop of prompting, reading, correcting, reviewing, testing, and prompting again.
More gets produced.
There’s just less space to think.
That made me wonder whether we’re measuring AI productivity the right way.
There’s an idea that’s become almost conventional wisdom:
AI dramatically increases productivity.
I used to accept that without much hesitation. I use AI every day and clearly get more done with it.
But the more closely I looked at my actual workflow, the more I started asking a different question:
Is AI improving end-to-end productivity, or is it mostly accelerating one stage of the process?
By productivity I don’t just mean how quickly code appears on a screen.
I mean the whole path from a request to a result: understanding the problem, building the solution, validating it, shipping it, and seeing whether it actually works.
Code generation is much faster.
But are projects shipping five times faster because code is generated five times faster?
Usually not.
That’s where one of the biggest AI illusions begins:
We confuse generation speed with productivity.
Before AI, a typical feature request might look like this:
Request → understand it → write code → test → get feedback → fix → ship.
Not exactly simple, but the communication path is direct.
With AI it often looks more like this:
Request → understand it → translate it into a prompt → interpret the AI’s response → verify that it understood the task → generate code → review the code → test → get feedback → fix → ship.
AI doesn’t sit between a coworker and the codebase and magically turn vague requests into finished software.
Someone still has to translate.
Suppose a coworker says:
“There’s something wrong with the ads on this page.”
That’s not really a coding task yet.
Does the ad fail to load?
Is it showing at the wrong time?
Is the close button broken?
Is the layout wrong?
Is the SDK misconfigured?
Is it a network problem, remote config problem, caching problem, or backend setting?
Before AI can help, I still have to narrow the problem down, gather the relevant code and logs, explain the expected behavior, and describe what actually happened.
Then, after AI proposes a solution, I have to verify it.
Did it touch the right code?
Did it change behavior somewhere else?
Did it violate an existing architecture decision?
Did it create a new release risk?
AI helps with part of the process.
It doesn’t remove the work of turning ambiguity into something executable, or turning generated output into something trustworthy.
Before AI, I mostly communicated with people.
Now I communicate with people, communicate with AI, and translate between the two.
AI didn’t eliminate communication. It added another layer.
This distinction matters because producing code is not the same as delivering software.
A real feature moves through requirements, clarification, implementation, review, testing, integration, feedback, release, and production risk.
AI is excellent at speeding up implementation. Sometimes dramatically.
But it doesn’t automatically clarify requirements.
It doesn’t eliminate integration testing.
It doesn’t make users or coworkers approve the result.
And it doesn’t make production failures less real.
In some cases AI actually creates more downstream work because it produces more code, faster.
More output means more surface area to review.
AI made “write it” much faster.
It did not make “make sure it’s right and safe to ship” equally fast.
This is probably the biggest shift I’ve felt personally.
AI has made generation incredibly cheap.
Correctness is still expensive.
When I write code myself, I’m slower, but I usually know why each piece exists. The implementation grows out of my own understanding of the problem.
With AI I may suddenly get changes across several files, a new abstraction, extra error handling, and a few “improvements” I never asked for.
Now I have to work backward through the result.
Did it misunderstand the requirement?
Did it break existing behavior?
Did it ignore the architecture?
Did it introduce a subtle bug?
Is this code maintainable?
Would I trust this change in production?
The larger the generated change, the more expensive those questions become.
The work hasn’t disappeared.
It has shifted.
Instead of spending all my time creating code from scratch, I spend more time reviewing, filtering, testing, and taking responsibility for code that appeared almost instantly.
AI made generation cheap. It didn’t make correctness cheap.
This isn’t just a personal feeling.
A lot of current AI engineering practice is moving toward the same problem: how do you make powerful coding agents reliable?
Ideas like Harness Engineering shift attention away from simply asking whether an AI can write code.
The focus becomes the environment around the agent: clear intent, constraints, feedback loops, tests, review processes, and systems that prevent a fast model from making uncontrolled changes.
That shift is telling.
The question is no longer just “Can AI write the code?”
Increasingly it’s “Can we trust the process that turns AI-generated code into production software?”
The gap between generation and delivery is becoming an engineering discipline of its own.
This problem goes far beyond software.
AI can write marketing copy quickly. That doesn’t mean the product will sell.
It can generate design variations instantly. That doesn’t mean the team will make better design decisions.
It can produce ten strategies in a minute. That doesn’t mean any of them have been validated.
It can write a PRD in seconds. That doesn’t mean the requirements are clear.
Generating more things is not the same as producing more value.
To me, productivity means something closer to this:
How much useful work was correctly understood, validated, delivered, and turned into a real result?
By that definition, raw generation is only one piece of productivity.
An important piece, certainly.
But not the whole thing.
For years people imagined AI reducing the amount of work humans would need to do.
My experience has been different.
The work is still there.
It just moved.
Developers used to spend more of their time directly producing the implementation.
Now more of the job is becoming orchestration: turning requirements into instructions, maintaining context, reviewing output, spotting mistakes, managing risk, and deciding what is safe to ship.
Human labor moved from the keyboard into judgment.
The old fatigue came from typing, debugging, reading documentation, and manually tweaking things.
The new fatigue comes from attention.
You’re constantly evaluating.
Is this answer right?
Did the model miss something?
Why did it change that file?
Should I accept this diff?
Did this fix one problem and create another?
That kind of work is less visible than writing code, but it’s still work. Often very demanding work.
AI didn’t remove human labor. It shifted it from production toward judgment, orchestration, and verification.
AI’s gains are easy to see.
Ask for code and code appears.
Ask for an article and an article appears.
Ask for an image and an image appears.
The speed is almost theatrical.
The costs that remain are harder to see.
The time spent clarifying requirements.
The time spent reading generated code.
The time spent testing.
The time spent fixing a misunderstanding.
The larger test surface created by larger amounts of generated code.
The production risk that still belongs to the human who ships it.
And then there are the costs that don’t show up in a dashboard at all: attention fatigue, context switching, the mental load of reviewing machine output all day, and the unsettling feeling that you’ve produced a huge amount of work without being completely sure how much of it you can trust.
Everyone can see how fast AI generates.
Very few people see the human effort required to turn that output into something reliable.
There’s another effect I’ve started noticing.
Before AI, if a feature took two or three days, that might have felt completely normal.
Now there’s an implicit question hanging over more and more work:
“If you have AI, shouldn’t this be faster?”
Nobody even has to say it.
Sometimes the pressure comes from ourselves.
You end the day without finishing something and wonder: Am I using AI badly? Are my prompts not good enough? Are other developers moving faster than I am?
The tools got faster, so our expectations accelerated too.
But human attention, judgment, memory, and recovery didn’t suddenly become five times more powerful.
I think of this as AI productivity inflation.
AI increases the amount we can generate, and then that increased output becomes the new baseline.
More code can be produced, so more code is expected.
More work can be started, so more work has to be reviewed.
The productivity gain creates a new productivity expectation.
Eventually part of the benefit gets consumed by the expectation it created.
The machine got faster.
So we started expecting humans to operate at machine speed.
That’s not sustainable.
The answer isn’t to stop using AI.
I certainly don’t intend to.
The better answer, in my experience, is to stop treating unlimited generation as the goal.
Good AI workflows need rails.
Let the AI understand the project before it starts editing.
Ask for a plan before asking for implementation.
Review the plan.
Keep changes small.
Inspect diffs.
Run tests continuously.
Let humans control the final merge and release decision.
That may sound slower than telling an agent “Here’s the problem. Go fix everything.”
But uncontrolled speed often creates expensive cleanup.
A slower-looking process can be faster overall if it reduces rework and makes failures easier to catch.
The stronger AI becomes, the more valuable good constraints become.
That’s not distrust.
It’s engineering.
AI has also forced me to rethink what I consider a productive day.
Finishing a feature matters.
Fixing bugs matters.
Shipping matters.
But so do things that don’t create visible output.
Clarifying a vague requirement is productive.
Proving that an approach won’t work is productive.
Deleting incorrect AI-generated code is productive.
Finding the root cause of a bug is productive.
Catching a release risk is productive.
Building a reliable test path is productive.
These things don’t generate impressive screenshots or massive diffs.
But they move a project closer to something that can actually survive contact with reality.
In the AI era, code is becoming abundant.
Judgment isn’t.
Neither is verification.
Neither is responsibility.
AI can generate an implementation.
Someone still has to decide whether it’s right.
Someone still has to decide whether it should ship.
And someone still owns the consequences when it doesn’t work.
I believe AI is one of the most useful tools I’ve ever had as a developer.
It makes me faster.
It lets me work in areas where I have less experience.
It lowers the cost of experimenting.
It can turn hours of tedious work into minutes.
None of that is in question.
But faster generation isn’t the same as faster delivery.
More output isn’t the same as more value.
And a machine’s ability to produce work faster doesn’t mean a human can review, understand, and take responsibility for that work at the same speed.
The biggest AI illusion may not be that we think AI can do everything.
It may be that we’ve started treating generation speed as a proxy for productivity.
AI should expand what humans can do.
It shouldn’t become a benchmark that humans are forced to chase.
AI is a lever, not a whip.
Real AI productivity isn’t about producing the most output.
It’s about reliably delivering more of the right things.
]]>