Reviewing it line by line was slower than writing it — working with agents calls for a C-level mindset

2026-06-10 · Ascendy Engineering

TL;DR

The claim (my opinion): when you work with agents, approach it not like an IC but like a C-level executive.
It started with a common pain: reviewing AI-written code line by line was slower than writing it myself. “Is this even efficient?”
Honestly: that review used to be right. When models are weak, cross-validation is impossible. What changed is the models reaching senior level and above (my trust formed around Opus 4.7–4.8, GPT-5.5).
So now even review is better done agent-to-agent — a tired me rubber-stamping bad code caused problems more often than a Codex–Claude cross-check did (my observation). Just as a CTO controls the system, team, and culture that produce code rather than the code, your value shifts from doing/reviewing to designing the system that does and reviews.

Source note. This is a column/opinion piece written from an operator interview (the first-person experience of a solo operator running many agents at once). Opinion is marked as opinion, speculation as speculation — in particular, what I say about C-level is an outsider’s guess; I’ve never held that seat. Related: redteam, an adversarial agent-pair harness (the “system” here, made into a tool), two AIs picked the same answer, pairing two AIs made things slower.

Reviewing was slower than writing

At first it seemed obvious. Have the AI write the code, I review it, a human guards the last gate — it looked like the right picture.

Then at some point I paused. Reviewing the code Claude wrote, line by line, took me longer than just writing it myself. So is this efficient? A lot of developers are probably standing in front of the same question right now: “They said AI makes you faster — so why am I more buried in review?”

But — that review used to be right

Here I have to be honest. There was a reason I reviewed every line: the coding-agent models weren’t trustworthy enough. When a model is weak, cross-validation itself is impossible — a weak model checking a weak model just falls into the same pit twice. Back then, a human reading each line was the only gate you could trust. Review wasn’t inefficiency; it was necessity.

So the point of this piece is not “stop reviewing AI code.” What changed isn’t my posture — it’s the premise.

The threshold — doubt turning to trust

A moment came when each vendor’s LLM crossed a line into senior-level-and-above competence. For me, that trust formed around Claude Opus 4.7–4.8 and GPT-5.5. (This isn’t a benchmark claim — it’s the threshold at which I came to trust them.)

At that point the feeling changed. From doubt to trust, and then to relief. I could put down the compulsion that every line had to be stopped by my own eyes.

Even review is better agent-to-agent than human

Here’s an uncomfortable fact to admit. By now, even the review is something agents do better than I do.

Agents make mistakes too, of course. But those mistakes are overcome by cross-model checking. And crucially — agent-to-agent cross-checking beats human-to-agent. My evidence is my own experience. The frequency of problems from a tired or distracted me missing bad code and reflexively hitting “approve” was higher than the frequency from Codex and Claude cross-reviewing each other. Humans tire; models look with the same intensity every time.

What we hardened into a tool is the redteam harness we open-sourced — one model writes, a different one attacks it adversarially. (The “system” this piece talks about is exactly this kind of thing.)

A CTO doesn’t read the code — they look at the system

Then a thought struck me. Does a CTO or a team lead really have to pick through every line of code?

When code breaks, a senior-enough engineer doesn’t look at that code directly. Instead, they find the root cause and build a system so the problem can’t recur. Isn’t that the difference between a plain senior engineer and a manager-level one? And the view that extends that to the whole organization — isn’t that C-level?

A CTO not seeing every single error, not knowing how to fix a specific bug, doesn’t mean they lack skill. The position simply has a different way of working and a different altitude of view. That’s why they’re paid more. (To be clear — I’ve never held that seat, so I’m only guessing. This is a picture seen from the outside.)

”But don’t you lose control?” — half true

There’s an obvious objection. “A CTO who doesn’t read the code eventually gets fooled or loses control. Skip line-by-line review and garbage ships without you knowing.”

This is half true and half false.

For a small company, an early stage — it’s true. The code volume is small and you’re still setting the foundation, so it’s right for the CTO to keep some direct control over the tech and the code.
For larger scale or a big company — it’s false. At that scale, a CTO “reading the code” is a lie or a delusion. If they really are reading every line, that CTO is working wrong.

The moment scale grows, the object of control changes. Not the code, but the agents and the dev team that produce the code, and the dev culture. And here’s the crux — garbage ships not because the CTO skipped a review, but because they didn’t fix a broken dev system.

So — the posture every developer needs

Most developers’ first reaction is “I have to catch the agent’s mistakes myself.” Natural. But the higher view solves it structurally — not by catching each one, but by building a system that filters even when things go wrong.

As the volume, intensity, and scale of my work with agents grew, I came to change my view itself. And I think this posture is now needed by every developer.

The person who can best wield agents is one who went from IC to executive-level manager. Because they keep their hands-on instincts alive, yet they look not at the line of code but at the structure and system that produce the code.

Takeaways

The agent-era posture is C-level, not IC — not the person who catches the code, but the one who sees the structure that produces it.
But the premise is that models have reached senior level and above. Line-by-line review was right when models were weak. The posture didn’t change; the premise did.
Even review is better agent-to-agent (my observation) — humans tire and reflexively approve; models look with the same intensity every time.
The object of control moves from code to system. Garbage ships from an unfixed system, not a skipped review. Your value moves from doing/reviewing to designing the system that does and reviews — not abandoning craft, but relocating it.

Authorship & citation: Written by Ascendy Engineering; quotable with attribution. Found something wrong? Let us know via a GitHub issue.

Tags: ai-agent, engineering-management, ai-collaboration, developer-mindset, opinion