AUBI - Autonomous Understanding and Behavior Inference

AUBI gives every employee an AI agent that learns their work context. When issues arise, teams just tag each other's agents instead of scheduling meetings. When someone leaves, their knowledge stays.

Comment 1

AUBI - Autonomous Understanding and Behaviour Inference

A context layer for autonomous software engineering.

AUBI gives every developer a persistent AI coworker that understands ownership, remembers team context, coordinates with other coworkers, and turns GitHub issues into human-approved pull requests.

Inspiration

Most AI coding tools start too late.

They ask:

What code should I edit?

But real software teams usually solve a different problem first:

Who understands this part of the system, what has the team already learned, and what context should guide the fix?

On an engineering team, a strong developer does not only read the file that failed. They also know who owns the area, who recently changed related code, what similar incidents happened before, which edge cases matter, and what should be checked before opening a PR.

That knowledge usually lives across people, commits, pull requests, issues, and team memory. A normal coding agent does not have that layer.

AUBI was built to make that missing context layer explicit.

Instead of treating every issue like a fresh prompt, AUBI treats software development like a team-memory problem. Every developer gets a persistent AI coworker backed by a Context Constitution - a living profile of ownership, expertise, collaboration style, current focus, known issues, and resolved incidents.

What it does

AUBI turns a live GitHub issue into a context-aware, human-approved pull request.

GitHub Issue
  -> Understand the incident
  -> Route to the right developer's AUBI coworker
  -> Ask related coworker AUBIs for context
  -> Retrieve shared team memory
  -> Read live repository files
  -> Generate a patch
  -> Run verification
  -> Wait for human approval
  -> Open a GitHub PR
  -> Write the outcome back into memory

The important part is not just that AUBI generates code. The important part is that it can explain the full chain:

Why this owner was selected
What team memory was used
Which coworkers contributed context
What risks and checks were considered
What code changed
Whether verification passed
What was learned for next time

Core workflow

Phase What AUBI does Why it matters
Understand Reads the GitHub issue and extracts affected files, service area, error type, and risk signals. Prevents the system from patching before it understands the problem.
Route Uses Qdrant memory and file ownership evidence to choose the most relevant coworker AUBI. Gets the right developer context into the run.
Exchange Asks adjacent coworker AUBIs for related context, prior incidents, and checks. Recreates how real teams solve issues by sharing context.
Read Fetches live files from the target GitHub repository. Grounds the fix in the actual codebase.
Fix Generates a patch using the issue, source files, owner memory, and coworker context. Makes the patch team-aware instead of prompt-only.
Verify Applies generated files in a temporary checkout and runs tests where supported. Keeps the demo tied to executable behavior.
Approve Pauses before PR creation until a human approves. Keeps developers in control of repository writes.
Learn Stores the resolved episode back into user and team memory. Makes future issues smarter.

The technical core: AUBI's context layer

The main thing we built is not only an agent that writes code. We built a context layer that sits between the team and the coding agent.

                 +-----------------------------+
                 |      GitHub Issue           |
                 +--------------+--------------+
                                |
                                v
                 +-----------------------------+
                 |   AUBI Context Layer        |
                 |                             |
                 |  - Context Constitutions    |
                 |  - Qdrant semantic memory   |
                 |  - Ownership routing        |
                 |  - Coworker exchange        |
                 |  - Should-check constraints |
                 +--------------+--------------+
                                |
                                v
                 +-----------------------------+
                 | LangGraph Issue-to-PR Flow  |
                 +--------------+--------------+
                                |
             +------------------+------------------+
             v                                     v
   +--------------------+              +----------------------+
   | GitHub PR + tests  |              | Memory writeback     |
   +--------------------+              +----------------------+

Context Constitution

Every AUBI coworker has a Context Constitution.

This is structured memory inferred from GitHub activity and updated after completed work.

Memory block Meaning
Code ownership Files, directories, services, and systems the developer appears to own.
Expertise Languages, frameworks, APIs, and technical domains inferred from commits and PRs.
Collaboration style How that developer tends to work, verify, and coordinate.
Current focus Areas of recent activity.
Known issues Risks or recurring problems tied to that developer's area.
Episodes Resolved incidents and PR outcomes remembered for future runs.

Example constitution fact:

{
  "subject": "Vitthal-Agarwal",
  "predicate": "owns",
  "object": "auth/ directory and auth/token.go in Neilyoo98/AUBI-demo",
  "category": "code_ownership",
  "confidence": 0.92
}

These facts are stored in Qdrant with metadata such as tenant, team, user, scope, category, and predicate so AUBI can retrieve the right memory for the right issue.

How the coworker mesh communicates

AUBI does not use one generic bot to hallucinate context. It creates a mesh of persistent AI coworkers.

Example:

AUBI Orchestrator
  -> asks Vitthal-AUBI:
     "Is this health endpoint issue in your domain?"

Vitthal-AUBI
  -> answers with backend ownership context and initial checks.

