Media outlets see “vibe coding” – a practice where you let an AI assistant churn out code for you, after describing what you’re after – as a “trend” that is beginning to “catch on”. I see it as a potential problem, especially for digital accessibility.
It’s more than just bad code. I kept thinking about it and kept finding more reasons to be worried. So, as usual, I made a list.
Disclaimers: I’ve not tried vibe coding beyond some simple Python experiments. But I have tried actual coding, and digital accessibility work. The list is in no particular order.
If you wish to add / edit / disagree with any of the following, please let me know – my socials are below.
- It’s bad code. Please understand: your current generation of AI assistants can’t “understand” the problem. They just churn out the bits that are statistically most likely to follow from one another. The examples I’ve tried didn’t solve the things I wanted them to solve. It’s bad news for anyone, not just for digital accessibility. But if a program crashes, then a person with disabilities usually has fewer options to fix stuff.
- It’s probably trained on inaccessible source material. In many cases, people are only now waking up to what digital accessibility means. And in most cases, the work is iterative, with accessibility “fixes” coming late in the day. AI crawlers don’t care. As a result, most of the input probably leaves a lot to be desired. You can’t expect AI to “magically” fix issues whose fixes it never encountered.
- It’s never met your users. Here, I’ll start getting ranty, and probably continue for two or three more ideas. Vibe coding, even in its name, is a lie. It’s not coding (just advanced copy-pasting), and it’s never vibed with anyone. A focus group, a user interview, even reading a support ticket – teaches you more about your real users’ accessibility needs than any amount of web scraping.
- It’s an open invitation to reduce scrutiny. If you don’t have to care about your users any more, why not extend that “vibe” to colleagues and collaborators? Something that’s vibe-coded in seconds will probably be pushed straight to production, without a single pair of eyes across it. If you cut out the “coding” part, then you’ll be also tempted to cut out the QA part. And so, you never hear about the accessibility problems.
- And therefore, it’s a “middle finger” to collaborative working culture. I know researchers whose brilliant work shows that great things can happen when coding teams work together on problems, and motivate each other to get better. Vibe coding is not just the opposite of this. It’s actually a rebellion against working this way. You may see benefits in terms of saving yourself time and effort – but there are plenty of downsides. And one of them is that you are not having accessibility conversations.
- It’s already outdated tech. Sure, watching your web app code itself in seconds is impressive. But if you look at what it’s made of – these are probably snippets of old code. AI crawlers and learning models aren’t likely to come up with cutting edge stuff. From a technical perspective, this means you’re getting an old code smoothie on your servers. This makes your website slower, less usable, less secure, and (as accessibility standards evolve along with tech) – less accessible.
- Vibe coding is an exploitative practice. It’s saving you time and effort – by slowing down countless servers and repos as it crawls them thousands of times a day. It’s saving you money – by exploiting the work of others and driving up their costs. I’m sorry if you didn’t expect politics from this post. I just feel it’s impossible to talk about digital accessibility without mentioning social justice and the ways in which we work and make stuff. And vibe coding, along with the rest of AI industry, fucks all of these things up.
- Therefore, it’s undercutting the communities that feed it. Think about it. What will the crawlers crawl when the code repos close down? What will the learning models learn from, when the good resources move to a fairer place? And, since all AI stuff needs careful edits and clean-ups behind the scenes (you never see it, but trust me, it’s there) – what will the products look like when the people who clean up after them get fed up and leave? Make no mistake: digital accessibility is a community. One of the best I’ve found. If that’s gone, then there’s no fresh stuff to feed your crawlers.
- The authoring tools themselves are not accessible. Most of the vibe coding workflows today depend on prompts (typed or dictated) and then a visual review (once the finished product displays on the screen). There are several ways in which this workflow would need to be amended to be made accessible. To be fair, even the regular ways of building stuff online still have a way to go when it comes to making their authoring tools accessible. But I do not think that vibe coding even knows where the ballpark is, when it comes to that.
- No docs + no know-how = no way to fix anything. Saved the best for last! Let’s say you vibe-code your whole website. Let’s say you deploy and forget about it. And let’s say that in two years’ time, an accessibility audit happens, and finds plenty of things to fix. Where is the documentation for what was done? Where is the README, where’s the change log? Also – where are the people who know which parts to fix, and how? None of this exists with vibe coding. So, when the inevitable “finding out” stage arrives, it’ll cost ya.
Would you disagree with any of the above? Would you add anything? Let me know if so, all my socials are below.
Vic Kostrzewski (cost-chef-ski, he/him) is a Learning Designer, Translator and Project Manager based in South Wales. To discuss a new project, email anytime: vic@cost-chef.ski
