PromptFloe
← All posts
June 21, 2026·9 min read

How everyone else lost at context engineering

ShareXLinkedInWhatsApp

Large language models do not fail at code generation for lack of capacity - they fail because the context they are handed is wrong. Feed the model your whole repository and it drowns: the window overflows, cost scales linearly, and accuracy actually drops as relevant tokens get buried in noise.1 Feed it too little and it hallucinates APIs and breaks the contracts between files. The job of an AI app builder is to compress your project down to the minimal, correct slice for the task at hand. This is a compression problem, and we think the rest of the field got it wrong.

1.The problem is context, not intelligence

A model gets a prompt and some context, and writes code. The writing is no longer the hard part - the models got good. The hard part is deciding which slice of a growing project to put in front of the model for this specific change. There are two failure modes, and the engine’s entire job is to live on the frontier between them.

Whole-repo dumpevery file, full source - noisy, expensive, driftsCompressed contextthe right slice only - changed in full, the rest as contractschangedrelevant · contractsrest · one-line summaries
Figure 1. Dumping the whole repository hands the model mostly noise. A context engine sends the changed files in full, the structurally-relevant files compressed to their contracts, and everything else as a one-line summary.

2.Why everyone else loses

Frontend-only generators (Bolt, Lovable, v0) mostly dump files or feed whole context. They drift across iterations - the single most common complaint is “it rewrote my whole app / lost my design.”

Embedding-similarity RAG - the default everywhere - treats code relevance as a fuzzy similarity cloud.2 But code relevance is a graph: what imports what, what calls what, what a file exports. Cosine similarity rewards surface co-occurrence and misses exact structural edges. Ask for “dark mode” and similarity finds whatever file contains the word “dark” - not the theme provider that has neither word but is the thing you must edit. A graph finds it every time.

Bolt / Lovable / v0Cursor / ReplitPromptFloe
Relevance modeldump files / naiveembedding similaritydependency graph + symbol
Cross-iteration memoryweak → driftschat historylocked design + decision log
Context selectionmostly all-intop-k vectorstiered + token-budgeted
Error groundingmanual retrypartiallocal-fix-first repair loop
Figure 2. Relevance and memory across AI app builders. Embedding-only retrieval cannot tell you an edit will break three callers; a dependency graph can.

3.Our approach: compression-first, structure-first

We architect the engine as a pipeline with a persistent memory at its center. Structural retrieval walks a real dependency graph; project memory locks the design system and prior decisions so the app never drifts; a compressor reduces each non-edited file to its contract; and a verification loop feeds build errors back as fix-context.

IngestGraphContractmemoryCompressAssembleVerify → repair
Figure 3. The context engine pipeline. Contract memory is the durable core; verification closes the loop, so a broken import becomes the next turn's context rather than a silent failure.

The key idea is the contract. A model editing one file rarely needs the implementation of its dependencies; it needs their contracts - what to call and with what types. Keeping a function’s signature and dropping its body is high-information-per-token compression in the precise, Shannon sense,3 and it directly prevents the “imported a symbol that doesn’t exist” failure class.

4.Proof of concept

We measured the engine end-to-end on a real 641-file codebase, for a single-file edit. These are benchmark results, not illustrations, reproducible via the contextCompressor and projectCompression benchmarks.

23.4×
per-file contract
83.4×
whole project · 641 files
~100×
at scale
full project1,317,978 tokassembled15,806 tok
Figure 4. A 641-file project totalling 1.3M tokens assembles to a 15.8k-token context for one edit - 83× smaller. The changed file goes in full, its graph neighbours as contracts, and the remaining ~620 files as a one-line symbol index, so the model knows what exists and what it exports.
250 files60.7×641 files83.4×1,000+ files100× (proj.)
Figure 5. The ratio scales with project size: the assembled context stays bounded (~16k tokens) while the project grows, so compression climbs past 100× on large codebases. Smaller generated apps compress less - there is simply less redundancy to remove. We stop short of dropping files the model needs; the goal is the right context, not the smallest.

5.Limitations and what's next

We are not going to pretend this is solved. Doing all of it server-authoritatively - so the graph and contract memory are the source of truth rather than something reconstructed per request - is hard, and we are still hardening it. The piece we want next is a persistent, versioned contract memory so an edit can never silently break a caller. We are building toward it; we are not claiming we are there. If a tool tells you context is a finished problem, it is selling you something.

6.The takeaway

Every AI builder generates code. That is table stakes, and it stopped being a moat the day the models got good. The winners will be the ones that solve context - that hand the model the precise, minimal, correct slice of your project for the task at hand. Cheaper tokens and higher accuracy don’t come from a bigger model. They come from compressing context intelligently. That is the bet we are making.

References

  1. [1] N. F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023.
  2. [2] P. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
  3. [3] C. E. Shannon, A Mathematical Theory of Communication, 1948.
ShareXLinkedInWhatsApp

Have an idea? Describe it.

Watch it become a real, running app.

Start building →