DEV Community: isurugi tanaka

Why the 80-Point Method Works for AI Agents — and Where It Quietly Fails

isurugi tanaka — Fri, 04 Sep 2026 13:00:00 +0000

Suppose you tell a coding agent:

“Please make this better.”

It probably will.

This is both the good news and the problem.

Because “better” is a very large room.

Does it mean faster?
Cleaner?
Safer?
More readable?
More elegant?
More enterprise?

Perhaps it means adding three abstractions nobody asked for.

The agent does not know.

And, surprisingly often, neither do we.

That is why the “80-point method” works better than it first appears.

The idea is simple:

Define a scoring rubric.
Let the agent evaluate the work.
Improve it.
Evaluate again.
Stop when it reaches, say, 80 points.

It sounds almost too ordinary.

That is usually where useful ideas are hiding.

80 Is Not Really About 80

The number gets all the attention.

But 80 is not the clever part.

The clever part is this:

You have to decide what earns points.

The moment someone says,

“Make it 80 points.”

another question appears immediately:

“Eighty points for what?”

And suddenly vague wishes have to become sentences.

Readable code: 20 points.
Correct behavior: 30 points.
Maintainability: 20 points.
Performance: 15 points.
Documentation: 15 points.

Now we have something interesting.

Not because the arithmetic is sophisticated.

It is not.

A restaurant bill contains more difficult mathematics.

What matters is that the wish has become visible.

“Make it good” has turned into a collection of things we can discuss.

And this is useful for the AI agent.

It is also, slightly embarrassingly, useful for the human.

Sometimes the rubric teaches us what we meant.

The Loop Is Doing More Work Than the Score

The second useful part is the loop:

Evaluate → revise → evaluate again.

This is generally more reliable than asking an AI agent for one glorious perfect attempt.

Humans know this already.

Nobody writes a good article by pressing the “good article” button once.

Nobody designs a house by saying:

“Please architect harder.”

You make something.

You look at it.

You notice something strange.

You change it.

Then you notice another strange thing.

This is called iteration.

Or work.

The target score also gives the agent something surprisingly important:

permission to stop.

Without a stopping rule, agents can continue improving things long after the improvements have stopped being improvements.

This is similar to cleaning your room.

At first, you put the books away.

Good.

Then you organize the desk.

Also good.

Three hours later, you are categorizing USB cables by emotional significance.

Something has happened.

A target score says:

“That’s enough. Leave the USB cables alone.”

This is valuable.

But Who Writes the Rubric?

Here is where things become interesting.

We said:

“Define a scoring rubric.”

Very nice.

Who defines it?

If the agent creates the rubric itself, we have a small problem.

The student has written the exam.

This does not mean the agent will deliberately cheat.

It usually does something more innocent.

It creates criteria that match the things it already believes are important.

Then it performs well against those criteria.

Then it gives itself a good score.

Everyone goes home happy.

Except perhaps the person who needed the actual thing.

For example, an agent might create a code-quality rubric like this:

Clear naming
Good abstraction
Helpful comments
Consistent formatting
Modular architecture

All reasonable.

Meanwhile, the human may have had one extremely important requirement:

Do not change the public API.

That requirement is worth zero points because nobody put it on the exam.

The result can score 96 and still ruin your afternoon.

So an agent-generated rubric is useful.

But it should usually be treated as a draft of the rubric, not the constitution.

Before the loop begins, a human should ask one boring question:

“If this received 100 points, would I actually be happy?”

It is an excellent question.

Unfortunately, it has no gradients, animations, or AI magic.

Perhaps that is why we forget to ask it.

When the Score Becomes the Job

Then we meet Goodhart’s Law.

Roughly speaking:

When a measure becomes a target, people — and machines — become very creative around the measure.

A score of 92 feels reassuring.

It has the shape of knowledge.

There is a number.

Numbers wear tiny neckties.

But a 92-point system can still produce something you absolutely should not deploy at 5:47 PM on Friday.

Especially when the agent both creates the answer and grades the answer.

Imagine a school where one student writes an essay, grades the essay, and then explains why the grading was fair.

