Published on August 26, 2026

Four weeks, two senior software engineers, a working backend, and a successful technical review: Our AI Lighthouse project has confirmed our initial hypothesis. A small team of experienced software engineers can achieve an astonishing amount in a very short time through consistent use of AI—even if the technology in question isn’t initially part of the team’s everyday toolkit. This led to the follow-up question: What does AI mean for everything that happens in the development process beyond just coding?

At the same time, we were aware that our experiment had taken place under laboratory conditions. We had deliberately simplified many aspects. The scope of documentation was reduced, the tests were limited to unit tests, the team consisted of only two developers, and the scope was clearly defined. A regulated medical device with all its requirements for development, documentation, and verification presents a different starting point.

That is precisely why we were interested in the question of what would happen if we applied the development speed achieved in the experiment to real-world projects.

Even if implementation now takes only a fraction of the time it used to, the other components of professional software engineering do not disappear. Requirements engineering, reviews, testing, verification and validation, cybersecurity, documentation, and approvals remain necessary—especially in the regulated medtech environment.

This creates the risk that the bottleneck will simply shift elsewhere. If we become significantly faster at implementation but reviews and V&V continue to take just as long as before, the total duration of a project will not be reduced by anywhere near the same proportion.

Our current processes are not yet fully optimized for AI in the development process. That is why our Chapter Leads are working on how we can adapt and streamline them without losing sight of what is most important to us: traceable quality and full compliance with ISO 13485 and IEC 62304.

This isn't about skipping necessary steps. Rather, we need to ask ourselves which tasks can be automated, what information needs to be available earlier, and how we can organize reviews and verification so that they keep pace with significantly faster development.

When reviewing our lab conditions, we noticed another point that at first seemed almost self-evident: the customer and the product owner were the same person in the experiment—someone from our own company.

This had a significant advantage. Technical questions from the development team could usually be answered immediately. If information was missing, we could obtain it quickly. When a decision had to be made, there was no need for lengthy coordination processes.

In a typical client project, the reality is often quite different. Information must first be gathered internally; contacts are not always available; decisions require coordination with multiple stakeholders; and a technical inquiry may well remain unanswered for several days.

With a traditional development pace, some of this wait time might still be manageable. But when the implementation itself suddenly becomes significantly faster, the balance shifts. A development team that could implement a feature within a few hours loses a significant portion of that speed advantage if it then has to wait several days for a business decision.

This raises a new question for us: Are not only our own processes, but also our customers, prepared for this type of development?

If you want to take full advantage of AI-powered software engineering, you need more than just a fast development team. Information must be available at short notice, technical questions must be answered promptly, and decisions must be made more quickly. This does not mean making decisions less carefully. Rather, it means structuring decision-making processes and assigning responsibilities in a way that keeps pace with the speed of development.

As a result, AI may also change the way clients and development partners collaborate during the development process. Short feedback loops and accessible subject-matter experts have always been integral to good agile development. In an AI-accelerated project, these are increasingly shifting from being an advantage to a prerequisite.

One of our most important insights from the Lighthouse is therefore this: The potential for acceleration doesn't end with coding. If we truly want to harness its potential, the entire project must learn to cope with this pace.

A second important finding concerns the role of the software engineer. Our experiment did not show that AI makes software engineers less important. Rather, the focus of their work is shifting.

Tasks that were previously considered peripheral to the actual implementation are gaining in importance. These include technical requirements management and software design—in particular, the sensible division of functionalities and responsibilities. Testing, verification, cybersecurity, and architecture are also becoming more important.

After all, AI can generate a solution very quickly. It can write code, assist with debugging, explain new technologies, and make suggestions for architecture. However, it can also recommend outdated libraries, overlook relevant context, or present a technically incorrect solution with great conviction. Furthermore, questions such as the licensing of components in use are not automatically answered reliably.

The core competency is thus shifting somewhat from the question “Can I program this myself?” to “Can I assess whether the resulting solution is correct, secure, maintainable, and suitable for its intended purpose?”

This still requires technical knowledge. Perhaps even more than before—just in different areas.

In our experience, for example, software engineers can very quickly familiarize themselves with new AI technology. At the same time, the less personal knowledge one has about a given topic, the more difficult it becomes to assess the quality of a response. AI therefore does not replace expertise. However, it can significantly accelerate the way we build and apply expertise.

Furthermore, good results don't automatically follow from simply providing a development team with a copilot. The past four weeks have also clearly demonstrated this.

Over the course of the experiment, the team learned to provide relevant context in a targeted manner, to formulate requirements and acceptance criteria as precisely as possible, to critically review results, and to use various models and tools for different tasks. The selection of the tools themselves also became part of the development work.

At BAYOOMED, we now want to make these insights available to a wider audience. Through training, low-threshold programs, shared best practices, and collaboration among colleagues, we aim to discover how AI can be meaningfully integrated into our development work.

Our goal is not simply to use as much AI as possible. What matters is using it where it provides a real advantage—while also recognizing its limitations.

Of course, Claude, GitHub Copilot, ChatGPT, and other AI assistants are, first and foremost, tools. Nevertheless, after our experiment, we are more convinced than ever that they will have a significant impact on software engineering.

For us, the key difference isn't just that software engineers can code faster. It's that the way they spend their time is changing. And as implementation speeds up, the processes and collaboration surrounding development will inevitably have to change as well.

You can view this in a positive or critical light. From our perspective, however, this trend cannot be ignored. That is why we want to continue to examine AI in the development process from a practical standpoint—especially in areas where it becomes challenging: in professional and regulated software projects.

For us, our AI Lighthouse was therefore less of a completed experiment and more of a starting point for the next set of questions.

We don’t want to address these questions solely through internal projects. That’s why we’re looking for clients who are willing to embark on additional Lighthouse projects with us—using small, agile teams, consistent use of AI, and short feedback and decision-making cycles.

We are particularly interested in projects in the medical field: companion apps, DTx, CDSS, and app-, web-, or cloud-based solutions. This could be a proof of concept, an MVP, or a feasibility study aimed at determining as quickly as possible whether and how an idea can be technically implemented. And, of course, this can also lead to the development of a medical device.

We are no longer just interested in how quickly we can develop software using AI. We want to find out how AI needs to be integrated into the development process so that this speed can be maintained even under real-world project conditions.

And if the next project also includes BLE connectivity, that would be particularly exciting. We have a hypothesis related to that which we'd like to test.

• AI in Medical Software Development – How we support manufacturers in the development, validation, and MDR-compliant approval of AI-powered medical devices.
• Companion Apps – Companion apps for therapies and medical devices.
• DTx – Digital therapeutics from concept to approval.