When AI Writes Everything: The Fundamental Skills Crisis Facing New Graduates and How to Break Through

From "Writing Code Yourself" to "Letting AI Write Code"

A recently graduated engineer posted on Reddit describing what he saw when he returned to his alma mater: the school is aggressively pushing AI-assisted teaching, and students are being taught how to use prompts to get AI to design, implement, and debug code—from PLC, HMI, SCADA to embedded, IoT, and ROS2, covering almost the entire mainstream industrial automation tech stack. In his words, "most students barely know how code works, and their fundamentals are almost zero."

The poster is not opposed to technological trends. He acknowledges that following the tide is a good thing, but insists that "the fundamentals still cannot be skipped." He mentions a troubling detail: over 60% of his classmates don't know what an array is, can't write Python, and can't write C++ code. Math skills are equally concerning—when asked "if you have an acceleration equation, how do you find velocity" or "what is the integral of acceleration," everyone drew a blank.

The PLC, HMI, SCADA, and ROS2 mentioned in the post are key technology stacks in industrial automation and robotics. Understanding their positioning helps grasp the system complexity involved in "AI writing code."

• PLC (Programmable Logic Controller): The most basic controller on the industrial floor, executing deterministic logic via ladder diagrams or structured text, directly driving sensors and actuators, with extremely high requirements for real-time performance and reliability.
• HMI (Human-Machine Interface): The interface layer for operator-equipment interaction, responsible for status display and parameter delivery, usually linked with PLCs.
• SCADA (Supervisory Control and Data Acquisition): Oriented toward broader monitoring and data acquisition, emphasizing communication protocols, historical data, and alarm management.
• ROS2: The second generation of the Robot Operating System, providing distributed communication, node orchestration, and real-time support—the mainstream framework for complex robotic systems.

What these systems share is that code must not only "run" but also be predictable in timing, memory, and exception handling. If AI-generated snippets lack understanding of these constraints, problems often only surface during integration.

Beneath the Surface: The Skills Gap Masked by AI

What makes this post resonate is that it touches on a growing concern. AI programming tools have indeed lowered the barrier to code output, but the code produced needs to be understood, maintained, and debugged. When students get used to "copy-pasting AI's answers without even checking them," what they lose is not just keyboard proficiency but the ability to reason about system behavior.

The "at a loss" scenarios described by the poster essentially expose a lack of mathematical intuition and physical modeling ability. Integrating acceleration to get velocity is one of the most basic concepts in engineering computation, but behind it lies an understanding of calculus and kinematic relationships. If students can't even cross this step, they will be helpless when facing more complex control systems or embedded real-time constraints.

Even more alarming is the state of "not knowing what you don't know." AI-generated code often looks reasonable, and runtime results may appear correct on the surface, leading beginners to mistakenly believe they have mastered the knowledge. Only when the system exhibits unexpected behavior and root causes need to be located does the skills gap truly reveal itself.

"Integrating acceleration to get velocity" is repeatedly mentioned because it encapsulates the correspondence among "model—mathematics—implementation" in engineering thinking. Acceleration is the derivative of velocity with respect to time; conversely, velocity is the integral of acceleration with respect to time. In discrete systems, this corresponds to numerical integration (such as Euler or trapezoidal methods), requiring handling of sampling periods, accumulated errors, and initial values.

If students only memorize formulas without physical intuition, they cannot judge whether an AI-provided integration implementation is reasonable: too low a sampling rate introduces bias, and integration drift causes velocity estimates to diverge. Similarly, arrays and memory layout relate to out-of-bounds, cache locality, and real-time performance, while the difference between Python and C++ involves trade-offs between interpreted vs. compiled execution and dynamic vs. static typing. These concepts are not "outdated fundamentals" but the coordinate system for understanding system behavior—without them, AI-generated code is just a black box that cannot be scrutinized.

A Senior Engineer's Perspective: Why Fundamentals Are Irreplaceable

The poster seeks advice from experienced working engineers, which itself is a pragmatic attitude. From the perspective of engineering practice, the value of foundational knowledge is not "hand-writing every line of code" but providing judgment.

An engineer who understands arrays and memory layout can judge whether AI-generated code has out-of-bounds risks; an engineer who understands the relationship between integration and differentiation can identify logical errors in control algorithms; an engineer who has studied operating systems and real-time system principles can evaluate whether an AI-proposed scheduling scheme is feasible. These judgments cannot be quickly acquired through prompt engineering—they come from repeatedly chewing on underlying principles.

AI is an amplifier, not a replacement. It amplifies your abilities, and it also amplifies your ignorance. When fundamentals are solid, AI helps you quickly implement ideas; when fundamentals are weak, AI helps you quickly cover up mistakes—until they explode on the production line.

How to Guide: Practical Advice for Those Who Come After

Regarding the question of "how to guide them in the right direction," we can approach it from several levels.

Treat AI as an object to be questioned, not a source of answers. Require students not only to submit code but also to explain why the code is written that way, what happens if the input is abnormal, and where the boundary conditions are. After AI generates code, deliberately modify a parameter or input, observe the behavioral change, and explain why.

Restore "no-AI" foundational training. Not a blanket ban, but setting up "no-AI checkpoints" at key junctures—such as data structures and algorithms, mathematical derivation, and low-level interface debugging. The poster mentions that when he was studying, AI wasn't good enough, so he had to write code himself—and that experience precisely shaped his fundamentals.

Use projects to force understanding. Have AI complete an entire module, then require students to perform code review, performance analysis, and fault injection testing. When the system is deliberately broken, whether they can locate the problem is an effective way to test depth of understanding.

Face squarely the foundational role of mathematics and physics. Integration, differentiation, and linear algebra don't become unimportant because of AI; rather, because AI can quickly produce results, humans need even more to judge whether the results are reasonable. A training model of "AI gives the answer, you are responsible for verifying it" can be introduced.

"Fault injection testing" is a verification method that actively breaks the system: artificially introducing errors into a normally running program (such as tampering with inputs, simulating communication interruptions, injecting delays or memory overflows) and observing whether the system can detect, isolate, or recover. In teaching, it exposes depth of understanding better than "making the code run"—students must know how the system is supposed to behave in order to judge whether a fault is handled correctly.

The accompanying "code review" requires students to explain line by line the intent, boundary conditions, and potential risks of AI-generated code, which in effect makes implicit understanding explicit. Combined, the two can transform AI from an "answer generator" into "an object to be reviewed," forcing students to invoke foundational knowledge to make judgments rather than passively accepting output.

Conclusion: The Trend Is Irreversible, but Choices Remain

The original poster finally says that he himself also just graduated, only that AI wasn't as good back then. His confusion represents a generational turning point: technological tools are accelerating in evolution, while human cognitive growth still takes time. It is inevitable for university education to embrace AI, but how to design courses so that AI becomes a "scaffold" rather than a "stand-in" is a more important issue than teaching students to write prompts.

For every learner, the question ultimately comes back to oneself: are you using AI to learn, or are you using AI to avoid learning? The difference will show up in your first real project after graduation.