In February, we began developing ITM InMind, an internal business application in which every line of code was written by AI agents. Five months later, it is in production and is used throughout our company every day. The project began as a practical response to three distinct operational needs. It became a lesson in what AI can accelerate—and what it cannot replace in software engineering.
Why We Built Our InMind Platform
Three internal projects came to the forefront at the same time. Our asset management software was being phased out by its manufacturer and needed to be replaced. We were also looking for better ways to manage our customer relationships. And finally, our internal SAP LeanIX tools had become so useful that we needed a central location to host them for our colleagues. Each of these issues could have been addressed individually. Together, they made the case for a single platform.
For asset management and CRM, we evaluated numerous commercial products. All were capable systems, but they were designed for organizations with far broader needs than ours, and their cost and complexity reflected that. For a company of our size, the price did not justify the value. The SAP LeanIX tools needed a secure home anyway. So rather than purchasing two systems and developing a third tool on the side, we decided to build a single platform for all three.
That does not mean three unrelated products in a single 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 related to 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 written by one of our human developers.
As of this writing, the repository contains 902 commits, none of which were authored by a human developer. AI agents wrote every line of code, but that does not mean the work was done without human oversight. Our developers set the direction, specify the tasks, 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 way of working: tell a model what you want, accept the output without closely reading the code, and iterate until the result feels right. This can be useful for prototypes, one-off scripts, and exploration. However, 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. These requirements define both what the application must do and what it must guarantee in terms of 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 vague prompt.
AI wrote every single line of code, but the process surrounding 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 rapid. The more significant lesson emerged as we continued to develop, improve, and refine the various modules and integrate 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.
These capabilities are not simply added on top of the product; they change the product itself. A new feature can no longer function 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 these dependencies accumulated, tasks that had initially seemed straightforward became much more demanding. Our developers 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 on our own and partly in collaboration with the developers. We documented those decisions and treated them as binding. This provides a stable foundation as the scope expands; without it, each session risks introducing new patterns, and the codebase gradually loses 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 initial implementation appeared complete, but gaps emerged 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 designing for them correctly from the start.
- 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 to light before implementation, rather than after they have become a problem.
- Let the agents write tests based on the requirements, not the code. We generate unit, integration, and end-to-end tests from detailed feature descriptions, so they specify expected behavior rather than what 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 slow things down: a full run of the test suite takes about four minutes, and when errors are detected, agents tend to run the tests multiple times until everything is fixed.
- Do not trust generated code without reviewing it. We built InMind using the latest state-of-the-art models from both Anthropic and OpenAI. Minor bugs remain common, and our code reviews show that roughly one in three commits 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 it protects our systems from AI slop.
- Compliance doesn't care who wrote the code. We are TISAX-certified and must demonstrate that our development process is controlled. This 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 addresses the use cases that prompted the project, provides our SAP LeanIX tools with a secure shared platform, and is less expensive to operate, maintain, and develop in the long term than licensing commercial systems for every employee who needs access. It also gives us the flexibility to adjust, add, and improve features so that they are precisely tailored 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 outlined separately in "Should You Develop Your Own EA Tool?"
If you're considering AI-assisted development for your own internal application, we'd be happy to share our experience in more detail—including the parts that didn't go as planned. Get in touch with us.