Vibe Coding Is Sociotechnical Systems Theory Testing Its Limits

Gartner recently identified AI-native development platforms as enabling a new pattern they call vibe coding: software development without deep technical knowledge, where one-shot tools generate working applications from a single prompt. The phrase caught my attention because it captures something real about what these tools do. A non-developer can describe an app in natural language and get back something that runs. That is genuinely new. But the more I thought about it, the more I kept returning to a paper from 1951. Trist and Bamforth studied British coal mines where the longwall method had mechanized extraction, splitting one autonomous team into three specialized shifts. The technical subsystem was optimized. Productivity collapsed anyway. I wrote about this recently in the context of move-fast culture, and the parallel to vibe coding feels even more direct.

Vibe coding optimizes a single moment of the software lifecycle: the moment of generation. You type a prompt, the model returns code, and the code does something visible. That is the technical subsystem operating at peak speed. But software engineering is not just code production. It is code review, testing, deployment, maintenance, documentation, and team coordination. It is understanding why a piece of code exists, who owns it, and what happens when it breaks in production at 3 AM on a Saturday. Vibe coding produces output at the front of this pipeline while deleting almost nothing from the back. The code still needs review. It still needs tests. It still needs to be deployed, monitored, documented, and maintained. These are not technical fringe activities. They are the social subsystem of software engineering, the practices and norms and shared understandings that turn a blob of working code into something a team can sustain.

The longwall method broke a single autonomous mining group into three specialized shifts. Each shift did one piece of the work and handed off the result. The handoff was where everything fell apart. Miners on one shift blamed the previous shift for problems. Informal coordination collapsed. Shared responsibility for output vanished. Vibe coding creates the same fragmentation. A developer vibes out a feature, gets a pull request with twenty files of AI-generated code, and the reviewer is expected to understand, validate, and take responsibility for code they did not write and did not see being written. The generation moment is fast. The review moment becomes slower, more uncertain, and more socially costly. When something breaks, who owns the fix? The person who wrote the prompt? The reviewer who approved it? The model that generated it? The question has no organizational answer yet.

Trist and Emery formalized this pattern into sociotechnical systems theory. Their core claim is that any organization contains a technical subsystem and a social subsystem, and optimizing either one alone degrades the performance of the whole. Joint optimization is the alternative: you design both subsystems together, accounting for how changes to one ripple through the other. Bostrom and Heinen (1977) brought this directly into IS research in the very first volume of MIS Quarterly, arguing that system failures are almost always sociotechnical problems, not purely technical ones. Sarker et al. (2019) found that only about 13% of IS research operates at genuine sociotechnical interaction, what they call Type IV. The rest treats technology as background, as a control variable, or as a deterministic force. Vibe coding is a perfect example of what happens when the industry normalizes operating at the purely technical end of that axis.

The distinction between prototyping and production software makes the problem concrete. Vibe coding works well for prototypes because prototypes have no social subsystem. A prototype needs to exist, to be seen, to be iterated. Who maintains it? Nobody. Who is responsible when it breaks? Nobody. Prototypes end up in a drawer. But production software has a social system built around it. On-call rotations. Service level objectives. Incident response playbooks. Code ownership. Deployment gates. When AI generates a piece of production code, that code enters a social system that was designed around human authorship. The code has no author, no context, no history of why it was written that way. The reviewer inherits all of that invisibility. Every AI-generated pull request becomes a review problem that the team did not have before. The generation is fast. The absorption into the social system is slow, and the mismatch grows with every line.

Sarker et al. (2019) identify three dangers of IS research that cluster at the poles of the sociotechnical axis: uneven emphasis on one dimension, limited variety in relationship types, and an instrumental focus that treats technology only as a tool for achieving human goals. Vibe coding suffers from all three. The emphasis is entirely on the generation moment. The relationship between the developer and the AI is treated as linear: prompt in, code out. And the AI is framed as a productivity tool rather than as a participant in a social system of accountability. The Substantive IT Role Check, drawn from Lee (2001) and discussed by Sarker et al. (2019), asks whether removing the IT context changes the model. If vibe coding is just a faster way to produce code, the IT artifact collapses to a typewriter. If it changes who is responsible for what, who reviews what, and how teams coordinate, then the IT artifact is doing real work and the sociotechnical system needs to be redesigned around it.

I think the industry will rediscover STS theory the hard way. Right now vibe coding is exciting because it lowers the barrier to making software. That excitement is real and it is not wrong. But the cost is deferred. The code being generated today will need to be maintained in 2027 and 2028, by teams that did not write it, working from prompts they did not see, supporting features whose rationale exists only in someone's chat history. The maintenance crisis is already visible in the growing friction around AI-generated pull requests, the finger-pointing when AI code introduces a production bug, the slow realization that vibing code into existence is not the same as building software. The technical subsystem has been optimized. The social subsystem is about to find out what that costs.

I wrote about the longwall method and move-fast culture a few days ago, and about sociotechnical systems theory and what joint optimization actually requires. Vibe coding is the same story with a newer technology. The coal mine became a code editor. Everything else is still where Trist and Bamforth left it.