# Faulty Towers, vibe sickness, and the vibe bobsled > Source: > Published: 2026-07-17 19:53:06+00:00 [Faulty Towers, vibe sickness, and the vibe bobsled](#f) I know. As if what the world needed was *yet another* blogpost about LLMs and AI tech. Yet there is a pile of things which have been on my mind, and I haven't seen them laid out elsewhere in the way I'm going to write them, and so here we go. I still don't use genAI to write my articles, fwiw. Here or anywhere else. These rambly words are my own. # The tower tilts I read [The Tower Keeps Rising](https://lucumr.pocoo.org/2026/7/13/the-tower-keeps-rising/) recently, and it has stuck in my mind. The piece is an observation, and [according to Armin on lobste.rs](https://lobste.rs/s/latr8d/tower_keeps_rising#c_erjpmu), it is not an advocacy for the state of affairs (though by running a vibecoding company, Armin is part of advancing this direction): For context: I'm the author. I intentionally did not make a judgement if this is a good or bad thing, or if this is going to continue working. It's primarily an observation that with agents you can continue to make progress even when people on the team maneuvered themselves into situations where previously they would have needed to talk to each other. The summary of Armin's post is effectively that vibecoded systems keep piling code on top of code, but in many systems things seem to keep building, but the abstractions keep piling on, but eventually no human can understand the codebase. But this is a new way of operating, because LLMs can "explain" a part of the codebase that no human can make sense of, and so continue building. Even if such systems continue to work, I find two things: 1) that now advocates for this state of affairs have pivoted into acknowledging that this is the end state of their systems and 2) they seem to be accepting it as the way forward. Regarding the first, I think it's very important to note that this is *a shift*. [Simon Willison](https://simonwillison.net/), probably the best pro-genAI writer on the internet (sometimes, I think, giving cover for a lot of weaker writers, but is that Simon's fault?), at one point coined the term ["agentic engineering"](https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/) and was very clear to [draw a line in the sand between agentic engineering and vibecoding](https://simonwillison.net/2025/Mar/19/vibe-coding/): We also need to read the code. My golden rule for production-quality AI-assisted programming is that I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else. If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development. The usage of an LLM to support that activity is immaterial. In an *incredibly short* period of time, basically a year, Simon changed published a fairly honest article titled [Vibe coding and agentic engineering are getting closer than I’d like](https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/): The problem is that as the coding agents get more reliable, I’m not reviewing every line of code that they write anymore, even for my production level stuff. I know full well that if you ask Claude Code to build a JSON API endpoint that runs a SQL query and outputs the results as JSON, it’s just going to do it right. It’s not going to mess that up. You have it add automated tests, you have it add documentation, you know it’s going to be good. But I’m not reviewing that code. And now I’ve got that feeling of guilt: if I haven’t reviewed the code, is it really responsible for me to use this in production? It's a great read, and what I will say is that I applaud Simon's *honesty* and willingness to self-reflect and challenge prior statements. But the gap of time between the [former](https://simonwillison.net/2025/Mar/19/vibe-coding/) and [latter](https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/) articles are *stunningly* short, just slightly over a year. And Simon isn't alone. Just a year ago, I think the memetic shape *was* by and large that something along the lines of "agentic engineering" is what people could or should do, and, though I think many people are hesitant to admit it, I think most people using these tools are tending towards vibecoding and not agentic engineering, just as Simon himself found himself pulled. Before we look at the consequences to this, I think we should look at why it's happening. # The vibe bobsled As far as I know I'm the only person who uses the term "vibe bobsled" and, well, I doubt it's a term that's particularly likely to catch on, but I find it personally useful. [Bobsledding](https://en.wikipedia.org/wiki/Bobsleigh), if you are unaware, is a particularly strange and interesting sport. It's a lot of fun, but you don't have a lot of agency in it. You sit in a bobsled, you go down an icy track, and really, there is only one way *to* go. But people can become experts in it, and can indeed measure themselves against each others skills; it's an olympic sport, and I remember my own first encounters with bobsledding as a child, when my father and uncle and aunts took me, and it was thrilling like a roller coaster and intoxicating upon my first encounter. But again, ultimately, there's only one place to go. The vehicle is the LLM, you are the passenger. And I think the amount of agency people have over their journey is greatly reduced from what they feel like it is. More than just a slippery slope, it is a pre-crafted journey. At the top of the chute, people tell themselves they're going to use these tools as a kind of fancy autocomplete. As they descend, they say they'll spin up some agents to explore ideas, but they'll write the code themselves. Next their agents are generating the code for them, but don't worry, but they'll review all the output. Soon they're plummeting downward and well, they don't actually review the code being spat out much anymore, but they trust the agents, heck maybe the agents are actually better coders than they are they say. And where does it go from there? From "I don't even code anymore" to ["I don't even prompt anymore"](https://lucumr.pocoo.org/2026/6/23/the-coming-loop/)? At every stage of the process, the coder in question removes themselves from the process of producing code, and gives in towards a faith-based initiative of code production, that the LLM knows and does a good job of what it's doing. But what is the source of gravity pulling the sled along this icy chute? It's simple. Generation is not the slow part of coding. Theory-building and review are. And plausible-enough things are extremely hard to debug and understand. But the machines are so *fast* at producing things. If you are going to review their work, you aren't really taking advantage of their most powerful property, which is speed. But theory-building and review are also *the programmer's most important role*. To illustrate just how hard it is to detect and review problems with something which *appears plausible*, let's look at Ka-Ping Yee's remarkable dissertation, [Building Reliable Voting Machine Software](http://zesty.ca/pubs/yee-phd.pdf). It is a wonderful read, and highly approachable. In the section "What makes software hard to verify?", Ka-Ping recognizes several major reasons why software is hard to verify: number of components, complex interactions, far-reaching effects, and nonlinearity. Notably, all of these problems are exacerbated by the patterns of code generation by LLMs. Still, let us leave that aside. Ka-Ping constructs a model voting machine, and decides to see how hard it would be to verify that we know it behaves correctly. To push that exploration to its furthest, Ka-Ping Yee and David Wagner try an interesting experiment: David Wagner and I decided to insert three bugs into Pvote to see if the reviewers would find them. We inserted what we thought would be an “easy” bug, a “medium” bug, and a “hard bug” to find, and chose each bug individually in such a way that an insider could conceivably exploit the bug to influence the results of an election. [...] We decided to insert all of these bugs in a 100-line region of a single file, lines 11 to 109 of Navigator.py, and told the reviewers to look in this region. We did this both because the navigator was the most interesting in terms of the program logic and because we knew the reviewers would have limited time. The new version of the code that we gave the reviewers contained all three bugs, but we did not tell the reviewers how many bugs there were. Yoshi Kohno, Mark Miller, and Dan Sandler participated as reviewers on the third day of the review. Dan was very familiar with Python and found the “easy” and “medium” bugs quickly, within about 70 minutes. Yoshi Kohno and Mark Miller found the “easy” bug after about four hours of reviewing. None of the reviewers found the “hard” bug. Ian Goldberg and Yoshi Kohno participated as reviewers on the fourth day of the review. Ian Goldberg also found the “easy” bug within about two hours; none of the other bugs were found on the fourth day. The reviewers spent a total of about 20 reviewer-hours focused on the task of finding the bugs in this 100-line section of Navigator.py. Ka-Ping chose from a highly seasoned group of reviewers who were even deeply familiar with security threats. Mark S. Miller has been a personal mentor to me throughout my career, and is one of the programmers I have learned most from and studied the work of most closely. I talked with him about the experience at one point. He remarked on how it took a significant amount of time to find the easy bug, hours to find the medium bug, and that nobody could find the hard bug... but the big observation (which was said to me personally, and is not recorded in the dissertation) was that "the astounding thing is that once the bugs were pointed out, we all agreed that they were retroactively obvious, and that we *should have* been able to find them!" If some of the best programmers in the world struggle to find bugs they even *know must be there* within a *100 line program*, there is simply *no hope for humans to review the volume of output from LLMs*. And so there is only one thing to do: don't bother. At each step, remove yourself. You tell yourself you won't, but you do. You give in to the chute and the shape of the vibe tunnel, and down you go. # Vibe sickness and the colonial settlers of the uncanny valley The term "AI psychosis" is thrown around a lot these days to describe anyone or any state of poor behavior or outcomes due to genAI usage. But the original description of "AI psychosis" was closer to something clinical, a description of people *quite literally* experiencing psychosis from encounters with chatbots which reaffirm far too much of the user, spinning them into spaces of delusional detachment from reality. But we should have *something* to describe the general sense of unwellness that seems to be befalling this world, and the best phrase of which I first saw in a [post from Glyph](https://mastodon.social/@glyph/116603752031736039): On the way home from #PyConUS 2026. Quite an experience this year; very intense. No point in sugar-coating the part where there is a pervasive vibe-sickness, open source is suffering a massive sustainability crisis, slop security PRs are overwhelming everyone (etc etc). But there was a lot of hope, a lot of energy, a lot of effort toward mutual understanding, and (surprising to me) a lot of appreciation. Including for my own work, both writing and coding. I like the phrase "vibe sickness", and if you aren't speaking of a form of literal psychosis, I think it's a better phrase. Vibe sickness is everywhere... heck, perhaps we are on the verge of, if not experiencing, a *vibe epidemic*. Everyone complains of slop, and yet nobody using these tools wants to self-describe their outputs as slop. Yet slop seems to be everywhere, and infecting one's everyday experience: posters of food at your local restaurant that have plausible and yet incomprehensible designs, the helpdesk support chatbot you wish you could make physically manifest so you could throw it off the edge of a cliff, [age verification code](https://neuromatch.social/@jonny/116935681120949448), and if you're a maintainer of an open source project, slop issues and pull requests. The thing is that all of this tooling is useful for *some* things, but the term "genAI" points at exactly what it's *worst* at: generating things. If we want to talk about *finding problems*, it's a different story. But even leaving aside the quality issues of the growing and wavering tower, there comes the problem of lack of understanding of how it is built, constructed, and maintained. The worst part of all this is you can't opt out. A colleague or an open source contributor sends you a "generous contribution" that is absolutely slop and certainly *not* understood by the person who submitted it. You're left sitting there, parsing whether or not you're going to be rude even to ask if this is LLM generated, or to unwittingly become a user of vibecoding workflows yourself by indirectly interacting with the agent through trying to respond to the issue/PR. You can't escape. To quote Glyph again: Protesting LLMs by refusing to use any software that includes them feels like attempting to protest the introduction of tetraethyl lead into gasoline by refusing to breathe until everyone stops putting it in their cars. So I am drawing my personal moral lines in such a way that I will probably accept this. But please don't mistake this for excitement about huffing a bunch of vaporized lead. Well put. In the meanwhile, the [uncanny valley](https://en.wikipedia.org/wiki/Uncanny_valley) colonizes our world and transforms it into its own. But there is a rot growing beneath our feet and within our walls as our world is swapped out with systems nobody understands. And I fear what it's going to be like to recover from this all, the price we do not even yet realize we are going to have to pay. For this reason, any project that chooses *not* to engage with current genAI stuff, I tend to gain respect for. But perhaps you can't opt out from aiding the problem. Your work won't let you, you're stuck in some situation... I don't mean to judge, but I do mean to end with a perspective. Sometimes I sit as the passenger of a car and watch the driver of said car get angry at someone biking on the road. It feels bad, because sometimes I bike on the road, and without sufficient infrastructure, bicyclists risk getting hit by car doors parked on the side of the road, squeezed out by impatient drivers, etc. I also drive. When I do, and there's a bicycle in front of me, I pause, and as the world broils to death, I take a moment to be thankful for their presence, and to think about how we could change the shape of the terrain to allow bicyclists to participate more safely (which would also help me drive more easily too, or choose to bike when I can). May we not give up on ourselves, and not lose faith in our ability to participate towards building a better world.