top | item 46727059

(no title)

barefootsanders | 1 month ago

"Outcomes not rules" is the whole game. On ambiguity: we don't try to solve it upfront. Get it 80% right, let them refine the rest in seconds. When something's wrong, they fix it in natural language, not by going back to eng to change logic or mess with config. The unlock is really iteration without a ticket.

Would love to swap notes on the accounting side. Similar problems, different domain constraints.

discuss

order

jackfranklyn|1 month ago

The 80% approach really resonates. We're building transaction coding tools for accountants and the key insight was similar - get the obvious stuff right automatically, surface the ambiguous cases for human decision.

The domain-specific wrinkle for accounting: every firm has their own coding style. What one bookkeeper calls 'Office Supplies' another calls 'General Admin'. So we had to build pattern learning at the individual level - watch how each person codes, learn their preferences, then apply that to new transactions.

The tax rules (VAT in the UK) add another layer - sometimes the same merchant gets different VAT treatment depending on what you bought. Gets messy fast.

Would be happy to swap notes - feel free to reach out. Always interested in how other domains handle the 'close enough to be useful, flexible enough for edge cases' problem.