DEV Community

Aviral Arora
Aviral Arora

Posted on

I Joined Ericsson With Modern Skills. The Codebase Was From Another Era. So I Gave Our AI a Memory.

#ai #cognee #wemakedevs #opensource

I Joined Ericsson With Modern Skills. The Codebase Was From Another Era. So I Gave Our AI a Memory.

Hackathon: The Hangover Part AI — Where's My Context? (WeMakeDevs × Cognee)
Live demo: https://frontend-six-alpha-67.vercel.app

GitHub: https://github.com/AviArora02-commits/code-archaeologist

A few months ago I joined a team at Ericsson.

On paper, I knew Java. I had worked with modern frameworks, clean APIs, and codebases where git blame actually tells a coherent story. I walked in ready to contribute.

What I found was different.

The systems my team maintains are mostly Java, with C++ in the mix — stacks that have been running for years, sometimes longer than I have been in the industry. The style is old. The patterns are unfamiliar. Variable names like tmpBuf2 and classes named after people who left before I was born. No one would call it beautiful.

And yet — they work. Surprisingly well. They handle real traffic, real customers, real infrastructure. Telecom does not get the luxury of a rewrite because the code looks ugly. You learn it. You respect it. You do not break it.

That is where my struggle began — and where this hackathon project started.

The hangover is real

The WeMakeDevs × Cognee hackathon frames it perfectly: "Your AI woke up in Vegas with no memory of last night. Where's my context?"

That was exactly my first month at Ericsson.

The first month: Amazon Q couldn't help me

Like many large enterprises, Ericsson gives developers access to an internal LLM — in our case, Amazon Q. On paper, it should have been my shortcut. Ask a question, get an answer, keep moving.

It did not work that way for legacy code.

I would paste a Java method and ask: "Why does this retry loop behave differently when the connection pool is exhausted?"

Amazon Q would give me a confident, generic answer about retry patterns — the kind you would read in a blog post from 2019. It had no idea that this specific loop existed because of a vendor firmware quirk from 2011. It could not connect the method to the commit that introduced the workaround, the internal ticket that justified it, or the senior engineer who spent three weeks debugging it at 2 AM.

I tried rephrasing. I tried giving more context. I tried asking about the C++ bridge layer that the Java service called into — a hand-written JNI wrapper that looked like it had been edited by five different people across fifteen years.

Same result. Plausible answers. Wrong context.

Meanwhile, my actual options were:

  1. Read thousands of lines of undocumented code and hope I did not miss the one if statement that mattered
  2. Wait for a senior engineer to get free
  3. Go back to them again when my follow-up question revealed I had misunderstood the first explanation

I did all three. Repeatedly.

That frustration is what sent me to this hackathon. I needed AI that doesn't forget — and that cites its sources.

How Cognee gives AI a memory

Cognee is a hybrid graph-vector memory layer for AI agents. Four operations. Total recall:

await cognee.remember("The retry loop caps at 3 because vendor firmware v2.1 hangs on the 4th attempt.")
answer = await cognee.recall("Why does the connection retry stop at 3?")
await cognee.improve()                          # enrich
await cognee.forget(dataset="old_repo")         # prune
Enter fullscreen mode Exit fullscreen mode

For this hackathon I used Cognee Cloud — persistent, hosted graph memory — via a single cognee.serve() call in our FastAPI backend. Each GitHub repo gets its own dataset (owner_repo). Connect ten repos, get ten isolated memories. Delete one, the others stay intact.

Stateless LLM (Amazon Q, ChatGPT) Cognee-backed memory
Forgets every session Remembers across sessions
Guesses from training data Recalls from your ingested context
No source citations Graph traversal to evidence
Cannot learn from your seniors remember() + improve() from expert input

This isn't a chat wrapper. It's a memory architecture — and it's why I built Code Archaeologist for the hackathon.

My build: Code Archaeologist

Code Archaeologist is the tool I wish I had on day one at Ericsson.

You connect a GitHub repository. The system ingests the codebase — 160+ languages including Java, C++, Python, COBOL, and more — along with git history, commit messages, and GitHub PR/issue links. Everything goes into Cognee via remember().

Then you ask why, not where.

A real question I would have asked

"Why does the SessionManager class use a synchronized block around the connection pool instead of a proper lock-free queue?"

