Vibe Coding and the Stewardship of Software
Over the past two years, something drastic has happened to my engineering practice: the ability to create working software has become dramatically easier, up to a point.
Leveraging modern AI tools, I can describe the features of a change to an existing app (or even specify an entirely new app from scratch), iterate conversationally, and assemble a working version in a matter of hours. I can scaffold full stacks nearly instantly. Ideas which would have required days or weeks of effort from me can now be realized with much less of my time and energy.
Not only have I been coding in this way myself, and been genuinely impressed with how quickly my ideas can become functioning applications, I've also watched non-engineers demo tools they built this way, with real pride in what they created. But, viewing these tools as someone who has spent many years stewarding production systems has created an interesting contrast. I know from experience that the moment a prototype begins turning into a product, a completely different category of problems will appear.
Slow queries will being to surface, data models will start to strain under real usage, security assumptions will turn out to be incomplete, and things will start to break without any visibility into why.
"It Works" Isn't the End
One misconception that vibe-coding can create is the feeling that once the application works, the hard part is done...in reality, that can actually be the signal that real work is only about to begin. A prototype demonstrates that an idea is possible, but a product is a running system that must reliably serve users, preserve data integrity, evolve safely, and withstand the unpredictability of real-world usage. Another way of putting it is that code itself is only one part of the overall system.
The totality of the product is the system that surrounds the code: infrastructure, usage guarantees, data integrity, observability, and operational discipline. All of these components are defined by the stance we take as stewards.
Where Complexity Actually Lives
As the barrier to creating applications drops, areas where real engineering expertise matter become more apparent. I've arranged these areas of complexity into the "4S of software stewardship":
Scale
A prototype that works for one user does not necessarily work for thousands (not to mention millions). As real traffic starts, queries that were nearly instantaneous slow down, latency grows, and costs can rise unexpectedly. Understanding how systems behave under load, and how to design them for stability, is critical.
State
Most real systems revolve around data, which introduces its own complexity. How should the schema evolve? What happens when multiple users modify the same data? What consistency guarantees should exist? If data becomes corrupted or a schema migration goes wrong, consequences can be severe. Understanding state evolution is a large part of real stewardship.
Security
Generated code can easily overlook the boundaries that protect both users and systems. Authentication, authorization, secrets management, and input validation require careful design. These become foundational concerns.
Systems Thinking
Software does not exist in isolation. It depends on services, changing APIs, and network infrastructure. When something breaks, someone has to understand why. This all requires observability, architectural thinking, and a system that has been designed to tolerate failure.
What Vibe-Coding Gets Right
I don't intend to demean vibe-coding. I myself rely on some form of it. (Though I practice a combination of the spec-driven approach and what I call "Socratic development".) In fact, I think it may be one of the most powerful tools we have ever had, at least in terms of software engineering. The ability to rapidly explore ideas lowers the barrier to experimentation and more people can build things, spurring more innovation.
But, as the barrier to building lowers, the discipline of operating software, rather than building it, becomes the commodity.
Software Stewardship
My main point is that responsibility is shifting away from producing code towards maintaining a system that evolves reliably over time. Understanding tradeoffs, preserving the integrity of data, and anticipating failure modes is where I spend my focus time. In a sense, engineering is less about writing software and more about stewarding these systems. As the tools make it easier to build an application, stewardship may become the most important role any of us can play.