![\"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> Four weeks, two senior software engineers, one real-world backend project: In our AI Lighthouse initiative, we wanted to find out what AI-powered software engineering can achieve in practice.<\/a><\/p>\n After the first week, our results were still mixed. The backlog generated with AI support had worked well, but the actual development wasn\u2019t nearly as fast as one might expect given all the promises surrounding AI coding. The team first had to find the right tools, familiarize themselves with cloud technology, and learn how to effectively integrate AI into their own development process.<\/p>\n In the second week, that began to change\u2014and, of all things, on a topic about which we had previously been rather skeptical.<\/p>\n<\/div><\/div><\/div><\/div><\/div> Up until then, we had assumed that while AI can generate code, it quickly reaches its limits when it comes to creating a good user interface. Our UI-savvy colleague refuted this assumption quite clearly. With AI support, functional and visually appealing interfaces were created at a speed and quality that surprised us.<\/p>\n That this impression wasn\u2019t just an isolated one became clear later during our retrospective. The board simply read:<\/p>\n<\/div> \u201cAmazed at how well the UI worked.\u201d<\/p>\n<\/div><\/div><\/div> This allowed us to rule out one of our initial hypotheses quite definitively.<\/p>\n The support went beyond simply implementing our specifications. The AI made suggestions for additional analyses and features that hadn\u2019t originally been part of our specifications. Not all of them made sense, but some certainly did.<\/p>\n This led to an interesting shift in the development process: When the effort required to test an idea becomes very small, the way we handle such ideas also changes. A feature that we might previously have added to the backlog for a later sprint often became something we could simply test out briefly.<\/p>\n<\/div><\/div><\/div><\/div><\/div> By the third week, the team had increasingly found its rhythm. The team members had a better understanding of which tool was best suited for which task, had gained a deeper understanding of the technology, and had also learned how to provide the AI with the right context.<\/p>\n It was precisely this context that proved to be crucial. AI was particularly helpful in the early stages of a project. One of the comments from the retro sums it up well:<\/p>\n \"Using AI is very helpful in the early stages of a project.\"<\/p>\n New topics could be explored quickly, and for straightforward problems, debugging\u2014for example\u2014could be significantly sped up. The team also found that AI makes it possible to try out and understand new technologies very quickly. Or, as one of our notes put it:<\/p>\n \"You can learn new topics very quickly because AI can explain them to you at both high and low levels.\"<\/p>\n<\/div><\/div><\/div><\/div><\/div> However, it wasn\u2019t quite that simple. As the system\u2019s complexity grew, collaborating with the AI became more challenging. The more interrelationships had to be taken into account, the greater the risk that relevant context would be missing. This was also made very clear during the retrospective:<\/p>\n<\/div> \u201cAs soon as the context becomes broader\u2014that is, if the problem is more complex\u2014AI faces its own challenges too.\u201d<\/p>\n<\/div><\/div><\/div> This became apparent, for example, when making changes to existing functions. A seemingly minor adjustment could have unexpected consequences elsewhere because the model had not fully taken the overall context into account. A colleague described exactly this experience:<\/p>\n<\/div> \u201cAdding a feature or debugging might cause a bug elsewhere because AI doesn\u2019t know the entire code.\u201d<\/p>\n<\/div><\/div><\/div> The technical proposals themselves also had to be critically reviewed. In some cases, outdated libraries or older versions were suggested, even though more current alternatives were available. Added to this is an aspect that must not be underestimated, especially for professional use: An AI-generated technical solution is not automatically reviewed for compliance with licensing laws. Evaluating the libraries used and their licenses remains the team\u2019s responsibility.<\/p>\n As the team gained more experience, it became better at dealing with these limitations. The result was not that they used less AI, but that they made more informed decisions about when and how to use it.<\/p>\n At the same time, the team began to think beyond the original requirements. For one of our reviews, for example, our colleagues quickly created an interface that allowed the entire system to be populated with data at the click of a button. This feature was neither specified nor part of a user story. However, it proved extremely helpful for development and the reviews.<\/p>\n Situations like these were among the most interesting observations we made during the experiment. When the technical implementation of a small idea requires only minimal effort, a team can experiment much more frequently, rather than spending a long time discussing whether it\u2019s worth implementing.<\/p>\n<\/div><\/div><\/div><\/div><\/div> By the fourth week, the difference from the project\u2019s start was clearly noticeable. The team had implemented all the must-haves and, in addition, had added some useful enhancements that had only emerged during development.<\/p>\n Of course, these four weeks were not four weeks of trouble-free feature development. The team had to familiarize itself with new topics, resolve technical dead ends, and scrutinize AI-generated solutions. Nevertheless, an astonishing amount had been accomplished in a very short time. The feedback from the retro was correspondingly clear:<\/p>\n<\/div> \u201cI\u2019m amazed that we got so much done.\u201d<\/p>\n<\/div><\/div><\/div> \"We accomplished a lot in a short amount of time, even though there were some topics we had to get up to speed on.\"<\/p>\n<\/div><\/div><\/div> It was also interesting, however, that the emotional assessment of working with AI was by no means entirely positive. One colleague wrote:<\/p>\n<\/div> \u201cWorking with AI can be both \u2018inspiring\u2019 and demotivating.\u201d<\/p>\n<\/div><\/div><\/div> That pretty much matches our experience. When something that used to take hours can now be done in just a few minutes, it can be incredibly motivating. On the other hand, realizing that you\u2019ve gone down a path that sounded convincing but turned out to be wrong can lead to frustration just as quickly.<\/p>\n Another comment from the retrospective therefore perhaps sums up the most important limitation of the entire experiment:<\/p>\n<\/div> \u201cWorking with AI can be both \u2018inspiring\u2019 and demotivating.\u201d<\/p>\n<\/div><\/div><\/div> \u201cThe more expertise you have in the subject matter, the greater the benefit from AI.\u201d<\/p>\n<\/div><\/div><\/div> At first glance, this sounds paradoxical. After all, AI is supposed to help fill gaps in knowledge. And that\u2019s exactly what it does. But the better the software engineer understands what\u2019s happening technically, the better they can evaluate, correct, and refine the AI\u2019s suggestions. AI therefore doesn\u2019t make expertise obsolete\u2014rather, it amplifies the impact of that expertise.<\/p>\n<\/div><\/div><\/div><\/div><\/div> For us, speed alone was not a sufficient measure of success anyway. That is why the resulting solution ultimately underwent a technical review by our CTO, Bernd Seidenspinner.<\/p>\n This result was also interesting. While he would have implemented some things differently, he rated the architecture and technical decisions as good and well-founded. This reinforced one of our original hypotheses: seniority and solid software engineering expertise, when supported by AI, may be able to compensate for some of the in-depth experience required in a very specific technology.<\/p>\n That doesn't mean that technical expertise is becoming less important. On the contrary: Anyone who wants to evaluate an AI's suggestions must be able to recognize when it is wrong, when an architecture is unsound, or when, for example, a suggested library is unsuitable from a technical or licensing standpoint.<\/p>\n After four weeks, we didn't just have a working solution. We also had a new question: If the actual implementation can suddenly become significantly faster\u2014are the processes surrounding development even prepared for that speed?<\/p>\n That's exactly what Episode 3 is all about. [Link to Episode 3]<\/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 first hypothesis we ruled out: the user interface<\/h2><\/h2><\/div>
By the third week, I was really getting into the flow<\/h2><\/h2><\/div>
Where AI-Powered Software Engineering Reaches Its Limits<\/h2><\/h2><\/div>
After four weeks, the must-haves had been implemented<\/h2><\/h2><\/div>
Both inspiring and demotivating<\/h2><\/h2><\/div>
The Technical Review<\/h2><\/h2><\/div>
What you'll find on our website<\/h2><\/h2><\/div>
\n