Published on August 26, 2026

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.

After the first week, our results were still mixed. The backlog generated with AI support had worked well, but the actual development wasn’t 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.

In the second week, that began to change—and, of all things, on a topic about which we had previously been rather skeptical.

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.

That this impression wasn’t just an isolated one became clear later during our retrospective. The board simply read:

This allowed us to rule out one of our initial hypotheses quite definitively.

The support went beyond simply implementing our specifications. The AI made suggestions for additional analyses and features that hadn’t originally been part of our specifications. Not all of them made sense, but some certainly did.

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.

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.

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:

"Using AI is very helpful in the early stages of a project."

New topics could be explored quickly, and for straightforward problems, debugging—for example—could 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:

"You can learn new topics very quickly because AI can explain them to you at both high and low levels."

However, it wasn’t quite that simple. As the system’s 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:

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:

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’s responsibility.

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.

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.

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’s worth implementing.

By the fourth week, the difference from the project’s 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.

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:

It was also interesting, however, that the emotional assessment of working with AI was by no means entirely positive. One colleague wrote:

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’ve gone down a path that sounded convincing but turned out to be wrong can lead to frustration just as quickly.

Another comment from the retrospective therefore perhaps sums up the most important limitation of the entire experiment:

At first glance, this sounds paradoxical. After all, AI is supposed to help fill gaps in knowledge. And that’s exactly what it does. But the better the software engineer understands what’s happening technically, the better they can evaluate, correct, and refine the AI’s suggestions. AI therefore doesn’t make expertise obsolete—rather, it amplifies the impact of that expertise.

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.

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.

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.

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—are the processes surrounding development even prepared for that speed?

That's exactly what Episode 3 is all about. [Link to Episode 3]

• AI in Medical Software Development – How we support manufacturers in the development, validation, and MDR-compliant approval of AI-powered medical devices.
• Software Engineering for Medical Devices – Our range of services for MedTech, pharma, and life sciences: from consulting to market readiness.