Dividing Labor With AI: Who Does What on a MEV Bot

The Moment I Caught Myself Outsourcing My Own Judgment

I am sitting at my desk at one in the morning, watching a draft transaction get rejected for the fourth time this hour. The AI assistant I work with has just produced its third proposed fix in twelve minutes. The fixes look reasonable. They cite the right error code. They reference the right account. I almost paste the third one in without reading it.

Then I stop.

Not because I caught a bug. Because I realized I had no idea what the bot was actually doing anymore. I had become a relay between an AI that produces plausible-looking patches and a Solana RPC that produces plausible-looking errors. Somewhere in that loop, the part where a human being decides whether the patch makes sense had quietly slipped out.

This is the question that has been sitting on my chest for weeks: as I build this MEV bot with an AI partner, what exactly is my job? What is its job? And what happens when those two get blurred?

Why This Question Is Suddenly Everywhere

This is not just my problem. It is the dominant labor question of the moment, and the data that has come out of academic and industry research over the past year is finally precise enough to argue with.

The World Economic Forum's Future of Jobs Report 2025, based on a survey of more than 2,800 companies, projects 170 million new jobs created and 92 million displaced by 2030 — a net gain of 78 million — driven heavily by AI and information technology. The same report says that 39% of core skills are expected to change by 2030, and that 86% of employers expect AI and information processing to transform their business by the end of the decade.

A solo developer building a single bot is not the same problem as 2,800 companies redesigning their workforce. But the underlying question is identical at every scale. The interesting answer is not "AI replaces humans" or "AI cannot replace humans." It is: which specific decisions, on which specific tasks, belong on which side of the keyboard?

That is the question I want to work through here, using my own day-to-day with the bot as the case study and the published research as the second opinion.

The 88% Insight That Changed How I Think About the Split

The single most useful data point I have read this year comes from a 2026 paper in Management Science by Fügener, Walzner, and Gupta. They ran an image classification experiment and reported four numbers that I think every developer working with AI should tape to the wall:

• Humans alone: 68% accuracy
• Full automation (AI only): 77%
• Full augmentation (human and AI on every task): 80%
• Optimized framework (right task routed to the right agent): 88%

Notice what is happening here. Naive augmentation — "I just have AI help me with everything" — beats both humans and automation, but only modestly. The big jump, the eight extra percentage points, comes from routing. From deciding which tasks should be handed to AI, which should stay with humans, and which require both. The researchers call this between-task complementarity, and they make the point explicitly: "Higher levels of between-task complementarity lead to a higher share of automation benefits through substitution and reallocation."

For me, this lands as a personal indictment. Most of the time I am not doing optimized routing. I am doing "AI helps me with everything," which is closer to the 80% case than the 88% case. The gap between those two is not a software feature. It is a meta-skill that nobody trains for: deciding, on each new task, which agent should own it.

The rest of this post is essentially my attempt to think harder about that decision.

What AI Genuinely Earns Its Keep On

There is a temptation, especially after a frustrating debugging session, to swing toward the "AI is overhyped" pole and start writing everything myself. I have done this. It is not a productive mood. The honest catalog of where AI is actually carrying weight in the bot project looks something like this.

Boilerplate and scaffolding. New file, new struct, new test harness, new wrapper around an RPC call. This is the lowest possible cognitive load for me and the highest possible accuracy for the model. I would estimate, qualitatively, that the time savings here are dramatic — closer to the Harvard Business School study's reported 75% reduction in writing time than to anything more modest. The HBS researchers, Iavor Bojinov and Edward McFowland III, studied 78 employees at a derivatives trading firm and found a 63% reduction in conceptualization time and a 75% reduction in writing time when AI tools were introduced. My experience on scaffolding tracks that range.

Search across a large surface area. "Find every place in the bot that calls this function." "Show me everywhere this constant is referenced." "What does this error code mean across all the DEX SDKs we care about?" AI is dramatically better than I am at chewing through that volume in seconds.

First-pass synthesis of unfamiliar material. When I bring up a new DEX, the first thing I want is a structured summary of its account model, its instruction layout, and the rough shape of its fee logic. AI can produce that summary in a minute. It will be wrong in places. But it gets me to "I have a working mental model" two hours faster than reading the source code cold.

