In February, we started building ITM InMind, an internal business application in which every line of code has been written by AI agents. Five months later, it is in production and used across our company every day. The project began as a practical response to three separate operational needs. It became a lesson in what AI can accelerate, and what it cannot take out of software engineering.
Why we built our platform InMind
Three internal projects became relevant at the same time. Our asset management software was being retired by its manufacturer and required replacement. We also looked at better ways to manage our customer relationships. And finally, our internal SAP LeanIX tools had become so useful that we needed a central place to host them for our colleagues. Each of these could have been solved on its own. Together they made the case for one platform.
For asset management and CRM, we looked at numerous commercial products. All were capable systems, but they were built for organisations with far broader needs than ours, and their cost and complexity reflect that. For a company of our size, the price did not match the value. The SAP LeanIX tools needed a secure home in any case. So rather than buy two systems and building a third tool on the side, we decided to build one platform for all three.
That does not mean three unrelated products in one codebase. Customer management, asset management and EA tooling are separate domains with their own data models and their own users. What they have in common is everything around the business logic: authentication and roles, audit logging, notifications, backups and controlled releases. InMind provides that foundation once, and each use case runs on it as a separate module. They share the platform, not each other's logic.
Today, InMind covers our customer relationship management, an asset management system that is integrated with our mobile device management, and our internal SAP LeanIX tools.
902 commits so far, and not a single one was authored by one of our human developers.
At the time of writing, the repository holds 902 commits, none authored by a human developer. AI agents wrote every line, but that does not mean the work happened without human engineering. Our developers define the direction, specify the work, review the results and test every module before colleagues rely on it.
Vibe coding or AI-assisted development?
The term vibe coding describes a particular mode of work: tell a model what you want, accept the output without closely reading the code, and iterate until the result feels right. That can be useful for prototypes, one-off scripts and exploration. It was not an appropriate method for a system that would handle company data, support day-to-day work and be subject to our security requirements and information security audits.
Before the agents wrote the first line of code, we developed clear use cases and documented functional and non-functional requirements. They define both what the application must do and what it must guarantee in security, performance and maintainability. For every major feature, we have followed specification-driven development practices: user stories, requirements and edge cases are worked out before implementation begins, and the agents build against that specification rather than a loose prompt.
AI wrote every single line of code, but the process around those lines remained software engineering. That distinction mattered more, not less, as InMind was integrated into our day-to-day work.
When a tool becomes the digital backbone
The first modules confirmed the promise of AI-assisted development. A focused application with a limited scope was straightforward to build, and progress was fast. The more consequential lesson emerged as we continued developing, improving and maturing the different modules and integrating their features into our daily work. Our TISAX requirements meant that the application needed comprehensive role-based access control and reliable evidence through audit logs, controlled releases, backups and documented reviews.
Those capabilities are not overhead added beside the product; they change the product itself. A new feature can no longer work only in isolation. It must respect permissions, trigger the appropriate notifications, appear correctly in audit logs, survive backup and restore procedures, and remain compatible with every existing module. As those dependencies accumulated, tasks that had initially seemed straightforward became much more demanding. Our coding agents now often need twice, and sometimes nearly three times, as long to complete a feature.
What we learned
- Start with a clear architecture and make it binding. Before building the first feature, we chose the software architecture and technology stack, partly ourselves and partly with the coding agents. We documented those decisions and treated them as binding. This provides a stable foundation as the scope grows; without it, each session risks introducing new patterns and the codebase gradually losing its structure.
- Build cross-cutting capabilities properly while the system is still small. InMind enforces role-based access control across all modules and data fields. Our first implementation appeared complete, but gaps surfaced in later development cycles and were difficult to trace and fix. Access control, notifications, backups and audit logging affect every module, so retrofitting them is far more expensive than correctly designing for them from the beginning.
- Use specification-driven development for larger features. For substantial features, we use specification-driven practices with tools such as Spec-Kit. This requires considerable planning and documentation, but it brings user stories, requirements and edge cases into view before implementation, rather than after they have become a problem.
- Let the agents write tests against the requirements, not against the code. We generate unit, integration and end-to-end tests from detailed feature descriptions, so they encode expected behaviour rather than whatever the code currently does. The agents use these tests to find and correct their own mistakes locally before the CI/CD pipeline fails. InMind now has more than 2,000 test cases. They are effective, but they affect speed: a full run of the test suite takes about four minutes, and when mistakes are caught, agents tend to run them multiple times until everything is fixed.
- Do not trust generated code without review. We built InMind with current frontier models from both Anthropic and OpenAI. Small bugs remain common, and our code reviews show that roughly every third commit contained a more significant logic error or security issue, for example in the enforcement of access control. We therefore run automated code reviews on every commit, and our developers test and validate the code before allowing it to be merged into our development environment. This takes time and requires computing resources, but protects our systems from AI slop.
- Compliance does not care who wrote the code. We are TISAX certified and must demonstrate that our development process is controlled. That requires documented security requirements, traceable changes, evidence of testing and review, and orderly releases. AI-generated code does not change this obligation. If anything, it increases the need for review records, test results and a complete change history that demonstrates human oversight.
The question this experience raises
For us, building InMind was the right decision. It covers the use cases that prompted the project, gives our SAP LeanIX tools a secure shared home, and costs less to operate, maintain and develop in the long term than licensing the commercial systems for every colleague who would need access. It also gives us the flexibility to adjust, add and improve features so that they are tailored precisely to our needs.
That experience has led to a related question in conversations with several customers: could they use AI to build their own EA tool instead of licensing a commercial platform? Our experience with InMind informs our answer, which we have written up separately in Should you develop your own EA tool?
If you are considering AI-assisted development for an internal application of your own, we are happy to share our experience in more detail, including the parts that did not go smoothly. Talk to us.