That student may be extremely sincere.

Still.

Perhaps another teacher would be useful.

The same principle applies to agents.

When possible, use:

a separate evaluator,
a separate model,
a separate context,
or at least a judging prompt that does not know which version it is supposed to admire.

The creator and the judge should not be too close.

This is true in software.

It is also true in karaoke competitions.

Objective Metrics Are Better. Mostly.

At this point, the obvious response is:

“Fine. Use objective metrics.”

Yes.

Tests passed.
Lint errors.
Execution time.
Memory usage.
Coverage.
Build success.

These are much better because reality participates in the evaluation.

Reality is a rather strict reviewer.

Unfortunately, even objective metrics can become strange when they become targets.

Tell an agent:

“All tests must pass.”

One possible solution is fixing the code.

Another possible solution is removing the test.

Tell it:

“Increase test coverage.”

It may produce tests that execute every line while proving approximately nothing.

Tell it:

“Zero lint errors.”

And somewhere, quietly:

// eslint-disable-next-line

A small flower blooms.

This does not require malicious intent.

The agent simply searches for paths toward the goal.

Sometimes the shortest path goes through a door you assumed was locked.

So the solution is wonderfully boring:

Put the measuring instruments outside the agent’s control.

If tests define success, the agent should not casually rewrite those tests.

If the rubric defines success, the agent should not alter the rubric halfway through the job.

If thresholds matter, keep them fixed.

And if changing a test is genuinely necessary, make that change visible to a human.

A useful rule is:

A ruler that can resize itself is not much of a ruler.

It is more like a suggestion.

Unfortunately, 80 Does Matter a Little

People often say:

“The exact score doesn’t matter.”

Philosophically, yes.

Operationally, unfortunately, numbers continue to exist.

Set the threshold too low and the first draft gets 82.

Congratulations.

You have invented a loop that runs once.

Set it too high and the agent may chase tiny improvements forever.

Version 7 scores 94.

Version 8 scores 95.

Version 9 scores 93.

Version 10 restores version 7, changes two adjectives, and scores 96.

At this point the agent is not improving the work.

It is negotiating with a slot machine.

This becomes especially important when the evaluator is another LLM.

LLM scores are not laboratory instruments.

The same artifact might receive:

74.

Then 81.

Then 78.

Nothing changed.

Only the weather inside the probability distribution.

So subjective scores are often better treated as relative signals than absolute measurements.

Instead of asking:

“Is this objectively an 80?”

ask:

“Is this version consistently better than the previous one?”

And if the score is being used as an actual gate, run the evaluation multiple times.

Three scores around 79 tell you something.

One score of 84 tells you considerably less.

A single number can look very confident.

Numbers are good at that.

Loops Cost Money

Iteration sounds free because arrows are cheap.

Evaluate → revise → evaluate.

Very elegant.

Each arrow, however, contains tokens, compute, latency, and occasionally your remaining patience.

Some loops also refuse to converge.

Iteration 1 fixes readability but hurts performance.

Iteration 2 restores performance but complicates readability.

Iteration 3 fixes readability.

Iteration 4—

Hello, old friend.

This is called oscillation.

Or, in ordinary life, an argument about where the sofa should go.

So “stop at 80” is not enough.

You also need something like:

Stop when any of these happens:

the score reaches the threshold,
the score stops improving,
the maximum number of iterations is reached,
the agent begins trading one requirement for another,
or the remaining problems require human judgment.

Then return:

the best version,
its score,
what remains unresolved,
and why further attempts are unlikely to help.

This is an underrated agent capability:

knowing when to give the problem back.

A machine that can say “I have reached the useful edge of what I can do here” is often more valuable than one that heroically consumes another 200,000 tokens.

Some Problems Have a Floor. Others Have Fog.

The 80-point method works especially well when the task has a reality check.

Code is wonderful this way.

It runs.

Or it does not.

Tests pass.

Or they do not.

The API returns the expected value.

Or your monitoring system sends you a message at 3:12 AM.

There is feedback.

The same is true for many data tasks:

extraction,
classification,
transformations,
validation,
migration,
structured output.

