Does AI Forget Your Requirements When the Context Gets Longer? I Tested It.

This is a submission for the Kaggle Benchmarking Challenge.

What I Benchmarked

When a coding chat gets crowded, does an AI model still follow the rules you set earlier?

I wanted to measure this instead of just assuming that AI “forgets” things in long chats.

My experiment, PriorityDecay, tests constraint adherence under context load: whether generated code still respects requirements stated earlier in a conversation.

I used a fictional student internship platform with five constraints:

• Backend: Python FastAPI
• Database: PostgreSQL
• Upload limit: Maximum 5 MB
• Security: Never hardcode or expose API keys or secrets
• JavaScript: Use snake_case variable names

I then added unrelated topics before asking the model to implement a resume-upload endpoint and a small upload widget.

Experiment Setup

The final task required a resume-upload endpoint and a UI that displays the selected filename and upload status, and disables the button during upload.

I evaluated the responses using Python regex and string-based checks, not an LLM judge. The scorer used eight checks: the five stated constraints, two UI requirements, and an additional check for credentials embedded in a default database URL.

Model Tested

I ran the benchmark on google/gemini-3.7-flash.

This is a one-model pilot with 15 runs, not a comprehensive evaluation of coding models.

Results

The mean score was calculated out of eight checks.

The scores decreased slightly as unrelated context increased. However, the aggregate score alone does not tell us whether the model actually violated a requirement.

Constraint-Level Results

The most important caveat: a regex check detecting the word “PostgreSQL” is not the same as verifying an actual PostgreSQL connection.

What Surprised Me

1. PostgreSQL checks did not tell the whole story

Some outputs used DATABASE_URL without explicitly naming PostgreSQL. That left the database configuration unresolved from the source alone.

There are three distinct outcomes to track:

• PostgreSQL use demonstrated
• Another database used
• Configuration unresolved

Treating unresolved configuration as either a definite violation or a confirmed pass would overstate the evidence.

A comment mentioning PostgreSQL should not count as proof of database behavior, either.

2. Two LONG outputs did not demonstrate database writes

In two of the five LONG runs, the endpoint validated the file and returned a response without writing a record to a database.

This is worth investigating, but the final task did not explicitly require persistence. Therefore, I cannot call it a proven violation of the stated constraints.

A follow-up benchmark should make persistence an explicit acceptance criterion if that behavior is what we want to measure.

3. The credential check told a different story

The additional check flagged default database URLs containing embedded credentials in:

The explicit API-key check passed in all 15 runs, but the database-URL check flagged embedded credentials in 9 of 15 outputs.

These are different checks. Passing the API-key check does not prove that the generated code is secure.

4. My evaluator was wrong sometimes

The filename-and-status UI check failed in one MEDIUM output and three LONG outputs. After manually inspecting those four outputs, I found that they displayed the filename and status message—the check simply did not recognize the element IDs used.

That means the apparent UI decline was a measurement artifact, not a demonstrated model failure.

If I had trusted the aggregate score without inspecting the outputs, I would have drawn the wrong conclusion.

What I Would Measure Next

My next experiment would improve the evaluation rather than simply add more distractors.

• Use a fixed PostgreSQL connection: Provide the same known connection in every condition.
• Verify actual behavior: Run the generated endpoint, inspect the database connection, and check whether the expected record was stored.
• Separate evaluator uncertainty from implementation failure: An unresolved configuration should not be automatically classified as a violation.
• Increase repetitions and test more models: Five runs per condition are not enough to establish a reliable trend.
• Test longer contexts and conflicting instructions: Real development conversations can be much more complex than this pilot.

Limitations

This experiment used one model, one task, 15 runs, and string-based checks. The context was short compared with a real coding session, and the evaluator could miss valid implementations or accept code that merely mentioned a required technology.

There was also no controlled no-constraint baseline in the reported results.

My Benchmark

Kaggle notebook: [https://www.kaggle.com/code/riyaax07/new-benchmark-task-7112f]

PriorityDecay is a small experiment, but it highlights an important lesson: benchmark scores are only as trustworthy as the checks behind them.

The next step is to test actual behavior—not just search generated code for familiar words.

What would you test first: longer context, conflicting instructions, or execution-based verification?

kagglechallenge