A stateless LLM might lecture you about concurrency best practices.

Code Archaeologist calls recall() with GRAPH_COMPLETION — Cognee traverses the knowledge graph and returns an answer with an evidence chain:

SessionManager.initPool() → commit a3f8c21 → PR #847 "Fix race under high load" → Issue #1204
Enter fullscreen mode Exit fullscreen mode

Every claim links back to something real. Not a guess. Your repo's actual history.

Expert knowledge — what Amazon Q could never do

When my senior finally explained why the C++ JNI bridge used a specific buffer size, that explanation lived in a Slack DM for about twenty minutes before it disappeared into the scroll.

With Code Archaeologist, a senior can write:

"The JNI buffer is 4096 bytes because the legacy DSP firmware only accepts fixed-size packets. Do not change this without coordinating with the platform team. — Raj, 2019 outage postmortem."

That goes through remember() into the same Cognee dataset. Then improve() enriches the graph. The next person who asks why the buffer is 4096 gets Raj's answer — stored permanently.

Full Cognee lifecycle (hackathon requirement)

Operation How we use it
remember() Ingest code entities + git blame + PR/issue context + expert notes per repo
recall() GRAPH_COMPLETION why-queries with evidence extraction
improve() After expert knowledge submit + positive user feedback
forget() Per-repo delete — removes dataset without affecting other repos

Also built: multi-repo fleet dashboard, knowledge graph visualization, dry-run cost estimates before ingest.

My build journey

Week 1: Prove the memory loop — connect repo, ingest, ask why, get sourced answer. Fixed raw JSON answers with a readable AnswerView component.

Week 2: Make Cognee Cloud reliable. Switched to blocking remember() per file — slower but honest. One dataset per repo.

Week 3: Expert knowledge panel (the feature that directly addresses my Ericsson pain) + knowledge graph UI.

Week 4: Ship to production — Next.js on Vercel, FastAPI on Railway, Cognee Cloud, 10 unit tests passing, CI on GitHub Actions.

Architecture 

Next.js (Vercel)  →  FastAPI (Railway)  →  Cognee Cloud
                              ↓
                    GitPython + GitHub API
                    (clone, blame, PRs, issues)
Enter fullscreen mode Exit fullscreen mode

Demo walkthrough

  1. Open https://frontend-six-alpha-67.vercel.app
  2. Connect any public GitHub repo (Java, C++, or https://github.com/azac/cobol-on-wheelchair for legacy demo)
  3. Review dry-run → confirm ingest
  4. Trace: ask why something works the way it does
  5. Expert knowledge: teach the graph something only a human knows
  6. Trace again — see the graph use your input
  7. Memory fleet sidebar — multi-repo overview

Free Cognee Cloud credit for hackathon participants: code COGNEE-35 at wemakedevs.org/hackathons/cognee.

What I learned

Lesson 1: Memory without sources is just a slower hallucination. Graph traversal + git blame = citations engineers trust.

Lesson 2: improve() after expert submissions genuinely makes follow-up queries better. The lifecycle isn't marketing.

Lesson 3: forget() matters — per-repo clean delete without breaking the fleet.

Lesson 4: Amazon Q failed me because it had no persistent memory of my codebase. Cognee fixes the architecture. Expert knowledge fixes the human gap.

Why this matters beyond the hackathon

Every month, someone new joins a legacy team at a global company. They face the same Java/C++ code, the same missing docs, the same overloaded seniors.

Code Archaeologist preserves what seniors know before the next person asks the same question for the fifth time.

Links

Built for The Hangover Part AI hackathon (WeMakeDevs × Cognee). Memory powered by Cognee. Side project born from real onboarding pain at Ericsson Global.

Publishing checklist (Best Blogs side track)

  • [ ] Post to Dev.to or Hashnode (copy everything above this checklist)
  • [ ] Title: I Joined Ericsson With Modern Skills. The Codebase Was From Another Era. So I Gave Our AI a Memory.
  • [ ] Cover image: screenshot of Trace answer + evidence chain
  • [ ] Tags: cognee, hackathon, wemakedevs, legacy, java, ai, ericsson
  • [ ] Submit blog URL on WeMakeDevs hackathon form
  • [ ] Share on social tagging @wemakedevs and Cognee (see docs/SOCIAL.md)

Top comments (0)