If you’ve done a job for years, you know a few things the software doesn’t.
You know which exception will cause trouble. Which number needs a second look. Which screen makes a simple task harder than it needs to be. You may have built a spreadsheet or invented a workaround because explaining the problem again seemed less useful than getting on with it.
There is knowledge in those workarounds.
Something that feels obvious to you may be obvious because you spent ten years learning to see it.
What interests me about AI is the possibility of putting more of that knowledge into the tools themselves. Someone who understands a problem can start shaping a solution, try it, and improve it without having to master every technical step first.
That could change who gets to decide what software should do.
A creative medium within reach
Computers have supported art, music, design, and homemade solutions for decades. What is changing is how approachable building with them can be.
Describe a small idea, ask for a working version, and begin responding to what appears. Move a control. Change the sequence. Realize that the first approach was wrong and try another. A prototype gives you something to think with while the idea is still fresh.
Recent announcements make that direction concrete. On September 25, Microsoft introduced Copilot Code for building apps and workflows from ordinary language, with a staged rollout beginning through its Frontier program. On September 29, OpenAI announced easier plugin creation and support for plugins in Sites, letting teammates use an app with their own connected data and permissions. Access varies: some features are still rolling out or limited to organizational plans. I see these as signs that shaping software is moving closer to the people doing the work.
The creative possibilities include a musician’s unfamiliar instrument, a teacher’s way of making an idea visible, or a screen that finally makes sense to someone who uses it every day.
Each involves a point of view. Each requires choices about what the experience should be.
The accountant knows the work
I’m an AI engineer, and I work with frontier models every day. That doesn’t make me an excellent accountant.
I can help build an interface and think through how information moves. An experienced accountant will recognize problems I might never think to ask about.
Imagine one who wants a better way to review possible duplicate invoices. She describes a tool that puts suspicious pairs together, shows the original information, and lets a reviewer record a decision. Then she asks AI to build a rough version using made-up records.
The first attempt looks encouraging. It finds repeated invoice numbers and presents them in a tidy list.
But two unrelated suppliers have used the same invoice number. The tool treats their invoices as a duplicate. Meanwhile, a duplicate entered with a mistyped number slips through.
She understands both mistakes. She asks it to compare more of the information, explain why each pair was flagged, and make clear that a match needs review. She keeps the source records beside the suggestion so a colleague can check it.
The next version is less impressive-looking in one respect: it sounds less certain. It is also closer to the way she would want to work.
Then a colleague tries it. He can follow the comparison, but asks how he is supposed to record why he ruled a pair out. She adds a short explanation field and makes previous decisions easy to find.
That small exchange changes the design again. Her experience gave her a starting point; someone else’s experience showed her what was missing.
This is taste at work. Deciding what belongs on the screen. Choosing a useful explanation over a confident label. Recognizing that the next person needs to understand a decision after the conversation is over.
The result carries some of its maker’s judgment. Other accountants might recognize their own needs in it and help make it better.
Useful enough to rely on
Our imagined tool still needs a fair test. A clean interface tells us very little about whether it will help someone do careful work.
We could compare reviews with and without it, using prepared examples with known answers. How many duplicates are found? How many harmless pairs demand attention? How long does the review take, including correcting mistakes?
Those are proposed tests, not reported results. The tool might create more work than it removes. Finding that out is part of building something useful.
Before real financial records enter the picture, privacy, access controls, reliability, and maintenance need serious attention. Engineering matters here. A prototype can help establish what is worth building; dependable software requires further work and people accountable for it.
Domain experience also needs questioning. A familiar process may contain assumptions that no longer make sense. The best version could emerge when the person who knows the work and the person who knows the technology challenge each other.
The things you have learned to see
There is a particular kind of frustration in understanding exactly what would help and having no practical way to make it.
AI gives more people a place to begin. A small experiment can make an idea concrete enough for another person to try, question, or improve.
Some of these tools will remain personal. Others may help a team or become useful to people throughout a profession. A meaningful result can be modest: fewer confusing steps, a mistake caught earlier, a task someone can complete with greater confidence.
The person closest to a problem has something to bring to its solution. More of that experience can now find its way into what gets made.
What is the software you wish existed because you know the work well enough to see what’s missing?
AI engineer, builder, and author of The Age of Imagineering.