How to Become a Stronger Engineer in the AI Era: Neither Surrendering Nor Rejecting

A Recurring Anxiety

As AI programming tools sweep through the developer community, a question on Reddit struck a chord with many: "How to become a better engineer without submitting to AI gods?" Behind this slightly tongue-in-cheek title lies a genuine career anxiety shared by many developers—when tools like Copilot, Cursor, and ChatGPT can generate code with a single click, what skills do we actually still need to hone?

GitHub Copilot was first publicly previewed in 2021, built on OpenAI's Codex model, marking the transition of AI-assisted programming from academic experiment to industrial practice. Subsequently, Cursor (an AI-native IDE based on GPT-4), Amazon CodeWhisperer, Google Gemini Code Assist, and other tools emerged in succession, forming a complete AI-assisted development ecosystem. According to data published by GitHub in 2024, developers using Copilot completed tasks 55% faster on average, with a code acceptance rate of approximately 30%—meaning AI has profoundly changed the daily development workflow.

This isn't unfounded worry. More and more junior engineers have grown accustomed to "Prompt-Driven Development," where their first instinct when encountering a problem is to ask AI rather than think independently. The risk of this workflow is that it skips the crucial "problem decomposition" phase of software engineering—developers no longer need to break complex problems into manageable sub-problems, no longer need to actively consider the details of data flow, state management, and error handling. Cognitive science research shows that active problem-solving is the key mechanism for forming long-term memory and deep understanding, while passively receiving answers makes it difficult to build lasting cognitive structures. Over time, an engineer's most essential abilities—abstract thinking, system design, and debugging—may gradually atrophy. This article draws on community discussions to explore how to truly improve engineering capabilities in the AI-assisted era.

AI Is Leverage, Not a Replacement

Use AI to Amplify Ability, Not to Mask Weaknesses

A core consensus in the discussion is that AI should be treated as leverage, not a crutch. This analogy comes from the concept of "leverage" in investing—in finance, leverage amplifies both gains and losses. If your investment judgment is correct, leverage delivers outsized returns; if it's wrong, leverage accelerates losses. AI tools work exactly the same way for engineers: for someone with a solid foundation, AI can dramatically boost output—auto-generating boilerplate code, quickly looking up APIs, assisting with refactoring, accomplishing in hours what used to take days. But for developers with weak fundamentals, over-reliance on AI can rapidly produce large quantities of seemingly working but fragile code, masking the knowledge gaps that truly need to be filled.

In other words, AI's value depends on the user's level. Given the same AI-generated code, a senior engineer can spot performance pitfalls and edge cases at a glance, while a novice might copy-paste it directly, burying technical debt. Technical Debt is a metaphor coined by Ward Cunningham in 1992, comparing suboptimal technical decisions made for short-term convenience to financial debt—just as financial debt accrues interest, technical debt causes development velocity to continuously decrease and maintenance costs to steadily rise. In the context of AI-generated code, if developers adopt it without review, they can easily introduce hidden technical debt such as lack of test coverage, excessive coupling, and hardcoded configurations. Therefore, the key to improvement isn't "whether or not to use AI," but "whether you have the ability to evaluate AI's output."

Maintain the Muscle Memory of Building from Scratch

Many seasoned developers recommend: periodically force yourself to complete tasks without AI assistance. For example, hand-write a data structure, build a small project from scratch, or independently debug a complex bug. This kind of "deliberate practice" maintains and strengthens foundational abilities, just like how athletes still need to maintain basic fitness training even with advanced equipment available.

The Core Skills That Truly Set You Apart

System Design and Architectural Thinking

AI excels at generating localized code, but remains highly dependent on human judgment for overall system design. How to balance consistency with availability, how to design scalable service boundaries, how to make tradeoffs between cost and performance—these decisions require experience, context, and deep business understanding, making them high-value areas that AI cannot replace in the near term.

Take "balancing consistency and availability" as an example. This involves the famous CAP theorem in distributed systems (proposed by Eric Brewer in 2000): in a distributed system, Consistency, Availability, and Partition Tolerance—at most two of these three properties can be satisfied simultaneously. This means engineers must make tradeoffs when designing distributed architectures—whether to prioritize data consistency like banking systems (CP systems, such as ZooKeeper), or prioritize service availability like social media platforms (AP systems, such as Cassandra). Such tradeoff decisions require deep understanding of business scenarios, user expectations, and failure impacts. This is purely a matter of engineering judgment that AI currently cannot replace.