Translating between idioms. I think in one programming language; the bot is written in another. AI is excellent at the mechanical conversion between the two, including the parts that involve idiom rather than syntax — moving from imperative loops to iterator chains, from null checks to option types.

Drafting documentation and commit messages. Not because I cannot write them, but because the marginal value of the time spent is low and the model produces something I can edit in thirty seconds. This is a Walmart-receipt task: I want it accurate, I do not need it to be art.

If I had to summarize where AI is most reliable, it is on tasks that are pattern-heavy, locally scoped, and verifiable in seconds. None of those words describe the hard parts of building a MEV bot.

What I Cannot Hand Off, and Why

Now the other side of the ledger. This is the part that took me longer to recognize, because most of the failures here were silent — the bot kept running, the patches kept landing, and the quality damage was invisible for weeks at a time.

Defining the actual problem. This is the one I underweighted hardest. A 2026 piece in Metaintro puts it plainly: "AI can process vast amounts of data, but it cannot define what the actual problem is." When a transaction fails on chain, the AI will happily produce a fix for the symptom I describe. It cannot tell me whether I have described the right symptom. It cannot tell me that the real bug is two layers upstream in how I scope a particular kind of opportunity. That meta-question — "what are we actually trying to solve here" — is mine, every time.

Architectural decisions. Where does a piece of logic belong? Which boundary owns this concern? Does this new feature live inside the existing pipeline or beside it? AI will give me a defensible answer to any of those questions, and that is exactly the problem. A defensible answer to the wrong framing is worse than no answer, because it carries the false weight of having been considered.

Business logic correctness. A report from CodeRabbit, which analyzed 470 open-source GitHub pull requests, found that AI-co-authored PRs contained 10.83 issues per PR versus 6.45 for human-only PRs. (CodeRabbit sells code review tools, so they have a commercial stake in the finding; their methodology infers AI authorship rather than confirming it. I treat the direction as credible and the magnitude as a ceiling.) The most striking number in their breakdown is security vulnerabilities running up to 2.74 times higher in AI code and performance regressions running roughly eight times more common. That last figure matches my experience precisely. AI-generated code defaults to clarity over efficiency. On a hot path where one extra clone or one extra round trip can move the needle on whether a transaction lands first, those defaults are quietly expensive.

Risk and tradeoff judgment. Whether to ship a change. Whether the marginal improvement justifies the marginal complexity. Whether a new failure mode is acceptable given the upside. This is the part where the Harvard Business School Institute for Business in Global Society's framing rings true: "AI can't reliably distinguish good ideas from mediocre ones or guide long-term business strategies on its own." In a MEV context, "long-term strategy" sounds grandiose, but it is just the accumulation of those daily tradeoff calls. AI does not have the context to make them.

Catching what the AI didn't notice it didn't notice. This is the one that scares me most. AI failure modes are not random; they are systematic. Surface-level correctness without control-flow protection. Repository conventions ignored. Local business logic violated. CodeRabbit's report flags exactly these patterns. Once you internalize that the failures cluster, you stop trusting your eye to catch them in passing review. You have to read each diff like a code reviewer at a regulated bank, not like a teammate skimming a colleague's branch.

The EPOCH Framework, Translated to a One-Person Shop

MIT Sloan's March 2025 research produced a useful mnemonic for what AI struggles to replicate: EPOCH, standing for Empathy, Presence, Opinion/Judgment, Creativity, and Hope. Roberto Rigobon, one of the researchers, says it well: "We think it's important to ask different questions — looking more at human capabilities than AI capabilities and shifting toward what technology can give us rather than what it might take away." The authors specifically argue these should not be called "soft skills," because they are in fact the hardest skills to develop.

Most of the framework's examples are aimed at large organizations — emergency management directors, psychologists, public relations specialists. It is fair to ask whether EPOCH applies to a solo developer staring at a transaction log at 1 a.m.

