Replacing a grown tax software landscape solo, and where the model stops
Claude writes a module in twenty minutes that would have taken me a week three years ago. It works, the tests pass, the output is correct. And then a single step in the workflow takes thirty seconds, because somewhere in it sits a beginner’s mistake I stopped making ten years ago.
What is being replaced
I am the only developer on a piece of software meant to replace a landscape that grew over years: custom legacy tax preparation software, third-party web applications, spreadsheets, and a long tail of one-off tools. That is what environments of this size look like — every layer solved the problem in front of it, and none of them were designed together. All of it works, and very few people understand all of it.
The subject matter is the path from an IFRS consolidated statement to a finished US tax return. IFRS is the accounting standard most of the world outside the US reports under, which means the starting point is a set of books never prepared with a US filing in mind. From there it runs through currency translation, book-to-tax adjustments, income characterisation, and a few dozen special cases you do not invent, you only know. At the end sit Forms 5471, 8858, 8865, 1120-F and 1065.
The shape is worth describing, because it is what “grown” actually means. Group figures come out of the client’s consolidation system. They are harmonised in a data warehouse. Book-to-tax adjustments follow, then the Subpart F and GILTI calculations are prepared. Those results are imported into one commercial platform, which produces the entity-level forms. For the individual return they move into a second, unrelated commercial platform. At the end there is a PDF, and the PDF gets printed. Five or ten Forms 5471 will go through electronically. A few hundred will not.
A large part of it is mine. The harmonisation layer, the book-to-tax logic — that was my job from 2019 to 2023. What it replaced back then was one workbook per entity per adjustment, several hundred of them, and it was a clear improvement. It was also written without seeing the process end to end. What comes out of that reliably solves the problem on the table, and nobody asks about the one behind it.
So this is the second time I am replacing this pipeline. The first time, one person with a data warehouse took on several hundred workbooks. This time, one person with a language model is taking on the whole chain.
Why we start at the end
You do not replace software like this in a big bang. Not here. The calculation logic in production has been validated over years — against real filings, real numbers, real examinations. Nobody rewrites that mid-tax-year. A mistake there is not a bug, it is an incorrect filing with the IRS.
So we start at the end of the process, where the risk is lowest: review and print export. Both can be modernised without touching a single number, and both are used daily, so the effect is immediate.
From there we work backwards against the direction of the process. From review and export to the forms, from the forms to the calculations, and at the far end of that chain sit the book balances from the IFRS statement. Every stage is validated against the existing system before the next one is touched.
The software itself is a greenfield project: new architecture, new code, nothing carried over. The rollout is the opposite. It costs time a hard cut would not. In exchange, nobody at any point works with numbers no one has checked against what was there before.
Where I stand
What exists so far: an interface organised around how the CPAs actually work rather than around a database schema. Master data for clients, entities and ownership structures. Filing obligation management that stays legible even for deeply nested structures. A structured review process with four-eyes approval. And a print export.
The goals behind it are less impressive than the list sounds: a modern interface, a single source of truth, scalability, multi-tenancy, and enough flexibility to run very different structures on the same platform.
Days instead of months
Productivity is higher by a multiple, not by twenty percent. Time to a working prototype is measured in days now, not months.
What I find more remarkable than the speed is what follows from it. A project that would have needed a team and a multi-year budget three years ago can now be done by one person, which changes less about how fast things move than about what you attempt at all.
Licensed compliance software exists, and the largest firms run their own engines. At this size and complexity they reach their limits — either the structure does not map at all, or it maps at the cost of substantial manual work. Developing your own answer to that was still not a realistic option three years ago. Not because it was technically out of reach, but because you could not staff it. That is the constraint that moved.
Claude is strongest at implementing concrete requirements: clearly defined processes, bounded modules, specified logic. When I know what I want and can describe it precisely, the result is usually good.
The second half of that sentence is the one that matters. Without a concrete process definition and a clear approach you get hallucinations — and, more often and more dangerously, you get omissions. Not the exotic edge cases. The obvious ones: the validation nobody explicitly asked for, the failure mode anyone would have anticipated, the consistency check you simply do.
Thirty seconds
The beginner’s mistake from the opening comes from the review process. It reads data at a very granular level across a whole set of tables. The first version worked correctly. It just took over thirty seconds. The cause was badly scoped database queries: instead of one query across all records, each record was loaded individually. A pattern common enough to have its own name.
I noticed because thirty seconds for that step is obviously wrong. Nothing flagged it — to a language model, code that produces the right output is correct code. The fix was unremarkable: name the problem, half an hour of optimisation with Opus, three seconds.
The model could solve the problem. It just could not see that there was one.
The obvious objection: that is what project instructions are for. Write the rule down once and the issue goes away. Probably true, and I had not written one for this case. But that moves the problem rather than solving it. To write the rule, you have to know you need it. And for the next mistake of this kind, the one I have not seen yet, there is nothing in the file.
It gets clearer with process design. If I ask how a review process for tax returns should look, I get a plausible, generic answer with little to do with how a US tax practice actually runs. Who signs off when, where responsibility sits, which step has to be documented for regulatory reasons and which one from experience — none of that is in the training data.
Without my ten years in data models, enterprise architecture and software development, the model has no guidance. It still writes code, just the wrong code.
What the model is missing
It has no sense of what normal looks like. Thirty seconds for a review step is not an error you can read off the code. It is only wrong if you know how often that step runs in a day and what a CPA is doing while it does. That information is in no repository.
The same holds for completeness. Whether a missing validation is a gap or a deliberate decision depends on context nobody wrote down, because it is obvious to everyone involved. That context is precisely what is absent from the training material, and that is precisely where the output comes apart.
Across model generations this has become rarer. I have worked on the same codebase since Opus 4.6, through five generations, and the improvement is clear. The behaviour has not disappeared — not even where a project instruction covers that exact case. That is an impression from continuous use rather than a measurement, but it is consistent enough that I plan around it.
Whether you can tell the model all of this is the less interesting question. You can. The more interesting one is whether it notices that it should ask.
Where you find people like this
If I needed a second developer on this project tomorrow, I would not know where to look. Development capacity is largely a budget question now. What is scarce are people who can do both.
External developers can be bought, and plenty of them write better code than I do. What they do not know is that the ownership percentage on page 1 of a Form 5471 for a Category 3 filer is not the percentage from the shareholder register, because shares held by certain family members are attributed to the filer. A data model that stores ownership as one percentage per person and entity is already wrong — and nobody arrives there without knowing the rule. In the other direction, we have colleagues who know US tax law cold — thinking in maintainable data models is simply not their core expertise.
I have not seen a convincing job posting for that profile. Probably because it develops over years and cannot be advertised for.
What companies are missing
I cannot imagine a development process without model support at this point. The advantages outweigh the drawbacks by a wide margin, and the gap grows with every generation.
Using it deliberately, on a budget, and responsibly is still its own discipline, and this is where it gets thin in most firms. Who is allowed to work with which tool? An experienced architect and a junior produce very different risks with the same model. How do you measure the benefit? Lines of code are nonsense, and time-to-prototype says nothing about what goes into production afterwards. And who is supposed to assess any of this? That role is in no org chart I know, and it cannot be done on the side.
Whether language models replace developers strikes me as the less interesting question. What occupies me more is where the people are supposed to come from who use them well.
In my case: no plan. I was hired as an SAP BI consultant, not as a tax person. Nobody designed the combination of tax law and software architecture for me — I worked my way into the tax side over years, next to the role I was actually employed for. It worked for me. As a staffing strategy it is worthless.
