Does vibecoding make coding more accessible?

I was a volunteer and organiser for codebar for several years and was heavily involved in outreach activities during my time at Cambridge. In the face of cuts to DEI initiatives, I believe that the lack of diversity at all levels of the tech sector seriously harms the sector.

Besides the obvious lack of demographic diversity (I am the only woman full-time employee software engineer in my department, out of 30 or so; although there are a handful others of research and hardware engineers), there is an over-valuation of people from computing and engineering backgrounds, at the expense of people from other disciplines, especially the social sciences and humanities, who have deep domain knowledge in their own fields. I am fortunate to work in a very interdisciplinary team, where I've had the opportunity to learn about a variety of topics in acoustics, audiology, music, image processing and data science; besides topics in computing.

At the risk of overgeneralising, software engineers lack this domain knowledge. Instead, we maintain our value by holding a monopoly over our skills, acting as middlemen between innovators and implementations. As with all middlemen, while this situation is very lucrative for us, it slows down the development process and often introduces misunderstandings along the way.

If "vibecoding" (Wikipedia) can indeed reduce the barrier for people from other disciplines to start coding, that is not necessarily a bad thing. Of course, many people are using these new abilities to create "innovations" that are either useless or actively harmful to society or the environment. But that is a wider problem with an economic system that rewards such creations. Maybe more on that in a future post.

From an educational point of view, however, I don't think vibecoding can be a substitute for becoming a well-rounded engineer.

My experience using LLMs is that they are excellent for generating prototypes and introducing one to a new technology or framework (or many other topics); but they remain very poor at any higher-level tasks. Vibecode does poorly with complex systems, and produces solutions that do not scale well, do not handle edge cases, and have important flaws such as security loopholes. And even code generation often produces plenty of unnecessary code, or "cargo-cult programming". When I point out these flaws in their solutions, they are usually able to adapt the solutions to address those issues but often create new problems.

I know about these considerations, through several years of experience and experimentataion, sometimes painful (e.g. accidentally dropping entire databases or buckets). And there are many more considerations that I do not know about, which is when I am very happy to have the advice of more senior engineers.

A novice programmer who relies on vibecoding may do a decent job creating a prototype and may even become quite comfortable with a programming language, but may find it difficult to grow beyond a small project or generalise this knowledge. This isn't a new problem, though: there are many courses, tutorials or bootcamps that equip students to develop apps using frameworks, but do not teach the principles behind the frameworks, leading to aforementioned cargo-cult programming. This is an all-too-common antipattern in science education: Timothy Gowers describes shortcomings of high school mathematics education, which bombards students with techniques and facts but does not introduce any rigor or foundations, producing students who pass exams but do not understand why.

So perhaps there is still a place for us software engineers. But we must do better than being code monkeys: in particular, we must adopt an attitude towards engineering that focuses on systems and thinks at a higher level, about business requirements.