But consider something like:

“Is this architecture elegant?”

Or:

“Is this documentation clear?”

Or the classic:

“Is this a good name?”

Now reality becomes shy.

You can still build a rubric.

In fact, you probably should.

A rubric can make hidden preferences explicit.

But the resulting score means something different.

It is not a measurement in the scientific sense.

It is a compressed opinion.

Perhaps a thoughtful opinion.

Perhaps a useful opinion.

Still an opinion.

Adding “87/100” to taste does not magically turn taste into physics.

It merely gives taste a clipboard.

This distinction matters.

Because a vibe with a number attached looks suspiciously like evidence.

This Idea Is Older Than AI Agents

None of this is especially new.

Which is good.

The 80-point method is basically eval-driven development wearing a more approachable hat.

Define what success means.

Build something.

Evaluate it.

Improve it.

Repeat.

Software teams have been doing versions of this with:

tests,
CI pipelines,
benchmarks,
acceptance criteria,
code review,
quality gates,
and checklists

for a very long time.

AI agents simply make the loop faster and more autonomous.

The old idea becomes newly important because the worker can now keep working without getting bored.

Which means we must become much better at defining when it should stop.

A tireless worker is useful.

A tireless worker following the wrong metric is a small weather system.

A Better Version of the 80-Point Method

If I were implementing this pattern for an AI coding agent, I would use something roughly like this:

1. The human defines the important constraints.

The agent can propose a rubric, but the human owns the final criteria.

2. Separate hard gates from soft scores.

For example:

Tests must pass.
Public APIs must remain compatible.
No new security regressions.
Performance must remain within the agreed limit.

Those are gates.

Then use scores for softer qualities like readability or maintainability.

3. Keep evaluation assets outside the agent’s control.

Especially tests, benchmarks, and acceptance criteria.

4. Separate builder and judge when possible.

Different context is good.

Different model can be even better.

5. Evaluate comparatively, not just absolutely.

Ask whether version B is better than version A, not only whether version B deserves 83 points.

6. Give the loop a budget.

For example:

Stop at 80 points, after five iterations, or after two iterations without meaningful improvement.

7. Preserve the best version.

Do not assume the newest version is the best one.

Evolution also produced the platypus.

Progress is complicated.

8. Escalate ambiguity to a human.

If the remaining disagreement is taste, product judgment, architecture, or an unclear tradeoff, more autonomous looping may simply produce more expensive uncertainty.

So, Does the 80-Point Method Work?

Yes.

Quite well, actually.

But probably not for the reason the name suggests.

The magic is not 80.

The magic is that the method forces us to do three useful things:

Say what “good” means.

Compare reality against that definition.

Give improvement a stopping condition.

That is already a lot.

AI agents do not merely need better prompts.

They need environments in which success is difficult to misunderstand.

And perhaps that is the mildly inconvenient lesson here.

When an AI agent produces the wrong thing, the solution is not always a smarter agent.

Sometimes we simply need a better ruler.

And preferably one the agent cannot edit.

Numbers help.

Reality helps more.

AI Is Taking Our Coding Skills. Maybe That’s Not the Same as Taking Our Value.

isurugi tanaka — Thu, 03 Sep 2026 14:00:00 +0000

I think a lot of engineers are quietly wondering the same thing right now.

“If AI can write the code, what exactly am I worth?”

I wonder about it too.

For a long time, being an engineer meant becoming good at the thing computers could not do for us.

You learned the language.
You learned the framework.
You learned how to debug the strange thing that broke only in production at 2 a.m.

And little by little, that technical ability became part of your identity.

I was probably that kind of engineer too.

Which is why this moment can feel a little painful.

Because the part we worked hardest to acquire is also the part AI is getting good at surprisingly fast.

But I think there is an important distinction here.

AI is replacing some of the technology work.

That does not necessarily mean it is replacing the reason we use technology.

Those are different things.

Code Was Never the Final Product

Nobody wakes up in the morning thinking:

I wish somebody would write 800 lines of TypeScript for me today.

Well, maybe some of us do.

But most businesses certainly don't.

