From Jira tickets to code reviews: how EIKONA Logistics uses AI
AI drafts texts, designs images, writes programmes, analyses data and has long been supporting work across a wide variety of professions. But how do those who develop the software themselves actually work with AI? How much do they leave to the models, and at what points is human input still required?
At EIKONA Logistics, AI is not just an additional tool that developers consult only occasionally. It is integrated throughout the entire development process: from project planning, through the analysis of a Jira ticket and programming, right through to code review. Specialised agents, various models and people work together in multiple testing and feedback loops. People do not hand over responsibility under any circumstances. However, their role in the development process is constantly evolving.
From customer consultation to merging: how AI changes the workflow
The use of AI does not begin with programming. For agents to work effectively, requirements must be clearly defined at an early stage and decisions must be documented in a way that is easy to follow. The current workflow can be broadly divided into five stages:
- Defining requirements
The process still begins with the customer’s requirement, which is recorded by project management. The associated tickets must be formulated as precisely as possible: the speed and number of issues that developers work on simultaneously have increased significantly as a result of AI’s use. Missing information, requests for further details and decisions that have not yet been made slow the process down. AI therefore provides support early on in the project by highlighting outstanding issues or unclear information. - Analysing a ticket and planning a solution
The developer instructs the AI to search for a ticket in Jira. It retrieves the task, analyses the available information and highlights any outstanding issues. It then develops a solution plan based on this analysis. Prior to implementation, the developer reviews this plan and approves the next steps. - Multiple agents work on a task
There are specialised agents for various subject areas, including architecture, planning, programming and testing. Depending on the task, different models may be used. An orchestrator agent coordinates collaboration in the background. This allows a developer to manage several agent-based tasks simultaneously – a significant difference from the pre-AI process, where they usually worked through individual tickets one after the other. - Check, correct, check again
The resulting code is not simply accepted. Before a merge, it is checked by a dedicated AI system specialising in code reviews. Its feedback is sent back to the agents involved, who assess it and make changes where necessary. The review then starts again. This cycle is repeated until there remain no outstanding relevant issues. - Human decision-making
Ultimately, there remains a clear boundary: the merge into the shared codebase is carried out by a human. At EIKONA, the AI is not permitted to trigger deployments independently, even though this would be technically possible. This safeguard is in place deliberately: it is up to a real person to decide when a change is to be incorporated and made available for the next project stages or for deployment. Ultimately, the developer remains responsible for ensuring that the code is secure, functional and meets quality requirements.
The more work AI takes on in the process, the more important it becomes to establish clear guidelines from the outset. AI can speed up individual steps, but it cannot simply compensate for missing decisions or incomplete requirements.
Output-versus-outcome-oriented prompting: goals and context instead of detailed specifications
With the latest AI models, the way developers work with them has also changed. Instead of specifying in detail how a task is to be carried out technically (output-oriented), developers now primarily describe the desired goal (outcome-oriented). This gives the AI greater freedom in its implementation. It largely decides for itself which technical steps to take.
For this to work, however, it requires significantly more background knowledge. Software that has evolved over many years comprises millions of lines of code, numerous modules and complex dependencies. Even the latest state-of-the-art models struggle to get a grasp of the entire codebase. Above all, they lack historical context: what has already been tried? Why was something built in a particular way? What needs to be taken into account for a specific client? Some of this knowledge is not fully captured in the code or in documentation, but resides in the developers’ minds.
To make this knowledge available in digital form, EIKONA has developed its own tools and defined skills and instructions for the AI. Static information such as coding guidelines, syntax rules or architectural decisions is stored directly in the repositories. Changes to the code and project-specific knowledge are also stored in a vector database operated centrally in the company’s own data centre, where they remain available to the AI for future development tasks.
When the AI modifies code, the documentation is also part of the process. It describes what has been changed and references the relevant sections, such as methods or classes. This information is automatically transferred to the vector database. The AI also creates the documentation for each commit as a matter of course. A human then checks whether the details are correct.
This not only reduces the amount of context that developers have to provide anew for each task. The AI can search for existing knowledge in a more targeted manner, rather than having to process large amounts of code and information from scratch every time, thereby saving tokens.
Hosting your own AI models? It’s all about the right combination.
When it comes to demanding programming tasks in particular, the most powerful external models are required. However, EIKONA also runs its own models in its data centre. These are specifically used in situations where data protection is of particular importance and requires complete control over the server environment.
At the same time, self-hosted AI is limited by the available hardware and must therefore be planned for the long term. Rather than taking an ‘either/or’ approach, EIKONA utilises different models and operating modes depending on the task at hand.
Who decides which tools are used?
EIKONA Logistics has set up an AI task force dedicated to keeping track of all the latest developments in the world of AI. The task force deliberately brings together people with different levels of experience and attitudes towards AI – ranging from the rather sceptical to those who are very keen to experiment.
The guiding principle is this: new tools must not simply be adopted just because they are interesting. The final decision on this currently rests with Sebastian Kremer, Head of Development & Operations. Before any tool is put into productive use, factors such as legal issues, data protection, data location, providers and the models used are all taken into account.
In this regard, the company deliberately prioritises flexibility. Annual subscriptions for AI tools are currently being avoided, as offerings, models and interfaces can change significantly within a matter of months. A tool that works well today may function differently after an update, or a preferred model may be withdrawn by the provider.
New technologies, new processes: Good AI development does not start with the code
The changes that AI brings to software development extend far beyond writing code. What matters is not only what a model is technically capable of, but also how well the development process surrounding it works. AI needs the right context, access to existing knowledge and clear rules governing which tasks it undertakes.
That is why limits are deliberately set. Deployments are not triggered autonomously by the AI; the developer decides on the merge and remains ultimately responsible for the code. Forward thinking is also something humans excel at: Which requirements will become important later on? Which architectural decisions must not be compromised? This knowledge and this responsibility cannot simply be handed over to a model.
The current development process is therefore not a final end state. Models, tools and working methods are changing far too quickly for that. What is crucial for us is to keep our own process flexible enough that we can try out and integrate new possibilities at any time. In doing so, we do not relinquish control, knowledge or responsibility.
