Cursor wraps a model in a harness for writing software
Cursor is the clearest working example of a harness I know. All four parts are visible, and one of them took the software industry decades to build.
Cursor is an environment for writing software. In Cursor, I describe what I want to build. The model interprets the request. The agent reads the files that make up the software and edits them. Then it runs the tests.
Explore AIM to find sites at city scale: Ask in plain language and see matches.
The Harness Supplies a Working Environment
Cursor wraps the model in a harness, and all four parts of a harness are present.
Context. How software is put together: what kinds of files a project needs, which libraries it relies on, how the pieces connect. Then the specifics of this project, its files and its structure. The model knows software in general. The harness shows it the software in front of it.
Instructions. The project's rules for how changes should be made. Which conventions to follow, which parts not to touch, how to name things, when to ask before acting.
Tools. The agent can navigate files, read them, edit code, run commands and run tests. Each one is an action the model cannot take on its own.
Checks. Tests that compare what the code did with what someone said it should do. A test states the expected result in advance, and it either passes or it fails.
Paste the same request into a plain chat window and the same model gives you a description of the change, in prose, with code you then copy across yourself. Same brain. No arms, no desk, no test.
Without the files and the tools, the model could describe an edit. It could not make changes to the codebase, or test the code to see if the changes actually worked.
The difference between those two experiences is the harness, and nothing else.
One Request, Step by Step
Take something small. I want to change the font on our website.
The model interprets the request. It knows that on a website a font is set in a stylesheet, that the change should probably apply everywhere and not to one page, and that a new font may need to be loaded before it can be used.
The agent finds the stylesheet, reads it, and edits the line that names the font. It runs the site to see the result. Then it runs the tests.
One test fails. A page that loaded the old font from a specific file cannot find the new one. The agent reads the failure, adds the missing font file, and runs the tests again. They pass.
The model did not touch a file. The agent did not decide what "change the font" meant. Neither one supplied the stylesheet, the rules or the test. Three layers, each doing the one thing the other two cannot.
A request can become software through repeated editing and checking.
Running Is Not Checking
In the font example, the agent used a tool to run the test. The comparison inside the test is the check. Running is an action. Comparing is a judgement, and someone wrote the standard down before the work began.
A test compares what the code did with a result someone specified in advance. Here, the test said: every page should load, and the heading should render in the new font. If the two do not match, the agent revises the edit and runs the test again.
An agent with tools but no checks can still make the edit. It would change the font, break the one page, and report that it was done. Fast, and wrong, and nobody would know until a customer opened that page.
A passing test proves less than it sounds like. It checks only the expectation written into it. A pass shows that one expectation was met on one run. It does not prove the software is correct. If nobody wrote a test for the mobile layout, no test ever checked the mobile layout.
The harness does not make the model right. It gives the work somewhere to happen, and a repeatable way to test whether a stated expectation was met. It is the difference between "I finished the feasibility analysis" and "I verified each assumption in the feasibility analysis".
Nobody Handed Software Its Checks
The checks are the part of Cursor that led me to real estate.
The checking environment was built deliberately, by engineers, over decades. It did not come with the code. Somebody had to decide that software should be testable, invent the tests, build the tools that run them, and make writing them a habit across an entire profession.
That habit was expensive. For most of the history of software, writing the automated tests for a programme took about as long as writing the programme itself. Two jobs for every feature. Many teams skipped the second one.
Today an AI agent can write the tests alongside the software, in the same pass. Much of the cost that kept teams from checking their work has gone. What did not go anywhere is the decades of scaffolding the tests run on: the tools, the conventions, the culture of expecting a pass before anything ships.
When a language model arrived that could write software, that scaffolding was already standing. The model dropped into an environment where the context was organised, the instructions were written down, the tools existed, and the checks ran on their own.
Building AI for software was not easy. It looks easy now because the hard part was done first, by people, over a very long time.
What Would a Harness Look Like for Real Estate?
Working with Cursor made me think about the system surrounding the model rather than the model itself.
Cursor built a software-development system around a language model. The system's context, instructions, tools and checks are specific to writing software. Take the model out of Cursor and put it in front of a zoning question, and none of that comes with it.
So the question is not just which model. The questions include:
What context, tools and instructions would we need to give a language model to work effectively in real estate?
Where is the codebase for a city? Where are the project rules for a parcel? What is the test that fails when a zoning read is wrong?
That question connected directly to a problem we had been working on for years.
Explore AIM to find sites at city scale: Ask in plain language and see matches.
