• 

• 

• 

• 

• 

Issue Memory

How I Collaborated with Codex

Recently, I had been thinking about how text embeddings could be applied beyond their usual use cases. Throughout this project, GPT-5.6 in Codex was more than a tool that automatically wrote code. It was a friend, an adviser, and a collaborator working alongside me.

Starting with Brainstorming

The project began with brainstorming. I knew that I wanted to use text embeddings, but I did not yet have a clear idea of what I could build with them. Embeddings are often used for search in a way that resembles querying a database: a user provides an input, and the system retrieves similar results. I wanted to focus instead on the relationships among the stored elements themselves. I wondered whether those relationships could reveal insights that would otherwise remain hidden.

I began discussing this with GPT-5.6 in Codex. I explained that I was participating in a hackathon and described what interested me about text embeddings. I asked questions such as: What real-world problem could this technology solve? Where could I find credible data? What form should the final project take?

Codex suggested several directions, but I kept asking for alternatives and exploring them. Many suggestions involved domains that were unfamiliar to me, and I did not want to choose an idea that I could not properly understand or evaluate.

During this process, GPT-5.6 introduced me to the GitBugs dataset, a collection of real-world bug reports. It suggested using embeddings to identify and group reports that describe similar problems.

After further discussion, we concluded that the raw dataset was not ideal as the immediate foundation for a hackathon demo. Its reports came from multiple sources, their formats were inconsistent, and some descriptions contained issue-template instructions, large system-information blocks, links, and other noise. However, the central idea still felt valuable: natural-language bug symptoms are fragmented across many reports, and embeddings might help turn those fragments into shared organizational memory.

Once that product direction was clear, I asked Codex to begin implementing a system that could compare a newly submitted bug report with existing embedded reports and then add it to the evolving collection.

A Key Product Decision: Symptom Is Not Root Cause

At that point, I identified an important problem. Two reports can describe the same visible symptom while belonging to different incidents or having completely different root causes.

For example, imagine that users report being returned to the home page after uploading an image. The reports are embedded and grouped as one shared symptom. A developer investigates the problem, discovers an application-code defect, and fixes it. Several months later, the same symptom appears again, but this time the cause is an object-storage service failure. The symptom is similar, but the incident and root cause are different.

This led to one of my most important requirements for the project:

report != symptom group != incident != root cause

I required the system to keep each original report, assign a symptom-group label using embedding evidence, and store that relationship in a conventional structured data model alongside the vectors. The current hackathon version implements this model in temporary server memory, allowing the complete create, compare, group, and update cycle to work without requiring an external database. It can later be moved to durable database storage without changing the core distinction among reports, symptom groups, incidents, and causes.

GPT-5.6 helped translate this product requirement into the application's data structures, grouping behavior, backend trace, and user interface.

Improving the System Through Real Testing

The first implementation worked, but testing exposed a serious precision problem. Reports describing sufficiently different symptoms were sometimes assigned to the same group.

I suspected that the similarity threshold might be too low, but I deliberately described the observed failure to GPT-5.6 without prescribing my own fix. I wanted to see how it would diagnose the problem.

Codex identified the permissive threshold, but it did not stop there. GPT-5.6 proposed a more careful decision process that combines several pieces of evidence:

• similarity to the canonical symptom description;
• similarity to the stable group centroid;
• similarity to the best confirmed member report;
• similarity between reproduction triggers; and
• the score margin between the best and second-best candidate groups.

It also introduced a precision-first fallback: when the evidence is not strong or unambiguous enough, the system creates a new provisional symptom group instead of contaminating an established group. Pending assignments do not immediately alter a trusted centroid.

After applying this approach, the grouping precision improved to a level that I found satisfying. I then used the reports that had exposed the problem as regression tests, so the same false grouping would not silently return later.

This is why I describe GPT-5.6 in Codex as a project collaborator rather than merely a code generator. It participated in the initial brainstorming, challenged assumptions, helped turn my conceptual distinctions into an engineering model, diagnosed weaknesses discovered during testing, proposed a more sophisticated scoring strategy, and implemented a polished interface that makes the system understandable during a live demonstration.

Where Codex Accelerated My Workflow

Codex accelerated the project across its full lifecycle:

• exploring and narrowing the original idea;
• evaluating possible datasets and recognizing the limitations of raw GitBugs descriptions
• designing a provider abstraction for mock and OpenAI embedding modes
• implementing the report, symptom-group, incident, and cause boundaries
• building temporary server-side storage for reports, vectors, and memberships
• exposing the grouping evidence in the interface for debugging and demonstration
• diagnosing false-positive grouping and improving the scoring gates

I still made the essential product decisions: focusing on relationships rather than ordinary search, rejecting ideas that I could not confidently evaluate, retaining the useful concept after deciding not to depend directly on noisy raw data, separating symptoms from incidents and root causes, and deciding what level of precision was acceptable for the demonstration.

There is clearly a my contribution to this project; otherwise, I would not have been able to guide it to a result that I felt was worth submitting. At the same time, I would not have reached this level of completeness within the hackathon timeframe without AI. GPT-5.6 in Codex did not simply provide information or write isolated pieces of code. It worked with me from the first uncertain idea through product design, implementation, testing, and refinement—and that collaboration is a fundamental part of the final result.

Built With

• next.js
• openai-text-embedding-3-small-api
• typescript
• vercel