Blog
LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building
The rise of large language models (LLMs) as everyday coding companions is not just changing how software gets written; it is reshaping what it even means to be a software engineer. Over the last year, many engineers have quietly crossed a threshold where writing code by hand is no longer the dominant activity. Instead, they increasingly describe, guide, review, and correct code produced by models. This shift is subtle but profound. It is also creating a growing divide in the profession—between engineers who primarily loved coding itself and those who primarily loved building things with code.
That split is not about skill level, seniority, or even intelligence. It is about motivation. For some engineers, the joy was always in the craft: typing, refactoring, wrestling with abstractions, and slowly shaping elegant solutions. For others, coding was a means to an end—the fastest path to shipping a product, validating an idea, or solving a real-world problem. As LLMs take over more of the mechanical and even conceptual aspects of programming, these two groups are reacting very differently.
That split is not about skill level, seniority, or even intelligence. It is about motivation. For some engineers, the joy was always in the craft: typing, refactoring, wrestling with abstractions, and slowly shaping elegant solutions. For others, coding was a means to an end—the fastest path to shipping a product, validating an idea, or solving a real-world problem.
The Historical Unity of Coding and Building 🔗
For most of software engineering’s history, coding and building were inseparable. If you wanted to build something—an application, a startup, a research prototype—you had to code it yourself or closely collaborate with someone who could. The constraints of the medium forced everyone into roughly the same workflow: design, implement, debug, iterate. Even engineers who were primarily product-minded still spent large portions of their day inside code editors.
This created a kind of cultural unity. The industry rewarded people who could both think abstractly and execute concretely. Mastery of syntax, frameworks, and tooling was not optional; it was the price of admission. Over time, many engineers internalized coding as an identity, not just a skill. Being good at software meant being good at writing code.
That unity began to erode slowly with higher-level frameworks, managed services, and low-code tools. But those abstractions still required a mental model of how code worked. LLMs are different. They operate at the level of intent expressed in natural language, not just APIs and libraries. This allows a single person to operate on a codebase in much larger “chunks” than before—a point emphasized by Andrej Karpathy in his recent reflections on coding primarily through agents rather than keystrokes (source).
When the cost of expressing intent drops this dramatically, the historical coupling between coding and building starts to break. And that is where the split begins.
LLM Coding as a Force Multiplier 🔗
LLM-based coding tools are not just faster autocompletes. They are force multipliers that change the scale at which an individual engineer can operate. Karpathy describes going from roughly 80% manual coding to 80% agent-driven coding in a matter of weeks, calling it the biggest workflow change of his career (link). That kind of shift fundamentally alters daily work.
Instead of thinking line by line, engineers think in terms of systems, features, and transformations. You describe what you want, review what the model produces, and intervene when it goes off the rails. The bottleneck moves from typing speed and recall to judgment, taste, and clarity of intent.
For builders, this is exhilarating. If your primary satisfaction came from seeing something exist in the world—an API deployed, a product launched, a workflow automated—then LLMs feel like removing friction from your true goal. You can get to “working software” faster, iterate more, and explore ideas that previously felt too expensive to try.
For coding purists, the experience can be disorienting. Much of the flow state they valued—incrementally shaping logic, feeling the texture of the solution emerge—is replaced by prompt refinement and review. As several engineers noted in a widely discussed Hacker News thread, this can lead to a sense of complacency or even creative atrophy if one simply accepts what the model produces (discussion).
The Engineer Who Loved Coding 🔗
Engineers who primarily loved coding often describe it as a craft. They enjoy the act itself: writing clean functions, finding the right abstraction, reducing complexity, and understanding systems deeply. Debugging is not just a chore but a puzzle. Performance tuning is an intellectual challenge. These engineers often take pride in knowing how things work all the way down.
LLM-driven workflows can feel like a loss of agency to this group. When a model generates hundreds of lines of code at once, the engineer’s role shifts from creator to editor. Even when the output is correct, it may not reflect the engineer’s personal style or values. Over time, constantly “correcting” a model rather than expressing oneself directly can erode motivation.
There is also a legitimate fear of skill decay. If you stop practicing the fine-grained mechanics of coding, will you lose them? Several commenters in the Hacker News discussion around Karpathy’s notes expressed concern that learning to use a specific model is a perishable meta-skill, while core reasoning and coding skills are more durable (source).
This does not mean coding-focused engineers are obsolete. On the contrary, as LLMs generate more code, the value of people who can deeply understand, audit, and reshape that code increases. But the emotional center of the job changes. Satisfaction may need to come less from writing code and more from ensuring correctness, maintainability, and elegance at a higher level.
The Engineer Who Loved Building 🔗
For engineers who primarily loved building, coding was always instrumental. They learned enough to express ideas and ship solutions, but their real motivation was impact. Did the product work? Did users adopt it? Did the system solve the problem it was meant to solve?
LLM coding tools feel tailor-made for this mindset. By offloading large portions of implementation detail to models, builders can focus on architecture, user experience, and iteration speed. The feedback loop tightens. Ideas move from conception to reality faster than ever.
This group is often more tolerant of “ugly” code as long as it works and can be improved later. With LLMs, that tolerance becomes an advantage. You can ask the model to refactor, simplify, or optimize once the concept is validated. The cost of change drops, encouraging experimentation.
Research on LLMs in commercial software engineering suggests that productivity gains are most pronounced when tools are used to accelerate end-to-end workflows rather than isolated coding tasks (study). That aligns closely with the builder mindset: optimize for outcomes, not for the act of writing code.
As a result, builders may find themselves thriving in an LLM-heavy environment, taking on broader scopes of responsibility and delivering results that previously required larger teams.
Why the Split Is Becoming More Visible Now 🔗
This divide did not appear overnight, but recent improvements in model capability have made it impossible to ignore. When LLMs were error-prone and limited, everyone still had to code extensively. Now, as models handle non-trivial refactors, generate entire features, and reason across files, the trade-offs become starker.
Karpathy notes that modern models no longer fail primarily through syntax errors but through subtle conceptual mistakes—exactly the kind that require experienced judgment to catch (link). This shifts value toward review and decision-making rather than raw implementation.
At the same time, awareness of these changes is uneven. Many engineers are already operating in a mostly agent-driven mode, while the broader industry discourse is still catching up. This lag amplifies the sense of dissonance for those who feel their relationship with coding changing faster than their professional identity can adapt.
The split is also reinforced by organizational incentives. Teams that reward shipping and metrics will naturally favor builder-oriented workflows. Teams that emphasize technical excellence, safety, or long-term maintainability may still prioritize deep coding expertise. LLMs do not eliminate either need, but they change their relative visibility.
Career Paths in a Post-LLM Coding World 🔗
As this divide widens, we should expect clearer differentiation in career paths. Coding-focused engineers may gravitate toward roles that emphasize correctness, performance, security, and infrastructure—areas where deep understanding and skepticism of generated code are critical.
Builder-focused engineers may increasingly resemble “software product engineers,” owning outcomes end to end. Their value will lie in framing problems well, guiding models effectively, and integrating systems into coherent products.
Neither path is inherently superior, but they reward different skills. Organizations that recognize this can design roles more intentionally instead of expecting every engineer to excel equally at everything.
LLMs do not remove the need for engineering judgment; they concentrate it.
This concentration may also reduce the number of engineers required for certain projects while increasing the impact—and pressure—on those who remain. Understanding which side of the split you naturally align with can help you navigate these changes proactively.
Education, Skill Decay, and the Fear of Atrophy 🔗
One of the most emotionally charged aspects of this shift is the fear of losing hard-earned skills. If you let models write most of your code, will you still be a “real” engineer? The concern is not unfounded. Skills that are not practiced tend to decay.
However, the historical record suggests that tools rarely eliminate skills outright; they change which skills matter most. We no longer hand-write assembly for most tasks, yet understanding low-level behavior remains valuable. Similarly, even if fewer engineers write large amounts of code manually, the ability to reason about code remains essential.
The risk is not using LLMs, but using them passively. Engineers who stay engaged—questioning assumptions, demanding simplifications, and occasionally writing critical sections by hand—are less likely to experience the “brain atrophy” described in community discussions (HN thread).
Education will need to adapt as well. Teaching future engineers only how to prompt models would be a mistake. Equally, ignoring LLMs would be unrealistic. The challenge is to teach foundational reasoning alongside effective collaboration with AI.
Reconciling Coding and Building Again 🔗
The split between loving coding and loving building is real, but it does not have to become a permanent schism. In the best cases, LLMs can allow engineers to fluidly move between levels of abstraction—diving into code when it matters, pulling back when it does not.
This requires intentional practice. Coding-focused engineers may need to redefine craftsmanship to include shaping model behavior and outputs. Builder-focused engineers may need to resist the temptation to treat generated code as disposable, investing time in understanding critical paths.
Ultimately, software engineering has always been about leveraging tools to extend human capability. LLMs are simply the most powerful such tool we have seen. They expose differences in motivation that were always there, but they also offer an opportunity: to let more people spend more time on the parts of the work they find meaningful.
The engineers who navigate this transition best will not be those who cling to or reject LLMs wholesale, but those who understand what they personally value—and adapt their workflows accordingly.
References 🔗
For more information, check out these verified resources: