Project AEGIS — Our first steps

NB: This post is a 4-human-hands written one. You may notice some style and vocabulary differences. It’s the beauty of human brain 😉

AI is progressing fast

Until a few months ago, developers interacted with Large Language Models (LLMs) primarily through chat windows, copying and pasting code segments, or via contextual autocompletion limited to a few lines. This approach, while useful, remained fundamentally reactive. The arrival of Claude Code redefines this paradigm by introducing an actor capable of “living” in the terminal, autonomously navigating complex file architectures, executing diagnostics, and proposing architectural changes that extend far beyond simple syntax.

Arrival of Claude 4 in May 2025

We believe that most of the work is done by LLMs so using the right models can significantly improve the work being done. So far the Anthropic models are ahead in the race, especially for the coding tasks.

But the tool allowing the use of the LLMs can also have an impact, but this area we believe that it has fewer impacts than the LLM, still we identified some features we believed critical:

• Support AGENTS.md standard definition
• Support agents definition to have specialized behavior
• Sub agent support for implementing workflows
• Support Skills standard
• Support MPC servers (local and remote)

Benchmark we follow/make

In order to assess models and tools, we defined a very standard feature request from our work, which would consist in:

• Adding a field in Database, with Liquibase changeset
• Updating repositories to be able to query using the added field
• Adding a GraphQL query to be able to look for an entity based on the added field

Note: our backends are mainly in Java/Kotlin using the Spring Boot framework

We unleashed several configurations on this task for one particular Kotlin service, and requested the owner team to review the code produced.

Configurations used:

• Claude Code (default model)
• Opencode with Sonnet 4.5
• Vibe CLI with Devstral (Mistral ❤️🇫🇷)

First results

Our first results were not passing the reviews, the code was not following the company standards, not correct regarding some practices and was lacking tests. But most importantly, the build was not passing

Our testing project was obviously lacking a basic setup to allow Agentic coding, like an AGENTS.md file that would help agents discover the project stacks, conventions, architecture and so on. Plus, we included links to our internal documentation so that the agent can know how we expect it to do things as per our global practices at Manomano.

Results were immediate, and the overall quality was way better than on the first try.

This leads us to the conclusion that **context engineering** is a powerful tool in order to improve what our coding agents will produce. But it comes at the cost of rethinking how we used to organize and share practices in the company. So far most of our guidelines and ADR are living in our Confluence, with reviews and updates being done from time to time. Having coding agents fetching content from Confluence felt like a bad idea: it would force network calls, or have the Atlassian MCP all the time, HTML is not cost-effective token wise.

This is why we are starting our journey with a monorepo containing our guidelines and AI coding knowledge named mm-agents, but we will come back to this.

CLI Tools

We identified at this point that focusing on a single tool or model could be a bad decision in a few months (given how things are moving fast). So we decided to leverage only standards, and they are not many 😓 So far the one we identified are:

• AGENTS.md as main instruction file, symlinks for took specific files (ln -ls AGENTS.md CLAUDE.md)
• Skills as a mean to instruct how to do specific tasks
• Agents as a way to work with a very specific posture

This led us to marking the below as our go-to tools: Claude Code and OpenCode.

IDE

Most of our devs do not live in the terminal but in an IDE. At ManoMano there were 2 different groups of dev: those with VS Code (mostly frontend) and the ones with IntelliJ (Backend / JVM).

Most of the VSC users were comfortable switching to Cursor, for the other life is not that easy 😞

Indeed, AI tools in JetBrains IDEs are not very fast and do not comply with any standard for agentic coding. Making their inclusion in our strategy quite a challenge, but on the other hand, reviewing diffs is way easier to do in an IDE interface.

Claude code integration in JetBrains IDEs allows using Claude global configuration, but the balancing our strategy between Terminal and IDE is something we identified as a big topic.

Agnostic by nature

