In February, we began developing ITM InMind, an internal business application whose entire code was written by AI agents. Five months later, it is up and running and is used daily throughout the company. A central platform emerged from three specific requirements. The project has shown us what AI-powered software development is capable of and where human input remains indispensable.
Why We Developed InMind
Three issues came together for us. Our asset management software had been discontinued by the vendor and needed to be replaced. At the same time, we wanted to improve our customer management, and our internal tools for SAP LeanIX had become so useful that we needed to make them available to our colleagues centrally. Each issue could have been resolved individually. Together, they made a case for a centralized platform.
We evaluated numerous commercial products for asset management and CRM. The systems were powerful, but were designed for organizations with significantly greater requirements. The costs and complexity were correspondingly high. For a company of our size, the price was not commensurate with the benefits. The tools for SAP LeanIX also needed a secure, centralized location. That’s why we opted for a single platform covering all three areas, rather than licensing two systems and developing a third tool separately.
That doesn’t mean we’re bundling three independent products into a single codebase. Customer management, asset management, and SAP LeanIX tools remain separate modules with their own data models and user groups. What they share is the technical foundation: authentication and role management, logging, notifications, backups, and controlled releases. InMind provides this foundation once. Each use case runs on it as a separate module. The modules share the platform, not the business logic.
Today, InMind supports our customer management—an asset management system integrated with our mobile device management—and operates our internal tools for SAP LeanIX.
So far, there have been 902 commits, and not a single one of them was made by a human developer.
As of the writing of this article, the repository contains 902 commits. Not a single one was written by a developer. The AI agents wrote all of the code. However, that does not mean the work was done without any human involvement. Our developers set the direction, specify the work, review the results, and test each module before our colleagues rely on it.
Vibe Coding or AI-Driven Development?
Vibe Coding describes a specific way of working: You specify the desired result to a model, accept the generated code without thorough verification, and iterate until the result looks right. This can be useful for prototypes, one-off scripts, and experiments. However, for a system that processes corporate data, supports day-to-day operations, and is subject to information security audits, this approach was out of the question for us.
Before the agents wrote a single line of code, we defined clear use cases and documented functional and non-functional requirements. These requirements determine what the application must be able to do and what standards it must meet in terms of security, performance, and maintainability. For every major feature, we take a specification-driven approach: user stories, requirements, and edge cases are worked out before implementation. The agents develop the code based on these specifications rather than following a simple prompt.
AI wrote every single line of code. However, the development work surrounding it remained traditional software development. This difference became more significant as InMind became part of our daily work routine.
When a Tool Becomes the Digital Backbone
The first modules confirmed the promise of AI-driven development. A focused application with a limited scope could be implemented quickly. The more important lesson came later, as we further developed and expanded the modules and integrated their functions into our daily work. Our TISAX requirements demand comprehensive role-based access controls. In addition, we needed traceable evidence in the form of logs, controlled releases, backups, and documented reviews.
These aren’t just additional tasks on top of the product. They change the product itself. A new feature can’t just work on its own. It must take permissions into account, trigger the appropriate notifications, be properly logged, be integrated into backup and recovery processes, and remain compatible with all existing modules. With each additional dependency, tasks that initially seemed manageable became significantly more challenging. Today, our AI agents often need twice as long—and in some cases, nearly three times as long—to implement a new feature.
What We've Learned
- Start with a clear architecture and make it binding. Before implementing the first feature, we defined the software architecture and the technology stack—partly on our own and partly in collaboration with the AI agents. We documented these decisions and treated them as binding. This keeps the foundation stable, even as the scope of features grows. Without this framework, each new session could introduce additional patterns, and the codebase would gradually lose its structure.
- Implement key fundamentals correctly from the start. InMind enforces role-based access control across all modules and data fields. Our initial implementation appeared to be complete. However, gaps emerged in later development cycles and were difficult to identify and fix. Access control, notifications, backups, and logging affect every module. Integrating them retroactively is significantly more time-consuming than designing them correctly from the start.
- Developing larger features in a specification-driven manner. For more complex features, we use specification-driven methods and tools such as Spec-Kit. This approach requires a great deal of planning and documentation. In return, user stories, requirements, and edge cases become apparent before implementation, rather than only after they have already caused a problem.
- We have tests generated based on requirements, not on the code. We use detailed functional specifications to generate unit, integration, and end-to-end tests. These tests verify the expected behavior rather than what the code is currently doing. The agents use these tests to find and correct their own errors locally before the CI/CD pipeline fails. InMind now has over 2,000 test cases. They’re effective, but they take time: a full run of the test suite takes about four minutes. If errors are found, the agents often run the tests multiple times until everything is fixed.
- Never accept generated code without reviewing it. For the development of InMind, we used the latest models from Anthropic and OpenAI. Minor errors still occur frequently. Our code reviews show that roughly one in three commits contained a logic error or a security issue, such as with the enforcement of role-based access control. That’s why we automatically check every commit, and our developers test and validate the code before it is deployed to the development environment. This takes time and computing power, but it protects our systems from “AI slop.”
- When it comes to compliance, it doesn’t matter who wrote the code. We are TISAX-certified and must be able to demonstrate that our development process is controlled. This includes documented security requirements, traceable changes, evidence of tests and reviews, and organized releases. AI-generated code does not change this requirement. On the contrary: review logs, test results, and a complete change history are crucial for demonstrating human oversight.
The question raised by this experience
For us, developing InMind was the right decision. The platform addresses the use cases that were the deciding factor for the project and provides a secure environment for our internal SAP LeanIX tools. In terms of operation, maintenance, and further development, InMind is more cost-effective in the long run than commercial licenses for all users. In addition, we can expand specific functions at any time and tailor them to our needs.
Based on this experience, a natural question arose during conversations with several customers: Could they develop their own EA tool using AI, rather than licensing a commercial platform? Our experience with InMind shapes our answer, which we’ve outlined in a separate article: Should You Develop Your Own EA Tool?
If you're considering AI-powered development for your own internal application, we'd be happy to share our experiences in detail—including the parts that didn't go smoothly. Get in touch with us.