Anyone who prompts AI with “build me the next WhatsApp or build me this revolutionary idea” will not succeed. The same applies to companies that rely on developers to stop developing and instead just prompt again to implement new features.

However, companies that develop a methodology for systematically transforming business needs into software using AI will win. The graphic above schematically shows this new methodology. The key principle is that the business has a problem, a need, or something it wants to sell, and it funds the software development. Business drives IT, not the other way around.

The requirements engineer who challenges with AI

The requirements engineer or business analyst must process, understand, and critically question the business need. It is no longer sufficient to simply specify “the business needs a new sales module”, that approach will fail. Instead, the requirements engineer or business analyst uses AI prompts to refine the requirements, asks the AI what is still missing for implementation, and iterates on that understanding. The requirements engineer or business analyst then feeds the software engineer’s AI with the specification as a general context, this is spec driven development. At the same time, individual feature stories are created with the help of AI and added to the Kanban board. This means there is a context prompt and also multiple feature stories, only together can this method produce maintainable code.

The AI assisted UI UX engineer

The new UI UX engineer also creates designs using AI prompts and provides these GUI designs to the software engineer’s AI agent via an MCP server.

The software architect defining AI

The software architect defines the framework conditions, specifies the software frameworks, develops core components, defines the AI agent’s skills, and creates templates that the software engineer can use as an initial codebase.

The software engineer augmented by AI

The new software engineer uses the requirements specification as context and incrementally pulls one story per feature, transforming each story into a meaningful prompt. In practice, the quality of prompting depends heavily on how well the engineer understands the codebase. The more technical and context aware the prompt is, especially when referring to patterns, components, and specific code areas, the easier the resulting code is to review and maintain. The software engineer can work on multiple stories by running multiple agents in parallel. After implementation, the engineer reviews the code, tests the functionality locally, re prompts the agent if changes are needed, and commits the result.

The test engineer

The test engineer validates the functionality, reports bugs back to the software engineer, and closes the story on the Kanban board when successful.

Conclusion

Companies that implement this methodical software development process in an efficient and standardized way will experience a significant productivity boost.