Vibe-coding earns its place for most internal tooling. A dashboard that pulls from your CRM, a Slack bot that formats deal summaries, a lightweight app that replaces a spreadsheet someone maintains by hand. You describe the problem, iterate fast, ship something the team uses in days.
The harder question is which problems fit. Complex service estimation is the one case where the mismatch is worth understanding before you're mid-deal and finding out.
The implicit knowledge problem
When you vibe-code a pricing tool, you're not writing code. You're encoding business decisions into the structure: how deals are shaped, what rates apply where, how scope maps to price, which edge cases get handled and which get ignored. Those decisions come from how your practice actually works. They're invisible in the output.
The tool works because the person who built it knows why it works. They leave, change roles, or just don't open it for six months, and the knowledge goes with them. The code stays. The reasoning doesn't.
Ask Claude to explain the code and you get an accurate description of what the code does. That's a different thing from knowing why the contingency calculation works the way it does, which commercial logic priced integration work at that rate, or which scope items are always included and which always get negotiated out.
The tool that ran fine while the founder owned every deal turns into a black box the moment someone new has to change it.
Complex estimation is hard for AI models
There's an irony here worth naming.
The pitch for vibe-coding a pricing tool is that AI built it, so AI can maintain it, update it, interrogate it. What you've usually built is something living in or around a complex spreadsheet, and complex spreadsheets are one of the places current models struggle most.
Humans read spreadsheets through visual cues: font weight marking a heading, fill colour separating inputs from calculated values, indentation grouping rows under a section. Those cues carry most of the meaning. A model gets cell values. The visual structure vanishes at the boundary, and it guesses from raw numbers.
Microsoft Research put numbers on this: a vanilla encoding of a complex spreadsheet ran past 1.5 million tokens and still answered structural questions poorly. With serious engineering to compress the representation, table-detection accuracy reached around 74%. A 2026 benchmark on complex financial spreadsheets, FinSheet-Bench, found the best frontier models averaged 82% on structured reasoning, well short of the 97% practitioners treat as the floor for automated financial work. 82% is one error in every six answers.
Your pricing model might not be a financial portfolio. But connected tabs, conditional logic, hidden helper rows, formulas referencing named ranges - that's the same structural complexity. Rules buried in nested formulas are hard to extract, verify, or update reliably. The more complex the logic, the less you can trust AI to maintain it.
Rate governance has nowhere to live
Your rate card isn't static. Rates change, costs change, you add roles, retire roles, adjust margins by practice area or deal type. In a vibe-coded tool the rates live somewhere: a config file, a constant in the code, a number someone typed into a formula and never wrote down.
When they change, the tool changes. Who does that? If the builder is gone, you're auditing where every rate lives, whether any are duplicated, and whether a change flows correctly through downstream calculations. On anything with real complexity, that's not trivial.
Rate drift stays invisible until a post-project review, six months after close, when someone asks why the engagement ran short on margin.
A governed rate card replaces the distributed constants: one source, updated once, applied across every deal. A vibe-coded tool has no such concept. It has wherever the rates happened to land.
Your most commercially sensitive data has the weakest controls
This one stands alone.
Commercial estimates hold your actual cost rates (the cost side, not billing), your margin targets, your pricing thresholds, your internal read on what work is worth taking. That's the data a competitor would most like to see.
A tool built fast stores it wherever was convenient: a local file, a shared Google Sheet, a Notion database, a repo with broad internal access. None of those carry the access controls, audit trails, or governance commercial pricing data needs.
Who can read historical estimates? Who can change the rate card? Is there a record of what changed and when? For most internal pricing tools the answer to all three is "whoever has repo access" or "nobody's checked."
Security for commercial estimation isn't an enterprise checkbox. It's whether your pricing data is controlled or just sitting there for the taking.
Where an internal pricing tool is the right call
None of this argues against AI for internal tooling. The point is narrower: fit.
Vibe-coding works when the business logic is simple and stable, the data doesn't need tight controls, and the tool isn't a single point of failure when the builder walks. Plenty of internal tooling fits that.
Complex service estimation doesn't. The logic is involved and it moves. The data is sensitive. The tool has to stay maintainable by people who weren't there when it was built, and the output has to be trusted enough to send to a client and defend in a negotiation.
That's a different design brief from the thing you build in a weekend. Spotting it early is cheaper than learning it mid-deal.
