Insight
A recurring administrative task looks like an obvious candidate for automation. Until it turns out that the real workings consist of exceptions, historical agreements, numbering, and knowledge that was never formally recorded anywhere. For me, automating therefore doesn't start with software, but with the question of which decisions are actually being made today — and which of those can never be allowed to go wrong.
Some processes look simpler than they are. Someone takes a template, adjusts a few details, picks a language, gives the document a sequence number, and saves it. If that action recurs regularly, automation seems like the obvious move.
Until you start asking. Why is that sequence number built up exactly that way? Which combinations are allowed, and which aren't? What happens when a single agreement covers multiple people? Which existing documents help determine what number comes next, and who's allowed to decide that an exception gets made after all? Then it turns out you're not automating a Word document. You're formalising a process that, for years, has lived partly in files and partly in people's heads.
Software is pretty good at executing rules. The difficulty lies in determining which rules actually exist. Someone carrying out a routine by hand rarely notices how many implicit decisions they're making along the way: that an existing number is never reused, that one customer is always treated just slightly differently, that a certain combination "doesn't occur" — until someone enters it anyway one day. As long as a human carries out the process, experience fills those gaps. Software doesn't. And that's exactly what makes it useful: good automation forces you to replace "normally we do it this way" with rules clear enough to apply and test. Then it has to be clear what's mandatory, what gets blocked, what has to stay unique, which data is the source of truth, and what happens when a step fails.
Only after that does technology become interesting. A tool that saves twenty seconds in a demo isn't much use to me if I don't know for certain whether two users can end up with the same sequence number, or whether existing data gets overwritten during a transfer. That's why, with internal tools, I first look at the things that absolutely must never happen. A button that works has little value if the exceptions around it aren't reliable.
That also shapes how I use AI on a project like this. A model can help write code, suggest test cases, question a design, or surface scenarios nobody had thought of. Useful. But "the AI wrote the code" says nothing about the quality of the result. Where a business rule has to be fixed, a model isn't allowed to quietly start guessing which type, number, or language applies. What counts is whether the same input consistently produces the intended outcome, whether errors get blocked before they damage data, and whether tests exist for behaviour that has to be preserved.
Not all human judgment has to disappear in the process. Some decisions you deliberately keep with a user. If a tool takes over ten actions and leaves one important decision with a person, that's often better than automating eleven actions and hoping the eleventh always goes right. For me, automating isn't about removing as many steps as possible, but about reliably taking routine away without automating away control at the same time.
The same goes for what already exists. A new tool rarely gets an empty playing field: there are documents, numbers, files and habits from before the tool, and those are part of the problem. A working piece of automation shouldn't only know what needs to happen tomorrow. It also has to respect what already happened yesterday.
That's why I'd rather start with an uncomfortable question: what must this tool absolutely never get wrong? As long as there's no clear answer to that, we're not ready to automate yet.