![\"Miriam](\"https:\/\/www.bayoomed.com\/wp-content\/uploads\/sites\/4\/2026\/08\/Miriam-Schulze-CEO-BAYOOMED.jpg\" "\\"Miriam")
<\/span><\/div><\/div><\/div><\/div>Miriam Schulze<\/strong> Published on August 26, 2026<\/em><\/p>\n<\/div> There\u2019s a lot of talk right now about AI in software engineering. Almost every day, new tools, success stories, and predictions emerge about how fundamentally AI will change the way we develop software. At some point, we became less interested in the latest hype and more interested in a very practical question: What actually works in a real software project when you set out to make it work?<\/p>\n To find out, we at BAYOOMED launched our AI Lighthouse. We deliberately chose not to develop an artificial demo project, but instead selected a task for which we had a baseline for comparison.<\/p>\n<\/div><\/div><\/div><\/div><\/div> We had already implemented a similar solution some time earlier as software in an FDA-regulated context. That solution consisted of an app and a backend; it involved a traditional project team of about six people with various roles in architecture, development, verification, quality, and product ownership. The project took nine months to complete.<\/p>\n We didn't have that much time. For our experiment, we changed the parameters. This time, we wanted to implement a slightly different technical scope exclusively as a cloud solution. Above all, however, we wanted to find out how far we could go if we set as few technological constraints as possible and consistently integrated AI into the development process.<\/p>\n<\/div><\/div><\/div><\/div><\/div> When selecting technologies, we therefore gave the team largely free rein. They were allowed to experiment with programming languages, frameworks, AI assistants, and even tools capable of generating large portions of an application. The only requirement was that the solution had to run in the cloud.<\/p>\n At the same time, there were a few non-negotiable requirements: The tools used had to be suitable for commercial use and meet our data handling requirements. In particular, our data could not be used for further training of the models.<\/p>\n<\/div><\/div><\/div><\/div><\/div> We also deliberately scaled back the development process for this experiment. Unit tests were part of the scope, but comprehensive documentation and verification were not\u2014at least initially. It was clear to us from the start that we were testing AI in software engineering under simplified conditions and that we could not apply the results directly to a regulated medical device.<\/p>\n<\/div><\/div><\/div><\/div><\/div> If we were going to explore just how far AI could take us in a project\u2014if we were going to explore just how far AI could take us in software engineering\u2014we didn\u2019t want to start with coding. Traditional product owner tasks should also be part of the experiment.<\/p>\n Our technical foundation was the SRS from the original project, which we had adapted to the new scope. We also had two UI designs and an initial prototype created with Lovable. We consolidated this material into a ChatGPT project and used it to generate a backlog\u2014including user stories, scope definitions, acceptance criteria, and links to the respective requirements. We then transferred the result from Excel to Azure DevOps.<\/p>\n That worked better than we had initially expected. Of course, the result had to be reviewed and refined in some areas. But it provided a solid foundation for launching the project.<\/p>\n The first user story was deliberately not a business feature, but focused on architecture and software design. After all, we didn\u2019t just want to know how much code AI could generate. We were interested in whether two experienced software engineers, with AI support, could use a technology that was relatively new to them in such a way that a viable architecture would still emerge in the end.<\/p>\n<\/div><\/div><\/div><\/div><\/div> We also changed our usual project rhythm. Instead of two- or three-week sprints, we worked in one-week sprints, with planning and review sessions on Mondays. We did away with a formal daily stand-up. With a team of just two developers, direct communication was already a given; any open questions could be clarified at any time via a Teams chat.<\/p>\n The short sprints were a deliberate choice. We assumed that an experiment like this could only be planned to a limited extent in advance. We wanted to be able to learn quickly, reprioritize regularly, and adjust our own hypotheses.<\/p>\n<\/div><\/div><\/div><\/div><\/div> It became clear as early as the first week that the backlog generated by ChatGPT was surprisingly useful. During planning, we had to clarify a few questions and refine some details, but the user stories were already so granular that the team was largely able to do without an additional task breakdown.<\/p>\n At the same time, we began searching for the right toolset. Claude and GitHub Copilot became essential tools in the development process. We also tried out Lovable, but ultimately ruled it out for our specific use case because it didn\u2019t offer enough flexibility for subsequent customization.<\/p>\n The first review brought a certain sense of disillusionment. The hoped-for dramatic acceleration was not immediately apparent. The cloud setup proved to be more complex than expected, and in some instances, the AI initially led the team in the wrong direction. At the same time, the team members had to figure out which tool was best suited for which task. And they rightly wanted to understand what the AI was producing, rather than simply adopting the generated code.<\/p>\n This experience already revealed a key insight that would later play an important role in our retrospective: AI in software engineering makes it much easier to get started with new technologies, but it does not render domain expertise obsolete. Especially when you know little about a topic yourself, it becomes harder to recognize when AI is wrong or taking an unnecessarily complicated approach.<\/p>\n After the first week, it was therefore by no means clear whether our hypothesis would hold true. However, we had already learned that AI-assisted development is not simply about generating as much code as possible.<\/p>\n And in the second week, the momentum of the project began to change significantly.<\/a><\/p>\n<\/div><\/div><\/div><\/div><\/div>
\nCEO<\/em>
\nDigital Health & Innovation
\nLinkedIn<\/a><\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>The comparison: nine months with six people<\/h2><\/h2><\/div>
AI in software engineering: Two Senior Engineers, No Specialists<\/h2><\/h2><\/div>
What We Have Deliberately Simplified<\/h2><\/h2><\/div>
AI Isn't Just for Development<\/h2><\/h2><\/div>
One-week sprints instead of two or three<\/h2><\/h2><\/div>
AI in software engineering, Week 1: Faster\u2014But Not Fast Enough Yet<\/h2><\/h2><\/div>
What you'll find on our website<\/h2><\/h2><\/div>
\n