Less than a year ago I published a video (don’t make many of those, not my favorite format) about the failures of AI, among which vibe coding was one of the greatest disappointments. I’m not a software developer; I write code as part of my scientific and statistical modeling work, so something that automates coding entirely would be a boon to me. Indeed, in less than a year these things became a lot more capable, allowing entire projects to be auto-coded. I also had the chance to do some serious contracting work where tech leads relied heavily on coding assistants, so I was compelled to match the tools for the Machine Learning Modeling, which I was responsible for – I didn’t really like the process: way too much code was generated to allow proper review, subjectively the code was not as solid (though that traded off with the coding tool handling dependencies and structure more efficiently than I would). But again, I’m a scientist and statistical modeler, not a developer, so I’m not in a position to judge code quality, software development best practices, mainatainability, etc, beyond the way they translate the mathematics faithfully to achieve their modeling purposes.
A couple of day ago a very nice article came out in the Financial Times: Who cleans up after the vibe-coding party? – not my favorite newspaper either, but since leaving the ivory tower my job now includes navigating less friendly or hostile territories, and occasionally putting on a hazmat suit (but credit to them for the nice images in the beggining of the post). It’s as much about code quality, as it is about understanding code contributions to open source software, maintaining the maintainability of code bases, and the social aspect of devloping software, with all the consequences it has for the software developer career of senior devs, junior devs, those being trained now or in the future. I really recommend its reading to anyone interested in a broad pespective of this ecosystem and the impact of LLM coding assistants, because I wont’ delve into the main point of the article – the development & maintenance of open source, the involvement of contributors in these projects, including the seasoning of junior and senior devs in the environment – instead I’ll focus on something that is hinted at, and is an argument that has been thrown around time and again: “AI is a new abstraction layer in the development of software”.
As I said, I cannot comment on the details of machine and assembly languages (in which I never coded) versus lower level langs like C and Fortran (which I used for a while), or much higher level ones like Julia or Python (which I’m comfortable with), but I generally disagree that LLM-assisted coding is an equivalent layer of abstraction. Intead of formal abstraction layers, I’m going to use software libraries and scientific findings as analogies. On that level the arguments goes like this: “using AI is just like using a Python library, you know what it’s supposed to do, but don’t necessarily understand how it does it”. And no, it’s not like that. When I use a library, I know there are people who understand how it’s done that have taken the time to thoroughly write that piece of software – it’s true that it’s impossible to fully know and understand the implementation of every single library you use, but there is a system of trust underlying them. That’s also the reason I use libraries like numpy and Stan instead of a random numerical or MCMC project, or code it myself from scratch, which in these cases I could aboslutely do for the methods I use, but would absolutey rather not spend the time needed to do it properly. Using an LLM assistant for doing that breaks the entire chain of trust – I cannot verify that what it did is correct unless I review the entire code, but nobody’s responsible for it like they are for numpy. Otherwise I need to trust that a model that outputs averages and standard deviates by construction did everything well within the boundaries of aboslute correctness. What about copying things from Stack Overflow (R.I.P.) without understanding it. That carries some of the same risks, maybe you’re relying on the expertise of a single person that could be wrong or not know enough to write robust code, but then we get into something a friend of mine calls a “shit sommelier”: would you prefer a more fragant crap or a full-bodied piece of shit with your meal today?
Of course if you want a solution that doesn’t exist, either you code it yourself or ask an LLM to do it, and that may work fine for prtotypes, low-stakes apps, etc, but the trust issue is the same. What about higher stakes, what about scientific programming? That’s what I do, and the main issue there is there’s no “good enough”, either your code specifies the exact math intended or it doesn’t: it’s \(F = ma\), not \(F = m^{11/10} a\). So when I saw one of the lead developers of a popular statistical (of all kinds) package (which I no longer use, but did a lot for my Ph.D. work) saying he only understood 10-20% of the code, that caught my attention – it didn’t alarm me immediately – because I thought there could be a good reason for it (a decentralized team, delegating tasks, incorporating validated libraries). Unfortunately there wasn’t, and worse, they were not even talking about the code, they were talking about the science underlying the implememtation,and boasting that the agents could read and implement faster than they could. Like the FT’s example of open source code, my opinion is that this spells disaster: there are already enough issues of reproducibility with the best and most robust software. In science too, you do not need to understand every single detail of the science you are relying on, but you do need a system where the robustness of the results are challenged, and even if they fail, somebody is accountable (scientific publishing has many, many, many problems, but they’re no justification for abandoning the standards and accountability of science and scientists).
So, all of that is also assuming that the specific choices from vibe building match one to one the scientific intentions of the vibe coder (which is physically impossible, since even direrct choices are sometimes ambiguous). Even if that were true, there’s no intrinsic validation and zero accountability to a system that generates output based on statistical distributions. If we cannot, at a bare minimum, rely on software doing what it’s supposed to, I’m pretty sure we’re not going to be safe flying in in vibe coded/built/tested aircraft, taking vibe-designed drugs prescribed by vibe diagnosing doctors, or vibe solving a climate crisis.
P.S. I sidestepped the issue of bugs, because a bug is an unintended consequence of an intentional implementation, but one the author is still accountable for. Vibe coding produces no bugs, because there’s no intention – comparing the human versus machine error rate is a separate discussion altogether
-- caetano,
July 13, 2026