Anthropic’s recent blockade of subscription usage from third-party tools like OpenCode has shattered the assumption that model providers are neutral utilities, exposing the fragility of workflows built on proprietary endpoints.

We believe that relying on a single vendor constitutes a critical single point of failure, as optimizing for a specific model creates a dependency that leaves developers vulnerable to sudden operational paralysis.

While Anthropic’s models are currently ahead in the race, the ban illustrates that focusing on one tool is a bad idea when the underlying economics conflict with high-frequency agentic workflows. This leads us to the conclusion that we must pivot from Prompt Engineering to Context Engineering, treating the “context” — the structured curation of state and memory — as the primary asset rather than the model itself.

Agentic Coding Battle

By adopting standards and “Bring Your Own Key” architectures, we can decouple the application layer from the inference engine, ensuring we are not locked into a single ecosystem. We identified that this approach allows us to swap models seamlessly, leveraging local inference for speed or frontier models for reasoning, without losing the “wisdom” of the session.

This strategy transforms the agent into a “Sovereign Agent” that owns its memory and defines its own state, ensuring resilience against vendor policy changes.

Ultimately, being agnostic to the model and focusing on context engineering is way more interesting in the long run, as it secures our intellectual property and ensures our coding agents remain effective regardless of which provider dominates the market.

MM Agents

Our Tech Stack

Before jumping into the second part, we need to describe our Developers Tech Stack. As our components are developed using different languages (Java/Kotlin/Typescript/Python/PHP), there is no consensus on the IDE to use. Every developer is free to use his favorite IDE (and yes, neovim is an IDE).

We are using the Atlassian suite: JIRA for ticketing and project management, Confluence for non-technical documentation and wiki.

Our code versioning tool is Gitlab, and we are using Slack as an internal communication tool.

MCPs

Two MCPs emerged naturally, Atlassian and Gitlab.

Atlassian MCP connects your agent to the full internal documentation and ticket management. In some cases (ticket refinement), it’s very powerful to read related tickets in JIRA in addition to project context in Confluence. But Atlassian MCP is consuming a lot of tokens and is not very smart. We are thinking about developing skills or our own MCP, but in a second step.

About Gitlab and his usage through MCP, we will come back to it in a later post. Shortly, it give the agents super-visibility over code, last changes and technical documentation ; not only for the current project but for any related project 🚀

A last one we experiment and adopted is Serena. This one is a game changer for complex change/refactoring. Starting from the same prompt, Claude is unable to perform the change without failing tests (and he is giving up 🤯). However, Claude using Serena MCP is performing the task first try.

Context Engineering

But at some point, we discovered that generated code (by agents) was not accurate enough and not following our standards. So we took the decision to develop a common source of knowledge to improve output quality.

Before thinking about complex RAG, we tried with markdown files. As you may know, agentic tools are good to read instructions from MD files. So let me explain our ManoMano Agents Tooling.

Mm-agents

ManoMano Global Knowledge

We have a set of guidelines detailing rules for each technology/pattern. Idea is to put non-standard rules (like usage of PATCH in REST is forbidden). These are very specific rules, related to ManoMano ecosystem and LLM doesn’t have this knowledge, because documentation is private. So we need a way to enforce them during Agentic Coding.

Our approach was to take each Guideline and to transform it into a short and AI comprehensive markdown file. It’s easy to read for humans/agents, easy to deploy and maintain.

Example

In the guideline:

In the markdown rules file (no example and shorter):

APIR_DATA_1 — Dates with time MUST be exchanged using the specified RFC3339-like format.

We did it first manually with small guidelines, then prompt AI to transform massive ones. A last human check and the ManoMano Guidelines were available for AI Agents. We tested on various use cases, newly generated code was more accurate and agents were not creating original naming conventions. For newcomers in your company, it’s really important to explain rules and practices, so we applied the same idea to agents.

Skills/Commands

Then, we encounter another issue. Some tasks were identified as repetitive (like update a lib version across all your microservices), so we provided these sets of instructions to ease developer life.

Skills are folders of instructions, scripts, and resources that AI loads dynamically to improve performance on specialized tasks. Skills teach AI how to complete specific tasks in a repeatable way, whether that’s creating documents with your company’s brand guidelines, analyzing data using your organization’s specific workflows, or automating personal tasks.

We first worked on some architectural patterns, then coding practices and we integrated progressively all the infra technologies we use (liquibase migration, kafka consumption, …)

We even have a skill to create other skill following good practices #inception.

We also created some commands (to trigger specifically a task) but commands were merged into skills (when we said agentic coding is going fast), so we adapted.

Agents

In some particular cases, you want to delegate work to a specialized agent, to produce better result or to work in parallel. Difference between skill and agent is subtil, but agent is more a specialized brain where skill is a tool to use when you need it.

We started with some simple agent like a reviewer one, or a specialized java developer. We also tried some agentic workflows like :

• launching multiple agents doing the same task to elect the best result => very costly
• splitting a complex task in multiple done by subagents => not better than plan mode + todo tasks
• parallelizing same tasks across different parts of the system => really efficient in some cases

Claude Code Agent Teams is opening a new world of teams working on a complex topic and we need more time to explore all the possibilities.

How to deploy

We choose to deploy this mm-agents repository in all developers workstations. First by asking developers to pull the project, then by providing it into our internal CLI tool (ezmm) by default. Project should be installed into home directory, one of the only common place between Mac and Linux ~/mm-agents

Installation of skills/agents is done automatically by creating symlinks in proper tools configuration folders (.claude/ and .config/opencode).

Skills and agents are automatically referring appropriates rules. For projects, we ask developers to manually refer rules that apply from their AGENTS.md

### Global Rules to Follow

* [Global JVM rules](~/mm-agents/rules/jvm/README.md) - JVM project standards and best practices
* [Observability rules](~/mm-agents/rules/observability/README.md) - Observability Guidelines
* [REST rules](~/mm-agents/rules/rest/README.md) - ManoMano REST API Standards
* [Kafka rules](~/mm-agents/rules/kafka/overview.md) - Guidelines for using Kafka at ManoMano

How to ensure quality

We test all our tools internally in the team, by checking performance, cost and output quality with and without the tool. Once we are happy with the result, we publish it and ask for first feedbacks.

Most of the times, the first testers provide small bugs and improvement ideas. We iterate and achieve a “production ready” level.

We don’t have yet a recurrent review in place, updating the tools and documentation regarding the news from Agentic world.

Innersource

We always wanted this repository to be open to contribution. So once the project was shared, people started to complete the skills/agents, always under our validation :

• should be a common practice
• should be validated with real use cases/prompts
• should be reviewed manually

Results

We reached today this numbers

• 26 Skills — Reusable capabilities for backend, frontend, infrastructure, and workflows
• 4 Agents — Specialized AI personas (Backend architect, Java expert, Reviewer, Tech refinement, …)
• 100+ Rules — Technology-specific guidelines (Kafka, Spring Boot, React, PostgreSQL, etc.)

We tested mm-agents in our teams in multiple cases and the results were stunning. Accurate code generation, no more original pattern usage, a better link with infrastructure. It’s now a requirement to develop any peace of code in ManoMano ecosystem.

Conclusion

We explained in this post our two first big steps into agentic coding at ManoMano. Choosing the best reasoning and coding models while thinking the near future can bring new ones. Choosing as first, a generic open-source terminal tool to follow the drama with Anthropic and come back to Claude Code. Then, everything we built around providing more ManoMano knowledge into the agents' context to produce better results, following our way of doing things. Finally, providing to everyone some accelerators like skills and subagents to quickly leverage agentic coding in their day-to-day developer life.

Next time, we will speak about our first teams onboarded, their feedbacks and how we extend tooling and documentation to more than coding.