Andrew Bihl is an engineer who accidentally became an accountant. More accurately, he's turning engineers into accountants at Numeric, his accounting automation platform. Meanwhile, externally, they're turning accountants into engineers — helping them reason about their job the way an engineer would and understand accounting as a big data engineering problem.
Accounting is something you go to school for. It's not something engineers just pick up for free. But it's also technically deep and every aspect of computer science rears its head somewhere in this space. You need a niche intersection of people who are very technical, very good engineers, but also have the humility to go deep into accounting and finance knowledge they otherwise never would have had.
Here are three things I learned from my talk with Andew about what's overhyped, what's appropriately hyped, and how to actually work with AI effectively
Delegation Is Hard And AI Makes You Learn It Fast
Delegation is difficult and takes work. People already run into this when they switch into management. Many people learn to delegate out of necessity when they're trying to do too much (and simply cannot). And it doesn't happen for free; you have to document things, plan ahead, make sure context is shared.
Getting into the mode of using AI is basically a new variant of the same problem. You have to get a lot more disciplined about how you equip something else to get work done and figure out what that line of communication is.
As AI gets into long-running agents, multiple of them running simultaneously, and you're project managing across them, you'll spend more time realizing you don't have any documentation or information written down anywhere. It's not possible for AI to do the job because you haven't documented it.
The good news? AI can help with writing the documentation. You get into this virtuous loop of improving the system's self-explanation and then pointing AI at it to both read the docs and improve them as it works. It's basically a fast loop on the "how do I get good at delegating" experience.
I've heard this described as "have empathy for AI." Not "remember please and thank-you," but: If this was a coworker you were handing your work off to, what's all the context and information they need to do the job well?
Some AI Workflows Are Overhyped And Might Make Us Anxiously Online Forever
Andrew thinks we're in a big explosive fan-out mode where everyone is trying everything. Teams are exploring and letting people figure things out. Now is not the time to standardize on best practice.
What's appropriately hyped: trying to drive towards orchestration of running multiple things at once. It opens up really fun avenues and will be common practice soon.
What's overhyped: Gas Town — that setup where someone ran a million agents with a management layer of seven agents on top. Too complicated to reason about what the hell is going on. It also goes against the lesson that if you optimize too much based on today's systems' traits, when the general models get better, you'll have to throw a lot of that work away.
Also overhyped: OpenClaw (or OpenQuadBot, or whatever it's called now) — the idea that you'd hook it into WhatsApp and have it pinging you all the time. Andrew's take? If you're using it for work, you're probably not doing the work if you're just texting your bot over WhatsApp. That time would be better spent setting up good test harnesses.
Andrew fears a future where we're all anxiously online, trying to keep agents running 24/7. Instead of interesting work, it’s just nudging many bots. That strikes him as a bleak future.
"I'm at my laptop plenty. I work plenty. When I'm doing good work, it's pretty dense. If I'm on my way home, I really don't need to be slacking with a bot that's routing through a server to execute Claude Code. It's just a bit much."
And on the flip side: If you're not an engineer but you use AI at work, that becomes less fun to use during personal time because it just reminds you of work.
Think Less About What AI Is And More About What It Does
There's a delineation between thinking about something for what it is versus what its impact will be. One mode is the carpenter who knows everything about every step of building a piece of furniture. The other is black box thinking: The thing is just whatever I observe it to do. How does it behave? Does it do what I need it to?
For engineers using AI (or anyone using AI to write an email), one mode asks: Is it perfect? Does it reflect how I would have done it? Am I excited about the quality and traits of this system? Can I rely on it? The other mode asks: How do I assume this thing will crash into walls and set up scaffolding so I can let it run and it'll be pretty safe? Just make sure it hits the goal.
It's not that one is right and the other is wrong. You have to start reasoning about which mode this particular situation calls for. But by and large, AI forces people into the latter mode: How do I reason, not about what I want this thing to be, but about how it should behave? How do I set up scaffolding to let the system self-improve?
That's a scary way to operate for some people, but it's just a different mode of thinking that drives more useful conversations. Teams everywhere are having challenging conversations about what's too much, what feels unsafe, what feels like going too fast.
The answer? Get more specific. Which parts of your company, business, or product are allowed to operate in the "if it's working as intended, that's fine" mode versus "we're depending on this primitive, let's make sure it's carefully defined"? Realizing both modes of thinking are helpful lets you have a conversation about which mode this particular situation calls for.
The Real Shift Happened Recently
What stood out to me from this conversation was Andrew's timeline. His work didn't change until five months ago. Claude Code wasn't useful until late 2024 when it tipped over the precipice from "good to fill in niche parts of coding" to "good at what it does."
It went from good for hobbyists (while professional engineers said "I would never use that code") to engineers having differing opinions to now. And that opens up anything else you might code.
It’s less "glue to help at the margins with existing workflows" and more "we're building scaffolding around something that can execute pretty well on long polls, run a continuous thread for a while, and expect good results."
That wasn't true in early 2025, but now it is. That's how fast this is moving.
Listen to the full episode of Actually Intelligent to hear more from Andrew Bihl about turning two aha moments that led to Numeric, why accounting is really a data engineering problem, and why nobody should be anxiously texting their AI bot on the way home.
LEAVE A COMMENT