Vitthal-AUBI
  -> asks Neilyoo98-AUBI:
     "Do you have adjacent memory from a similar backend issue?"

Neilyoo98-AUBI
  -> retrieves shared team memory from Qdrant.

Neilyoo98-AUBI
  -> returns prior risks, verification advice, and should-check items.

AUBI Orchestrator
  -> reads the relevant source files and generates the patch using that context.

Each coworker exchange contains:

Field What it shows
Requester Which AUBI asked for help.
Responder Which coworker AUBI answered.
Reason Why that coworker was selected.
Selection signals Ownership, expertise, current focus, known issues, collaboration, or shared-memory overlap.
Context shared The useful reasoning or memory passed between coworkers.
Should-check items Constraints that the generated fix should satisfy.
Shared memory hits Evidence that the answer came from persistent team memory, not only the current prompt.

This is what makes AUBI feel like a team of AI coworkers instead of a single coding assistant.

How we built it

We built AUBI as a full-stack, real-time issue-to-PR system.

Layer Technology
Frontend Next.js, React, TypeScript, Tailwind CSS, Framer Motion
Backend FastAPI, Python, LangGraph, LangChain
Memory Qdrant semantic vector memory
AI OpenAI-compatible reasoning models
GitHub integration GitHub API, PyGithub, Git CLI
Streaming Server-Sent Events
Verification Temporary repo checkout and test execution
Deployment Railway backend, Vercel frontend, Docker

Backend graph

issue_reader
  -> ownership_router
  -> query_single_agent
  -> coworker_mesh_exchange
  -> code_reader
  -> fix_generator
  -> test_runner
  -> approval_gate
  -> pr_pusher
  -> memory_writeback

Product views

View What it demonstrates
Team Each developer's AUBI coworker and Context Constitution.
Coworkers The mesh of AI coworkers and their ownership relationships.
Flow The live issue-to-PR execution path with progress, diff, tests, and approval.
War Room The explanation layer: context exchange, shared memory, considerations, and reasoning trace.

What makes it different

Regular coding agent AUBI
Starts with a prompt. Starts with team context.
Acts as one generic assistant. Uses persistent developer-shaped AUBI coworkers.
Retrieves code chunks. Retrieves ownership, expertise, prior incidents, and team memory.
Generates a patch. Explains owner routing, coworker context, checks, tests, and approval state.
Forgets after the run. Writes resolved incidents back into persistent memory.
Pushes toward full automation. Keeps a human approval gate before PR creation.

AUBI's thesis is that developer productivity is not just faster code generation. It is getting the right context to the right AI coworker at the right time.

Challenges we ran into

The hardest part was making the project real instead of a scripted mock.

We had to connect:

  • live GitHub issue selection,
  • GitHub repository file reads,
  • Qdrant-backed memory retrieval,
  • coworker-to-coworker context exchange,
  • streamed LangGraph events,
  • patch generation,
  • test verification,
  • approval state,
  • GitHub PR creation,
  • and memory writeback.

Another major challenge was explainability. It was not enough for agents to communicate internally. We needed the UI to show the reasoning clearly: who asked whom, why they were selected, what memory was used, what checks were produced, and how that affected the final patch.

Accomplishments that we are proud of

We are proud that AUBI demonstrates a complete, context-aware development loop:

  • Persistent AI coworkers for each developer.
  • Context Constitutions generated from GitHub activity.
  • Qdrant-backed user and team memory.
  • Explainable ownership routing.
  • Coworker-to-coworker context exchange.
  • Live GitHub issue selection.
  • Real repository file reads.
  • Generated patches from source context.
  • Test verification.
  • Human approval before PR push.
  • GitHub PR creation.
  • Memory writeback after successful work.

The best part is that AUBI can explain itself. It does not only say, "Here is a fix." It shows the chain of context that led to the fix.

What we learned

We learned that the most important missing layer for AI developer tools is not always code generation. It is context orchestration.

A useful AI coworker needs to know:

  • what the developer owns,
  • what the team already learned,
  • what related coworkers know,
  • what risks matter,
  • what should be checked,
  • and when to stop for human approval.

That is the layer AUBI focuses on.

What's next

We would expand AUBI into a production-grade developer productivity platform:

Next step Why it matters
More language-specific test runners Support Python, TypeScript, Java, Rust, and more repo types.
Persistent LangGraph checkpointing Make approval resumes production-safe across multiple workers.
Slack and Discord ingestion Add real collaboration memory beyond GitHub.
Reviewer assignment Route PR reviews to the right human and AUBI coworker.
PR comment automation Explain what memory was used directly inside the PR.
Memory confidence and decay Keep long-term memory useful as projects evolve.
Multi-repo team graphs Let organizations share context across many repositories.

Final thought

AUBI is AI that knows the team, not just the codebase.

It is a step toward developer agents that do not only generate code, but understand ownership, remember context, coordinate with other AI coworkers, and learn from every issue they help resolve.

Built With

Share this project:

Updates