Cursor, But for a 50-Year-Old Engineering Firm

Cursor reads your whole codebase and works next to you. You never start from a blank file, and never dig through old folders to remember how you solved something two years ago.

I built that for a combustion engineering firm that has run for fifty years and never used AI. A system that has read their actual work, every proposal, estimate, procedure, and completed job, and works alongside their engineers like Cursor works alongside a developer. It runs on a computer they already owned and cost a few thousand dollars.

The starting point

The firm does heavy industrial engineering: furnaces, burner systems, combustion safety, the equipment that keeps steel mills and process plants running. They are very good at it, and had no AI anywhere.

That isn’t an oversight. The usual pitch to a company this size asks them to change how they work, spend a fortune, retrain everyone, and trust it pays off. For a business whose value is decades of knowledge held by a few people, that trade rarely makes sense. Nobody built a version that fit.

The problem

Fifty years of work is roughly 480 gigabytes of files: proposals, drawings, estimates, vendor sheets, finished jobs. Everything the company knows is in there somewhere, but nobody has time to read it. So the knowledge lives in the heads of a few senior engineers.

A job comes in, one of them reads it, recalls similar jobs, remembers what parts cost and which vendors they used, and builds an estimate. It works, and it is the bottleneck. The goal: take both halves, files and judgment, and give them to the whole team.

The system underneath

The estimator is the visible part. It sits on the piece I care about most: a memory system that understands the firm’s work.

The naive approach is to chunk all 480 gigabytes, embed everything, and search the pile. Here it fails. Most of those files are published codes, vendor catalogs, scanned drawings, CAD binaries. Embed a million pages of reference material and you bury the few thousand that carry the firm’s own thinking.

So I inverted it. Instead of embedding the raw corpus, I built a knowledge layer first. The system reads the source once and rewrites it as dense, structured pages: one per client and job, one per procedure, one per recurring concept. Each page distills what the material says, every claim traced to its source. Search then runs over the distilled pages, not the raw mass. It is how a person works: read hard once, write good notes, reason over the notes.

Three decisions made it work:

• Cheap model reads, capable model judges. Distilling one document to its cited facts is grunt work, so a small, cheap model does it hundreds of times in parallel. The capable model handles what matters and how pages connect. Using it for extraction would cost twenty to fifty times more for nothing.
• Numbers are copied, never generated. A model that paraphrases a price can turn $1.2 million into $120,000, and one bad figure poisons everything downstream. Extraction is verbatim or nothing; ambiguous, it cites the source and stays silent.
• Hybrid retrieval, plus the firm’s own words. Vector embeddings and keyword matching over the structured pages, with a glossary that expands queries first, so “GTG maintenance” also reaches “gas turbine generator.” Acronyms and house shorthand are how engineers ask, and what plain embeddings miss.

On a real evaluation set from the firm’s own questions, it returns the right source over ninety percent of the time, without the heavier machinery, rerankers and query decomposition, these systems usually need. The accuracy comes from organizing the knowledge well, not stacking models on a weak index. That retrieval layer is the real product. Everything else is something you ask it.

The estimation engine

The first thing I asked it to build was estimates. An engineer describes a job in plain language: six-burner reheat furnace, gas train upgrade, natural gas. The engine works in two passes.

The first settles structure. It classifies the job by type, industry, and fuel, finds the most similar completed jobs, and reads how they were scoped. From that it assembles the line-item skeleton, cross-checking several matched jobs, so when four had a section this draft is missing, it flags the gap. That alone catches the mistake a tired estimator makes on a Friday.

The second settles price. Underneath sits a living cost tree from the firm’s own estimates and vendor sheets: roughly a thousand parts, each price dated and traceable to its job. New quotes feed it without overwriting history, so it sharpens every time. Each line is priced into the firm’s existing template, and the math is run.

Every number carries a confidence level. From a current vendor sheet, marked solid. Interpolated from an older estimate, marked as such. Anything that depends on engineering judgment, labour, custom fabrication, scope that varies, it does not guess: it shows the historical range and leaves the line for the engineer.

This decides whether the tool survives real users. The failure mode is not a bad quote going out; these engineers catch errors. It is trust. Give an engineer one wrong number and they stop trusting all of it, then re-check every line by hand, the exact work the tool was meant to remove. Catalog work gets automated. Judgment stays with the person qualified to make it.

Where it goes

Estimating is the proof, not the product. Because the memory is solid, an estimate is just one thing you can ask for. The same foundation answers how an interlock was handled on a 2014 job, or which vendor has been reliable for a part, grounded in the firm’s history.

The harder frontier is the drawings. Fifty years of engineering lives in CAD files and marked-up documents, the densest part of what the firm knows, geometry and annotations, not text. Bringing the same treatment there is where this is headed. The Cursor comparison carried all the way: not an assistant for one task, but a companion across the whole craft.

What it cost

A few thousand dollars to build, a small subscription to run. No new hardware, no cloud bill that scales with usage. It runs on one office PC the firm already had, on their premises, data staying in the building. The budget forced discipline: the cheap option where it sufficed, the expensive one only where it earned its place.

This is the version of AI a small or mid-sized company can actually commit to. It fits the budget, runs on existing hardware, and makes the team better at their work instead of anxious about it. It was never meant to replace anyone, but to let a small expert team do more of what they do well.

Most attention in AI goes to systems that are larger, more expensive, a step ahead on a benchmark. This is the other kind: a fifty-year-old firm given a tool that fits how they operate and makes the job easier. Not state of the art, not flashy. It works, for a real client, in the real world. That is the kind of system worth building.