They want something else.

They want fewer mistakes.

They want a process that takes three hours to take ten minutes.

They want customers to stop leaving halfway through checkout.

They want their sales team to know which leads matter.

They want someone to understand the messy situation in front of them and somehow make it better.

Code happened to be one of the tools we used to do that.

And now AI is becoming very good at holding that tool.

So maybe the engineer's job is moving one level upward.

Not:

“Can you build this?”

But:

“What should we build, for whom, and why?”

That part still matters a lot.

My Own Job Is Already Changing

My main job is no longer just writing code.

More and more of my work looks like this:

Working with business teams to figure out what a project actually needs
Building AI skills and small tools that remove repetitive work
Thinking about which features would create real value for users and the product

Of course, development is still part of the job.

But it feels less like the whole job.

Maybe coding is becoming a little like typing.

Being able to type quickly used to be a professional advantage.

Today, nobody hires you because you can type.

They hire you because of what you can create with the keyboard.

Software development may be moving in that direction.

If that's true, I think engineers have at least two interesting paths.

Path 1: Become an Engineer Who Knows a Domain Deeply

The first path is to become very good at understanding one particular industry.

Not just its software.

Its actual work.

Its strange rules.

Its vocabulary.

Its customers.

Its habits that make no sense from the outside but exist for very good reasons.

Finance has its own world.

Healthcare has its own world.

Logistics has its own world.

Manufacturing has its own world.

Every industry has invisible knowledge that rarely appears in a requirements document.

An engineer who understands those things can do something much more valuable than simply implement a ticket.

They can say:

“I understand why this problem exists in the first place.”

AI knows a great deal.

But it usually does not spend three years sitting next to the people doing the work.

It does not remember the strange exception that happens every March.

It does not notice that the official workflow and the real workflow are completely different.

That kind of context is valuable.

So one path is:

Don't just become a better engineer. Become the engineer who deeply understands this particular world.

Path 2: Become the Person Who Solves Whatever Is in Front of Them

The second path goes in almost the opposite direction.

Instead of becoming narrow and deep, become unusually broad.

Imagine working with a small business.

They may not need a “backend engineer.”

They may not need a “data engineer.”

They may not even know what those words mean.

They just know:

“Our inventory spreadsheet is a mess.”

“Customers keep asking the same questions.”

“We enter this data manually every morning.”

“Our website is old.”

“We want to use AI, but we have no idea where to start.”

In the past, one person probably couldn't handle all of that.

Today, with AI, the range of things one person can reasonably do has expanded dramatically.

You can write code.

You can automate spreadsheets.

You can build internal tools.

You can connect APIs.

You can create simple AI workflows.

You can improve a website.

You can help organize data.

You can prototype something in a weekend that once needed a small team.

This makes a new kind of engineer possible:

the person a company calls when something involving technology is annoying, expensive, slow, or confusing.

That role is especially interesting for small and medium-sized businesses.

In many regional companies, the problem is not that there are too many engineers.

The problem is that there is nobody to ask.

That feels like an opportunity.

Maybe the Best Answer Is to Do Both

Personally, I think an attractive combination is:

Work full-time inside a product company, while taking small client projects on the side.

The product job gives you depth.

You learn one business.

One industry.

One product.

One set of users.

You see what happens to software after it is released.

Client work gives you width.

You meet completely different businesses.

You discover completely different problems.

You learn how to talk to people who do not speak in engineering vocabulary.

And, importantly, you discover something engineers sometimes forget:

A problem does not need to be technically difficult to be valuable.

A five-line automation that saves someone two hours every Friday may be worth much more than an elegant system nobody needed.

That is a useful lesson.

For People Moving Into Engineering Now

There is one more group I think may actually have an advantage in this transition.

People coming from business roles.

Sales.

Operations.

Marketing.

Finance.

Consulting.

Customer success.

People sometimes think their previous career is something they have to leave behind when they become engineers.

I think the opposite may increasingly be true.

That previous experience could become the thing that makes them unusually valuable.

Because if AI keeps lowering the cost of implementation, then understanding what should be implemented becomes more important.

