Revisiting the Disillusionment with Software Engineering

Around six years ago, I read an article titled “The Disillusionment with Software Engineering.”

I felt that comparing software development to building airplanes or architecture wasn’t quite fitting. The latter involves processes that are difficult to alter once underway, whereas software development is inherently built on the premise of continuous iteration. Given their differing natures, it’s hard to make a direct comparison. It’s like how you wouldn’t ask builders midway through constructing a house to add Howl’s Moving Castle features so the house can walk on its own.

Since the emergence of AI—from initially thinking it wasn’t a big deal back in 2023 and was far from replacing daily development; to getting used to AI-assisted development by 2025, where autocomplete became indispensable; to now, where over 90% of code is generated directly by AI—the disillusionment with software engineering has swept back in, albeit in a different form.

In the past, engineers wrote bad code themselves; now, AI churns out massive amounts of code that appears to work, yet nobody truly understands.

Software development in the era of AI has roughly split into two camps. One camp believes coding should be handed over entirely to AI, with no regard for maintainability, readability, or extensibility—humans only need to set the intent and direction. The other camp believes this “AI slop” offers zero value.

@yusukebe Yusuke Wada (@yusukebe) on X まじでPRの意味がなくなるな 低品質のPR PR取り込んでもらいたいだけの人のコミットを入れたくない CI回すのが怖い コードならメンテナが書ける

The author of that tweet is the creator of Hono (if you’re still using Express, I highly recommend checking out Hono). He posted several tweets detailing his deep frustration with receiving a flood of low-quality, obviously AI-generated pull requests lately.

We are currently in the chaotic middle ground between the emergence of LLMs and their maturity.

The era of stable and mature LLMs will inevitably arrive, and model advancements will fundamentally reshape software development. But we don’t know when that day will come. Until that singularity arrives, all we can do is drift with the current.

Caught Between Pain and Excitement

On one hand, I am very bullish on the future of AI. As model capabilities continue to improve and grow stronger, many tasks that currently require human intervention will inevitably be replaced.

Whether in terms of code quality, the quality of AI-generated output, or the effort required to polish a project, the barrier to entry will only get lower.

Yet recent events have also brought a certain amount of pain. In projects or across the community, you frequently see people tossing out AI-generated content without reviewing it at all.

This shows a complete lack of regard for the reader—whether it’s code, documentation, or even discussions where someone just dumps an entire chat transcript with Gemini right into the thread. In my view, the baseline expectation should be having your own thoughts first, using AI to validate or strengthen your arguments, and only then bringing them forward. You should synthesize and curate the information first; that’s basic respect for the reader.

As Simon points out in Anti-patterns: things to avoid, if you generate thousands of lines of code with AI and open a PR without reviewing it yourself, you are simply shifting the burden of verifying whether the code works onto the reviewer.

The reviewer could have asked an AI to write it themselves—so what did you actually contribute?

A responsible PR should look like this: you are confident the code works because you’ve verified it yourself; the scope of changes is small enough that the reviewer doesn’t immediately want to close the tab; and the PR description provides enough context explaining why you made the change—instead of having AI generate a slick-sounding summary that you haven’t even read yourself.

AI has made generating code far too easy, which conversely means you need to proactively prove that you’ve put in the work.

Attaching logs of manual testing, explanations for implementation choices, or even a screenshot—all of these tell the reviewer: I’ve reviewed this; this isn’t just garbage I dumped on you.

Taste

Another source of pain for me comes down to taste and experience.

After writing code for a long time, you naturally develop an eye for anti-patterns. You know that while a piece of code works right now, it will inevitably cause trouble later—and sometimes the fix takes only a few lines.

The trouble is, many people today have grown accustomed to using AI-generated code right out of the box without looking back (myself included, at times). This creates a vicious cycle: the AI takes flawed code as context, and its subsequent outputs build on that flawed foundation, straying further and further off course while the developer remains blissfully unaware.

Here are a few concrete examples:

