Don't Outsource Your Thinking to AI: An Engineer's Warning

AI coding tools are spreading far faster than people's understanding can keep up. From students to senior engineers, almost everyone is using LLMs to write code, look up documentation, and build prototypes. But a software engineer's rant on Reddit points out a neglected problem: most people have no idea where the boundaries of AI use lie. His two rules—don't use AI to think for you, and students shouldn't use AI to build projects directly—are worth reading for anyone who treats AI as a master key.

Outsourcing Thinking to Machines Is the Biggest Risk

The author cites an oft-repeated ratio in software engineering: in real software development, typing code accounts for only 5% to 10% of the work. The rest is requirements decomposition, architecture design, edge-case reasoning, performance estimation, and failure planning. AI can accelerate that 5%, but it cannot replace the judgment involved in the other 95%.

He offers an extreme but realistic scenario: someone with no systems knowledge spends an evening furiously prompting AI and builds a website. The features work, and the client is satisfied. But because no one considered concurrency or infrastructure along the way, the service collapses as soon as real traffic hits after launch, costing the client a million dollars. At that point, should the client blame AI or the person who rented out their brain? The answer is self-evident.

The author doesn't deny that AI lowers the barrier to going from zero to demo. But he emphasizes: a demo is just a demo. Even for a small-scale application, you still need to understand the technical details to make correct decisions when facing real user requests. And an LLM's memory is limited—it knows nothing beyond its context window, and it won't proactively remind you that "you forgot to consider scaling."

Rule one: Don't use AI to think.

Context Window is a key concept for understanding the boundaries of LLM capabilities. It refers to the upper limit on the total number of tokens a model can "see" and process in a single inference, including your input prompt, the conversation history, and the model's generated response. Mainstream models' context windows have grown from a few thousand tokens in the early days to hundreds of thousands or even millions today, but no matter how large, it remains a finite and closed scope. The model can only infer based on information within the window; it cannot perceive system states, business context, or future changes outside it. So it won't proactively warn you that "your database connection pool might not be enough," nor will it remember the deployment environment you mentioned last week. Understanding this limitation makes it clear why the author insists that architecture decisions can't be handed to AI—it can't see the whole picture, only the fragments you feed it.

Students' Dilemma: Building Projects with AI Means Learning Nothing

The author, as a practitioner, has met quite a few students, and a recent experience left him speechless. A senior student entered a hackathon with a project billed as a crawler tool "with LLM support." The author asked to see the code and found that the so-called LLM support was just a placeholder implementation returning static JSON. When pressed, the student's answer was: "I don't know, I generated it with an AI tool." He hadn't even opened the generated content to look at it.

The problem this case exposes isn't that the student was "lazy," but that AI tools are creating an illusion of competence. The student thought he had delivered a project, when in fact he had delivered code he didn't understand at all. The author draws a clear distinction between professionals and students: professionals use AI to speed up because they already have the ability to judge the quality of the output and are accountable for the results; students who use AI to skip the learning process are essentially buying a diploma that will inevitably be exposed someday.

Rule two: Students should not use AI to build things directly. You can use it to support learning, but blogs and books remain more reliable paths.

Illusion of Competence is a classic phenomenon in cognitive psychology: when people are repeatedly exposed to certain information or see fluent output, they overestimate their mastery of the field. Students who generate code with AI and get it running develop the false impression that "I built this project," when in fact no real knowledge construction has taken place. The counterpart to the illusion of competence is the Generation Effect—knowledge acquired through hands-on derivation, trial and error, and debugging is remembered and understood far more deeply than through passive reading or copying. AI conveniently skips this generative process, turning "learning by doing" into "learning by watching." This is also why the author insists that blogs and books are more reliable: they force readers to reconstruct the logical chain in their own minds rather than simply receiving a black-box result.

Attention Is Shrinking, Thinking Ability Is Degrading

The article ends with a broader concern. The author cites research data claiming that Gen Z's IQ has dropped by more than 10% compared with the previous generation, while attention spans are shortening and people find it increasingly hard to sit still and finish an article or a lecture. He reserves judgment on IQ as a metric itself, but believes the critical thinking it correlates with is indeed being lost.

This judgment closes the loop with the AI usage problem: when you get used to throwing problems straight at AI for answers, you skip the cognitive process of "confusion—reasoning—verification," and the muscle memory generated in that process is precisely the prerequisite for solving the next, harder problem. The author calls for "saving the thinking ability that has kept humanity alive for hundreds of years"—the wording is blunt, but the direction is right.

It's worth noting where the IQ decline data the author mentions comes from. Widely cited in recent years is research based on PISA data from institutions such as Northwestern University, showing a downward trend in adolescents' cognitive indicators such as attention and working memory. But academia is still divided over whether the "reverse Flynn effect" holds, and IQ as a single metric can hardly reflect critical thinking comprehensively. Still, Cognitive Offloading is a more solid concept: humans are naturally inclined to hand memory and computation tasks to external tools, from pen and paper to calculators to search engines. What's different about AI is that it offloads the reasoning process itself—and the reasoning process is precisely the training ground for forming judgment. Long-term reliance on external reasoning may lead to a "use it or lose it" weakening of cognitive ability—consistent with the article's core concern.

Practical Advice: Where Are the Boundaries of AI Use?

Drawing together the article's points, several actionable principles emerge:

Think for yourself first, then use AI to verify. When you hit a problem, first write down your hypotheses and solution, then compare them with AI's output. If the two disagree, that point of difference is what you should learn from.

Let the student stage return to "slow learning." Writing code slowly, looking up documentation slowly, debugging slowly—this "inefficiency" is precisely the necessary cost of building technical intuition. If you can't understand AI-generated code, you're better off not submitting it.

Maintain architecture-level vigilance toward AI output. It can give you a demo that runs, but it doesn't know your user scale, deployment environment, or the cost of failure. Those judgments must come from you.

Clarify accountability. If you're not responsible for the output, you can use AI however you like; if you are responsible for the results, then AI is just one link in the toolchain, not the decision-maker.

The article's tone is a bit sharp, and its wording carries obvious personal emotion, but the core contradiction it raises—the mismatch between tool capability and user judgment—is one of the most real risks in the current wave of AI adoption. The more powerful the tool, the more you need to know when not to use it.

One-line Summary

With AI coding going mainstream, the biggest risk isn't that the tools are too powerful, but that users' judgment can't keep up.

Paragraph Summary

A software engineer's rant on Reddit raises the question of the boundaries of AI coding tools. The author proposes two rules: don't use AI to think for you, and students shouldn't use AI to build projects directly. The core argument is that coding accounts for only 5% to 10% of software development work; architecture design, concurrency reasoning, and failure planning still require human judgment. A website built by someone with no systems knowledge using AI collapses under real traffic, and the loss falls on the developer, not AI. Students who generate code with AI without understanding it create an illusion of competence and fake project experience. The article also cites research on declining cognitive indicators among Gen Z, pointing out that skipping the "confusion—reasoning—verification" process weakens critical thinking, and offers practical principles: think first, then use AI to verify; students should return to slow learning; maintain architecture-level vigilance; and clarify accountability.