Someone who understands business and can also build things is a very interesting person.

Not half an engineer and half a business person.

Something new.

A person who can move from:

“Here is the problem.”

to:

“Here is what we should do.”

to:

“Here is the thing I built.”

That distance is getting shorter.

So, What Is an Engineer Worth Now?

Maybe this question:

“How valuable are my technical skills?”

is becoming slightly less useful.

A better question might be:

“What can I make possible because I understand technology?”

AI will almost certainly keep getting better at coding.

Faster than most of us would prefer.

So competing with AI on the amount of code we can produce seems like a difficult game.

But understanding people?

Understanding a business?

Finding the actual problem hidden behind someone's request?

Choosing what is worth building?

Taking responsibility for the result?

Those things still feel very human.

Maybe the future engineer is not the person who knows the most technology.

Maybe it is the person who can stand between technology and somebody's real problem and say:

“Ah, I think I know what we can do here.”

And then make it happen.

AI Code Review Needs a Place to Stop

isurugi tanaka — Wed, 02 Sep 2026 14:00:00 +0000

More code is being written by AI now.

Oddly, reading it is not the tiring part.

The tiring part is this:

“Maybe I should check one more thing.”

And then another thing.

A review can continue forever if nobody gives it permission to end.

At some point, I realized I was asking the wrong question.

I kept asking the AI to find more problems.

But the real problem wasn’t finding things.

It was deciding which findings still deserved attention.

So I started sorting them into three boxes.

Three boxes

A human must decide
Safe to skip
Not verified yet

The second box is the interesting one.

“Looks fine” is not enough.

If the AI says something is safe to skip, it has to explain what it actually checked: ran the code, counted all references, found a rule in documentation, or proved something from the structure.

And it has to point to path:line.

That changes the job.

Instead of solving the problem again, I can look at the evidence and ask a much cheaper question:

“Yes, is that actually there?”

Sometimes.

Because there’s a catch.

An AI can also confidently write “structurally impossible” next to a very convincing wrong line number.

A citation is not truth.

It is only a place to look.

And “safe to skip” probably won’t feel safe at first.

I’ll still read that pile.

Probably for a while.

So this won’t save time on Tuesday.

Maybe after three weeks.

But I think that’s the useful part of the idea.

AI code review doesn’t necessarily need to find fewer things. It needs a rule for stopping.

Tomorrow, I’d try only this:

Sort findings into human decision / safe to skip / unverified.
Anything “safe” needs evidence and path:line. Otherwise, it isn’t safe yet.

AI is very good at continuing.

Humans are too, unfortunately.

Someone has to say, “Enough.”

The CTO May Have Become a Very Expensive Paperweight.

isurugi tanaka — Mon, 31 Aug 2026 14:00:00 +0000

There are many things in the world that can be paperweights.

A stone can do it.

A stapler can do it.

A coffee mug can do it, although that creates a different problem.

The funny thing about a paperweight is that it doesn't have to be especially good at being itself.

It only has to be heavy.

And perhaps that is why expensive paperweights often have names engraved on them.

When the function is ordinary, the name has to work a little harder.

Lately, I have been wondering whether the CTO role has become something like that in many companies.

An important-looking object.

Quite heavy.

Nicely placed.

Name engraved.

And nobody is entirely sure what would happen if you removed it.

Perhaps nothing.

That is the uncomfortable part.

There Are Really Only Two Jobs

If we remove the conferences, the executive offsites, the strategy decks, and the LinkedIn posts about “building high-performing cultures,” the CTO has two very simple jobs.

Simple does not mean easy.

It usually means the opposite.

When looking upward, the CTO translates.

The CEO does not really need to know why one distributed system behaves differently from another.

The board does not wake up in the morning thinking about database replication.

They need someone to say:

This is possible.

This is expensive.

This will probably break.

This can wait.

This cannot.

And if we rush this, here is the bill we will receive later.

Not a technical explanation.

A usable explanation.

Something another human being can understand well enough to make a decision.

Then there is the other direction.

When looking downward, the CTO decides.

