DEV Community

Cover image for When Your Company Gives You a Chatbot, but Not a Coding Agent
Dechun Wang
Dechun Wang

Posted on

When Your Company Gives You a Chatbot, but Not a Coding Agent

At work, we have access to AI chatbots, but not coding agents.

This sounds like a small difference until you try to use one for a ticket that spans several repositories.

ChatGPT, Claude, Microsoft 365 Copilot — they are already pretty good at reasoning about code.

The problem is that they only know the code you give them.

So a conversation can quickly turn into this:

Where is this event consumed?

I search the repos and paste the code.

Can you show me the callers?

I search again.

What tests cover this?

Another search.

Is there any related config or Git history?

And at that point I'm basically doing the codebase investigation for the AI.

That is the problem behind Project Brain.

The basic idea

I wanted to see how much of the investigation experience of a coding agent I could bring to a normal chatbot, without giving the chatbot direct control of my repositories.

Project Brain sits between the chat and the local codebase.

The chatbot can ask for more context. Project Brain retrieves that context locally. I bring the evidence back into the conversation.

The loop looks roughly like this:

Ticket + docs ↔ Chat AI ↔ you
                 │
                 ├── human/runtime question → answer directly
                 ├── CONTEXT_REQUEST → Project Brain → source evidence
                 └── enough evidence → implementation plan
Enter fullscreen mode Exit fullscreen mode

The useful part is that I no longer have to guess every relevant file upfront.

The chatbot can decide what it still needs.

That might be:

  • a symbol definition;
  • callers;
  • implementations;
  • related tests;
  • configuration;
  • Git history;
  • a complete file;
  • or something in another repository.

Project Brain retrieves the evidence and gives it back to the chat.

Why multi-repo matters

A lot of the tickets I deal with do not live neatly inside one repository.

A change might involve something like:

payment-service
customer-service
eligibility-service
notification-service
...
Enter fullscreen mode Exit fullscreen mode

One service publishes an event. Another consumes it. A third owns the actual business logic. Tests may live somewhere else again.

That is where a normal chatbot becomes awkward.

It can reason about the code perfectly well once it sees it, but somebody still has to find the right code first.

Project Brain was designed around that problem from the beginning.

It can search across repositories and retrieve source, callers, tests, config, Git history, and cross-repo relationships.

The goal is not to dump ten repositories into one huge prompt.

It is to find the next useful piece of evidence.

A small example

Imagine a ticket saying:

A customer jurisdiction change sometimes fails to update trading eligibility.

The chatbot might need to know:

  1. where the jurisdiction-change event is produced and consumed;
  2. what calls the eligibility recalculation logic;
  3. which tests cover the flow;
  4. whether configuration changes the behaviour;
  5. whether something similar was changed before.

Instead of me manually finding all of that, the chatbot can return a structured request:

CONTEXT_REQUEST:
  version: 1
  objective: >
    Understand how a jurisdiction change reaches eligibility recalculation.

  searches:
    - query: "JURISDICTION_CHANGED"
      repos: []

  symbols:
    - name: "TradingEligibilityService.recalculate"
      repos: [trading-service]
      include:
        - definition
        - callers
        - implementations
        - tests

  history:
    - query: "JURISDICTION_CHANGED"
      repos: [trading-service]
Enter fullscreen mode Exit fullscreen mode

Project Brain turns that into local retrieval work and returns the relevant evidence.

The chatbot can then reason again.

If it still needs something, it asks for another round.

If it has enough context, it can produce an implementation plan.

That back-and-forth investigation loop is the part I was missing most from coding agents.

Why keep it local and read-only?

Because the environment is the whole reason this project exists.

If I could install any coding agent I wanted, give it repository access, connect arbitrary tools, and let it operate directly on the workspace, I probably would not need Project Brain.

But company environments are often more restricted than that.

Sometimes you get an approved chatbot.

That's it.

So Project Brain keeps a deliberately narrow boundary:

  • repository investigation happens locally;
  • target repositories are treated as read-only;
  • there is no hosted code index;
  • the normal workflow does not require a model API key;
  • the chatbot does the reasoning;
  • Project Brain does the retrieval.

I actually like that separation.

The AI does not need control of the workspace just to understand what I'm talking about.

Why not just use MCP?

This is the obvious question.

If your company allows MCP or similar integrations, then yes — connecting the chatbot directly to Project Brain would make the whole thing much smoother.

The chatbot could call the retrieval tools itself and most of the copying between the two sides could disappear.

But the people I had in mind when I started this often do not have that option either.

Sometimes the only thing available is a chat window.

No coding agent. No direct repository integration. No custom tools connected to the model.

So the slightly manual workflow is not really an accident. It is what makes the same idea usable in a restricted environment.

The chatbot does the reasoning. Project Brain investigates the codebase. I stay in the middle and decide what crosses that boundary.

If MCP becomes available, the same retrieval layer can become much more seamless.

If it does not, the current workflow still works.

Where it is today

There are still plenty of things I want to improve.

Retrieval can get better. Some investigations can take fewer steps. Cross-repo relationships can be stronger. The handoff between the chatbot and Project Brain can be smoother.

But I do not want to turn it into a coding agent just for the sake of saying it is one.

The original constraint is still useful:

help the chatbot understand the codebase without giving it control of the codebase.

That is where I want to keep the project focused for now.

Try it

Project Brain is open source and MIT licensed:

GitHub: https://github.com/superorange0707/project-brain

There is also a demo workflow in the repository, so you can try the multi-repo investigation loop without pointing it at your own work code.

If you're in the same chatbot-but-no-coding-agent situation, I'd be interested to hear how you're dealing with it.

Top comments (0)