Dancing with AI
# Software EngineeringI still remember when ChatGPT 3.5 was first released. It was useful as a translation tool, but when it came to programming, it could only write scripts or simple functions.
In 2023, Cursor was still in beta, and its main feature was just tab completion. Before that, I had also used GitHub Copilot, but after trying it I found the accuracy too poor, so I stopped using it.
Later, when GPT-4o came out, I did indeed feel a leap in model capability. But in my view, programming was still human territory—AI could help, but it could not truly replace us yet.
Then in 2024, things quietly changed. Cursor evolved from simple tab completion to adding an AI Agent, and development shifted from “occasionally trying it out” to “indispensable.” LLMs could already independently write runnable demos, but production-grade code still required a lot of human intervention and review.
Then came 2025. Every model was improving almost on a monthly basis. By midyear I learned about Claude Code, and that was the first time I felt a qualitative leap in the model. Although it still required deep developer involvement in review and guidance, it was already able to write usable designs, and even generate corresponding code according to those designs.
The code that had originally been hand-written by humans was, in less than a year, rapidly shifting toward an AI Agent-led model.
On 2026/02/26, Cursor co-founder Michael Truell posted a tweet that clearly divided this process into three eras:
- The first era was tab completion—AI identifies repetitive work and automates it, and developers keep pressing tab to write code
- The second era was synchronous agents—engineers direct AI through prompts, working back and forth together to complete tasks
- The third era—agents can run independently for hours on cloud virtual machines, autonomously completing larger-scale tasks, while engineers only need to review the results at the end
In just a little over a year, software development has become completely different.
AI replacing software development
Back then, whenever I saw people say “AI will replace software development and software engineers,” I scoffed at it and thought it was just marketing and hype from AI companies.
As a frontline developer, the models at that time were nowhere near capable of replacing day-to-day development. They could handle simple scripts or function refactors, but once the context got large or the code became complex, the models completely fell apart, and their responses often made no sense at all.
Model capability has advanced at a breathtaking pace. AI was originally just an assistant, with most code written by humans; now AI writes more than half the code, and most of the code is produced by AI while you are responsible for review and design.
Even system design and documentation are now delegated to AI, and meeting notes are generated fully automatically by AI.
The reason is simple: model capability has progressed to the point where it can handle everyday development, and some people even iterate on products without reading the code at all.
Is that a good thing? I used to have a big question mark about that. My attitude is gradually changing now. Under certain conditions, human involvement really is the biggest bottleneck.
I ship code I don’t read
Another thing worth thinking about is: who said this? Just as Wiwi once mentioned on his blog:
Everyone has a secretly assigned “IQ default value” in our minds. The same nonsense, when said by someone with a “high default value,” we will actively try to find reasons for it and interpret the deeper meaning; when said by someone with a “low default value,” we immediately judge them to be an idiot.
Peter Steinberger was originally an active engineer in the iOS world. In 2011, he created the PDF SDK “PSPDFKit,” turning a developer tool into a document technology company widely adopted by enterprises.
After burnout left him away from programming for a while, AI made him fall in love with coding again, and he developed OpenClaw. At least when it comes to programming, his technical ability is beyond doubt.
Although software development has changed, the core principles of software engineering have not. In fact, system design, documentation, and testing have become even more important.
Test cases are the boundary that keeps AI honest. Documentation is the foundation for AI to understand context. System design ensures the overall architecture does not spiral out of control under rapid output. The things you can hand over to AI will only keep increasing, and these principles are how humans keep the lead.
But quality assurance is not just about writing tests.
From my past experience, frontline developers are usually not good QA.
Developers know their own implementation too well, and will subconsciously avoid paths that may produce bugs. When testing, they almost always follow the happy path.
At the same time, their understanding of requirements is often constrained by the implementation itself—you know how the code was written, so it becomes hard to step back and re-examine it from the user’s perspective. This is not an ability issue, but a structural limitation of the role.
What will matter in the future?
When the cost of execution approaches zero, direction is everything. How do you turn a user’s problem into a clear, actionable plan?
Past development experience here is a double-edged sword. It can become a curse of knowledge, or it can become an advantage that helps you stay ahead.
Some say Harness Engineering is just a rebranding of Software Engineering. It is true that concepts like constraining the scope of AI, making AI validate in a closed loop, and clearly defining standards for what is good and what is bad already existed before.
This reminds me of a book I’ve recently been reading, 《機制化之神》.
Turning what you take for granted as “good” into a standard that can be referenced and reproduced. In the past, this was for smoother team collaboration; now it is also so AI can reproduce it. That is the essence of Harness Engineering.
Having direction is not enough—you have to turn that direction into reality.
AI cannot push a project forward. You have to communicate with stakeholders and users, convince other teams that your plan is feasible, and even deal with all the strange realities inside an organization. None of that can be solved by AI.
Responsibility is the most important thing I’ve learned in the past year.
The way work used to be structured, along with team division of labor, made it easy for people to draw very clear lines around responsibility: “as long as I do my part, that’s enough.”
But with the same AI, different people can produce completely different outputs and results. The difference lies in whether you are willing to take responsibility for the outcome.
That makes me think of Hanzawa Naoki. No matter how unreasonable the environment or the boss, if it’s a case he is responsible for, he will find a way to break through one obstacle after another—and even think several steps ahead for the client.
The combination of skills also needs to be rethought. If AI can do 70 points worth of work, then doing 80 points is nowhere near enough—AI is cheaper, more obedient, and easier to use than you are. Going down a pure specialist path requires top-tier ability. People like Andrej Karpathy are still heavily sought after by major companies, but that is the very top of the pyramid.
For most people, I would recommend the path of a generalist with one specialty. It can’t just be superficial dabbling; in every domain, you should have at least Senior-level understanding. The boundaries between functions will become increasingly blurred in the future. From design, architecture, development, testing, deployment, to operations, you need sufficiently deep understanding to make good judgments.
Last is taste.
Architecture, technology choices, system deployment, UI/UX—behind all these decisions lies a central set of principles. Taste is the set of principles formed through your own experience, background, and values. It can only grow through repeated practice.
And taste is not limited to technical decisions; it also includes judgment about the product itself. Including myself, even though developers are the people closest to the product and know every implementation detail of every feature, that does not necessarily mean they have any real thoughts about the product. A requirement comes in, you build it; once it’s done, you hand it over. Rarely do you step back and ask, “Does this feature really solve the user’s problem?”
Software engineers should move toward becoming Product Builders. You can’t just make things—you need to have opinions about the product itself, and even proactively propose improvements. When AI pushes implementation costs extremely low, the people who can define “what to do” and “why do it” will be more valuable than those who only know “how to do it.”
A new kind of software engineer — the Forward Deployed Engineer
I want to start from the role of Forward Deployed Engineer, which may be a path software engineers can try in the future. Below is OpenAI’s Forward Deployed Engineer job description.
A Forward Deployed Engineer is a role that works directly on the customer’s site—observing how they actually operate, identifying pain points, then personally building solutions and pushing the project all the way through to launch.
As major enterprises begin adopting AI, demand for FDEs is exploding.
Adopting AI is not something you can solve by vibe-coding one solution. It often means being embedded in the company, facing their problems, working with internal teams, and coordinating across functions.
The existence of the title Engineer means that in day-to-day work, there are still many problems that require hands-on coding to solve, including building PoCs, writing and deploying production-grade code, and collaborating with on-site product teams.
As The Pragmatic Engineer notes, the responsibilities of an FDE are similar to a startup CTO—owning the execution of high-stakes projects end to end in a small team. According to Salesforce’s analysis, in the first nine months of 2025, FDE job postings grew by more than 800%, and Salesforce itself announced plans to build a 1,000-person FDE team.
The core skill of this role is turning vague requirements into directions that can actually be executed.
Clients often know something is wrong, but they can’t clearly say what they want. The job of an FDE is to find a shape within that chaos and turn it into something real.
You need to earn the client’s trust quickly so they are willing to tell you the real problem. You need to convince stakeholders that your plan is feasible. You need to deliver an answer that is not perfect, but good enough, under limited resources and tight deadlines.
AI as a double-edged sword for development tools
As Huli wrote in “AI 與鴨子，惰性與真實” and Kao Chen-lung wrote in “AI 時代寫程式，你是在學習還是在偷懶,” they argue that fundamentals matter, and that vibe coding is eroding the motivation to learn them.
I think these two articles share several ideas, and I strongly agree with them:
- Do not blindly accept AI output: the duck theory comes from Duck Typing. It is a very fitting metaphor for AI output—“if it works, that’s good enough” used to be a joke among developers, but now if you only aim for “it works,” that is basically vibe coding.
- Testing has become much more important: both articles mention the importance of testing. Beyond allowing AI to self-verify, tests are the way to keep AI from going off the rails.
- AI is an assistant: use AI to accelerate learning or handle higher-value tasks, such as thinking about product direction and clarifying user needs.
- Judgment and fundamentals: without solid programming fundamentals, beginners cannot even tell whether code generated by AI is good or bad.
The lesson of AlphaGo
I often wonder about the meaning of the Olympics. What major contribution does it make to human development? If tomorrow everyone stopped playing baseball and no competitions were held anymore, would the world really be any different?
After thinking about it for a long time, I came to a conclusion: the pursuit of limits is meaningful in itself, even if it does not make the world better. Taking that further, apart from survival, most human behavior is actually “meaningless”—yet we still do it, and we do it with joy.
That makes me think of AlphaGo. In 2016 it defeated human players, but Go competitions did not disappear, and humans did not give up the game.
Instead, players began learning from AI, breaking centuries of established patterns and thinking, and exploring moves no one had ever tried before. Go became richer because of AI’s involvement. (No idea why Chia-Jia Hsieh keeps showing up in my YouTube recommendations)
Will programming follow the same path?
Maybe one day, hand-written code will become a pure kind of enjoyment, just like some people choose to write with fountain pens or take photos on film. Not for efficiency, but because they enjoy the process itself. Most code will be generated by AI, and those who insist on hand-writing it will simply be enjoying a skill that is no longer “necessary.”
I still don’t have an answer.
Do we still need to study computer science?
Computer science students should, by nature, be solving harder problems. If the only reason to enter a CS program is to write a CRUD app four years later, then perhaps you really don’t need to study it—because LLMs can already do that now.
But if you think about it the other way around, when everyone can build products with an extremely low barrier, the harder problems become more valuable. So what counts as a “harder problem”?
A few examples off the top of my head:
- The evolution of the Linux kernel — AI workloads are placing new demands on operating systems: better schedulers, safer memory models, and highly predictable real-time systems. These problems will not disappear just because AI can write code; in fact, they are becoming more urgent because AI is becoming mainstream.
- Next-generation computing architectures — although we already have dedicated designs like Google’s TPU or NVIDIA’s Tensor Cores, the bottleneck in LLM inference is still memory bandwidth and latency.
- Compiler and programming language design — AI generates massive amounts of code, but correctness, security, and performance are ultimately determined by the underlying language and compiler.
AI lowers the barrier at the application layer, but at the same time it pushes the challenges at the lower layers higher and makes them more important. The value of a CS degree has never been about teaching you how to write code; it is about training you to solve these hard problems.
A new feudal era
What is the difference between monopoly and feudalism? Monopoly controls price, feudalism controls ability. Monopoly makes what you buy more expensive; feudalism makes it hard to leave.
I keep wondering which one best describes the concentration of power in the AI era.
We’ve already lived through past tech monopolies. In the era when Microsoft monopolized operating systems, developers “had to” use Windows. When Google monopolized search, advertisers “had to” buy Google Ads. But those monopolies affected distribution—they were about who got how much money. Your skills themselves did not lose value just because Microsoft monopolized OSes; if you switched platforms, you were still the same engineer.
AI is different. When models can directly replace your labor, the monopolist affects not just price, but whether your labor has value at all.
This is much closer to the dependency structure of feudalism.
In traditional feudal society, tenant farmers could not leave the landlord. Capitalism broke that dependency: everyone could participate in the market, accumulate capital, and use their own skills to compete for a place in the capital market.
Now things are moving backward. To make full use of AI in development, Claude Code or Codex are necessities. These tools are highly concentrated in the hands of Anthropic, Google, and OpenAI, and the technical and capital barriers are so high that they are almost impossible to replicate. If you don’t use them, while your peers are developing with AI, you are at a competitive disadvantage. That pressure will only grow.
Some people will say this is just capital monopoly—nothing new.
I think the key difference is leverage. Historically, every improvement in labor conditions—shorter hours, higher pay—was mostly not given spontaneously by the structure, but obtained through labor movements and political pressure in exchange for leverage.
Workers’ greatest leverage has been: you cannot do without me. If I strike, your factory stops. But models can replace strikes, and strike action itself is no longer a weapon.
What truly unsettles me is this: as a group, knowledge workers are losing structural bargaining power, and the new source of leverage has not yet emerged.
Open models like Llama, Mistral, and DeepSeek have indeed lowered the barrier. But in terms of general capability, the gap with the big three is still obvious. The scale of data, compute, and engineering accumulation needed to train models is not something the open-source community can catch up to in the short term.
The evolution of open models and the spread of personal compute may become this era’s printing press. But it took centuries from the invention of printing to the point where it truly shook power structures. Whether we have that much time, I don’t know.
About AI slop
Recently many people have been complaining that there is more and more AI garbage on the internet—articles full of AI voice, hastily made images and videos clearly generated by AI. People call this phenomenon AI slop.
Whenever a technology becomes industrialized, the market will inevitably be flooded with large amounts of cheap, rough products. From the perspective of a hand-pour coffee enthusiast, instant coffee is utterly unforgivable slop. (I like both hand-pour and instant coffee.)
A lot of people do not pursue quality. What you see as AI slop may be exactly the right product for them. Just as, in the eyes of hand-pour coffee enthusiasts, I may be nothing more than an unsophisticated commoner.
Slop is an inevitable byproduct of a technology once it truly becomes widespread. Or, put another way—software development is also about to become industrialized.
AI can easily generate an article that is fluent and logically sound, but has no real point of view. Content that truly has opinions, lived experience, and humanity will instead become scarcer and more valuable.
The market will eventually find its own balance.
Slow down
The meaning of a concert is not to perfectly reproduce the studio recording, but the moments created by improvisation, mistakes, and interaction with the audience.
Code written by AI may be more “correct” than yours, but the edge cases you accidentally discover during debugging and the intuition you build after stepping in holes are the truly valuable things. Taste grows out of imperfect experience.
AI also makes output extremely easy.
Writing blog posts and taking notes—these “slow” things are, at their core, processes of reflection. Organizing your own thoughts is itself an act of resistance, resisting being swept away by speed.
What becomes important, in contrast, are the things that seem like “a waste of time”: writing code by hand to understand the underlying principles, spending three hours reading a book unrelated to work, talking to people face to face, maintaining a blog read by only a few dozen people. The returns on these things may suddenly appear at some unexpected moment.
I want to see your imperfections more, and hear what you’re worried about.
Threshold of experience
Ohtani Shohei recently said in an NHK interview: “The accumulation of the process is important, but grasping the technical key point takes only a moment.”
過程の積み重ねは大事だが、技術的なコツを掴むのは一瞬
The same is true for learning any skill. Before reaching the threshold, accumulation is certainly important, but the moment when real change happens is often instantaneous.
The key is whether you can keep going until that moment of change arrives.
Most anxiety in the AI era comes from fear, and fear comes from the unknown.
There are many things you can only truly understand after acting on your own and accumulating experience. AI cannot cross that threshold for you. It can speed up your accumulation, but that “instant of insight” can only be reached by you yourself.
Dancing with AI
Use AI well and make it your accelerator. Give repetitive tasks to AI, and use the time you save to do the things only you can do: define problems, design direction, communicate with people, and take responsibility for the outcome.
Slop will pass. Transitional periods are always like this. Instant coffee did not eliminate specialty coffee, and AI-generated content will not eliminate opinionated creation.
The things that take time are worth actively pursuing. The accumulation that looks low-ROI will, at some unexpected moment, pay off and become what makes you different from others.
In an era where AI is getting stronger and stronger, human connection has become even more important. AI can help you write code, organize data, and generate reports, but it cannot build trust for you, share experiences, or tell you the hard truth when you are lost.
If you liked this article, feel free to write me a note and tell me what you think!