Why More Instructions Make Your AI Worse

Update, September 2026: the Deal Engine is no longer offered for install. It runs inside Serious Land Capital’s own deal review.

What I’m thinking about: The SLC Deal Engine is live after two-plus years of versions that weren’t good enough to sell…and the answer-key method that got it over the line has rewired how I think about every AI system we build.

The more I fixed our AI underwriter, the worse it got.

Quick recap for context…the Deal Engine is the land underwriting software we’ve been building for over two years, through more names than I’d like to admit (e.g. Land Pricer, then SLC Chat, then a Cowork plugin).

By mid-July an early version was live with our first customer, and after SO. MANY. misfires my confidence was buoyed on early results…my manual review on a minor subdivide would land at $8,800 per acre, and the engine would come back around $9K

Then the variance started widening upon further testing . Same deal type, same process, wildly different outputs.

Every patch made it worse somewhere else. I’d spent YEARS on this method, months in ship it or zip it mode (really, I tried)…and the reliability piece (the most important part) was still breaking down in my hands.

Those were some darker days…a lot of disappointment and frustration, sharpened by the fact that a live customer was already running the thing…I’d finally delivered the system, and the quality kept slipping the more I tried to improve it.

Underneath it all sat the outcome I didn’t want to face…going back to my audience, AGAIN, to say I couldn’t deliver. That’s the risk baked into any public promise…prove it, or bail. (Like every human being, I’m assuming people are thinking about me WAY more than they actually are…but I really do take it seriously to be able to deliver value to you all, and I care about your feedback.)

Where vibe coding breaks

So I sat down with Claude and forced the uncomfortable conversation, “Look at every single piece of this build, and tell me straight…is this even feasible with the state of technology currently?”

What we had was vibe coding. An idea fed to an AI tool, then patch after patch after patch, with written instructions standing in for what should have been actual code.

Think of it like an assembly line with ten stations. If each station gets it right 95% of the time (my initial internal target), only about 6 in 10 finished products come off the line clean. Every station sounds reliable on its own…but the line as a whole is roughly a coin flip. (FYI 10 stations was the number for our build, you could have more or less, and the more you have, the higher the per-step accuracy required).

True reliability needs every station near ~99% (e.g. for our 10 station build, and certainly for anything over that), and written instructions can’t get an AI there. Past a point, every new rule you write makes it forget a different one…an endless game of whack-a-mole.

The fix was an inversion. The procedure became software…a ten-stage pipeline that cannot skip, forget, or reorder steps, and stops when something is missing.

The AI stopped being the manager of the factory and became a specialist on the line, called in for the two things it’s world-class at…judgment (scoring comps against our rubric) and writing the final read. The mental model that finally stuck…you’re running a quality-control program around a talented, forgetful employee, rather than prompting a genius.

The answer key

The rebuild ran on a grading method…every time I reviewed a run and caught an error, that correction got written down as a checkable expectation about a specific property (e.g. “this parcel cannot reliably be mapped, and has unclear characteristics per MLS photos, so it cannot be utilized for pricing consideration”).

My reviews stopped being feedback and became the specification itself…a growing answer key the engine has to pass before anything ships (the Check stage from Sharran Srivatsaa’s four-column framework, made permanent).

Then we graded like a factory, station by station, instead of testing the whole line at once. Freeze one stage’s inputs, run it across several fresh sessions in parallel, and the rate is the score…five of five ships, while three of five means something systematic is broken.

It took 31 41 rounds of this as of last week (actually as of the deadline before this newsletter was published, writing this at an ungodly hour Sunday night trying to give you all the absolute latest build), and an absurd number of tokens (early build trials burned ~25% of my weekly Claude Max allowance on their own, but I’d have thrown five Claude accounts at the problem if that’s what reliability took.)

The $19K disagreement

The defining test came on a test small acreage deal. The engine came back at $99K to $101K…my manual read said $80K to $90K.

