The problem
The office set property values with a calibration engine written in FORTRAN, with a FoxPro front end. It was decades old. Nobody maintained it, it was slow and clunky, and it was hard to teach to new staff. The one thing it got right was the math. So the job was to take that math out and put it somewhere people could keep working on it, without changing a single value.
Where I started
I had never used version control, never written an automated test, and never worked in C#. My background is statistics and SQL. This project is where I learned all three, with Claude as the tool I learned through.
My role
The engine is split into modules. A senior programmer made the first AI-generated port, covering about a module and a half. I took it from there:
- Verified his port line by line against the original source, which existed for those modules.
- Ported the rest. For the later steps, the source was incomplete or didn’t match what production actually ran, so I worked backward from production’s outputs to find out what the program really did.
- Built the testing, wrote the project’s decision records, and got it to a pilot.
I made more than 200 of the project’s commits.
How I worked
Every change went the same way: write a plan with Claude, build it, test it, commit it. The tests compared the new engine’s output with the old system’s output on real models. A change wasn’t done until they matched.
Once the tests passed, I ran mutation testing. It plants small bugs in the code on purpose and checks whether the tests notice. Wherever they didn’t, I wrote better tests. I went around that loop until the core calculations scored 86%.
Two decisions that shaped it
1. Match the logic, not every last decimal. Old FORTRAN and modern C# don’t do floating-point math quite the same way, so some tiny differences were always going to show up. I wrote down a rule early: if a difference comes from a different calculation, it’s a bug and gets fixed; if it comes only from how the computer rounds, it’s measured and accepted. That rule kept me from chasing noise, and it also meant real bugs couldn’t hide behind “it’s just rounding.”
2. Copy one old bug, refuse to copy two. Doing a faithful port means deciding what to do with the old program’s mistakes. One quirk was baked into values people relied on, so I reproduced it and documented why. Two others gave meaningless results that depended on whatever happened to be in memory. There was nothing sensible to match, so the new engine stops with a clear error instead of quietly giving a wrong answer.
I recorded more than 20 decisions like these, so the next person won’t have to work them out again.
Results
- Parcel values match production exactly: 538,964 land and building values across 24 models.
- 263 automated tests, with an 86% mutation score on the core calculations.
- A working pilot in about a month, ready to run alongside the production system while staff test it.
What I learned
- AI made the project possible; the tests made it trustworthy. Claude let me take on work I had no training for. Comparing against the old system is what told me when it was right.
- Splitting the work between models made it worse. I tried having a stronger model write the plan and a cheaper one carry it out. The handoff caused more bugs than it saved time, so I went back to one model doing both.
- Write decisions down as you make them. Several surprises in the old code would have cost days to rediscover.