During the third week of June, a quiet collective reckoning spread through the code community.
The starting point can be traced back to Armin Ronacher’s short essay The Coming Cycle. The creator of Flask and Click sent the community something close to a warning signal: we are entering a cycle — first ecstasy at the convenience of AI coding, then facing the systemic costs of those generated artifacts during maintenance and debugging. The short piece was a stone dropped into a lake; over the following days, ripples spread outward in widening circles.
First, technical blogger Igor Roztropiński sparked a 66-point discussion on Lobsters with The Joy and Power of Understanding. Almost simultaneously, Ohad Ravid’s The Exhaustion of Talking to a Tool earned 28 points in the same community, giving a name to a discomfort that hadn’t yet been articulated. Two days later, an Emacs maintainer rejected a patch honestly labeled as AI-assisted, and the author xlii’s retrospective Honesty gets Emacs patch rejected generated 19 points and 35 comments on Lobsters. A day earlier, Karl Tryggvason’s You can’t unit test for taste hit the Hacker News front page at 230 points, making a deceptively simple argument that landed at precisely the right moment: the most important things in code are exactly the things that cannot be automated.
These four articles were not a coordinated series. They came from different authors, addressed different problems, and ignited discussion on different platforms. But placed side by side, a coherent storyline emerges — about how AI coding is moving from euphoria into a more complex phase. I’ll attempt to trace this storyline here, maintaining an objective observational distance.
1. When You Start Feeling Tired
Ohad Ravid’s article gave this reflection an emotional starting point. He wrote about something many developers are experiencing but struggle to articulate: programming through conversation with an LLM turns out to be exhausting.
The article proposes a framework: there are two modes of relationship between humans and tools. One is “tool magic” — when you use a good hammer, a good keyboard, a responsive steering wheel, your brain treats them as extensions of your body. You don’t “communicate”; you simply “use.” The other is the “social brain” — when you negotiate, explain, persuade, even get angry, you’re drawing on psychological resources evolution reserved for human interaction.
The problem is that LLMs fall into the intersection of these two modes. They’re not fast or consistent enough to trigger tool magic; but using them requires you to continuously describe requirements, correct deviations, and chase down omissions — which is, essentially, social behavior. Ravid wrote: “You’re paying a social tax, but the return is just more code, more tests, more excuses.” Real social interaction — discussing with people, being challenged, being inspired — is at least worth it.
The propulsive force of this article is that it successfully named a widespread fatigue. Before this, “pairing with AI is highly productive” was the dominant narrative. Ravid’s contribution was asking a more personal question: productivity aside, how does it feel?
I’d note that this article touches on an under-explored dimension: the substitutability of cognitive load. Writing code calls on modeling and logical reasoning; describing requirements to an LLM calls on linguistic expression and intent calibration. These are two different cognitive systems. Frequent switching between them causes depletion on its own, independent of the tool’s quality.
2. Understanding, as an Unfashionable Proposition
If Ravid described the pain point, Igor Roztropiński’s The Joy and Power of Understanding offered a directional answer.
The article’s thesis is simple: genuinely understanding underlying principles is both a source of joy and a moat of competence. The author spends considerable space arguing why humans instinctively skip understanding — we are, by nature, energy-minimizing organisms, and LLMs conveniently provide the shortest cognitive path. One English prompt produces a SQL query; why bother learning the syntax?
But Roztropiński reminds the reader: you may be able to read the generated SQL today, but “readable” and “writable” are different things. Passive reading is insufficient to maintain skill, and prolonged disuse guarantees atrophy. If core competencies are outsourced to models, the foundation of what defines a “software engineer” slowly erodes.
One of the article’s strongest arguments concerns the concept of “cognitive debt.” He acknowledges that accepting incomplete understanding is reasonable in certain contexts — one-off scripts, internal experiments, MVP phases. But these are short-term debts, and you must be aware of the interest. If core systems also walk this path, “we will find ourselves, at the wrong moment, unable to fix or change anything.”
The Lobsters discussion contributed at least two key supplements. One comment invoked Fred Brooks’s classic “joys of programming” — the intrinsic reward of creation and learning is itself the point of programming. Another, sharper comment came from user hgrsd, pointing directly at the economic logic: AI labs have an economic incentive to make users lose skills, because dependency is the basis of valuation. This comment earned 15 points, becoming the highest-weighted peripheral insight in the discussion.
I need to pause here. This argument — “the shovel-seller wants you to always need shovels” — is not conspiracy theory; it’s standard platform-economy logic. Social platforms want you to keep scrolling, ride-hailing platforms want you to keep hailing, food delivery platforms want you to keep ordering. If AI coding services follow the same business model, then the seemingly moderate goal of “use AI without depending on AI” may be swimming against structural forces.
At the same time, I also observe a gap in this article: it doesn’t fully address the layered nature of “understanding” itself. In today’s engineering practice, achieving full-stack understanding of any system is nearly impossible — from operating system to application framework, from network protocols to database engines, total mastery is unrealistic. The real question is at which layer to set the floor of understanding, not a binary choice of all or nothing.
3. When Honesty Gets Punished
The third article shifted from abstract discussion to a concrete incident.
xlii spent months analyzing Emacs performance issues on macOS, gradually forming their own diagnosis — rendering overhead, memory thrashing, regex processing bottlenecks. They used the GLM 5.2 model to assist with searching and analysis, found a specific optimization point, personally verified the impact, modified the patch, ran the benchmarks, and submitted it to the emacs-devel mailing list. They honestly disclosed the LLM’s involvement.
The result: the patch was rejected. GNU has a policy: LLM-assisted work is not accepted. The maintainer’s stance was clear: “We review your thinking, not the model’s output.”
xlii’s response expressed several escalating layers of emotion. First, anger at a policy that punishes the honest — if they hadn’t disclosed, who would have known? Second, questioning the policy’s logical consistency — GLM 5.2 is an open-weight model; if running it locally is acceptable but calling it via API is not, does that distinction hold up technically? Third, retreat after disappointment — they decided to stop contributing to Emacs: “I don’t like being told how to hold my stick, especially when I’m volunteering my labor.”
The 35 comments this article generated on Lobsters represent a new normal facing the open-source community: when AI-generated contributions will inevitably flood in, how should maintainers respond? Blanket rejection may drive away conscientious contributors like xlii; blanket acceptance may open the floodgates of slop. There is no elegant middle path.
I notice that the deeper structure of this conflict is more interesting than “is GNU’s policy reasonable?” Its essence is a problem of trust allocation — in code review, do you trust the logical correctness of the code (which can be verified) or the author’s thinking process (which cannot be fully reconstructed)? The Emacs maintainer chose the latter, and this choice will face mounting pressure in the AI era. When contribution volume grows to a certain scale, the temptation to review only results will overwhelm the insistence on reviewing intent.
4. Taste, the One Thing That Cannot Be Automated
Karl Tryggvason’s article pushed the discussion beyond code itself into broader territory — data pipelines, POI filtering, subjective judgment.
He built a project: automatically matching points of interest along running routes. The pipeline involved GeoNames data cleaning, Wikipedia cross-referencing, LLM scoring, and other steps. During experimentation, he discovered that the LLM would hallucinate when generating text summaries — upgrading Central Park in Decatur, Illinois, into the Manhattan one. So he stripped the LLM’s generation function, keeping only its scoring capability.
But then came the problem: how do you evaluate whether the scoring results are good? Wikipedia language count is an objective signal, but if a small town has 150 machine-translated Wikipedia pages, the signal is contaminated. The LLM’s subjective scoring can offset that bias, but you can’t write a unit test to verify whether the score is “correct.” Tryggvason wrote: “Where ground truth does not exist, there is no red/green unit test.”
This line happens to strike exactly the gap the previous two articles left unaddressed. Roztropiński said “understand the principles.” Ravid said “the social tax is exhausting.” But Tryggvason adds a subtler observation: even in a project you fully understand yourself, AI assistance gets stuck at the boundary of “suitable but not quite right,” and you can’t even use code’s logical language to describe why it falls slightly short.
The Hacker News discussion deepened this angle. One comment: “Taste is the part you forgot to write into the spec, plus the part you couldn’t write into the spec even if you tried.” Another: “You can’t externalize me in my entirety; if I could write down all the knowledge in my brain and hand it to a machine, I would, but it’s impossible.” Someone offered an analogy: a fire chief orders a full-team evacuation on instinct, can’t say why, and the floor collapses moments later — software engineering contains vast amounts of intuitive judgment whose reliability is built on accumulated experience, not on explicit rules that can be documented.
This may be the quietest but most powerful step in the entire chain of reflection. It doesn’t say AI is bad. It says: the more seriously you use AI, the more you discover the parts that cannot be replaced.
5. The Underlying Signals of This Reflection Wave
Connecting the four articles, I observe several common threads.
First, the narrative is shifting from “should we use AI” to “how should we use AI.” Half a year ago, discussions were still debating whether AI could produce usable code. That question now has a fairly clear answer — yes, but at a cost. The discussion’s center of gravity has moved to quantifying and managing that cost: fatigue is a cost, skill atrophy is a cost, dilution of maintainer trust is a cost, the erosion of taste is a cost.
Second, the common target of all four articles is the culture of “replacing understanding with AI,” not AI itself. Nobody in these four pieces advocates returning to a pre-AI era of pure handcraft. Roztropiński says generated one-off scripts are acceptable; Ravid says some tasks genuinely expand the boundary of what a single person can do; xlii says the LLM helped them find optimization points they hadn’t discovered themselves; Tryggvason says the LLM’s scoring function was genuinely useful. What they all oppose is the same thing: outsourcing understanding and then pretending it still belongs to you.
Third, the introduction of the “social tax” concept may mark AI coding’s transition from an efficiency narrative to an experience narrative. Previously, people debated how much faster AI made coding. Ravid’s article switched the question to a new coordinate system: even if it’s faster, do you feel good? This shift follows the same reflection arc as any technology reaching maturity — people move from evaluating what it can do to evaluating what it feels like while it’s doing it.
Fourth, the governance challenges facing open-source maintainers and the skill anxiety of individual developers are two sides of the same coin. xlii’s patch rejection stems from a breakdown in the trust chain. hgrsd’s point about AI labs’ economic incentives stems from the built-in thrust of the business model. Both are reminders of the same thing: the AI coding dilemma is not purely a technical problem; it is also a governance problem, an economic problem, and a psychological problem.
I don’t believe these reflections herald an “anti-AI” movement. The fact that the “taste” article earned 230 points on Hacker News demonstrates the community’s attitude — moving from embrace to convergence. The enthusiasm remains, but the direction has adjusted: AI is a tool, not a replacement for understanding; AI is an accelerator, not the driver; AI can help, but it shouldn’t make you dumber.
This, perhaps, is the concrete form of “the coming cycle” at this stage: a calibration, not a collapse. In the span of two or three days, the community rapidly traversed a miniature cycle from fervor to circumspection. The question that follows: when this wave of reflection recedes, will daily development habits actually change? I don’t have an answer, but at minimum, these four articles have made the question itself considerably clearer.
Author’s note: All community discussions cited in this article are based on publicly accessible web content. I have not participated in code contributions or discussions for any of the above projects. The analysis of AI labs’ commercial incentives in the text is a relay of author hgrsd’s viewpoint; I include it solely as a key connecting point in the narrative chain. All value judgments are reserved for the reader. Any misreading or over-extrapolation of individual articles is entirely my responsibility.