The use of Vibe programming platforms, in which software developers use natural language prompts to guide large language models (LLMs) to generate, refine, and debug code, continues to expand. In parallel, the Vibe technology itself continues to evolve. While it is unclear how this will play out in the future, Vibe programming has already disrupted existing methodologies for developing software. And those impacts are significant. It is like agile on steroids, or “hyper-agile.”
Methods for software development, whether more akin to waterfall or agile development, are built around what has been a steadfast bottleneck: the time and effort required to write code.
How traditional development methods work around the coding bottleneck
In order to navigate around this bottleneck, organizations do things like:
• Spend time, even in agile workflows, defining desired outcomes and software requirements.
• Spend time identifying exhaustive lists of software requirements. Given the time and effort to build software, stakeholders treat each development project as their one and only opportunity to get everything on their wish list, and so they define and want it all.
• Build in feedback loops. One of the truths about software development is that no one knows what they want until they see it. As a result, particularly in agile workflows, stakeholders are asked to review work to reduce the likelihood of the project going off track. In the agile method of Scrum, this feedback comes in product, release, and sprint planning, as well as during end-of-sprint demonstrations.
• Employ project and portfolio management. Because of the time and effort required to build software, the cost of getting things wrong is high. In response, organizations build ancillary processes like project and portfolio management, which are designed to reduce project risk.
• Treat software projects like capital projects, requiring an approved business or value case that generates a return on what could be a large investment in time and effort.
What changes when code is no longer the constraint
How does the use of Vibe programming platforms change this? It significantly reduces the time and effort required to write code. With Vibe programming, the AI-powered platform writes the software, while human software engineers refactor it. Even better, Vibe programming frees software engineers to focus on defining and designing solutions.
The bottleneck moves: A theory of constraints moment
What does this mean? The bottleneck around which development methodologies have traditionally been defined shifts to another part of the process. This is a perfect example of the theory of constraints.
If the historically massive bottleneck around writing code is gone, how do our methods need to change?
Early lessons from Vibe programming in practice
My early experience with Vibe programming indicates the following.
• Requirements can evolve instead of being exhaustively defined upfront.
The need for a detailed or exhaustive definition of requirements goes away. Because the time from identifying a need to the delivery of working software is short, requirements can evolve through a series of expanding versions. The initial requirements might be as simple as a concept that can then be iterated.
With Vibe programming, it takes far less time to create a version of the software. Given that, how much does the quality of the initial definition of requirements really matter? If the delivery team does not grasp the requirements, a corrected version is only hours or a few days away.
The requirements should focus on the desired outcome of the software product. What is its purpose? How will its impact be measured? What are its success and acceptance criteria? These outcome-based requirements become the North Star for the development team.
• Scope no longer needs to be tightly constrained.
There is no longer a need to control scope by saying no to some ideas or needs. Stakeholders can provide their wish lists.
• Stakeholder review becomes the new bottleneck.
If it takes 50%, 60%, or 75% less time to build a version of the software, stakeholder reviews and decision-making must occur on a much faster cycle. It is likely that the team will have a review-ready version of the software in a day or two, or even more frequently early in the project.
Stakeholders and decision-makers are often busy people. Do they have time to meet once a day or every other day to review the most recent version of the software? Perhaps not.
One option is to replace frequent reviews and decision-making with a more empowered development and product team. As the team defines desired outcomes, it should also identify which types of decisions require stakeholder involvement. These should be limited to decisions that affect outcomes.
Should the team consult with the CEO about how many pixels from the edge of the page an image should appear? Hopefully not. Only a small subset of decisions should require stakeholder review so the team can move quickly.
• The business case should be treated as an experiment.
Because the time and effort required to build a product are dramatically reduced, organizations should rethink how they approach the business or value case for projects.
Is it still necessary to build, review, and approve a business or value case before starting the work? Or can the project be treated as an experiment, where an initial version is delivered based on expected value and its impact is measured?
If the impact aligns with expectations, functionality can be expanded and the next version released. If it does not align, the team can pivot and move to the next concept. The cost of getting it wrong is now low.
• Deployment only becomes a bottleneck if teams let it.
There could still be a bottleneck in the deployment process, but only if the organization is not already adept at DevOps, DevSecOps, and CI/CD. The AI can be informed of the deployment target and perform much of the work.
Accelerating time to value requires process change, not just tools
In scenarios where a team is building something designed to generate value, Vibe programming allows organizations to realize that value much more quickly. However, to truly shorten the time to value, the entire process, from inception to reviews and development cycles, must change so it does not become the next set of bottlenecks.
It would be a shame for an organization to inject Vibe capabilities without overhauling the broader software development process.
