An accountant who's never written code got 63 people arguing: how should we really be using AI?

Anthropic has aresearch reportanalyzing 235,000 people and 400,000 Claude Code sessions. It gives this example: an accountant who has never used Python, but who can clearly tell the AI which reconciliation rules to follow and can catch the edge cases it misses in month-end close, is the expert on that task.

The report also found that success rates for the top ten occupations all fell within seven percentage points of software engineers'. Managers scored slightly higher.

I turned this into a Threads post that opened with "An accountant who has never written a single line of code."

Then it blew up.

More than 12,000 views, and 86 comments from 63 people. Some said I didn't understand software. One called it the most bullshit AI post they'd ever seen. One asked if I'd dare ship it to production. The latest comment opened with "Anyone can tell you're a noob."

I read every comment, one by one, and personally replied to twenty-some of them.

Then I used my usual method: I pulled all the comments and had AI categorize and count them. It took a few minutes.

That's right: the stats on a fight over whether AI is any good were compiled by AI. Several people even tagged Meta's AI into the thread to act as referee. By the end, everyone was asking AI.

What the comments were really arguing about

Here's how the AI sorted them.

Engineering expertise isn't the same as domain knowledge: 17. Questioning the data or the baseline: 15. Pure mockery and trading insults, from both sides: 15. Domain knowledge comes first: 12. Spam or off-topic: 12. Personal horror stories: 6. Compromise or division of labor: 4. Dismissed it as AI-written or bullshit: 3. Everyone will get replaced: 2.

Categorizing inevitably involves some subjectivity, but the direction is clear: the opposition was louder than the support.

What's interesting is what happens when you lay out the opposing examples one by one.

One person said someone at their company asked AI to run the numbers in Excel, and it hardcoded the results, with no formulas at all.

One said AI will pull an entire table and loop through it row by row, when a built-in database function could do the job in a fraction of a second. Then they added: if you don't know, don't say, and don't ask, AI will just pick any path that gets the job done.

One said that if you don't tell AI to handle something, it won't necessarily handle it.

One said that AI couldn't find a database, so it simply created its own. The user didn't notice, old and new data ran separately, and eventually something went badly wrong.

I believe all of these. I've run into them myself.

But look: who is the subject of these stories?

Nobody watching, nobody checking the work, nobody knowing what to ask.

Are these stories about AI being unable to write code? No. They're about users who don't know how to use it, and about nobody being accountable when things go wrong.

Even the comment calling me a noob put it this way: AI is better at programming than humans, and only people with domain knowledge and a view of the big picture can make AI work for them.

They called me a noob, and I won't argue with that. But that second part is exactly what I've been trying to say.

The kinds of heat I saw

After reading all the comments, I saw roughly five kinds of reaction. This is my own reading, and I can't claim it's what those people actually think.

The first is leading with credentials. "I majored in this." "I work at a trillion-dollar company." "You're not even an engineer." These lines argue about who's qualified to speak, not about what AI can do.

The second is changing the definition. Once the thing has been built, the question becomes: which part of talking to AI actually counts as "writing" code?

The third is raising the bar. I talk about accountants reconciling books, and someone asks whether an accountant could handle Singles' Day traffic. But accountants were never supposed to handle traffic. What they care about is whether every transaction is correct.

The fourth is the unfair comparison: setting the worst results of amateurs misusing AI against the best work of senior engineers. What about code written by human engineers? Security incidents and projects that broke on launch day were plentiful long before AI. Do engineers never write bugs?

The fifth is drawing conclusions from seeing it used badly. They watch a colleague botch it once and decide that's all AI can do. But models change every few months, and an impression from six months ago may already be out of date.

Of course, not everyone who disagreed fits these patterns. Some people really do carry production systems every day and have seen too many incidents, so there's a reason they speak bluntly. One engineer said that conflict with users actually reassures them, because each side understands half the picture. I have real respect for that.

And some people on the supportive side went too far as well. "Don't overthink security" is not something I would ever say.

Accountants don't understand network architecture or security. Of course they don't.

But does a backend engineer have frontend expertise? Everyone has gaps. The only difference is that getting stuck used to mean finding someone to ask, and now you can ask AI first.

What Jensen Huang and Karpathy are doing

In a video interview, Jensen Huang said he wants his company's engineers to stop spending time on typing. Cisco, summarizing hisremarksfrom this February, also wrote that code itself is becoming a commodity, and that what matters is domain expertise and understanding customers' problems.

That isn't telling engineers they're out of a job. It's telling them to spend their time on things other than typing.

Late October brought a more concrete example.

Andrej Karpathy, an AI luminary formerly of OpenAI and Tesla, opened YouTube one night and found the recommendations terrible.

The next morning, he asked Claude to build him his own YouTube, sourcing videos from those recommended on Hacker News.In about two hours, HackerTube was live。

His method was simple: the Claude Code desktop app on a Mac, Opus 5.5, effort set to Medium. He says he no longer reads or writes code, or even types terminal commands. He just talks to Claude.

He did only three things himself: applied for an API key on Google Cloud, spun up a server, and bought a domain.

