Old Principles and New Prompts

A lot has changed in software engineering, and we are still trying to understand whether its older principles remain relevant. Coding has evolved significantly, but I think every major technological shift follows a similar pattern. We begin by exploring possibilities, often through brute force. As we understand the limitations, we start introducing principles, structures, and methods to optimise what we have built. Perhaps software engineering is going through a similar transition today.

Many companies have already developed their own standards, codebooks, and repositories that define how software should be built. But I don't think these practices are universally accepted, especially considering how coding has evolved. Humans no longer want to remember every syntax, pattern, or implementation detail. They simply want to say, "Build me this," and expect the system to take care of the rest. I think we have spent far too much time doing manual groundwork that machines can now handle. If a principle is meant to optimise how a machine works, let the machine apply it. If creativity, imagination, or judgment is required, let humans bring that in.

I think this is where software engineering is heading. So far, we have spent years learning syntax, design patterns, and principles that make machines efficient. But how much of that has actually made our thinking efficient? Maybe the focus of software engineering education should now shift towards creativity, human thinking, usability, workflows, and problem-solving. The older principles will continue to exist, but humans may no longer need to remember every detail of their implementation. Machines can take care of much of that work while humans focus on understanding problems, exploring possibilities, and deciding what is worth building. Of course, humans still need enough understanding to evaluate whether the systems are doing the right thing.

In one of our previous stand-up sessions, we discussed how older software engineering approaches are still relevant, even in the age of vibe coding. Consider three familiar approaches: Waterfall, Spiral, and Throwaway Prototyping. In the Waterfall Model, we define requirements upfront and proceed through sequential phases of development. Something similar can happen when we give an AI agent a complete set of requirements and expect it to build the product according to a predefined plan, with minimal changes along the way. Thrinayani suggested calling this the Vibe-Fall Model. Now consider the Spiral Model, where development happens through repeated cycles of planning, risk evaluation, development, and review. In vibe coding, we see something resembling this iterative behaviour. We keep prompting an AI agent, reviewing what it builds, correcting its mistakes, and refining our requirements. Sometimes, the agent does something entirely different from what we intended and new iteration begins. Raunak and Vishruth suggested calling this the Spiral-Prompt Model, although repeated prompting is closer to iterative development unless we also evaluate risks in each cycle. The third approach is Throwaway Prototyping. We have an idea, build something quickly, explore whether it works, and then discard the prototype. Instead of improving the same product, we start again with a better understanding of what we actually want. I want to call this Vibe-Away Model. What interests me is that none of these approaches is entirely new. We are still applying many of the same software engineering ideas, but the way we implement them is changing.

We are still following many of the same ideas that software engineering introduced to us decades ago. The difference is that machines are progressively taking responsibility for implementation, while humans are moving towards exploration, creativity, and decision-making. So perhaps the real question is not whether the older principles are still relevant, but which principles humans need to understand and which ones machines should take care of.