Calling setState inside a React useEffect, causing unnecessary re-renders; or architectural decisions like skipping a CDN and serving static assets directly from the file system.

These things work completely fine in local testing and hold up when traffic is low. But when traffic surges and the codebase swells, fixing them is no longer a matter of tweaking a few lines.

And this isn’t necessarily because developers are too lazy to check—they might genuinely not know there’s a problem. They haven’t tripped over that pitfall before, so they can’t see it. Yet these details have a profound impact on software quality. The end result is that whoever cares about quality suffers. Both Huli and Brother Long have expressed similar sentiments.

AI 時代寫程式，你是在學習還是在偷懶？ | 高見龍 AI 帶來的變革堪比當年從組合語言到高階語言的轉變，而最核心的挑戰在於從「確定性」轉變到「非確定性」。AI 會說謊、會瞎掰，但用得好能讓效率翻倍。本文探討 Vibe Coding 的陷阱、學習迴圈的重要性，以及初學者與資深工程師使用 AI 的策略差異。AI 是工具不是魔法，能讓你變強也能讓你變弱，關鍵不在於「要不要用 AI」，而在於「怎麼用 AI」 高見龍

AI 與鴨子，惰性與真實 - Huli 終於到了個我覺得適合來寫一篇文章，聊聊我對 AI 的感想的時機了。 前兩年都還太早，很多東西進步的速度太快，文章會跟不上。舉例來說，假設我 2023 年底寫了篇文章，可能會說 AI 看起來厲害但工作上幫不了太多忙。若是 2024 年底寫，會說 AI 工作上可以幫忙了，但一半的工作還是要自己來。而.. Huli

You could say my taste is built upon “solid fundamentals.” When others’ output fails to meet what I consider fundamental, it becomes a source of frustration, and over time, even I start to feel its influence on my own work.

I’m Still Looking for Answers

Just yesterday, human error caused source maps for Claude Code to leak, allowing people to easily reconstruct the source code. Even engineers at Anthropic earning upwards of 10 million NTD a year make mistakes (though the root cause might not have been AI). Does that mean caring about fundamentals, security concerns, and quality no longer matters?

Coding is largely solved ——Boris Cherny

Go and Baseball

A decade ago, AlphaGo defeated world-champion Go players Lee Sedol and Ke Jie. Today, no human player can beat AI. In a sense, Go has been “solved”—yet Go hasn’t disappeared. People still play, professional players still exist, and people still get thrilled by a brilliant move.

The same goes for baseball. Objectively speaking, 9+1 players on a field throwing, hitting, and running the bases offers no tangible contribution to the functioning of the world. The same could be said for virtually all competitive sports. Yet humans still engage in these “useless” pursuits, and they take them remarkably seriously.

Perhaps once AI has solved most productive work, coding will become an activity more akin to Go or baseball: you code not because the world desperately needs you to, but because you care about the process itself.

Next Steps

Go with the flow. Maybe that’s the best answer after all. Before the technological singularity, there are still a few things I want to try:

• Formalize the taste in my mind into reproducible standards
• Share my software development experience from recent years, including architecture and tech stack selection
• Share some thoughts on software development in Japan

There’s another point I’ve been feeling deeply about lately, but my thoughts haven’t fully crystallized yet. I’ll share once there’s progress.

Finally, I’d like to share a quote by Zaitsu from 100 Meters that I really love:

不安は対処すべきではない。人生は常に失う可能性に満ちている。そこに命の醍醐味がある。 恐怖は不快ではない。安全は愉快ではない。不安とは君自身が君を試す時の感情だ。 栄光を前に対価を差し出さなきゃならない時、ちっぽけな細胞の寄せ集めの人生なんてくれてやればいい。

Anxiety isn’t something that should be managed. Life is always full of the possibility of loss. That is the true essence of living. Fear is not unpleasant, and safety is not pleasant. Anxiety is the emotion that arises when you are testing yourself. When you must pay a price in the presence of glory, why not just surrender a life that’s merely a petty cluster of cells?

What do you want to do?