At Octomind, we build AI agents - but our code is still mostly written by humans. We love LLMs and use them everywhere we can, from our product to our internal workflows. But despite all the hype, we’re nowhere near “agents writing most of our code.”

*one of many, source: LinkedIn

A few vital things are “not there” yet. Here’s why it matters - and what it takes to actually close the gap.

Experimenting with coding agents in day to day coding

We’ve been using Cursor, Claude Code, and Windsurf for months, but none of us can honestly say they’ve boosted our productivity in a meaningful way (say, 20% or more). Sure, tab completions are often solid, and I’ve had some success getting them to generate unit tests - especially when there’s existing tests to copy from (like new routes).

Still, that’s nowhere near the 80%+ efficiency gains others claim. So, driven by equal parts FOMO and curiosity, my colleague Fabio and I decided to spend the past week implementing a roadmap feature entirely with AI.

Before diving in, we combed through the documentation for our preferred tools to make sure we weren’t missing anything useful. We also updated our Cursor rules and CLAUDE.md file to inject updated knowledge about our product and our dev workflow, enabled BugBot for AI code reviews and went to work.

The feature we tried to build (with AI)

At Octomind, we build an agent-powered end-to-end testing platform. Our tests aren’t tied to branches - they live centrally in our system, which doesn’t support branch-specific versions of test cases. That works fine until you start using branch deployments.

Picture a SaaS app with three tests: login, create post, edit post. The app under test is developed with branch deployments for each pull request (PR). Now imagine a branch that changes the login flow - say, it adds 2FA. The existing login test (which only checks username + password) will now fail, blocking the pipeline for that PR.

‍

At the moment, you’ve got two options:

1. Remove the failing test so it doesn’t block unrelated PRs, fix it manually (or via AI) to handle the new flow, merge, then re-enable it.
2. Update the test directly and merge your PR - but now every other dev’s pipeline breaks until you’re done.

Neither is great. One blocks others; the other breaks trust in your merge.

‍

To combat this, we wanted to extend the concept of branches to our tests. When a branch is created, you can spawn a branch-specific copy of a test. That copy runs only for that branch and can be edited freely. When the branch merges, the copy becomes the new default.

We figured this feature should be doable in about a week with two developers.

‍

First try: Running wild

As the first iteration, we let the agents roam. We did not expect this to work perfectly, but we wanted to see where it’s at.

We’ve got a decent-sized monorepo, so “just dump everything into context” isn’t an option. We take testing seriously and have guardrails the AI can use to check its own output.

So I wrote a detailed brief and attached the files it needed into the context. This wasn’t a ‘tiny prompt performing miracle’ thing - I iterated the prompt until it was as specific as possible. Within ~5 minutes, the agent produced a plan with reasonable 11 TODOs:

*Cursor agent produced a coding plan ‍

We hit run and that’s where it went sideways. The agent started cranking out lines, but stumbled on basics any dev would breeze through - like regenerating the Prisma client after a database schema change (yes, the Cursor rules spelled it out).

I went back and forth with it several times for clarification. It reported success with the message: “The feature should now work correctly! The fork button should be functional, and you’ll be able to see forked test cases using the new filter. 🎉” while:

• Not checking off all the TODOs
• Producing nothing that worked on our dev server (which it had access to via computer use)
• Ignoring basic coding guidelines we explicitly listed ‍

An incomplete list of misses that wouldn’t trip up a human dev here:

• Built a React component for new buttons… and never wired it into existing components
• Skipped our standard logging library
• Used very inefficient database queries (it made an extra request for every ID that is joined anywhere)
• Ignored our naming and structure conventions
• Added two new external libs for trivial stuff we already have

and I am not even talking about bugs here. These are just things that immediately stick out and would not have happened to a developer. -

Yes, we tried multiple rounds of “still doesn’t work - you forgot to actually use the new button” and similar nudges. The result: a 2,000-line PR that needs review and rework almost everywhere.

‍

Take two: Smaller, incremental changes

I decided to start over. We never expected this to just work - these agents are supposedly better at smaller features anyway. So I stepped back and thought through how I’d actually build it myself, step by step. This kind of ideation is where I usually do like using an LLM - not to code, but to bounce around approaches in planning mode. ‍

Then I had it make a plan again, this time for just the first piece: loading the correct test from the database given an execution URL.

It produced another long, seemingly sensible plan. I let it run - expecting to step in more often this time. After running through several contexts worth of chat, I had another pull request.

About 1,200 lines of code, just for this one part. Does it work? Well… it typechecks. Beyond that, who knows.

