Dancing with AI
I still remember when ChatGPT 3.5 was first released. While it was handy as a translation tool, using it for programming was limited to simple scripts or rudimentary functions.
In 2023, Cursor was still in Beta, with its marquee feature being tab auto-complete. Before that, I had tried GitHub Copilot, but after testing it out, I stopped using it because its precision was simply too poor.
Later, when GPT-4o came out, I definitely felt a leap in model capabilities. Yet coding, in my view at the time, remained firmly within the human domain—AI could help, but it couldn’t truly replace us.
By 2024, Cursor evolved from pure tab auto-complete to integrating AI Agents. Development shifted from “occasional experiments” to “essential workflows.” LLMs were already capable of writing functional demos independently, but production-grade code still demanded substantial human intervention and review.
Then came 2025. Models across the board seemed to evolve on a monthly basis. By mid-year, I learned about Claude Code, and for the first time, I felt a qualitative leap in model capability. Even though developers still needed to participate deeply in reviewing and guiding it, it could already produce usable architectural designs and implement the corresponding code according to those designs.
In less than a year, code once written by human hands was rapidly transitioning to an AI Agent-driven paradigm.
On 2026/02/26, Michael Truell, co-founder of Cursor, posted a tweet clearly dividing this journey into three eras:
- The first era was Tab—AI identified repetitive tasks and automated them, with developers hitting tab repeatedly to write code.
- The second era was Synchronous Agents—engineers directed AI through prompts, collaborating back and forth to complete tasks.
- The third era—Agents can run independently in cloud virtual machines for hours, autonomously completing larger-scale tasks, with engineers only needing to review the final results.
In just over a year, software development has transformed completely.
AI Replacing Software Development
Back then, whenever I heard claims that “AI will replace software development and software engineers,” I scoffed, thinking it was just marketing hype and bluster from AI companies.
As a frontline developer, the models at the time were nowhere near capable of handling day-to-day development. Writing simple scripts or refactoring functions was fine, but as soon as context grew or the codebase became complex, the model fell apart entirely, often generating nonsensical responses.
Yet model capabilities advanced at breakneck speed. Initially, AI was merely an assistant, with humans writing most of the code; now, AI accounts for more than half of the code written. Most of the implementation is generated by AI, leaving you responsible for review and design. The first time I felt this shift was in mid-2025 after I started using Claude Code.
AI has even become involved in system design and documentation, and meeting notes are now generated entirely automatically.
The reason is simple: models have progressed to the point where they can handle daily development tasks, and some developers even iterate on products without reading the code at all.
Is this a good thing? In the past, I would have had serious doubts. Now, my stance has gradually shifted: under certain conditions, human involvement is indeed the biggest bottleneck.
I ship code I don’t read
Another question worth pondering is: who said this? As Wiwi once pointed out on his blog:
In our minds, each person secretly has a “default IQ rating.” When a piece of nonsense comes out of the mouth of someone with a “high default,” we proactively find excuses for them and interpret its profound meaning; when it comes from someone with a “low default,” we immediately write them off as an idiot.
Peter Steinberger was an active engineer in the iOS community who created the PDF SDK “PSPDFKit” in 2011, scaling it from a developer tool into a document technology company widely adopted by enterprises.
Having stepped away from coding due to burnout, AI reignited his love for programming and led him to develop OpenClaw. At least when it comes to coding, his technical competence is beyond question.
Although software development has changed, core software engineering principles remain immutable. System design, documentation, and automated testing have actually become more critical, not less.
Test cases define the boundaries for AI to do its job well; documentation provides the foundation for AI to understand context; system design ensures that the overall architecture doesn’t spiral out of control amidst rapid output. As more and more tasks are handed over to AI, these principles become the very means by which humans retain agency—a discipline that has come to be known as Harness Engineering.
What Will Matter in the Future?
When the barrier to development drops to an unprecedented low and the cost of execution approaches zero, direction is everything.
Past development experience becomes a double-edged sword: it can either be a curse of knowledge, or the edge that keeps you ahead.
Some argue that Harness Engineering is merely Software Engineering repackaged.
To be fair, concepts like constraining AI scope, enabling closed-loop verification, and establishing clear criteria for what is good and bad have always existed.
This brings to mind a book I recently read, The God of Systematization.
Turning what you take for granted as “good” into a referenceable, reproducible standard used to be about making team collaboration smoother; now, it’s about enabling AI to reproduce it too. That is the essence of Harness Engineering.
Having a direction alone is not enough. AI cannot drive a project forward—you must communicate with stakeholders and users, convince other departments that your approach is viable, and navigate the oddities of organizational dynamics. None of these can be resolved by AI.
A sense of ownership is the most important lesson I’ve learned over the past year.
Traditional working styles and team divisions made it easy for people to compartmentalize responsibility: “As long as I do my part, that’s enough.”
Yet with the exact same AI tools, different people produce radically different outputs and outcomes. The differentiator lies in whether you are willing to take ownership of the final result.
It reminds me of Hanzawa Naoki: whatever project he took on, no matter how unreasonable the environment or his superiors were, he would find a way to break through every obstacle, always anticipating the client’s next step, or even their next ten steps.
Our skill combinations also demand rethinking. If an AI can score a 70 out of 100, reaching an 80 is far from enough—AI is cheaper, more obedient, and more accessible than you are. Pursuing a purely specialized path requires world-class caliber; figures like Andrej Karpathy will always be fiercely sought after by major tech firms, but that represents the very pinnacle of the pyramid.
For most people, I recommend the “generalist plus a specific spike” route. This doesn’t mean just scratching the surface; you need at least a Senior-level grasp across multiple domains. Moving forward, the boundaries between roles will increasingly blur. From UI/UX design, architecture, and development to testing, deployment, and operations, making sound judgments will require deep comprehension across the entire stack.
Finally, there is taste.
Architecture, tech stack selection, deployment strategies, and UI/UX—all these decisions require a core set of guiding principles. Taste is that very set of principles, forged through your experience, background, and values. It can only be cultivated through repeated, deliberate practice.
Taste isn’t limited to technical decisions; it encompasses judgment about the product itself. Developers—myself included—are often closest to the product and intimately familiar with every implementation detail, yet don’t necessarily have opinions about the product itself. When a requirement lands, we build it; when it’s built, we ship it, rarely taking a step back to ask: “Does this feature actually solve the user’s problem?”
Software engineers will inevitably transition into Product Builders. It’s no longer enough to merely build things; you must develop opinions about the product and proactively propose improvements. When AI drives implementation costs down to near zero, those who can define what to build and why to build it will be far more valuable than those who only know how.
The New Archetype of Software Engineer: Forward Deployed Engineer
Looking through the lens of the Forward Deployed Engineer (FDE) role offers a glimpse into a potential future career path for software engineers. Take, for example, OpenAI’s Forward Deployed Engineer job description.
A Forward Deployed Engineer works directly on-site with clients—observing how they actually operate, uncovering their pain points, building hands-on solutions, and shepherding projects all the way to production.
As major enterprises race to adopt AI, demand for FDEs has exploded.
Adopting AI isn’t as simple as vibe-coding a quick solution. It often means embedding within an enterprise, confronting their nuanced challenges, and collaborating and coordinating with internal teams.
The “Engineer” title remains because daily responsibilities still involve a great deal of hands-on coding to solve real problems—building PoCs, writing and deploying production-grade code, and working side-by-side with on-site product teams.
As The Pragmatic Engineer noted, an FDE’s responsibilities resemble those of a startup CTO, owning the end-to-end execution of high-stakes projects within small teams. According to Salesforce’s analysis, FDE job postings grew by over 800% in the first nine months of 2025, with Salesforce itself announcing plans to assemble a 1,000-person FDE team.
The core capability of this role is translating ambiguous requirements into actionable, executable roadmaps.
Clients often sense that something is broken, but cannot articulate what they need; an FDE’s job is to discern the contours within that chaos and bring them into reality.
You must build trust with clients in a short time so they feel comfortable revealing their genuine problems; you must persuade stakeholders that your proposed solution is viable; and under real-world constraints of limited resources and tight deadlines, you must deliver an answer that may not be perfect, but is good enough.
AI as a Developer Tool: A Double-Edged Sword
As Huli wrote in AI and Ducks, Laziness and Reality and Kao Chen-Long (Eddie Kao) wrote in Coding in the AI Era: Are You Learning or Slacking Off?, both emphasize that fundamentals matter, and that Vibe Coding is eroding the motivation to learn them.
I found several shared insights across both articles that strongly resonate with me:
- Don’t blindly accept AI output: The duck metaphor originates from Duck Typing. It fits AI output remarkably well: “as long as it works, it’s fine” used to be an inside joke among developers, but if your standard today is merely “it works,” you are simply vibe coding.
- The importance of testing has increased dramatically: Both articles emphasize testing. Beyond enabling AI to perform self-verification, tests are the safeguard preventing AI from running amok.
- AI is an assistant: Use AI to accelerate learning or tackle higher-leverage tasks, such as thinking through product direction or clarifying user needs.
- Judgment and foundational competence: Without a solid programming foundation, beginners have no way of evaluating whether AI-generated code is sound or flawed.
Lessons from AlphaGo
I often wonder about the purpose of the Olympic Games. What major contribution do they make to human development? If everyone stopped playing baseball tomorrow and all competitive sports ceased, would the world really be any different?
After thinking about it for a long time, I reached a conclusion: the pursuit of the absolute limit is its own meaning, even if it doesn’t make the world an objectively “better” place. Taken further, beyond basic survival, most human activities are technically “meaningless,” yet we continue doing them—and revel in them.
This reminds me of AlphaGo. In 2016, it defeated the human Go champion, yet competitive Go tournaments didn’t vanish, nor did humans abandon the game.
Instead, Go players began learning from AI, shattering centuries-old joseki patterns and conventional wisdom to pioneer strategies no human had ever played before. Go became richer because of AI. (I have no idea why Joanne Missingham keeps popping up on my YouTube recommendations.)
Will programming follow the same path?
Perhaps one day writing code by hand will become a pursuit of pure enjoyment, much like choosing to write with a fountain pen or shoot with a film camera. Not for efficiency, but for the sheer pleasure of the craft itself. Most code will be generated by AI, while those who insist on writing it by hand will simply be savoring a craft that is no longer “necessary.”
I don’t have the answer yet.
Is a Computer Science Degree Still Worth Pursuing?
Computer science students should always have been focused on solving harder problems. If the sole purpose of enrolling in a CS degree is to emerge four years later knowing how to build a basic CRUD app, then indeed, it’s no longer necessary—LLMs can already handle that today.
Conversely, when the barrier to building products drops so low that anyone can do it, solving the harder problems becomes all the more valuable. What are these “harder problems”?
To name a few:
- Next-generation computing architectures—Despite specialized hardware like Google’s TPU or NVIDIA’s Tensor Cores, the primary bottleneck in LLM inference remains tied to memory bandwidth and latency.
- Compiler and programming language design—AI may generate vast amounts of code, but correctness, security, and performance are ultimately dictated by underlying languages and compilers.
AI has lowered the barrier at the application layer, but it has simultaneously elevated the significance and complexity of low-level challenges. The value of a CS degree was never just about writing code; it lies in equipping you with the ability to tackle these fundamental challenges.
Stop emphasizing that you don’t have a CS degree; in this century, anyone without rigor is effectively non-CS. — Jserv
The Neo-Feudal Era
What is the difference between monopoly and feudalism? A monopoly controls prices; feudalism controls capability. A monopoly makes things more expensive; feudalism makes you dependent.
Lately, I’ve been reflecting on which form the concentration of power in the AI era resembles more closely.
We’ve all lived through tech monopolies before. When Microsoft monopolized operating systems, developers had to use Windows; when Google monopolized search, advertisers had to buy Google Ads. But those monopolies governed distribution—a question of who captured how much revenue.
Yet when an AI model can directly substitute for your labor, the monopolist no longer merely dictates price; they dictate whether your labor holds any value at all.
In traditional feudal societies, serfs could not exist apart from their landlords. Capitalism disrupted this dependency, allowing individuals to enter the market, accumulate capital, and leverage their skills to stake out a place in the market economy.
Today, the tide seems to be reversing. To develop effectively with AI, tools like Claude Code or Codex are becoming indispensable. These tools are highly concentrated in the hands of Anthropic, Google, and OpenAI, surrounded by technical and capital moats virtually impossible to replicate. If you choose not to use them while your peers do, you operate at a stark competitive disadvantage. That pressure will only mount.
Some might argue this is merely standard corporate monopoly, nothing novel.
I believe the critical difference lies in leverage. Throughout history, every improvement in labor conditions—shorter working hours, higher wages—was rarely granted spontaneously by structures; it was won through labor movements and political pressure backed by bargaining chips.
A laborer’s greatest leverage has always been: you cannot function without me. If I strike, your factory halts. But when models can replace striking workers, the strike itself ceases to be a weapon.
What truly un緻rves me is that knowledge workers, as a collective class, are losing their structural bargaining power, and new leverage has yet to emerge.
Open-source models like Llama, Mistral, and DeepSeek are indeed lowering barriers. Yet in terms of general capability, the gap between open models and the Big Three remains pronounced. The scale of data, compute, and accumulated engineering required to train frontier models is not something the open-source community can bridge in the short term.
The evolution of open-source models and the decentralization of personal compute might eventually become the printing press of our era. But the printing press took centuries from its invention to fundamentally overturn power structures. Whether we have that much time, I do not know.
On AI Slop
Lately, many have voiced frustration over the surge of AI junk across the web—formulaic, poorly crafted articles dripping with AI mannerisms, along with overtly AI-generated images and videos. People have taken to calling this phenomenon “AI Slop.”
Whenever a craft is industrialized, the market is inevitably flooded with cheap, shoddy products. Through the eyes of a pour-over coffee purist, instant coffee is unforgivable slop. (Personally, I enjoy both pour-over and instant coffee.)
Many people simply do not demand premium quality; what looks like AI Slop to you is good enough for them. Just as in the eyes of a pour-over aficionado, my tastes might seem unrefined.
Slop is an unavoidable byproduct of a technology achieving widespread adoption. Looked at from another angle: software development is on the brink of being industrialized.
AI can effortlessly generate an article with coherent phrasing and tight logic, yet devoid of any genuine perspective. Consequently, content with authentic viewpoints, lived experience, and human warmth will become rarer—and far more valuable.
The market will eventually find its own equilibrium.
Slowing Down
Code written by an AI might be more “correct” than yours, but the edge cases you uncover during grueling debugging sessions, and the intuition forged after stumbling into pitfalls—those are what truly hold lasting value. Taste grows out of imperfect experience.
AI has made production extraordinarily effortless.
Writing blog posts and taking notes—these “slow” rituals are inherently reflective. Organizing one’s own thoughts is an act of resistance in itself, resisting being swept away by velocity.
Ironically, the activities that seem like a “waste of time” are precisely the ones that matter: writing code by hand to grasp underlying principles, spending three hours reading a book unrelated to work, having face-to-face conversations, or running a blog that only a handful of people read. The dividends of these pursuits tend to surface unexpectedly, at moments you least anticipate.
I would much rather witness your imperfections and hear about your real struggles.
The Experience Threshold
In a recent NHK interview, Shohei Ohtani shared a thought: “The accumulation of the process is important, but grasping the technical knack takes only an instant.”
過程の積み重ねは大事だが、技術的なコツを掴むのは一瞬
Learning any skill works this way. The grind before reaching the threshold is undoubtedly essential, but the actual breakthrough often arrives in a flash.
Whether you can sustain your efforts until that moment of transformation arrives is what truly matters.
Much of our anxiety in the AI era stems from fear, and fear stems from the unknown.
Many insights can only be internalized through your own actions and accumulated experience; AI cannot cross that threshold on your behalf. It can accelerate your accumulation, but that fleeting moment of epiphany is something only you can reach.
Dancing with AI
Embrace AI and let it serve as your accelerator. Delegate repetitive tasks to it, and invest the time you save into the things only you can do: defining problems, setting direction, communicating with people, and taking ownership of outcomes.
The slop will pass; transitions are always turbulent. Instant coffee never wiped out specialty pour-overs, and AI-generated content will not extinguish creative work infused with genuine perspective.
Things worth doing slowly are worth pursuing deliberately. Those investments that appear to have low immediate ROI will cash out when you least expect it, becoming the very qualities that set you apart.
In an era where AI grows increasingly powerful, human-to-human connection matters all the more. AI can write code for you, organize data, and generate reports, but it cannot build trust for you, share lived experiences, or offer you an honest word of truth when you find yourself lost.
If you enjoyed this post, feel free to drop me a note and share your thoughts!
Related Posts
- Revisiting JWT vs. Session Cookies When is JWT suitable, and when are session cookies better? A re-examination of this classic topic from the perspectives of security, implementation cost, and user experience.
- In 2026, You Might Not Need AWS Before choosing a cloud platform, calculate the true cost your team pays for AWS.
- Why You Should Deploy Services with ECS When running containerized services on AWS, why ECS is a more pragmatic choice than EC2 and EKS—and how deployment complexity eats away at your budget.
- Revisiting the Disillusionment with Software Engineering With massive advancements in LLMs completely transforming the landscape of software development, building an application now comes with virtually zero barrier to entry.