Once the server was up, he gave Claude the IP and told it to update, deploy, secure, harden, and optimize.

And Claude finished the job.

I know some people will say: that's Karpathy, of course he knows to mention "security."

Yes, and that's exactly the point. He knows what to ask.

So what about those of us who aren't Karpathy?

The question I ask AI most often

"What is this? Explain it to me in plain language."

That's probably what I've asked AI more than anything else. I don't come from engineering. I've been a PM for 30 years, and I still can't write code.

One commenter said that I only mentioned SSL and encryption later, so I must have asked AI to find out about them.

Even if I did, so what?

I asked, so now I know. Next time I'll bring it up myself.

That's how I've learned web technology over these past few years. When a term I don't understand pops up, I ask what it is, why it's needed, and what happens without it. I keep asking until I get it. AI doesn't get annoyed with me, and it never replies, "You don't even know that?"

The engineers' strongest rebuttal is this: if you don't know something needs handling, you won't tell AI to handle it.

That's true. But the solution is in the same chat box.

When you finish building something, ask one more question: "What haven't I thought of? What could go wrong with security? What happens if people use this at the same time?"

What you don't know is no longer a wall. You just have to ask.

Starting from that old-and-new database comment: other people's old code

In that comment from earlier, AI created its own new database, and old and new data ran separately. I replied that old and new clashing happens all the time. It also brought to mind the thing I feel most strongly about.

Anyone who has managed engineers knows that taking over someone else's code is the most thankless job there is.

The author left long ago. There's no documentation, or the documentation is three years old. Understanding it takes days, and during that time you appear to produce nothing. Change one line and you don't know what will break; when it does break, the blame lands on you. So the answer you often hear is: this is so badly written that it's faster for me to rewrite it.

That's not engineers being lazy. I'd make the same choice. People only have so much time and patience.

AI is different. It has no emotional resistance to reading other people's code. Given enough tokens, it can read an entire legacy system file by file, map out where each feature lives, how data flows, and what looks likely to break, then write it all up as documentation for you.

We've taken on exactly this kind of project: a membership system someone else had written, with more than 9,000 members. The first time I connected to it, text messages weren't going out and the disk was almost full. I couldn't understand a line of the code. AI investigated and reported back: the text message problem had nothing to do with the code. The SMS provider only allowed Taiwanese IP addresses, and the server was in Japan. The disk was full because more than a thousand old backups and logs had piled up. It was all fixed the same day, and disk usage dropped from 91% to 41%.

If we'd hired someone, just getting them to understand this system wouldn't have come cheap.

Here's a less appropriate example, but one that shows what AI can do. Lately,people have been using AI to decompile old games, meaning they work backward from the finished product to the original code, then port it to new platforms. It's become so common that Anthropic is about to add rules to Claude Code to stop it from recreating other people's games.

This involves other people's intellectual property, so blocking it makes sense, and I'm not encouraging anyone to do it. My point is that AI can chew through things even without the source code. So when a company has all the source code for its own legacy system, what reason is there to think it couldn't handle that?

But there are things it can't read.

Code shows what was done, not why it was done that way. That one odd rule may come from a major client's contract. The commenter I mentioned nailed it: AI won't know what's been handed down within a company but never documented.

So the order matters. First have it research, reading without changing anything, and list what it can't make sense of. Take that list to the people still at the company. Only then start making changes, and back everything up first.

See? It comes back to the person using it again.

So what about responsibility?

The best question in the comments was: if you can't write code, how do you know it works?

I don't know whether every line is right. Honestly, bosses don't know whether every line their engineers write is right either.

So I look at other things.

We currently run dozens of projects, some for clients and some of our own. I don't read the code, but I do set requirements. Changes aren't done until they pass automated checks. Services must be monitored and send an alert when they go down. Backups must actually have been restored once; having a backup file doesn't count. Before anyone says something works, they have to walk through the real user path and send an actual LINE message.

AI does all of this for me. But the rule that these things must be done is mine.

It has messed up, too. Early one morning in August, while we were changing code for our 94eat, a scheduled AI had just touched the same section first. Several parts of the later change failed to match up, and no error was raised. Our LINE bot went silent for 80 minutes, reading messages without replying. We had tested before launch, but we tested the web path, which happened not to be the one that broke.

Engineers will probably say: see?

But the same thing happens to engineers. What matters is that we changed the rules afterward: every edit must be confirmed to have actually applied, and tests must follow the path that actually changed.

That's what responsibility is: someone is there when things go wrong, and the same mistake doesn't happen twice. It doesn't have that much to do with whether you can write code.

Back to the human work

So can AI write code or not?

That's the wrong question. It can already help with a great many things. What matters is who's using it, how they're using it, and who's responsible.

Engineers won't lose their jobs. People who can make those architecture and security calls will just move faster with AI. Accountants don't need to become engineers either. If they can spell out the rules of reconciliation clearly, they'll get much further than they could before.

One commenter compared this to carriage drivers: however skilled, they can't beat the engine. I only half agree with that analogy. Carriage drivers did disappear, but more people wanted to travel far.

AI can help in far more places than we can currently imagine.

Finding those possibilities, I think, is our work as humans.