A month earlier that gap would have kicked off another round of vibe coding patchwork. This time I took it straight back to Claude Code, we walked the two runs step by step, and the reason surfaced the same day.

Five separate safety filters, each reasonable on its own, had quietly thrown away every low datapoint before the final range was determined. Nothing was wrong with the math…the cheap evidence simply never made it into the room.

Every fix became a permanent test in the answer key: real sales can no longer be deleted just because unsold listings make the market look rich, the search widens itself when sold evidence runs thin, and every discarded record gets listed by name, price, and reason.

Re-run the same evening, the engine reconciled to $80K to $90K…my band. And on picking the highest probability exit number, its estimate landed at $87,992 against my manual $88,000.

That’s the difference a real foundation makes… once the architecture held, a five-filter pricing bug became an afternoon of fine-tuning. The lesson travels to any AI engineered workflow, which is where my day-to-day has been trending, with the SLC Deal Engine standing out as the core proof point for our team’s capabilities.

(Figuring reliable land pricing automation out, on a national level, is one of the most inherently difficult workflows to solve in ANY industry, accounting for data access/variability/quality…and by the fact that no one has solved it yet, or even come close. Most existing solutions, including brand new ones from well-resourced enterprises are merely slapping lipstick on a pig IMO. So if we can figure this out…every other workflow, related industries or not, will be viewed as surmountable.)

What it costs to run now

The first full measured run, on a difficult subdivide, took 3.5 hours end to end and ~15-20% of a week’s Claude Max allowance…correct conclusion, unsustainable economics and efficiency. That ordering was deliberate (a correct system can always be optimized…)

Since then, cheaper AI models took over the gathering work (structured data pulls now cost under 50 cents per deal through Apify, a scraping service), the most powerful model got reserved for judgment and the final read, and a workflow audit last week deleted every fake wait in the pipeline (jobs standing in line behind jobs they never depended on).

Token cost is down to ~1% of weekly usage, and a clean unattended run now projects to under an hour (this is why I’m up so late writing, trying to carve minutes off while keeping accuracy high…it’s stretching the creativity of Claude + me to our limits. To me, under an hour to have pricing done without ANY of the user’s attention is reasonable, and I eat my own dog food as a rule, but the market will decide.)

The bigger structural change is that the method itself now lives behind our server. A customer’s machine holds a shell that runs the process and asks our server for every verdict. Updates push live the way your iPhone apps update themselves, and the engine calibrates to YOUR business over time (your geographies, your pricing standards).

You feed it a parcel number, county, and state (obviously even this part can be automated too)…it handles the rest, full comp workbook, pricing range, and a plain-English read, while you work on or do literally anything else.

Two-plus years, one wrong architecture, and 41 grading rounds later, the operators getting reliable AI systems are doing the same unglamorous thing…codifying what they already know, turning the procedure into software, keeping the AI for judgment, and grading everything against an answer key that only earned expertise can write (e.g. our multi-million dollar profitable track record with 41% operating margins). The models get faster and cheaper by the week. The answer key is the part nobody can download.

=====

The SLC Deal Engine is now open for installs. The demo on that page is me underwriting a parcel by hand while my own software races me on the same deal…honest clocks on both sides, both ranges revealed at the end.

(BTW how the demo video, the sales page, and the entire marketing engine behind this launch got built in about a day is its own story…and lands next week.)

The risk sits with me, twice over. I install the deal engine on your machine personally, and we run a live deal together on the call…if what you see doesn’t look like the video, say so before we hang up and the install is refunded on the spot. In writing, too…if it doesn’t cut your underwriting time by at least half (meaning, your time, personally) across your first three deals, refunded as well. I can’t guarantee your deals make money (nobody honest can), but I can guarantee the process, because it’s the one I stake my own capital on (and apparently Sunday nights, in the relentless pursuit of quality).

If you’re ready to become the kind of land operator whose underwriting runs without you (or your team), watch the race and judge the output yourself.

Related: