Three Levels for AI Agents: The Repo, the Company, and the Developer

Software Development

Code Review

Software Engineering

AI Agent

Three Levels for AI Agents: The Repo, the Company, and the Developer

Michael Kraft (mAsTEr of WhenShouldSystemEnd :D)

6 min read·

Oct 13, 2026

--

ai generated

Shared rules, personal expertise, and code reviews where we still learn from one another.

An agent reads a ticket, writes code, runs checks, and prepares a pull request. Much of this can be accelerated. But as soon as several developers work this way, another question arises: What experience still informs their decisions?

If everyone sends the same agent through the same tasks with the same rules, their solutions and reviews may resemble one another. That does not have to be a bad thing. Shared standards matter. Yet a team also needs the different questions that arise from different experiences.

In my day-to-day work, three levels have therefore proved useful for organizing guidelines and skills: the repository, the company, and the developer. Each level has its own location. And each describes knowledge with a different scope of applicability.

Shared rules should standardize collaboration without standardizing developers’ judgment.

My earlier article, “AI Will Not Replace Developers — But It Will Expose Weak Decisions”, was about who decides what should be built and which constraints matter. Here, I want to become more concrete: How do we organize this knowledge for agents without making the developers behind it invisible?

Level 1 lives in the repository of the respective app or service. It contains preferred components, code style, architectural decisions, and the particular characteristics of the system.

Applications that have evolved over time especially need more than a general instruction such as “use clean architecture.” Perhaps an older area follows a different pattern than a newer one. Perhaps a component is deliberately intended only for certain tasks. Perhaps a workaround looks unnecessary but protects an existing interface.

An agent needs to recognize where a rule applies and which exception is justified. Otherwise, it may produce a change that looks tidy on its own but fits poorly into the application.

Application knowledge belongs where its validity can be checked.

These rules can be versioned, discussed, and improved together. An architectural decision thereby gains a traceable origin. Anyone working on it later does not have to guess its reasoning again.

However, the repo does not describe every experience a developer brings. It records the knowledge that should apply collectively to this system.

Level 2 lives in a shared repository. It contains rules and workflows that apply to employees across projects: reading the ticket, identifying ambiguities, creating a plan, checking the work, preparing the branch and pull request, and reporting the result clearly back to the ticket.

This process does not have to be reinvented and maintained separately in every service. If, for example, the expected PR description is improved, the change can be discussed in a shared location and subsequently used in several projects.

What should apply collectively needs collective maintenance.

A central storage location alone is not enough, however. The agent must actually be able to find and use the rules. It also needs to remain traceable which version it worked with. A shared repository that nobody accesses does not standardize a workflow.

The levels are also not an automatic hierarchy for every conflict. In my approach, a personal preference should not silently override a binding project rule. Conversely, a general requirement needs to be able to accommodate justified application-specific characteristics. Contradictions should be made visible and resolved.

Level 3 lives privately under Home. It contains my clean-code practices, patterns, additional checks, and personal extensions to the workflow. Above all, it contains questions I ask because of my experience that an agent or colleague may not ask.

An individual pattern is rarely the distinguishing characteristic. What matters is when I apply it, which interactions I recognize, and when I deliberately depart from it.

Join Medium for free to get updates from this writer.

A change can look clean in the current service while making another service more dependent. A retry can handle a temporary failure or intensify an overload. A new cache can speed up access and raise new questions about data freshness. Such decisions require looking beyond the immediate area being modified.

The personal developer level describes which additional questions a developer asks — and which connections they recognize in doing so.

This expertise across domains is easily underestimated when only the finished diff is considered. The personal level gives me a place to express it for collaboration with the agent. It accompanies me across projects and does not have to be formulated from scratch for every ticket.

Private does not mean withholding professional insights. I can retain a personal review method and openly explain its findings in the review. If an insight proves useful for the application or the organization, it can be incorporated into the shared level.

My own rules must also remain open to change. A habit that has worked for years may be unsuitable for the next system. A developer’s value therefore also lies in applying their recorded experience critically.

ai generated

The Review: Where Different Experience Becomes Shared Knowledge

Every developer knows something different. One recognizes operational risks, another sees a problematic dependency, and a third questions the assumption behind the entire change. These differences should be allowed to surface in the review.

That reviews do more than find defects is well documented. Bacchelli and Bird observed, interviewed, and surveyed developers and managers and examined review comments. Their study of modern code review describes knowledge transfer, a better shared understanding of the work, and alternative solutions among its outcomes.

A code review should not only find defects. It should move knowledge between developers.

The personal developer level can support these differences. It does not guarantee them: Different files can contain the same ideas, and an agent can overlook additional guidance. What matters is whether developers check the results themselves and contribute their reasoning to the discussion.

A good comment therefore expresses more than a preference. Instead of “I would choose a different pattern,” a concrete question helps: “What happens to this process if the same request arrives twice?” We can then examine behavior, tests, and alternatives together.

Discussion needs a purpose, however. Not every matter of taste should hold up a change. Google’s review guidelines account for both the learning function and the need to make progress: Purely educational comments should be identifiable as nonmandatory; technical arguments matter more than personal preferences.

We can therefore distinguish between necessary corrections, justified alternatives, and comments intended for learning. This keeps technical discussion possible without turning every pull request into a debate over first principles.

Three levels alone do not save tokens. If every small task loads all rules and skills in full, we merely have three large texts instead of one.

My approach therefore needs a concise entry point: Which rules always apply? Which additional skills does this task require? Where are the details?

This on-demand loading also appears in Anthropic’s Agent Skills concept: Short descriptions first make the available skills discoverable. Detailed instructions and further resources are read when needed. This principle concerns the amount of context loaded; my three levels concern responsibility for that context.

We should load context selectively and also use the time saved to make better decisions.

A concrete process could look like this: The shared workflow guides the agent through the ticket. The repo rules determine implementation in the affected service. My personal review method adds, for example, questions about repeated operations, failure cases, and effects on other systems. During the review, a colleague asks another question that I have not yet considered.

This discussion can lead to a new test. Perhaps we also change a shared rule. Perhaps I only extend my personal review method. Knowledge has then moved through the levels instead of simply disappearing into a comment.

Agents can check suggestions and question assumptions. It does not follow that their review is complete or that responsibility for the decision has been settled. I still need to understand what I accept and be able to explain why.

The time AI saves during implementation should also create room to understand decisions together.

My goal is therefore a team in which shared rules apply reliably and different experiences remain visible. The agent helps me apply my knowledge. The review gives others an opportunity to question and expand it. In this way, faster implementation can be connected with learning together.