Therefore, rather than spending time memorizing syntax, it's better to deeply study "slow-variable" knowledge like distributed systems, database internals, and concurrency models. The concept of "slow variables" is borrowed from systems dynamics, referring to foundational elements in a system that change slowly but have far-reaching impact. In software engineering, how the TCP/IP protocol stack works, the performance characteristics of B+ tree indexes, how CPU cache hierarchies affect program performance, the tradeoffs in process scheduling algorithms—these concepts haven't fundamentally changed since the 1970s. In contrast, frontend frameworks have gone from jQuery to Angular to React to Svelte, experiencing paradigm shifts every 3-5 years on average. Engineers who invest in slow-variable knowledge can quickly understand and adapt to any new framework because they understand underlying principles rather than surface-level APIs. These foundational principles won't become obsolete within a decade, while specific framework APIs might be deprecated every two years.

Debugging and Problem Localization

Debugging is one of an engineer's core skills and one of the hardest areas for AI to replace. Bugs in real production environments often involve complex context, timing issues, and environmental differences that cannot be resolved by simply "copying the error message to AI."

Production bugs often exhibit a "Heisenberg effect"—their behavior changes when you try to observe them. Typical scenarios include: Race Conditions that only trigger under specific concurrent loads, memory leaks that take hours of runtime to manifest, and data inconsistencies caused by network partitions in distributed systems that only appear under specific failure combinations. Debugging these issues requires engineers to understand temporal relationships, construct minimal reproduction scenarios, skillfully use toolchains like profilers, tracers, and debuggers, and make reasonable inferences with incomplete information. AI can help explain individual error messages, but cannot replace the systematic thinking needed to locate root causes in complex systems. The ability to form hypotheses, narrow the investigation scope, and read logs and stack traces is a key differentiator between senior and junior engineers.

Reading and Understanding Others' Code

As AI-generated code becomes increasingly prevalent, the importance of Code Review is actually rising. Engineers need to be able to quickly understand the intent of unfamiliar code, identify potential risks, and judge whether it conforms to team conventions. This ability cannot be developed by delegating to AI—it can only be accumulated through extensive reading of high-quality open-source projects.

In an era where AI-generated code is increasingly common, Code Review also needs to address new dimensions: Does the AI-generated code introduce anti-patterns from training data? Are there license compliance risks (because AI models may have "memorized" code snippets under strongly copyleft licenses like GPL during training)? Is the generated implementation over-engineered or oversimplified? Google's research shows that approximately 25% of its internal new code was generated by AI in 2024, making human review the last line of defense for quality assurance. Developing solid code reading and review skills isn't becoming optional in the AI era—it's becoming more critical than ever.

An Actionable Growth Path for Engineers

Build a Strong Computer Science Foundation

Regardless of how tools evolve, foundational subjects like operating systems, networking, data structures and algorithms, and compiler theory remain the bedrock of engineering capability. This knowledge lets you understand "what's actually happening on the machine when code runs," giving you confidence in performance optimization and troubleshooting. For example, understanding virtual memory mechanisms helps you diagnose OOM (Out of Memory) issues; understanding TCP's congestion control algorithms helps you optimize service performance under high-latency networks; understanding compiler optimization strategies lets you write more hardware-friendly code. This foundational knowledge constitutes an engineer's "meta-capabilities"—regardless of what language or framework you use, they're always at work underneath.

Deeply Engage in Real Projects

The most effective growth comes from solving real, challenging problems. Contributing to open-source projects, independently developing a complete product, or proactively taking on complex modules at work all provide hands-on experience that AI tutorials cannot offer. The key is owning something end-to-end, experiencing the complete cycle from design, implementation, deployment, to maintenance. Only after being woken up at 3 AM by alerts to troubleshoot a production incident will you truly understand why observability and fault tolerance need to be considered at the design stage.

Establish a "Think First, Then Ask AI" Work Habit

A practical principle is: when encountering a problem, first try to come up with your own solution or at least form a clear line of thinking, then use AI to validate, supplement, or accelerate. This way you enjoy the efficiency dividend while maintaining independent thinking ability. Treat AI as a senior colleague you can discuss with anytime, rather than a boss making decisions for you. In practice, try the "5-minute rule": spend at least 5 minutes thinking independently when you encounter a problem, sketch out a rough approach or list possible solutions, then seek feedback from AI. This way, even if you ultimately adopt AI's suggestion, you've gone through the active thinking process and deepened your understanding of the problem.

Conclusion: Neither Surrendering Nor Rejecting

Facing the AI wave, engineers need not "surrender to the AI gods," nor is there any need to blindly reject it. True wisdom lies in finding balance: using AI to handle repetitive work and free up creativity, while safeguarding the core capabilities that truly define an engineer's value—systems thinking, deep debugging, architectural judgment, and continuous learning.

Technology will keep changing, but the ability to "understand deeply, think independently, and solve real problems" will always be scarce. In an era where everyone can write code with AI, engineers who can harness AI rather than be harnessed by it will be the ultimate winners.