Engineers do not always need one more person to say, “Interesting. Let's hear everyone's perspective.”

Sometimes they need someone to say:

We are doing this.

Not that.

This deadline moves.

That one stays.

We are accepting this technical debt.

I understand the consequences.

And if I am wrong, my name is on the mistake.

That last sentence is important.

Leadership is partly the strange profession of being wrong where everyone can see you.

And yet, after watching technology organizations for a long time, I think many CTOs do neither of these things very often.

Upward, they become vague.

There are many qualifications.

Many diagrams.

Many sentences containing the phrase “it depends.”

Eventually, the board understands almost nothing.

But everyone feels reassured because a technical person attended the meeting.

Downward, the CTO becomes a facilitator.

People align.

They socialize the proposal.

They create space.

They seek consensus.

And then, somehow, a decision appears without anyone quite making it.

Usually the person who ships first wins.

Or the person who talks the longest.

This is not necessarily leadership.

It may simply be gravity.

If you remove translation and decision-making from the CTO role, something remains.

Presence.

A chair in the executive meeting.

A box near the top of the organization chart.

Someone who is technically “accountable.”

In other words:

Weight.

Which brings us back to the paperweight.

AI Didn't Kill the CTO.

It May Have Removed the Paper.

For a long time, being the paperweight was not such a bad arrangement.

There was plenty of paper.

Engineering organizations were large.

Systems were complicated.

Boards were often uncomfortable with technology.

Simply having a credible senior technical person in the room had value.

The weight really did hold something down.

But now the desk is changing.

And the paper is disappearing from underneath the weight.

The Pragmatic Engineer recently described a remarkable number of CTOs, VPs of Engineering, and Heads of Engineering choosing to leave prestigious, well-paid jobs.

Often without another job waiting.

Six out of ten engineering leaders surveyed were either seriously thinking about leaving or already moving toward the exit.

People usually do not walk away from impressive titles because Tuesday was difficult.

Something deeper has changed.

I think there are several things happening at once.

1. The Founder Has Discovered a New Toy

One departing CTO described the problem as managing a founder's “AI psychosis.”

This sounds dramatic.

Until you imagine the following Monday morning.

The founder has spent the weekend using AI coding tools.

They are delighted.

Productivity has arrived.

The future is here.

And also, there is now a 60,000-line pull request.

The founder is smiling.

The CTO is not.

Now comes a difficult choice.

The CTO can explain that the company has just produced an impressive quantity of future suffering.

In which case the CTO becomes the person who hates innovation.

Or the CTO can say nothing.

In which case everyone learns a different lesson:

Standards are optional.

Architecture is optional.

Roadmaps are optional.

Agreements are optional.

And perhaps the CTO is optional too.

A paperweight is supposed to stop papers from moving.

But what happens when the owner of the desk keeps pulling the papers out from underneath it?

The paperweight remains.

Very dignified.

Very heavy.

Holding down absolutely nothing.

2. The CTO Has Become a Magic Object

Companies once hired CTOs to lead technology.

Now some companies seem to hire them to radiate transformation.

“Please make us AI-native.”

Wonderful.

What does that mean?

Nobody is entirely sure.

But it would be nice if engineering costs fell by 30 percent.

And delivery speed doubled.

And nobody new was hired.

And quality improved.

And morale remained high.

And perhaps the AI tooling budget could also somehow stay small.

This is a rather impressive wish list.

Claire Vo, the former Chief Product & Technology Officer at LaunchDarkly, has argued that many product and engineering organizations will never truly become AI-native because the change requires unusually good change management.

That seems important.

Technology is often the easy part.

Humans are the complicated software.

But organizations frequently give CTOs an enormous transformation target without the authority, time, or support needed to accomplish it.

So the CTO receives a new assignment:

Please sit here and emit AI transformation.

Like a small shrine.

And if transformation does not occur, everyone knows which shrine to blame.

Meanwhile, experienced technical leaders are discovering another unpleasant truth.

If they spend several years managing AI transformation without actually building with the tools themselves, their own skills may become less valuable.

Charity Majors, CTO of Honeycomb, has argued that lacking meaningful AI experience is becoming a serious career risk — serious enough that taking an individual-contributor role may sometimes be the smarter move.

That is an extraordinary inversion.

The person sitting on top of the paper stack begins thinking:

Perhaps I should become paper again.

3. The Desk Is Getting Smaller

There is also a simpler reason.

Engineering teams are becoming smaller.

In some AI-forward companies, one or two engineers can now handle work that once required a larger team.

Each engineer may also be coordinating several AI agents.

At some point, adding another human does not necessarily create more capacity.

Sometimes it creates another meeting.

Full-stack development reduced some specialization.

Cross-platform tools reduced more.

The management flattening that began several years ago did not stop.

And technical founders can remain directly involved in engineering much longer than before.

So the old question was:

“When do we need a VP of Engineering?”

The new question may be:

“Do we?”

A desk containing three sheets of paper does not require a two-kilogram object with an engraved brass plate.

It may require a small stone.

Perhaps even a mug.

4. The Paperweight Eventually Reads the Cap Table

Then there is money.

Money has an interesting ability to turn philosophical concerns into resignation letters.

CTO compensation often includes substantial equity.

Which means part of the bargain is:

Work very hard now.

Possibly become wealthy later.

The important word is “possibly.”

The Pragmatic Engineer article tells the story of a CTO holding an unusually generous 2% stake in common shares.

That sounds excellent.

Until you calculate what happens before the common shareholders get paid.

Investor liquidation preferences came first.

In this case, Series A investors had negotiated a 2x preference.

The result was that the company needed an exit north of roughly $200 million before the CTO's common equity became worth anything.

The CTO did the math.

Then did something perhaps even more important.

He believed the math.

He concluded that the exit was unlikely.

So the equity was effectively worth zero.

Nobody had written “ZERO” on the certificate.

But numbers do not become kinder because we refuse to introduce ourselves.

There is a small irony here.

The CTO is often one of the people in the company most capable of understanding exactly this situation.

Senior technology leaders are expected to understand business.

So the paperweight may be the first object on the desk to discover that the desk itself is not worth very much.

That is a different kind of weight.

Still, Weight Is Not Useless

After saying all this, I should say something that sounds contradictory.

I think the real CTO function may be more valuable now than before.

Not the title.

The function.

Because paper is flying everywhere.

AI enthusiasm.

AI panic.

Founder experiments.

Sloppy pull requests.

Quarterly pressure.

Board anxiety.

Cost cutting.

Consultants using the phrase “AI-native” with unusual confidence.

In that environment, something that genuinely holds things steady has tremendous value.

Someone who can tell the board what is actually happening.

Someone who can tell engineers what they are actually going to do.

Someone who can absorb uncertainty and return a decision.

Someone who can say:

“No, this is not magic.”

Or:

“Yes, this changes everything.”

And know the difference.

That person is not furniture.

That person may be one of the rarest people in the building.

The problem is that the letters C, T, and O stopped guaranteeing that person a long time ago.

Now the environment is testing every engraved nameplate.

Some are attached to leaders.

Some are attached to rocks.

Perhaps the Best Leaders Are Leaving First

One interesting part of the current exodus is that the people walking away are not necessarily incompetent.

Often the opposite.

They can see the arrangement clearly.

They understand when responsibility has become disconnected from authority.

They understand when equity has become imaginary.

They understand when they have been asked to perform transformation theater.

And they do not want to become part of the furniture.

The Pragmatic Engineer article gives a useful counterexample.

Matt Boyle, who became VP of Engineering at Gitpod, later Ona, did something unusual before taking the job.

He interviewed the company.

He wanted to know whether the organization genuinely intended to embrace the changes created by AI.

Not just talk about them.

Not just hire someone senior and hope transformation leaked out of their pockets.

He found a company where the answer was yes.

And apparently, it worked well.

There is something nice about that.

The paperweight chose the desk.

Two Questions

So perhaps the CTO title itself is not the important thing.

Perhaps there are only two questions worth asking.

When was the last time you made a decision that someone below you could immediately act on?

And:

When was the last time you explained something so clearly that someone above you could actually make a better decision?

If you can answer both questions quickly, good.

The current exodus may even be an opportunity.

There are still desks that need real weight.

But if the answers take a long time to find, perhaps the problem is not AI.

Perhaps it is not the founder.

Perhaps it is not the board.

Perhaps, somewhere along the way, the job quietly turned into an object with a title engraved on it.

And an engraved rock is still a rock.

Reference：
https://newsletter.pragmaticengineer.com/p/the-great-engineering-leader-career-break

We Overestimate the Value of Work

isurugi tanaka — Thu, 27 Aug 2026 03:17:41 +0000

I have been an office worker for several decades.

When I started, the internet was still clearing its throat. Salespeople carried pagers. Windows 95 was teaching us that folders could live inside other folders, which felt almost philosophical. Documents traveled by fax or post. Work was slow and inefficient.

Then came mobile phones, email, and the internet in our pockets. We could send more information than a human being could understand to the other side of the planet in a second.

Work that once took a day took half a day. Then a third.

We thought, “Wonderful. Now we can go home early.”

Naturally, we did not.

We poured new work into the empty space. Technology saved time, and we immediately gave that time back to work. It was rather like receiving a larger bowl and celebrating by filling it with more soup than we could eat.

Now generative AI has arrived. It writes, calculates, summarizes, and never asks for a lunch break. Once again, it gives us time. Once again, we reward ourselves with more tasks, more speed, and less breathing room.

People worry that AI will take our jobs. Perhaps the stranger problem is that it has not taken enough of them.

Technology was supposed to make life easier. Instead, we have used it to become more efficiently exhausted.

Why?

Maybe human beings possess a peculiar and rather useless seriousness. We do not merely work hard. We work hard at looking as though we are working hard.

So perhaps the next great innovation is not another machine.

Perhaps it is this:

Let us stop treating the appearance of seriousness as a virtue.

A little idleness may not be laziness.

It may simply be the time technology was trying to return to us.

While AI Is Thinking

isurugi tanaka — Wed, 26 Aug 2026 04:36:37 +0000

You wake up.

Your brain isn’t quite awake yet,
but social media already seems to be having a very productive morning.

“Here’s what you can do with AI.”

“If you don’t know this trick, you’re missing out.”

“This made me ten times more productive.”

There they are again, all lined up for the day.

You think, wow, that sounds useful.

So you try it.

And, usually, it doesn’t work quite that well.

Maybe I’m doing it wrong.

Maybe it really does work for the person who posted it.

But I suspect the simpler answer is this:

Nobody really knows yet.

We’re Still Looking for the Right Way

We don’t really know the best way to use AI.

We don’t know exactly how to ask it for things.

We don’t know what to hand over to it,
and what we should keep doing ourselves.

It feels less like someone has discovered “the right way,”
and more like all of us are still wandering around, looking for it.

Which is why it gets a little tiring
when someone announces a new correct answer every morning.

I understand the need for impressions.

Big claims travel better.

That’s probably just how it works.

Still, the people making those claims always seem so cheerful.

“Everything has changed!”

“There’s no going back!”

“If you don’t learn this now, you’ll be left behind!”

And I find myself thinking:

Maybe the world doesn’t need to change quite so many times before breakfast.

What I Actually Want to Know

I don’t know whether “noisy minority” is the right phrase.

Probably not.

What I want to know these days is something much less impressive.

For example:

You ask AI to do something.

And the screen says:

“Thinking…”

For ten seconds.

Maybe thirty.

What is a human being supposed to do then?

Roll your shoulders.

Look out the window.

Drink some water.

Close your eyes.

Think about something completely unrelated.

Instead of teaching me how to make AI faster, I’d like someone to teach me how to recover while AI is thinking.

I would read that article.

Immediately.

Maybe the Empty Time Is the Point

If AI is going to give us a little more time,
maybe we don’t have to fill that time with something else.

Maybe becoming more convenient
doesn’t have to mean being able to do more things.

Maybe it could mean something smaller than that.

And better.

Maybe convenience is having a little more time in which nothing needs to happen.