In the spirit of the experiment, I handed the PR to BugBot for review. It left four comments - one of them pointing out that transaction handling was broken. That’s not great for data consistency, so I fed the comment back into the chat.

‍

The AI’s response:

“Of course, massive oversight on my part, I apologize. Let me fix it: …”

Apology accepted, I guess. It did patch a few places, and when I asked if it saw any more issues, it replied:

Recommendation‍

• Fix Transaction Consistency: Ensure all database calls within getFullTestCasesWithPrerequisites use the same transaction client. (and … 7 more things)

All of this was in a single file. The only context it needed was the database schema - literally the thing it was just working on.

It also has a habit of making life easy for itself:

It’ll check for linter errors, but only by running head -30 and some regex filters, so it convinces itself everything’s fine. ‍

Confidently marking half-done work as finished, apologizing for “massive oversights,” fixing things only to break others (look up the German word verschlimmbessern), and completely ignoring our existing designs and UX is not even the worst part.

‍

The issues that really matter

1. Loss of mental model

Let’s say the agent can now ship medium-complexity features with little help. And let’s even assume we’ve fixed the “wait 3 minutes, review 1000 lines of output” problem by turning developers into orchestrators of agents instead of coders. That’s the dream many LinkedIn posts are selling.

Even then, a huge issue remains: I lose my mental model of the codebase.

Right now, I know how changing one part affects another, where bugs tend to hide, and how the data model behaves. That intuition disappears when the AI keeps dropping thousand-line PRs that might even get auto-merged. When a teammate does that, I can trust they made thoughtful trade-offs, and I’ll pick up context while reviewing or building on top of it. With AI, that learning loop is gone.

So when a tough bug or edge-case feature comes up - the kind the AI still can’t handle - it feels like I’m seeing the codebase for the first time. Maybe I skimmed some reviews of features I know the AI can do by itself (unless I ran auto-review tools like CodeRabbit), but that’s nowhere near the understanding that comes from actually interacting with the code yourself.

Until I can trust the AI completely, I need to keep my own mental model alive. Otherwise, every time I need to do something myself feels like joining a new company.

‍

2. Absence of self-reflection

AI is currently bad at judging its own performance. Constant replies like these are only annoying if you let them get to you, but boy, is it hard not to:

I asked it to do so before implementing the feature, to which it responded with:

MODERATE CONFIDENCE - I can implement this correctly, but with some caveats: Overall Assessment: I can implement this task correctly, but it would require careful attention to detail, thorough testing, and potentially some clarification on the missing methods and business logic. The complexity is manageable but not trivial.‍

That sounds like a human engineer’s self-assessment, because the model is parroting human training data. The problem is that it shouldn’t use the training that is made by humans (at least until recently) to judge its own ability, because it is not a human.

And that’s the core issue: the model has no concept of its limits. You only find out if it can do the task by letting it try. An intern can say, “I’ve never done this.” An LLM doing so is very unlikely.

Worse, on our smaller follow-up task it graded itself even higher:

COMPLEXITY: HIGH - This is a substantial refactoring MY ABILITY: HIGH CONFIDENCE - I can definitely implement this correctly because:

• The plan is very detailed and specific about what needs to be changed
• I understand the current architecture and data flow
• The changes follow established patterns in the codebase
• The implementation steps are clearly outlined

The task is definitely implementable and I have high confidence I can complete it correctly - it’s just a matter of following the detailed plan step by step and implementing all the missing pieces.

The good parts of coding agents

AI absolutely has a place in a developer’s toolbox. I use ChatGPT or Cursor’s Ask mode daily - to brainstorm, debug, or get unstuck on smaller problems. Tab completions? They’re right about 80% of the time, which is good enough to keep them on. I even let AI handle things like writing unit tests for clean interfaces or refactoring small snippets. Wrapping a loop in Promise.allSettled is boring for me - but trivial and instant for AI. It’s also great at recreating well-known patterns from scratch - like traversing a tree structure.

And for non-technical users, automation powered by AI can be a massive unlock. That’s literally what we work on at Octomind: automating a technical task, but within well-defined boundaries using specialized agents. They don’t write the whole codebase; they handle narrow, observable parts of it where output constraints keep them in check.

Other focused tools can deliver similar value. And sure, maybe one day AI will truly handle everything it’s being credited with today (whether that’s LLMs or something beyond them). ‍

But we’re not there yet - and more people are starting to admit it.

‍ Veith Röthlingshöfer AI engineer at Octomind