It does, but quietly. The Opinion/Judgment slot is the one I draw on every time I decide whether to merge a change. The Creativity slot is what I draw on when none of the obvious solutions to a class of bug is working and I have to invent a new framing. The Hope and Vision slot is what gets me through the weeks where the bot's results sit at zero and the temptation to give up is real. Even the Empathy slot shows up in the form of imagining the next developer — including future-me — who will read this code and have to understand it.

These are the parts of the job that no model is going to take from me, not because the model is incapable, but because the responsibility is not transferable.

The Knowledge Distance Problem (Or: Why AI Doesn't Turn Beginners Into Experts)

This is the finding from the Harvard Business School study that I keep returning to. Bojinov and McFowland III broke their 78 subjects into groups by how close their day-to-day work was to the domain they were writing about. Three tiers showed up:

• Web analysts who lived inside the relevant domain scored 3.96 out of 5 on article quality.
• Marketing specialists, adjacent to but not inside the domain, scored 3.92.
• Technology specialists, the most distant from the domain, scored 3.42.

The gap between insider and outsider is roughly 13%, despite identical access to the AI tools. McFowland's interpretation: "The folks who are too far away from the domain experts lack either sufficient understanding...or lack the skills to use it effectively." And the kicker line from the researchers, which I have written down twice in two different notebooks: "GenAI can provide the map, but navigating the terrain is another matter."

For a MEV bot project, this is not abstract. There is a deep DeFi-specific terrain I have been learning — concentrated liquidity behavior, the way different DEX programs compose account inputs, the social dynamics of leader timing, the on-chain consequences of a sloppy transaction layout. I cannot delegate that learning to AI, because the AI can tell me what I do not know I do not know only when I already half-know it. The 13% quality gap is the gap between someone who can validate AI's output against real terrain and someone who is only checking it against the same map the AI used.

This has practical consequences. The more time I have spent in the actual on-chain terrain — reading real failed transactions, watching real account state move, comparing my mental model against what blocks actually contain — the more useful AI becomes to me. The causality runs in the direction I did not expect. Domain expertise does not make AI redundant; it is what makes AI valuable. A beginner with AI is not the same as an expert with AI, and pretending otherwise is the fastest way to ship code that ships bugs at scale.

The Cognitive Offloading Trap

There is a quieter risk that nobody warned me about at the start, and the DK Consulting piece from February 2026 names it clearly. They call it cognitive offloading. The argument: "When GenAI compresses ambiguity into a neat response, it removes the friction that prompts deeper thought." The author cites research showing a correlation between increased AI use and declining critical thinking performance.

The practical version of this in my day-to-day looks like the scene I opened this post with. The AI produces a fix. The fix looks plausible. I am tired. The path of least resistance is to apply it, run it, see if the error goes away. If it does, I move on. If it doesn't, I describe the new error and the AI produces another fix.

This is a loop that can go on for hours and accomplish nothing.

The specific recommendation from that piece is one I have started applying: "Before posing a research question to AI, add your own preliminary thought, hypothesis, or interpretation — even if incomplete or incorrect." Even forcing myself to write one sentence of what I think the bug is, before I ask, changes the texture of the conversation. The AI's response is no longer a complete answer I evaluate passively. It is a counterproposal I evaluate against my own.

In sports terms, the difference is between watching a relief player come in to finish the game and actually being on the field yourself with the relief player ready. Both roles exist. They are not the same role. If I want to stay sharp, the AI cannot be in the game for me.

What This Looks Like in My Actual Workflow

This is the section I almost left out, because it risks sounding prescriptive. Take it as one developer's working approximation, not as a rule.

For every task I sit down with, I try to ask which of three buckets it falls into.

Bucket one — AI owns it. Pattern-heavy, locally scoped, easily verifiable. Scaffolding a test, generating a struct from a schema, drafting a regex, writing a one-off script that processes a log file. I describe what I want, I read the output, I run it. If it works, it works. The verification is cheap enough that I do not need to slow down.

Bucket two — I own it, AI assists. Anything that touches the bot's core decision-making — what to scan, what to skip, how to size, when to send. Anything that touches a part of the on-chain interaction where a mistake costs real money. Here I write the framing myself, the AI fills in the mechanical parts, and I read every line of the diff as if the AI were a contractor I am not entirely sure I trust yet. The conversation is closer to pair programming with a sharp but green junior who happens to know every API by heart.

Bucket three — I own it, AI stays out. Architectural decisions. Tradeoff calls that depend on context the AI does not have. The post-mortem after a bad day where I am trying to figure out whether a string of failures shares a root cause or is just bad luck. The decision to stop chasing a particular kind of opportunity because the math no longer supports it. I have learned that I get worse outcomes when I bring AI into these conversations. The model's confident answer crowds out my own uncertainty, and my own uncertainty is the data I am trying to honor.

The routing is not always right. I miscategorize tasks all the time. But having even an explicit three-bucket model is better than the previous default, which was "ask AI first, think later." That earlier default is what the 80% augmentation case looks like in practice. The three-bucket model is my crude attempt at the 88% case.

The Skills That Compound Around Working With AI

One more piece of data, because it changed how I think about my own time investment. The WEF's 2026 follow-up reports that workers who pair AI fluency with strong human skills earn significantly more than peers who lean on only one. The same report puts analytical thinking at the top of the most-desired skills list, with seven out of ten companies in the 2025 dataset calling it essential.

When I look at how I spend my non-coding time on this project, I notice the time has shifted in the same direction the WEF data points. Less time learning new framework syntax, because the AI handles that surface. More time reading actual on-chain transactions byte by byte. More time thinking about why a failure happened, not just whether the patch made it stop. More time writing notes to myself in plain language about what I think is going on in the system, so that I have a hypothesis to test against rather than a blank screen to fill.

This is the meta-skill the research is pointing at without quite naming. It is not coding. It is not prompt engineering either. It is the discipline of remaining the person who decides what gets asked, what gets accepted, and what gets shipped. The WEF's 2026 framing — "the abilities to ask better questions, navigate ambiguity, empathize and turn ideas into action are not extracurricular; they are the defining competencies of our era" — sounds like a slogan until you watch your own project drift when those competencies slip.

What This Means Going Forward

The practical implication of all of this, for me, is that the work of dividing labor with AI is itself the work. It does not get done once and stay done. Each new feature, each new bug, each new DEX integration brings a fresh routing question. The 88% case from the Management Science paper is not a steady state; it is a discipline.

The other implication is one I am still working out. If domain expertise is what makes AI valuable — and the HBS data is hard to argue with on that point — then the worst possible strategy for a developer right now is to use AI as a substitute for learning the terrain. The short-term wins from doing so are real. The long-term cost is that you become the technology specialist in the HBS study, scoring 13% lower than the insider and not understanding why. You become someone who can move fast but cannot tell which direction you are moving.

I do not have a clean conclusion here, because I am still inside the experiment. The bot is still being built. The errors are still happening. The next patch the AI suggests will look plausible, and I will have to decide whether to read it carefully or just apply it. I am trying to default to reading carefully. Some nights I succeed.

Key Takeaways

• The most valuable insight from current research is not "AI helps" but the 88% finding from Management Science 2026: optimal task routing between humans and AI beats both pure automation and naive augmentation by a meaningful margin.
• AI earns its keep on pattern-heavy, locally scoped, easily verifiable tasks — boilerplate, scaffolding, cross-codebase search, first-pass synthesis. Time savings here can approach the 75% reduction the Harvard Business School study measured.
• AI systematically underperforms on business logic, architecture, and tradeoff judgment. CodeRabbit's analysis flagged security vulnerabilities up to 2.74x higher and performance regressions roughly 8x more common in AI-co-authored code; commercial bias noted, but the direction matches independent research.
• Domain expertise is not made obsolete by AI; it is what makes AI useful. The HBS study showed a ~13% quality gap between domain insiders and outsiders even with identical AI access.
• Cognitive offloading is a real risk: AI that compresses ambiguity removes the friction that produces thinking. Writing your own hypothesis before asking is a cheap, durable countermeasure.
• The meta-skill that compounds in the AI era is not coding speed or prompt craft. It is the discipline of remaining the person who decides what to ask, what to accept, and what to ship.