Op-Ed: Engineering in the Era of Vibe Coding

Part of a new op-ed series featuring IEOR student voices, this piece is a collaboration between Alberto Gennaro (5th Year PhD), Grace He (3rd Year PhD), Ricky Huang (3rd Year PhD), and Jessica Zhao (1st Year PhD).

“Vibe coding,” the process of relying on generative AI tools for code-writing, has become the buzz phrase related to many engineering disciplines since it was coined by AI researcher Andrej Karpathy in early 2025, occupying the thoughts of everyone from software engineers to journalists at the Wall Street Journal and even the U.S. government. This is not without reason – with the sophistication of code-targeted large language models (LLMs) such as Anthropic’s Claude and OpenAI’s Codex, it has never been easier to translate written English into working code for various applications and across domains, seemingly with or without programming experience. Specific to IEOR, LLMs are more than capable of formulating and analyzing optimization problems in most modeling languages, such as AMPL’s Amplbot.

While the rise of vibe coding has generated considerable excitement, it has also raised broader questions about the role of engineers in a rapidly evolving AI landscape. Headlines such as “Vibe Coding is Coming for Engineering Jobs” and “Goodbye, $165,000 Tech Jobs. Student Coders Seek Work at Chipotle” have become common enough to create the impression that advances in large language models for code generation are directly threatening the livelihoods of engineers whose work depends on programming expertise. This perception is not entirely unfounded: AI coding tools have clearly improved programmer productivity in certain settings. In a 2023 controlled experiment conducted by researchers at Microsoft and GitHub (https://arxiv.org/abs/2302.06590), programmers using AI copilots completed their tasks 55.8% faster than those working without AI assistance. Results such as these help explain why many observers see LLMs as a transformative force in software development.

Yet greater speed in narrowly defined coding tasks should not be confused with the ability to independently perform the work of an engineer. The same study that highlights productivity gains also presumes the continued presence of human direction, judgment, and oversight. In other words, AI tools may accelerate parts of the workflow, but they do not eliminate the need for someone to define the problem, evaluate tradeoffs, and ensure that the resulting system actually works in practice. This limitation becomes even clearer when LLMs are tested in settings that more closely resemble real software engineering. For example, an ICLR paper published in 2024 (https://arxiv.org/abs/2310.06770) found that one of the strongest available models could solve only 1.96% of coding requests drawn from real GitHub issues. That result suggests a crucial distinction: models may be useful assistants for bounded tasks, but they remain far less capable when confronted with the ambiguity, persistence, and contextual complexity of real-world engineering work.

That distinction matters because most engineers who work with code do far more than simply write it. In practice, they are not limited to solving the kind of self-contained exercises that appear in online programming platforms or college coursework. Rather, engineering work typically involves long-horizon, context-rich challenges that unfold across teams, systems, and time. Engineers must interpret imperfect requirements, work around legacy infrastructure, balance scalability with cost, manage security and privacy constraints, and make design choices whose consequences may not become clear until much later. A 2025 benchmark study on LLM performance in software engineering tasks (https://arxiv.org/abs/2509.16941) underscores exactly this point, emphasizing that real-world engineering involves forms of reasoning and coordination that AI systems still struggle to handle reliably. Seen in this light, code itself is only one part of the job; the deeper task is problem-solving under messy, evolving, and highly variable conditions.

This is also why the ability of LLMs to generate code does not represent as sharp a break from past engineering practice as some commentary suggests. Engineers have never worked in isolation, nor have they relied exclusively on what they can produce from memory. For decades, programming has been embedded in a rich ecosystem of external support: open-source communities, well-maintained documentation, version control systems such as Git, and query platforms like Stack Overflow have long provided an enormous repository of reusable code, technical knowledge, and troubleshooting strategies. In that sense, software engineering has already been a practice of searching, adapting, integrating, and verifying rather than simply writing code by hand from scratch. LLMs fit naturally into this existing pattern. They may make the search process faster, reduce friction in drafting boilerplate code, or help surface possible approaches more efficiently, but they do not alter the underlying nature of the work. The engineer is still the one who must decide what problem is worth solving, which solution is appropriate, and whether the generated code can be trusted in production.

For that reason, the claim that state-of-the-art LLMs can replace engineers as problem-solvers remains overstated. The central challenges of engineering do not disappear simply because a model can produce syntactically plausible code. If anything, some of these challenges become more pronounced. Legacy systems still need to be understood rather than merely interfaced with. Scalability still requires architectural judgment rather than local code completion. Data privacy and security concerns remain especially acute, and in some cases are complicated further by the proprietary nature of the models themselves and the uncertainty surrounding how sensitive information is processed. Moreover, modern LLMs are imperfect tools: they can generate faulty, brittle, or difficult-to-interpret code, whether because of hallucinations, outdated assumptions about software packages, or failure to grasp the broader system in which the code will run. As a result, they often shift rather than remove labor needs, creating new demands for verification, debugging, and careful review.

Taken together, these developments suggest that AI is changing software engineering, but not in the simplistic way suggested by alarmist headlines. LLMs are powerful aids, particularly for speeding up certain parts of programming, but speed alone is not the same as understanding, and code generation is not the same as engineering judgment. The real contribution of engineers lies not merely in producing code, but in solving difficult problems within complex technical, organizational, and social constraints. So long as those broader demands remain central to software development, LLMs are better understood as tools that augment engineers than as systems that replace them.