DEV Community: Paulo Victor Leite Lima Gomes

tokens are now more expensive than juniors, and less predictable

Paulo Victor Leite Lima Gomes — Fri, 01 May 2026 09:05:02 +0000

I think a lot of companies are still telling themselves a very comforting story about AI costs.

The story goes like this:

Tokens are cheap.
Models keep getting better.
A few copilots here, a few agents there, maybe a chatbot for support, maybe some code generation in CI, and somehow this all stays in the “software subscription” bucket.

I do not buy that story anymore.

My take is simple:

tokens are starting to behave less like a cheap productivity feature and more like a volatile labor line item.

And in a growing number of workflows, they are already expensive enough to compete with what companies would happily pay for junior humans.
Not just junior developers.
Junior assistants too.

The worse part is not even the absolute price.
It is the unpredictability.

A junior hire has a salary.
A token budget has moods.

the spreadsheet starts lying very early

On paper, token prices still look harmless.
They are quoted per million tokens, which is a wonderful way to make real usage feel abstract.

A few examples from current public pricing pages:

OpenAI GPT-5.4: $2.50 / 1M input and $15 / 1M output
Anthropic Claude Sonnet 4.6: $3 / 1M input and $15 / 1M output
Google Gemini 2.5 Pro: $1.25 / 1M input and $10 / 1M output for prompts up to 200k tokens, then $2.50 input and $15 output beyond that threshold

That still sounds cheap if you are thinking about a few prompts in a playground.
It stops sounding cheap the moment AI stops being a toy and starts becoming part of your operating model.

Let’s do slightly less fake math.

Imagine a team with 10 people using coding agents, document summarizers, support drafting, and internal automation.
Nothing science-fiction here.
Just normal “we adopted AI everywhere” behavior.

Assume each seat consumes 5 million input tokens and 2 million output tokens per workday.
That is not tiny, but it is also not insane once you include long contexts, retries, tool traces, generated code, explanations, and review loops.

Here is what that looks like over roughly 22 workdays:

Provider/model	Approx monthly cost for 10 seats
OpenAI GPT-5.4	$9,350
Claude Sonnet 4.6	$9,900
Gemini 2.5 Pro	$7,150 to $9,350

That range on Gemini is already part of the point.
The same team can pay very different numbers depending on prompt size behavior.

Now compare that with actual wage data.
The U.S. Bureau of Labor Statistics lists:

$47,460/year as the 2024 median pay for secretaries and administrative assistants
$133,080/year as the 2024 median pay for software developers
$79,850/year as the lower 10th percentile for software developers

Monthly, that works out to roughly:

$3,955/month for an administrative assistant at the median
$6,654/month for the lower 10th percentile of software developers
$11,090/month for the median software developer

So no, one engineer casually using a model is not suddenly more expensive than a junior developer.
That would be a silly headline.

But a company-wide AI workflow absolutely can become more expensive than junior labor, very fast.
And in some cases it already is.

Five heavy AI seats can outrun a median administrative assistant.
Ten can get uncomfortably close to, or exceed, what many companies would budget for an early-career developer.
That is before you count observability, vector databases, eval pipelines, orchestration glue, and the humans still needed to check whether the machine did something stupid.

token costs are worse than salaries because they are less stable

This is the part I think many executives still do not fully internalize.

A salary is expensive, yes.
But it is legible.

Token spend is worse in one important way:

you often do not know the real cost profile until after the workflow becomes popular.

A few reasons:

1. output is where the pain lives

A lot of people anchor on input pricing because it looks small.
That is the wrong anchor.

The expensive part is often output.
Especially when models reason longer, explain more, retry more, or emit giant blobs of code and text nobody asked them to be that verbose about.

OpenAI GPT-5.4 is 6x more expensive on output than input.
Claude Sonnet 4.6 is 5x more expensive on output than input.
Gemini 2.5 Pro jumps hard on output too.

So the team that says, “we only send a lot of context” is often missing the real bill.
The bill usually shows up when the system starts talking back too much.

2. the same work can suddenly tokenize differently

Anthropic documents that Claude Opus 4.7 uses a new tokenizer that may consume up to 35% more tokens for the same fixed text.

That should make every finance person mildly uncomfortable.

Imagine paying 35% more for the same semantic workload because the tokenizer changed.
Not because your product changed.
Not because customers changed.
Just because the vendor changed how text gets counted.

That is not labor-like.
That is utility-bill-like.

3. thresholds and modes quietly change the bill

Gemini 2.5 Pro charges one rate for prompts up to 200k tokens and a higher one above that.
Anthropic has regional multipliers and a fast mode with premium pricing.
OpenAI offers batch discounts, but also a data residency premium.

So even if the application behavior looks “the same” from the outside, the internal billing shape can move around because:

prompts got longer
cache hit rates dropped
a team enabled a faster mode
a product shifted regions
grounding or search got added
the model started generating more output than last month

That is not predictable staffing.
That is spend drift.

4. agents multiply hidden tokens

This gets worse with agents.

A normal chat interaction is one thing.
An agent loop is another beast entirely.

Now you are paying for:

the original prompt
tool schemas
tool results
chain-of-thought-adjacent reasoning budgets, depending on platform semantics
retries
file context
summaries of prior turns
review passes
self-correction loops

People love saying “the agent did this task in 8 minutes.”
Cool.
What they often do not say is that the agent may have consumed the token equivalent of several ordinary interactions to get there.

That means your marginal cost per useful result is often much blurrier than the dashboard suggests.

this does not mean “stop using AI”

To be clear, I am not making the boomer argument here.

I am not saying, “AI is too expensive, go back to doing everything manually.”
That would be dumb.

AI is real leverage.
It is already useful.
It can absolutely make a strong person much stronger.

But I think companies need to stop treating token spend as if it were automatically better than human spend.

Sometimes it is.
Sometimes it is not.
And sometimes it is only better if a human is still clearly in charge of:

scope
review
escalation
quality control
budget discipline
model selection

The winning pattern is not “replace juniors with tokens.”
The winning pattern is more like:

use tokens to amplify good people, while good people remain the owners of correctness, cost, and consequences.

That is a much more boring sentence.
It is also the one that survives contact with finance.

my opinionated version

I think a lot of AI adoption right now is being sold with the same bad habit we saw in early cloud conversations.

People love the upside story.
Nobody wants to dwell on the bill shape.

So teams say things like:

“it is only a few dollars per million tokens”
“the model is cheap enough”
“we will optimize later”
“let’s just let everyone use the best model for now”

That is exactly how small variable costs become strategic costs.

And unlike hiring, token spend can get uglier without any emotionally obvious moment.
You do not interview a token.
You do not onboard a token.
You do not notice 14 small workflow expansions the same way you notice one new headcount request.

That is why this category is dangerous.
It slips past normal management instincts.

You would debate a junior hire.
You might not debate a bunch of “helpful” agent workflows until the invoice starts looking like a small payroll category.

what smart companies should do instead

My recommendation is not anti-AI.
It is anti-delusion.

If you are serious about using models across the company, then do a few boring things early:

price workflows, not prompts

Do not benchmark one cute demo request.
Measure the full workflow:
retries, context growth, tool calls, review passes, and average output length.

assign model tiers intentionally

Not every task deserves the frontier model.
Most companies are massively overpaying because they use the most expensive reasoning setup for work that could be routed to a cheaper model.

put humans on the acceptance boundary

Do not use expensive models as a management substitute.
If the output matters, a human should still own acceptance.
Otherwise you are paying for generation and then paying again for the fallout.

treat token budgets like cloud budgets

Tag them.
Attribute them.
Alert on them.
Set hard ceilings where needed.

Cloud taught us this already.
Variable spend is only “efficient” when someone is actually watching it.

optimize for controlled leverage

The right comparison is not “AI versus humans.”
It is “AI plus one good human versus the old way of working.”

That framing usually leads to better architecture and more honest economics.

my take

Tokens are still useful.
Sometimes incredibly useful.

But they are no longer a cute rounding error.
And they are definitely not predictable enough to treat as a harmless software snack.

For many teams, token spend is becoming a real labor-adjacent budget category.
In some workflows it is already expensive enough to beat junior human cost.
In many more, it is at least expensive enough that the comparison should happen before the rollout, not after the invoice.

So no, I would not stop using AI.

I would just stop pretending that tokens are magically cheaper than people.
They are often cheaper than some kinds of work.
That is different.

And unlike people, tokens come with a billing model that can change under your feet, a cost profile that explodes with usage patterns, and a nasty habit of looking cheap right until they are not.

That is why my current default is simple:

use AI aggressively, but never let the token budget operate without adult supervision.

references

OpenAI, API Pricing — https://openai.com/api/pricing/
Anthropic, Claude pricing — https://docs.anthropic.com/en/docs/about-claude/pricing
Google, Gemini Developer API pricing — https://ai.google.dev/gemini-api/docs/pricing
U.S. Bureau of Labor Statistics, Software Developers, Quality Assurance Analysts, and Testers — https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm
U.S. Bureau of Labor Statistics, Secretaries and Administrative Assistants — https://www.bls.gov/ooh/office-and-administrative-support/secretaries-and-administrative-assistants.htm

controller staleness is the hidden tax of platform automation

Paulo Victor Leite Lima Gomes — Fri, 01 May 2026 00:02:16 +0000

I think a lot of platform engineering discourse still has a very annoying habit.

We keep treating automation as if the main risk is not having enough of it.

Not enough controllers.
Not enough reconcilers.
Not enough policy engines.
Not enough workflows.
Not enough AI copilots orchestrating the orchestrators.

And sure, sometimes that is true.
But once a system gets a bit serious, the failure mode changes.
The problem is usually not that you lack automation.
The problem is that you now have automation making decisions from a stale mental model of reality.

That is why the Kubernetes v1.36 work on staleness mitigation and observability for controllers is more important than it sounds.
It is not just a controller-author quality-of-life improvement.
It is a small but very clear signal about the next platform pain point.

My take is simple:

controller staleness is the hidden tax of platform automation, and the more teams automate, the more expensive that tax gets.

automation is only smart if its view of the world is fresh enough

A lot of infrastructure automation depends on a pretty fragile assumption:
that the thing making a decision is acting on an acceptably current view of the system.

That sounds obvious when you say it out loud.
But a surprising amount of platform logic quietly assumes it anyway.

Controllers watch resources, build a cached view of cluster state, and then reconcile toward some desired outcome.
That model is powerful because it scales much better than constant direct reads.
It is also exactly where the subtle bugs show up.

Kubernetes described the problem pretty bluntly in the v1.36 post: controller staleness can lead to controllers taking incorrect actions, often because the author made assumptions that only fail once the cache falls behind reality.
And that is the nasty part.
These issues often do not look dramatic at first.
They look like occasional weirdness.
A duplicate action here.
A delayed correction there.
A reconciliation loop that technically succeeds while doing the wrong thing for a few minutes.

That is why staleness is such a good platform topic.
It sits right in the uncomfortable zone between “works fine in normal demos” and “causes expensive production behavior.”

the hard part of automation is not execution. it is timing and truth

I think this is where a lot of modern platform thinking gets too romantic.

People love the idea of automated systems because automated systems feel decisive.
A desired state exists, a controller sees drift, the controller corrects it, everyone goes home happy.

Real life is more annoying.

In real systems, automation is constantly negotiating with:

partial visibility
event delays
retries
caches
race conditions
eventual consistency
competing controllers
humans making changes at inconvenient times

So the real challenge is not only “can the system act?”
It is “can the system act based on a trustworthy-enough view of reality?”

That distinction matters a lot.
Because if your automation gets stronger while your freshness guarantees stay fuzzy, you are not really scaling trust.
You are scaling the blast radius of outdated assumptions.

That is the hidden tax.
Not the compute bill.
Not the YAML sprawl.
The cognitive and operational cost of having more autonomous behavior than your observability and consistency model can safely support.

this is not just a kubernetes problem

Kubernetes controllers make the issue easy to see, but the pattern is much broader.

You can find the same shape everywhere now:

internal platform workflows acting on lagging state from APIs
cost automation reacting to yesterday’s data as if it were real time
deployment systems assuming their inventory view is current when it is already drifting
security automation revoking or granting based on incomplete propagation
AI agents chaining actions across tools with a stale understanding of what the previous step actually changed

That last one is where this gets especially relevant.
A lot of "agentic" demos look impressive because they show automation doing more steps.
Very few of them spend enough time on whether the agent is acting on fresh, verified state between steps.

Honestly, that is why I keep being skeptical of the shallow version of AI platform enthusiasm.
We are adding more decision-making loops into systems that already struggle with stale state in much simpler automation.
The problem does not disappear because the interface got friendlier.
It usually gets harder to see.

observability for controllers is really observability for trust

One thing I like about the Kubernetes v1.36 direction here is that it treats staleness as something you should not just tolerate silently.
You should be able to detect it, reason about it, and design around it.

That sounds small.
It is not.

A lot of platform incidents happen because the system was technically doing what it was built to do, but under conditions the builders were not properly measuring.
A stale controller is a great example.
The logic might be correct.
The intent might be correct.
The action might still be wrong because the world moved and the automation did not notice fast enough.

That means the observability question is bigger than metrics trivia.
It is really a trust question:

how stale can this controller become before its actions are unsafe?
which reconciliations depend on fresh reads versus eventually consistent cache views?
where are we assuming ordering that the platform does not really guarantee?
which automation loops should refuse to act when their view of state is too old?

That is the grown-up version of platform automation.
Not “make it autonomous and hope.”
More like “make it autonomous inside clearly observed truth boundaries.”

platform teams should think less about magic and more about control surfaces

This is also why I think the most valuable platform engineering work right now is weirdly unglamorous.

Not the giant internal developer portal launch.
Not the seventh wrapper around LLM tool invocation.
Not the architectural diagram where every box sounds intelligent.

The valuable work is often things like:

defining where freshness matters more than throughput
making state lag visible before it becomes user-visible damage
deciding which control loops need hard safeguards
building reconciliation logic that can prove it is acting on current-enough information
teaching teams that “eventually consistent” is not a decorative phrase

That is not as sexy as talking about fully autonomous platforms.
But it is much closer to what keeps systems from becoming haunted.

And yes, I said haunted.
Because stale automation has exactly that vibe.
Something changed.
Some controller noticed too late.
Another system reacted to the wrong intermediate state.
And now everyone is trying to explain why the system behaved like it believed in ghosts.

more automation means more responsibility to constrain automation

I think this is the part many teams still underestimate.

When you increase automation, you do not only gain leverage.
You also take on a stronger obligation to define the conditions under which that automation is trustworthy.

That means automation design has to include things like:

freshness assumptions
backoff behavior
conflict handling
idempotency
safe no-op conditions
clear refusal modes when state confidence is too low

This is one reason I think platform engineering is slowly becoming less about tooling assembly and more about operational philosophy.
What do we allow the machine to do automatically?
Under what evidence?
With what rollback path?
With what visibility?

Those are not secondary implementation details anymore.
They are the real product decisions of the platform.

my take

The Kubernetes controller staleness work matters because it highlights a problem that a lot of modern infrastructure is about to feel more sharply.

As platforms add more controllers, more policy engines, more automation layers, and more AI-shaped orchestration, the scarce resource is not only compute or developer time.
It is trustworthy system awareness.

If the automation loop cannot see reality clearly enough, then adding more automation does not reliably create more control.
Sometimes it just creates faster confusion.

That is why I think controller staleness is the hidden tax of platform automation.
It is the price teams pay when automated systems are allowed to act with more confidence than their view of the world deserves.

The next generation of strong platform teams will not just ask, “what can we automate?”
They will ask a better question:

how fresh does the truth need to be before we let the machine touch anything important?

That is a much less flashy question.
And a much more useful one.

references

Kubernetes, Kubernetes v1.36: Staleness Mitigation and Observability for Controllers — https://kubernetes.io/blog/2026/04/28/kubernetes-v1-36-staleness-mitigation-for-controllers/
Kubernetes, Gateway API v1.5: Moving features to Stable — https://kubernetes.io/blog/2026/04/24/gateway-api-v1-5/
Martin Fowler, Structured-Prompt-Driven Development (SPDD) — https://martinfowler.com/articles/structured-prompt-driven/

your second brain should not be a folder full of markdown

Paulo Victor Leite Lima Gomes — Thu, 30 Apr 2026 15:02:24 +0000

I like markdown.
I really do.

Markdown is simple, portable, git-friendly, easy to back up, and great for writing.
But I also think a lot of “second brain” tools quietly fall apart at the exact moment they are supposed to become useful.

They work nicely while your memory is small.
Then one day you want to find that one thing:

the exact hour you went to the gym three Tuesdays ago
the bakery you liked in a city you visited once
the detailed advice a friend gave you in a long conversation six months ago
that random insight you had during a walk and saved from your phone

And suddenly your “second brain” is just a polite pile of files.

That is the moment where I think most markdown-first memory systems reveal their real limitation:

they are optimized for storing text, not for retrieving memory.

That is why I find Jurupari interesting.
Not because it adds more note-taking ceremony.
Quite the opposite.
Because it strips the idea down to what actually matters:

store memories in a real database
search them semantically
expose them through MCP and HTTP
let any AI tool read and write them for you

That is much closer to what a real second brain should be.

the problem with markdown second brains

A folder full of notes feels smart at first.
Engineers especially love it because it feels open and under control.
No vendor lock-in, no weird proprietary format, just files.

I get the appeal.
I have that instinct too.

But once memory stops being “a few documents I can browse manually” and becomes “an extension of my day-to-day thinking,” files start getting awkward.

The problem is not that markdown is bad.
The problem is that memory retrieval is a search problem, and search gets much better when you treat it like a database problem instead of a filesystem hobby.

If your idea of memory is:

searchable history
timeline fragments
personal facts
recurring preferences
conversation details
lightweight journaling
structured and unstructured recall

...then embedded search plus a proper data model beats filename gymnastics every time.

what jurupari gets right

Jurupari is basically a very simple personal knowledge base with the right primitives:

PostgreSQL for storage
pgvector for semantic search
MCP so AI tools can use it directly
HTTP API for direct integration and automation
CRUD support, not just retrieval

That last part matters a lot.
A lot of “memory” integrations are glorified search adapters.
They can retrieve context, maybe rank snippets, maybe inject them into a prompt.
But they cannot really behave like a durable memory system because writing is awkward or missing.

Jurupari fixes that.

With MCP in front of it, memory stops being a manual note-taking ritual and becomes something much more natural:

Hey, save this on my Jurupari memory.

That is the right abstraction.
I do not want to stop what I am doing, open another app, decide on a folder, decide on a title, decide on tags, and become my own archivist.
I want memory capture to be cheap.

If the system is good, I should be able to talk to Claude, GPT, OpenClaw, Hermes, n8n, or any other MCP-capable tool and say:

save this
find that
update this
remove that

That is a second brain.
Not a graveyard of notes.

semantic search is the real feature

The real power here is not “you can store notes in Postgres.”
That part is almost boring.

The real feature is that semantic search changes how you interact with memory.

You do not need to remember the exact words you used.
You just need to remember what you meant.

That is a huge difference.

A filesystem usually rewards perfect recall:

correct filename
correct folder
correct keyword
correct tagging habit

A semantic memory system rewards approximate recall:

“find that thing I wrote about feeling tired after leg day”
“what was the coffee place I liked near the station?”
“search my memory for that conversation about changing jobs”
“what did I say last month about sleep quality?”

That is much closer to how human memory actually works.

this is where a second brain becomes actually useful

A lot of “second brain” marketing is weirdly grandiose.
It talks like you are building a digital philosopher king inside your laptop.
I do not think that is the useful framing.

The useful framing is much simpler:

your memory gets more valuable when it becomes easy to save and easy to find.

That means very normal things suddenly become worth recording.

For example:

1. everyday activity logging

You want to remember what time you did something.
Not because it is deep or poetic, but because reality is slippery.

Examples:

what time did I go to the gym?
when did I stop by the bakery?
what time did I take the dog out?
when did I last call my parents?

Prompt examples:

Save this on my Jurupari memory: I went to the gym today at 07:10.

Save this memory: I went to the bakery at 08:35 and bought sourdough and two pastéis de nata.

Later:

Search my Jurupari memory for the last time I went to the gym in the morning.

2. detailed conversations

Sometimes the most useful thing to remember is not a task.
It is context.

Maybe a friend told you something important.
Maybe you had a subtle conversation with your partner.
Maybe someone gave you advice that only makes sense when you preserve the detail.

Prompt examples:

Save this on my Jurupari memory: today I talked to Daniel for an hour. He said he is thinking about leaving his job because the team structure changed, he feels blocked by management, and he wants to move closer to product strategy.

Later:

Find my memory about Daniel thinking of leaving his job.

That is way better than hoping you named the note career-chat-daniel-maybe-job-change-final-final.md.

3. journal entries that you can actually recover

This is the part I like most.
Jurupari can work like a journal, but not the kind of journal you write and then lose inside your own archive.

You can keep small fragments of life:

what made you anxious today
what went well this week
a lesson from a hard conversation
a small win you want to remember
a pattern you are noticing in your energy, habits, or mood

Prompt examples:

Save this memory: I felt unusually focused today after sleeping 8 hours and going for a 20-minute walk before work.

Search my memory for patterns involving focus, sleep, and walking.

That is where the “second brain” idea stops being branding and starts becoming practical.

mcp is what makes this feel native instead of bolted on

The reason this gets much more interesting now than a few years ago is MCP.

Without MCP, a memory system is usually another app you have to remember to use.
With MCP, memory becomes part of the interface layer of your AI tools.

That changes behavior.

Instead of thinking:

I should go open my note system and save this.

You think:

Hey, save this.

That is a much lower-friction action.
And low friction is everything for personal memory systems.
Because the best memory tool is not the one with the fanciest graph view.
It is the one you actually keep feeding.

Jurupari is especially nice here because it is not trying to trap you inside one product surface.
You can plug it into:

Claude
GPT
OpenClaw
Hermes
n8n
other MCP-capable tools

So the memory follows your workflow instead of demanding a new one.

the real second brain is writable

I think this is the most underrated idea in the whole space.

A real second brain cannot be read-only.

If an AI can search your memory but cannot update it, correct it, append to it, or save new facts when you ask, then it is not really your second brain.
It is just a retrieval plugin.

Jurupari exposing CRUD through MCP is the important design choice.
That is what makes these flows possible:

Save this on my Jurupari memory: the plumber said he will come on Friday between 14:00 and 16:00.

Update that memory: the plumber moved it to Saturday at 10:30.

Delete the duplicate note about the bakery. Keep the one with the exact time.

That sounds small, but it is the difference between “search over notes” and “persistent memory you can manage conversationally.”

how to run your own jurupari

The nice part is that this is not some giant infrastructure project.
The repo is refreshingly direct.

At a high level, the setup is:

deploy Jurupari somewhere you like
point it at a PostgreSQL database with pgvector
set your environment variables
run the API
expose MCP so your AI tools can connect to it

From the project README, the local dev flow is basically:

cp .env.example .env
# fill DATABASE_URL, OPENAI_API_KEY, JURUPARI_TOKEN

docker compose up -d
pnpm install
pnpm db:push
pnpm dev:api
pnpm --filter @jurupari/mcp build && node packages/mcp/dist/index.js

And if you want a simple hosted version, the project explicitly mentions deployment on places like AWS or Railway.

The mental model is straightforward:

Postgres + pgvector stores and indexes your memory
the API gives you direct application access
the MCP server lets AI clients talk to the memory naturally
the token model controls read/write access

There is also a nice split between remote and local MCP setups:

Remote SSE for web clients and remote integrations
Local stdio for tools like Claude Desktop, Claude Code, or Cursor

That means you can choose convenience or locality depending on your setup.

who this is for

I think Jurupari makes the most sense for people who:

already use AI tools every day
are tired of fragmented personal context
want memory to be available across tools
prefer owning their own stack
understand that retrieval quality matters more than note aesthetics

Especially engineers.
Because engineers often over-romanticize plain files and under-invest in retrieval.

I say that with love.
We do this all the time.
We will build a beautiful directory tree and call it knowledge management, then act surprised when finding anything becomes annoying.

my take

If you want a writing system, markdown is still fantastic.
If you want a durable searchable memory that can live behind your favorite AI tools, markdown folders are usually the wrong center of gravity.

That is why I think Jurupari is a much more honest version of the “second brain” idea.

It does not pretend memory is about collecting pretty notes.
It treats memory like what it actually becomes at scale:

a search problem
a retrieval problem
a write problem
a data-model problem
an interface problem

And once you see it that way, the architecture becomes obvious.

Use a real database.
Use semantic search.
Expose CRUD.
Plug it into the tools you already talk to.

That is much closer to a real second brain than a synced folder full of markdown will ever be.

references

Jurupari GitHub repository — https://github.com/brazanation/jurupari
Jurupari README — https://raw.githubusercontent.com/brazanation/jurupari/main/README.md

Do know about the AI transparency index? you should

Paulo Victor Leite Lima Gomes — Thu, 30 Apr 2026 10:00:12 +0000

AI Transparency index and the numbers are uncomfortable, still you should know

stanford's foundation model transparency index dropped its december 2025 edition and if you build anything on top of these models, you should probably read it.

the mean score dropped 17 points. from 58 to 41. meta down 29, mistral down 37, openai down 14. this is not a documentation problem — these companies have entire policy teams. it's a choice.

a few things that stood out to me:

ibm scored 95. first place across all three years. nobody talks about this.
open-weight ≠ transparent. deepseek and alibaba release weights and still scored 32 and 26. publishing weights is not the same as being auditable.
training data is still a black box everywhere. what they trained on, whether they had licenses, how they handled pii — consistently the worst-scoring subdomain, three years running.
anthropic didn't submit a report. the fmti team built one manually. anthropic ranked 2nd. good score, bad signal.

as engineers we're the ones building on top of these systems. when something goes wrong in production, "we didn't disclose how we trained it" is not an answer you can give anyone.

the index doesn't fix that. but it names who's trying to be honest versus who's retreating as market share grows. that's useful signal when choosing what to build on.

Why you should know about the fmti?

most people pick their ai provider based on benchmarks, pricing, or vibes. the foundation model transparency index measures something different: how honest a company is about what they actually built.
that matters more than most engineers realize.
when you integrate a model into a product, you inherit its risks — biased outputs, leaked training patterns, copyright exposure, opaque safety evaluations. you can't audit what was never disclosed. and when something breaks, you're the one explaining it to stakeholders, not the lab.
the fmti gives you a structured way to ask: does this provider tell me enough to reason about what i'm building on?
it's not perfect. scores can be gamed, and disclosure isn't the same as safety. but it's one of the few independent, recurring attempts to hold this industry accountable before regulators do it badly.
if you're doing vendor evaluation, building on llms in a regulated domain, or just tired of treating "trust us" as an architecture decision — this index is worth bookmarking.

software engineers are becoming reliability engineers for generated output

Paulo Victor Leite Lima Gomes — Thu, 30 Apr 2026 05:28:16 +0000

The funny thing about the whole “AI will replace software engineers” discourse is that it keeps describing the wrong job.

Yes, models can produce more code, more docs, more tests, more plans, more tickets, and more very convincing nonsense than ever.
That part is real.

But once you use these systems in real work, the shape of the engineering job starts changing.
Less “person who types every line.”
More “person who decides what deserves to become real.”

My take is simple:

software engineers are quietly becoming reliability engineers for generated output.

Not just for code, by the way.
For migrations, SQL, runbooks, Terraform, docs, architecture notes, postmortems, prompts, dashboards, and all the other machine-produced artifacts that now show up faster than humans can properly trust them.

That is where I think the job is moving.
Not toward disappearance.
Toward accountability.

the real shift is that plausible output became cheap

The biggest change is not that AI writes things.
The biggest change is that AI makes plausible output cheap.

For most of software history, output had a natural throttle:

humans were slow
writing took effort
context switching was expensive
making a mess required actual labor

Now a model can generate in minutes what would have taken a human hours.
That sounds like pure leverage until you hit the obvious second-order effect:

if output gets cheap, bad output gets cheap too.

Actually, not just cheap.
Abundant.
And often polished enough to fool tired people.

That is why I do not think the durable engineering moat is “being the person who can produce the first draft fastest.”
The machines are already very strong there.

The moat is increasingly being the person who can answer harder questions like:

is this correct?
is it safe?
what assumptions is it making?
what breaks under concurrency, retries, or bad inputs?
does it fit the rest of the system, or does it just look locally smart?
what damage happens if this gets merged, deployed, or copied ten more times?

That is reliability thinking, even when the artifact is “just code.”

ai does not remove the backlog. it changes the queue.

One thing I keep noticing is that AI does not simply reduce work.
It often changes the queue.

You used to have a backlog of things not yet written.
Now you increasingly get a backlog of things already generated but not yet trusted.

That is a very different problem.

A few examples:

The model generates a migration quickly, but someone still has to verify rollback safety, locking behavior, and ugly data edge cases.
The model produces a Kubernetes manifest quickly, but someone still has to spot the security assumptions, fake resource guesses, and operational nonsense.
The model writes lots of tests quickly, but someone still has to figure out whether the tests validate behavior or just mirror implementation trivia.
The model drafts a design doc fast, but someone still has to separate actual architecture from autocomplete theater.

So the bottleneck does not disappear.
It moves.

In a lot of teams, the new bottleneck is no longer raw production.
It is validation, integration, and accountability.

That is why the “AI replaces engineers” framing feels shallow to me.
A better framing is:

AI increases the volume of candidate artifacts, and engineers become the reliability system that decides which ones deserve reality.

the new senior engineer smell test

I think this is going to change what seniority feels like.

Strong engineers are increasingly the people who can look at AI-generated artifacts and immediately feel where the lies are.

You know the vibe:

“this looks clean but it is hiding a consistency problem”
“this abstraction reads well and will be miserable to operate”
“this PR is syntactically fine and semantically clueless”
“this agent plan is doing six steps because it does not understand the real system boundary”

That kind of judgment does not demo well.
But it is probably getting more valuable, not less.

Because if AI keeps making output cheaper, then high-quality skepticism becomes a force multiplier.

the job is shifting from authoring to acceptance

Maybe the simplest way to say it is this:

software engineers are spending less of their future being pure authors, and more of it being acceptance systems.

Not passive approvers.
Not human lint rules.
Something more active:

deciding which generated changes are worth keeping
defining the tests and invariants the machine has to satisfy
shaping the architecture so local generation cannot create global chaos
building tooling that catches the model’s favorite failure modes
creating boundaries where generation is useful and boundaries where it is dangerous

That is a different kind of leverage.
And honestly, it is a more senior kind.

Typing faster was never the deepest layer of engineering anyway.
Understanding consequences was.

this is why systems thinking matters even more now

Generated output is usually strongest locally and weakest systemically.

Models are pretty good at producing a function, an endpoint, a refactor diff, a script, a nice-looking explanation.
They are much less trustworthy when the real question is about:

long-range coupling
rollback behavior
observability gaps
cost shape
security boundaries
human maintenance burden six months later

That is where good engineers still earn their keep.
Not by being the fastest autocomplete in the room.
By being the person who sees the system that the autocomplete cannot really hold together on its own.

That is also why I am skeptical of the lazy “every engineer becomes a prompt engineer” storyline.
Maybe every engineer becomes a bit better at delegation.
Fine.
But the durable skill is still evaluation under constraints.
That is basically systems judgment.

this applies way beyond code

One reason I like the phrase “generated output” more than just “AI code” is that the pattern is much broader than programming.

Modern engineering work is full of machine-assisted artifacts now:

incident summaries
postmortems
architecture docs
customer replies
risk assessments
onboarding guides
support runbooks

All of these can now be generated faster.
And all of them can now fail faster too.

A wrong incident summary can send a team chasing the wrong problem.
A polished but shallow design doc can approve a bad direction.
A confident security explanation can normalize unsafe assumptions.
A cheerful AI-generated runbook can make an outage worse.

So the reliability role is not limited to code review.
It is becoming a broader discipline of truth maintenance around machine-produced artifacts.

my take

I do not think software engineers are disappearing.
I think the center of gravity of the job is shifting.

AI changes the economics of engineering by making production cheaper and verification more important.
Once that happens, the valuable humans are not the ones who merely produce more.
They are the ones who can keep generated output aligned with reality.

That means correctness.
Safety.
Operability.
Maintainability.
Context.
Accountability.

So yes, engineers will still write code.
Probably a lot of it.
But the deeper job is starting to look more like reliability engineering for a world where output is abundant, confidence is synthetic, and mistakes can replicate faster than understanding.

Honestly, that sounds much closer to the real profession anyway.

The job was never just to make software.
It was to make software that deserves to exist.

references

Princeton NLP, SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — https://www.swebench.com/
OpenAI et al., GPT-4 Technical Report — https://arxiv.org/abs/2303.08774

github failed at the only thing they should do: git

Paulo Victor Leite Lima Gomes — Wed, 29 Apr 2026 14:23:13 +0000

Yes, I know GitHub does a lot more than Git these days.
Actions, packages, security tooling, issue tracking, enterprise management, AI features, code search, and half the software industry glued into one UI.

But that is exactly why this story is so funny in the worst possible way.

When a company built around Git takes a critical hit in the git push pipeline, my reaction is pretty simple:

guys, this was the one thing you absolutely had to not mess up.

That is my opinion here, and I do not think it is unfair.
GitHub failed at the only thing they should do: Git.

what happened

On April 28, GitHub published two important posts about a serious incident and the vulnerability behind it.
Wiz also published its own breakdown of the issue, tracked as CVE-2026-3854.

The short version:

Wiz described it as a CVSS 8.7 remote code execution vulnerability
the affected area was GitHub’s git push pipeline
GitHub said it validated, fixed, and investigated the issue in under two hours
GitHub also said it found no evidence of exploitation
separately, GitHub published an availability update acknowledging customer-facing impact during the incident window

That is already enough to make engineers pay attention.
A critical RCE in the push path is not some side quest.
That is the bloodstream.

this is why the story matters more than the cve headline

A lot of people will read this as just another security incident.
That is too shallow.

The deeper issue is trust concentration.
GitHub is not just a code host anymore.
For a lot of teams, GitHub is now:

source control
CI/CD trigger point
release workflow anchor
access-control boundary
automation hub
policy surface
audit trail
developer identity checkpoint

That means a bug in the push pipeline is not just “one bug.”
It touches one of the highest-trust points in the entire software-delivery chain.

And that is why my reaction is stronger than “well, incidents happen.”
Of course incidents happen.
But some incidents hit the exact place where your credibility is supposed to be strongest.
This was one of those.

github’s response was fast, but that does not erase the failure

To be fair, GitHub’s own security post says it moved very quickly:

validate the report
mitigate the issue
investigate for exploitation
confirm no exploitation evidence

That is good.
That is exactly what they should do in incident response.

But fast response does not cancel the original problem.
It just means the recovery side looked competent.

And that distinction matters.
A good fire brigade does not mean you should stop asking why the building caught fire.

the platform expansion story is part of the problem

This is where I think the broader lesson sits.

GitHub has spent years becoming more than Git.
That was strategically obvious.
It became a platform on top of a protocol, then a workflow engine on top of a platform, then increasingly a software-operating environment.

That growth worked.
Commercially, it was a huge success.

But expansion has a tax.
Every layer of platform ambition increases complexity, and complexity has a way of drifting back into the supposedly foundational surfaces.

When you become the center of:

pushes
merges
bots
actions
enterprise controls
security scanning
AI assistance
policy enforcement

...your “core Git path” is no longer just a clean old-school plumbing layer sitting alone in a quiet corner.
It becomes part of a much more dangerous machine.

That is one reason I do not buy the very comfortable narrative that this is just one isolated bug.
It is also a reminder that platform sprawl eventually leaks back into the base layer.

availability matters too

GitHub’s availability post matters here because it makes the incident feel more real than a sterile CVE note.
The company was not just publishing a technical write-up after the fact.
It also had to talk publicly about service disruption.

That combination matters:

security issue
high-trust path
customer-visible impact

Once those three things line up, this stops being just an internal engineering embarrassment.
It becomes a reliability story too.

And reliability is part of the product.
Especially when the product is infrastructure for how other engineers ship software.

the market keeps forgetting what “boring critical infrastructure” really means

I think the market often rewards GitHub for looking exciting.
AI features, flashy demos, ecosystem gravity, all of that.

But the real value proposition is still much more boring.
It is something like:

your code lives here
your push lands here
your repo history is here
your automation starts here
your delivery chain trusts this place

That is not glamorous.
That is utility.
That is plumbing.
That is exactly why breaking trust there feels worse than some bug in a side feature.

If your core business is where software teams place their code and start their release motion, then your standard is not “generally impressive platform.”
Your standard is “this path must be extremely hard to break in dangerous ways.”

this is also why single-vendor convenience has a hidden cost

This incident is another reminder that centralization is efficient until it is not.

Putting source, CI, automation, access, and process gravity into one place makes life smoother on normal days.
But it also means that when something goes wrong in a core path, the blast radius is psychological even when the technical blast radius is contained.

Teams start asking:

what else is too centralized here?
what assumptions did we stop questioning?
how much of our delivery trust sits inside one commercial boundary?

Those are healthy questions... probably overdue ones

my take

I think GitHub deserves credit for responding fast.
I also think that is not the main headline.

The main headline is simpler and harsher:

GitHub had a critical RCE problem in the git push pipeline.

And if you are GitHub, that is the kind of sentence you should find humiliating.
Because among all the things people can reasonably argue about in your product, this is the one surface where you are supposed to be boringly excellent.

That is why my opinion is what it is:

GitHub failed at the only thing they should do: Git.

Not because Git is literally the only feature they offer.
But because Git is the foundational trust contract that justifies the existence of the whole giant platform built on top of it.

When that layer cracks, the rest of the value proposition looks a little less sophisticated and a little more fragile.

references

Wiz, GitHub RCE Vulnerability: CVE-2026-3854 Breakdown — https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854
GitHub, An update on GitHub availability — https://github.blog/news-insights/company-news/an-update-on-github-availability/
GitHub, Securing the git push pipeline: Responding to a critical remote code execution vulnerability — https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/

why agi is not possible with the current llms and transformers

Paulo Victor Leite Lima Gomes — Wed, 29 Apr 2026 13:49:03 +0000

Yes, I know this is the kind of title that usually makes people angry before the second paragraph.
But let’s be honest for a second: a lot of the AGI discussion right now is built on vibes, product demos, and investors hallucinating roadmaps.

Current LLMs are impressive.
Transformers were a historic breakthrough.
But that does not mean the current architecture is a straight road to AGI.
And this is not even some fringe opinion anymore. People very close to the center of the modern AI wave have been signaling versions of this for a while.

The point is not that LLMs are useless.
The point is that they are probably not the final substrate for general intelligence.

transformers changed everything, but not everything they changed leads to agi

The 2017 paper Attention Is All You Need gave the industry the transformer architecture.
That mattered more than almost any AI paper of the last decade.
Without it, you do not get GPT-style models in the form we know them.
Without that scaling path, you probably do not get the current commercial AI race in the same shape either.

But there is a very common mistake here.
People take “transformers unlocked a huge jump” and quietly convert that into “transformers must therefore be the road to full general intelligence.”

That does not follow.
A system can be historically important and still be incomplete.
A ladder can get you much higher without reaching the roof.

llms are very good at pattern completion, but that is not the same thing as a mind

This is the part people hate because it sounds like downplaying the models.
It is not downplaying them.
It is just refusing to confuse capability with explanation.

LLMs are extremely strong statistical systems for sequence modeling.
That is already a huge deal.
They compress gigantic distributions over language, code, and other symbolic artifacts into something operationally useful.
That is why they can write decent prose, summarize legal text, explain a Rust borrow checker error, and generate creepy-good autocomplete.

But being very good at next-token prediction over giant corpora does not automatically imply:

grounded world models
durable causal reasoning
stable long-horizon planning
embodiment
self-directed agency with coherent goals
persistent internal models of truth independent of text imitation

That gap matters.
A lot.

Right now, much of the industry is basically betting that enough scale, enough reinforcement, enough tooling, and enough product scaffolding will cause those missing properties to emerge strongly enough.
Maybe some of them will.
But that is still a bet, not a proof.

even the people closest to this wave have hinted that current llms are not the final answer

Ilya Sutskever has been one of the most important people in modern deep learning.
He co-authored the AlexNet paper, was a co-founder and chief scientist at OpenAI, and has been as close to frontier model development as almost anyone alive.

He has also repeatedly signaled that scale alone is not the whole story.
Not in the simplistic “just make the next model bigger” sense.
The broader direction from people like him has been that current systems are powerful, but there are still core unsolved questions around reasoning, agency, and what kind of architecture actually gets you to something more general.

That matters because the people with the best empirical seat in the house are usually less naive about architecture than the market is.
The market sees product demos and says “AGI soon.”
Researchers see brittle failure modes, hidden scaffolding, evaluation gaps, and weird generalization boundaries.

Those are not the same thing.

current llms still depend too much on scaffolding

One of the easiest ways to see the limit is to look at how much extra machinery we keep wrapping around these models.

Every time the model struggles, the answer becomes:

give it retrieval
give it tools
give it memory
give it better prompting
give it decomposition
give it agents
give it reflection loops
give it verifier models
give it structured outputs
give it a planner on top of the planner

None of this is bad.
A lot of it is smart engineering.
But it is also a clue.

If the core system were already on a clean AGI trajectory by itself, we would not need this much external scaffolding just to make it robust at ordinary multi-step work.

We keep building exoskeletons around the model because the raw model is not enough.
That is useful.
But it is also diagnostic.

the context-window obsession is also a tell

A lot of modern LLM discourse treats bigger context windows as if they are a direct proxy for deeper intelligence.
They are not.
They are useful, yes.
But usefulness is not the same as cognition.

A very large context window can help a model:

see more documents
maintain more local continuity
reference more recent constraints
reduce some memory hacks

Great.
But that still does not solve the harder problems of abstraction, grounding, causal stability, or independent model-building.

A model that can read a whole repo is not automatically a model that understands software the way a strong engineer understands systems over time.
A model that can ingest a giant conversation is not automatically a model with coherent memory in the human sense.

A bigger whiteboard does not equal a better brain.

this is also why code generation is a dangerous shortcut to agi hype

Code is one of the strongest arguments for LLM usefulness.
And also one of the easiest places to overstate what the systems are doing.

Yes, current models can write useful code.
Yes, they can fix bugs, generate boilerplate, explain APIs, and occasionally outperform mediocre humans on bounded tasks.
That is all real.

But even in code, they still show the same structural weaknesses:

unstable long-range consistency
brittle execution loops
hidden dependency on retries and external validation
no reliable internal model of correctness unless tied to tools/tests
tendency to bluff through uncertainty

That is not AGI.
That is a very strong probabilistic synthesizer with some surprisingly valuable affordances.
Which is still impressive, by the way.

three tiny code examples that make the point

Here is the difference between producing plausible code and actually sustaining deeper software understanding over time.

rust

fn divide(a: f64, b: f64) -> Option<f64> {
    if b == 0.0 {
        None
    } else {
        Some(a / b)
    }
}

An LLM can write that easily.
The hard part is not syntax.
The hard part is whether the system understands when this function belongs in a larger error-handling model, how it should evolve in a real service, what invariants surround it, and how those choices cascade through a production codebase.

java

public record User(String id, String email) {}

public class UserService {
    public Optional<User> findById(String id) {
        return Optional.empty();
    }
}

Again, easy.
But can the model reason reliably about persistence boundaries, consistency guarantees, privacy constraints, operational tracing, and how this service should change under real business pressure?
Sometimes partially. Consistently? Not really.

clojure

(defn safe-parse-int [s]
  (try
    (Integer/parseInt s)
    (catch Exception _ nil)))

Nice, compact, useful.
But local code generation is not the same thing as robust system-level intelligence.
It is one slice of it at best.

That difference is where a lot of AGI marketing hides.

the transformer may be a stepping stone, not the final architecture

This is the view that seems most plausible to me.

Transformers are probably like a major aircraft design breakthrough, not the final aircraft.
They changed the feasible frontier.
They made certain scaling patterns obvious.
They created new industries.
But that does not mean they are the final form of general intelligence any more than early jet engines were the final form of flight.

Maybe AGI, if it ever arrives, will still inherit ideas from transformers.
That seems likely.
But it may require architectures that integrate memory, planning, grounding, world modeling, and self-correction in ways that current autoregressive LLMs do not naturally do.

That is a much narrower and more reasonable claim than “LLMs are fake.”
They are not fake.
They are just probably not sufficient.

my take

I think the current transformer + LLM wave is historically important, economically real, and still not the same thing as a solved path to AGI.

That is the part people need to hold in their heads at the same time.

The models are powerful.
The products are useful.
The industry is not crazy for taking them seriously.

But the leap from “very strong sequence model with tools” to “general intelligence” is still doing a lot of hand-wavy work.
Too much, honestly.

So when people say AGI is right around the corner because current LLMs keep getting better, I think the right answer is:

maybe something important is around the corner.
But it is far from obvious that the current transformer stack is the full road there.

And that is not pessimism.
That is just architectural humility.

references

Vaswani et al., Attention Is All You Need (2017) — https://arxiv.org/abs/1706.03762
Brown et al., Language Models are Few-Shot Learners (2020) — https://arxiv.org/abs/2005.14165
Wikipedia, Ilya Sutskever — https://en.wikipedia.org/wiki/Ilya_Sutskever
Wikipedia, Attention Is All You Need — https://en.wikipedia.org/wiki/Attention_Is_All_You_Need
Wikipedia, Large language model — https://en.wikipedia.org/wiki/Large_language_model

Without google's transformers, there is no GPT-ishs

Paulo Victor Leite Lima Gomes — Sat, 25 Apr 2026 12:01:11 +0000

Yes, remember back there in 2020/2021 when OpenAI created the gpt2? How about we really focus on what enable them to do that? google transformers.

The modern generative AI industry was built on one of the most consequential papers in the history of software: Google’s 2017 paper, Attention Is All You Need.

That paper introduced the Transformer architecture.
And without that architecture, GPT-2 does not happen in the way we know it.
Honestly, most of today’s AI industry does not happen in the same way either.

This is one of those moments where the industry narrative got flattened.
People remember products, brand names, launches, demos, APIs, and valuation charts.
But under all of that sits a technical shift that changed what was economically and architecturally possible.

That shift was the Transformer.

The pre-Transformer world was not useless, but it was narrower

Before Transformers took over, the field was already making real progress with recurrent neural networks, LSTMs, GRUs, sequence-to-sequence models, and attention layers added on top of those systems.
This mattered.
It was not fake progress.

But it had limits.

Those older architectures were much more painful to scale for long-range dependencies, much harder to parallelize efficiently, and generally less well-suited to the kind of giant training runs that would later define modern language models.

That matters more than people think.

A lot of AI history is really compute history wearing a research costume.
If an architecture is elegant but does not map well onto large-scale training infrastructure, it can hit a ceiling even if the ideas are good.

The brilliance of the Transformer was not only that it worked.
It was that it worked in a way the industry could scale.

What Google actually changed

The key claim in Attention Is All You Need was radical for its time: sequence modeling did not need recurrence or convolution at the center.
The model could rely entirely on attention mechanisms.

That is the line that changed everything.

Google’s authors proposed a model architecture that:

removed recurrence from the core sequence model
relied on self-attention to model relationships across tokens
made training far more parallelizable than RNN-heavy approaches
created a cleaner path toward scaling with more data, more parameters, and more compute

This is why the paper mattered so much.
It did not just improve benchmark performance.
It changed the operating assumptions of the field.

Once that door opened, the industry got a new answer to a bigger question:

what if language modeling could be treated as a scaling problem instead of a carefully hand-managed sequence bottleneck problem?

That is the real pivot.

GPT-2 is not just “an OpenAI breakthrough”

GPT-2 absolutely mattered.
It helped prove that large-scale generative language modeling could produce outputs with a level of fluency that forced the industry to pay attention.
It made a lot of people understand, maybe for the first time, that language models were not just autocomplete toys.

But GPT-2 was not born in a vacuum.

GPT-2 stands on the Transformer architecture.
Not metaphorically.
Directly.

Even the name GPT says it:
Generative Pre-trained Transformer.

That last word is doing a lot of work.

Without Google’s Transformer paper, there is no straightforward architectural foundation for GPT-2 as we know it.
Maybe OpenAI would have built some other path eventually.
Maybe the field would have discovered a similar breakthrough through a different line of work.
But the GPT-2 that actually happened, when it happened, and how it happened, is inseparable from the Transformer.

That is just the technical truth.

The Transformer did something more important than improve models

The biggest thing Google gave the industry was not merely a better model block.
It gave the industry a scaling primitive.

That sounds dry, but it is the whole story.

The AI industry today is defined by a few recurring ideas:

pretraining at large scale
transfer of general capability into downstream tasks
parameter growth
context-window expansion
foundation models as platform assets
model families with derivative products, tools, and APIs

All of that became much more viable because the Transformer architecture matched the industrial reality of training large systems on serious hardware.

That is why its influence extends so far beyond NLP papers.

The Transformer did not merely improve one subfield.
It helped create the modern operating model for AI companies.

Why this shaped the industry so deeply

The reason the Transformer shaped the entire industry is simple:

it connected research progress to economic scale.

That is what wins.
Not just cleverness.
Not just novelty.
Not just benchmark gains.

The winning architecture is usually the one that makes the next order of magnitude possible.

Transformers made it easier to imagine:

larger language models
broader pretraining corpora
reusable model backbones
generalized text generation
eventually multimodal systems built on related scaling logic

Once that happened, the center of gravity changed.
The industry stopped thinking in terms of narrow task-specific systems and started thinking in terms of large trainable model families.

That shift is still the water we are swimming in.

You can argue about whether the current generation of AI products is overhyped, overcapitalized, or overmarketed.
I make that argument all the time.
But the architectural break itself was real.

And Google triggered it.

This is one of the great ironies of AI history

One of the funniest parts of the whole story is that Google created one of the most important technical foundations of the generative AI boom, and then for a while let the market narrative get captured by everyone else.

That is an extraordinary industrial fumble.

Researchers at Google helped create the architecture that underlies the most important AI platform shift in years.
Then OpenAI became the popular face of the revolution.
Then the rest of the industry ran around trying to catch up in public, even while depending on the same architectural lineage.

That is not a criticism of the Transformer.
If anything, it proves how foundational it was.
Once an idea is that powerful, it stops belonging to one company in the practical sense.
It becomes infrastructure for an era.

That is exactly what happened.

GPT-2 was one of the first public proofs of what the architecture unlocked

GPT-2 matters because it was one of the first large public demonstrations of what a Transformer-based generative system could look like when pushed hard enough.

It was not the final form.
It was not the most advanced model by today’s standards.
But it was one of the moments when the broader industry could no longer pretend this line of research was marginal.

People saw coherent text generation at a level that changed expectations.
Developers, founders, investors, media, and eventually platform teams all started recalibrating.

That is why saying “GPT-2 would not be possible without Transformers” is not rhetorical exaggeration.
It is just a concise summary of the dependency chain.

Google created the architectural breakthrough.
OpenAI used that breakthrough to push generative language modeling into a new public phase.
Then the rest of the industry reorganized around the consequences.

My take

If you want to understand why the AI industry looks the way it does now, you have to stop treating products as the primary story and start treating architectures as the primary story.

ChatGPT was a product event.
GPT-2 was an early capability event.
The Transformer was the deeper industry event.

That is the layer that changed the shape of the map.

Without Google’s Transformer paper, there is no clean path to GPT-2 as we know it.
Without that path, there is no similar acceleration in large-scale generative language modeling.
And without that acceleration, the current AI industry probably looks slower, messier, and far less unified around the same technical backbone.

So yes, OpenAI deserves credit for what it built.
But the underlying architecture that made that path real came from Google research.

The industry loves to celebrate whoever ships the loudest product.
It is worse at remembering who changed the underlying physics.

In this case, the underlying physics changed in 2017.
And the rest of the AI industry has been compounding that decision ever since.

Why all AI-coding plans are getting more expensive?

Paulo Victor Leite Lima Gomes — Thu, 23 Apr 2026 14:14:19 +0000

This weeks are giving the AI coding market a rare honest moment, showing that we are far away from AI-only coding.

GitHub tightened Copilot’s individual plans, paused some new signups, and explicitly admitted that agentic coding workloads no longer fit inside the old flat-rate box.

Anthropic, meanwhile, tested removing Claude Code from the $20 Pro plan for some new users while keeping Claude Code in the much more expensive Max tier.

People are reacting as if these are random pricing tweaks.
They are not.

This is what it looks like when AI vendors hit physics, GPU supply, and the reality that an “AI coding request” is no longer a cheap autocomplete call.

The short version is simple:

flat monthly pricing was designed for chat and light completion usage, but users are now buying autonomous, long-running, tool-using coding workflows that can burn through inference budget like a small batch job.

That mismatch was always going to break.
April 2026 is just when it became impossible to hide.

What changed this week

GitHub was unusually explicit.
In its April 20 post about Copilot Individual plans, the company said it was “pausing new sign-ups, tightening usage limits, and adjusting model availability” in order to protect existing customers.
It also said that “agentic workflows have fundamentally changed Copilot’s compute demands” and that “it’s now common for a handful of requests to incur costs that exceed the plan price.”

That is the important sentence.
Not the marketing copy.
That one.

It means the unit economics are breaking at the workflow level.
Not in some abstract MBA sense, but at the level of a single heavy user running parallel agent sessions on expensive frontier models.

On the GitHub Copilot pricing page, the public structure now shows individual tiers including Free, Pro ($10), Pro+ ($39), and Max ($99), plus temporary availability messaging and premium-request mechanics.
That is not simplification.
That is a company trying to carve up users by how much expensive inference they consume.

Anthropic’s side looks similar, even if the messaging was messier.
Reporting from Ars Technica, The Register, and The New Stack points to Anthropic testing the removal of Claude Code from the $20 Pro plan for some new signups.
At the same time, the current Anthropic pricing page positions “Includes Claude Code” under Max, starting at $100/month, with Max framed as 5x or 20x more usage than Pro.

Again, the signal is obvious.
The vendors are separating general conversational usage from high-intensity coding-agent usage.
Because they are not the same product economically anymore.

The old pricing assumption is dead

For a while, AI coding products got away with pricing that felt almost SaaS-normal.

one monthly fee
vague “fair use” boundaries
some model differentiation
maybe a premium bucket for the power users

That worked when the product behaved like autocomplete plus a few chat turns.
It does not work when the same product can:

recursively plan and re-plan a task
read dozens or hundreds of files
call tools repeatedly
open parallel subagents
generate long intermediate contexts
loop until a test suite passes
burn expensive large-model calls for review, repair, and validation

That is not “a request” in the old sense.
That is closer to renting a little slice of an inference cluster and asking it to behave like an intern who never sleeps.

The product still looks like software.
The cost profile increasingly looks like compute infrastructure.

That is why the old flat-rate subscription logic is failing.
It assumed average usage would remain average.
But agentic coding does not create average users.
It creates a power-law distribution where a relatively small set of users can generate absurdly disproportionate cost.

Once that happens, a $20 or $10 all-you-can-eat plan stops being generous and starts being structurally stupid.

Tokens are only part of the story

A lot of people still talk about this as if the only issue is token pricing.
That is too shallow.

Yes, tokens are expensive.
Yes, frontier reasoning models are especially expensive.
Yes, long contexts, repeated repair loops, and verbose agent behavior make bills explode.

But the real cost stack is bigger than raw tokens.

Vendors are also paying for:

scarce accelerator capacity
multi-region serving infrastructure
peak load headroom
rate limiting and abuse controls
storage and retrieval for tool-heavy sessions
orchestration layers for agents and subagents
premium model routing and fallback systems
the reliability tax of keeping interactive latency acceptable while users run workloads that increasingly resemble background jobs

That last point matters.

AI coding tools are now caught in an awkward middle state.
Users expect chat-like responsiveness, but they increasingly use them for batch-like workloads.
That is a nasty platform problem.
You either overprovision capacity, degrade latency for everyone, or start pushing users into harder limits and more expensive tiers.

So when people say “the companies need to stop burning tokens,” I think the deeper truth is this:

they need to stop pretending that autonomous coding agents are cheap consumer chat products.

Because they are not.
They are compute products wearing a SaaS costume.

Why this is happening now, specifically in April 2026

The timing is not random.
Several trends converged.

1. Agent mode crossed from demo into real usage

For the last year, vendors kept shipping “agent” features as if they were just a nice extension of chat.
But in practice, more developers started using them for actual work: multi-file changes, repo exploration, iterative debugging, PR generation, and longer coding loops.

Once that behavior becomes normal, cost per user stops looking like chat.

2. The strongest models moved from luxury to default aspiration

Users do not merely want a coding assistant anymore.
They want the best model, the biggest context, the most tools, the longest runs, and the least friction.
If a plan includes access to the good stuff, power users will find the ceiling fast.

This is what happens when premium models stop being occasional upsells and become the default expectation.

3. Providers have better usage data now

In 2024 and even much of 2025, some of this could still be hand-waved as growth strategy.
In 2026, these companies now have enough real workload data to know exactly which cohorts are underwater.
And once you know a plan is underwater, the option to ignore it becomes temporary.

4. Capacity is still finite

The market keeps talking as if inference capacity is infinite because the interface feels infinite.
It is not.
Even large vendors do not have infinite high-end compute, infinite power, or infinite thermal headroom.
A surge in long-running agent sessions does not just change the bill.
It changes scheduling, reliability, and service quality.

5. The industry is starting to move from request theater to usage realism

GitHub’s language is especially revealing here.
The moment a provider publicly says that a handful of requests can exceed the plan price, the old fiction is over.
That statement is basically an obituary for simplistic request-based pricing.

If one “request” can mean “please rename this variable” or “run an autonomous coding workflow across my repo for half an hour,” then request counts are not a serious billing primitive anymore.

This is also an energy story

There is another part of this that the industry still tries not to say too loudly.

Inference is not just expensive in money.
It is expensive in electricity, cooling, and hardware wear.

The AI industry spent the last two years behaving as if the right answer to every product question was “let the model think longer, call more tools, run more agents, increase the context window, and smooth it over with another subsidy.”
That strategy was useful for grabbing market share.
It was never going to be durable.

If an AI coding session behaves like a tiny distributed compute job, then the industry eventually has to price it like one.
Or ration it like one.
Or both.

That is what we are seeing now.
Not a moral awakening.
A resource correction.

The servers were always real.
The power bill was always real.
The GPU queue was always real.
April 2026 is just the month more companies started admitting it in public.

Expect more segmentation, not less

I do not think this ends with one weird GitHub week and one awkward Anthropic pricing test.
I think this is the start of a broader repricing cycle.

Expect more of the following:

premium models pushed into higher tiers
“agent mode” split from normal chat plans
stricter monthly quotas on autonomous workflows
token-based or credit-based billing replacing vague request counts
separate pricing for interactive use versus background execution
more enterprise emphasis, because business customers tolerate clearer metering better than consumers do
more local and hybrid execution, because offloading some work becomes economically rational

In other words, AI coding tools are becoming less like Netflix and more like cloud infrastructure.
That should surprise nobody.

The weird part is that the industry tried to pretend otherwise for so long.

The market trained users to expect the wrong thing

Part of the backlash is deserved.
The vendors created it.

They spent months teaching users to think in slogans like:

unlimited
your AI teammate
delegate whole tasks
runs in the background
use the best models
more agentic workflows

Then the bill arrived.

You cannot market autonomous software labor and then act shocked when people use it like autonomous software labor.
If the product pitch is “give it bigger jobs,” users will give it bigger jobs.
If the product pitch is “parallelize your work,” users will parallelize their work.

So yes, some developers are burning absurd amounts of inference.
But the companies encouraged exactly that behavior.

This is why I expect pricing language to get more explicit from here.
Not because the companies suddenly became honest, but because they cannot afford not to be.

My take

I think both GitHub and Anthropic are reacting to the same underlying truth:

AI coding has moved from lightweight assistance to compute-intensive delegated work, and the original prosumer subscription tiers were priced for the former, not the latter.

That is why access is being segmented.
That is why the better models are moving upward.
That is why “premium requests” are showing up.
That is why coding-agent access is being pulled toward $39, $99, or $100+ tiers instead of being bundled into a cheap chat subscription.

This is not greed replacing generosity.
It is reality catching up with a bad pricing abstraction.

And honestly, that is healthy.

The AI market needs fewer fake-unlimited plans and more truthful pricing tied to actual resource use.
It also needs users to understand that long-running agent workflows are not magic.
They are expensive distributed systems hidden behind a pleasant interface.

If April 2026 becomes the month vendors stopped subsidizing the fantasy that infinite agentic coding fits inside a cheap flat monthly plan, that will probably be remembered as a correction, not a mistake.

A lot of AI products still pretend tokens are abstract.
They are not.
They are compute, power, queue time, and capacity.

And eventually, physics always sends the invoice.

References

Image banner from azquotes

Claude code and 512000 Becoming Public

Paulo Victor Leite Lima Gomes — Wed, 01 Apr 2026 11:00:24 +0000

The Moment Every Engineer Knows

You publish a package.

Everything seems fine.

Then someone on the internet discovers something you absolutely did not intend to ship.

And suddenly half a million lines of your internal code are circulating on GitHub.

That’s essentially what just happened with Claude Code, Anthropic’s command-line developer tool.

What Actually Happened

Anthropic released version 2.1.88 of the claude-code npm package.

Inside the package there was a source map file.

For people outside the frontend / JS ecosystem, a quick explanation:

A source map is normally used to map compiled JavaScript back to the original TypeScript source files for debugging.

But if the source map accidentally includes references to the original sources and the sources are embedded or accessible, anyone can reconstruct the entire codebase.

And that’s exactly what happened.

The result:

~ 2,000 TypeScript files
~ 512,000 lines of code
internal architecture exposed
instantly mirrored and forked across GitHub

Within hours, developers were already exploring the internals.

Important: The Models Were NOT Leaked

Let’s be clear about something.

The leak did not expose the Claude models.

No weights.

No training data.

No internal datasets.

What leaked is the CLI developer experience layer.

Think of it as the operating system around the AI, not the AI itself.

Still, that layer is extremely valuable.

Why This Matters

Many people underestimate developer tooling.

But tools like Claude Code, Copilot CLI, Cursor, etc. are not simple wrappers.

They are complex systems with:

tool execution frameworks
memory management
query orchestration
prompt pipelines
plugin systems
guardrails
verification loops

According to early analysis of the leaked code:

~ 40k lines for the plugin/tool system
~ 46k lines for the query engine
complex memory rewriting pipelines
multi-step memory validation
background context refinement

Which confirms something many engineers already suspected:

These tools are production-grade software systems, not thin wrappers around LLM APIs.

Why Competitors Will Study This Carefully

This leak gives a rare look at how a modern AI developer tool is built.

Competitors can now analyze:

architecture decisions
orchestration patterns
prompt pipeline design
tool execution safety models
memory persistence strategies

Even if companies don't copy code directly (which would be legally risky), they can learn a lot from the design choices.

It's basically a blueprint of a modern AI coding assistant.

The Security Angle

There's also a darker side.

Whenever internal architecture becomes public, attackers can:

analyze guardrail logic
probe validation layers
search for weaknesses in tool execution
discover bypass patterns

Security through obscurity is never a real defense, but suddenly giving attackers a full architectural map does raise the stakes.

The Irony

Claude Code itself exists to help engineers ship code faster.

And the leak happened because of a release packaging mistake.

Not a hack.

Not a breach.

Just a build artifact that shouldn't have been published.

Every engineer reading this knows the feeling.

My Take

From an engineering perspective, two things stand out.

1. The sophistication is real

People often say:

"These AI tools are just wrappers around an API."

That’s clearly not true anymore.

Half a million lines of orchestration code tells a different story.

2. This will accelerate the ecosystem

Ironically, leaks like this often speed up innovation.

Now thousands of developers can study:

memory strategies
prompt pipelines
tool orchestration
AI developer UX design

And build their own versions faster.

That’s how software ecosystems evolve.

The Bigger Picture

AI development tools are becoming something closer to operating systems for programming.

They orchestrate:

context
tools
models
memory
safety

Claude Code is just one example of this emerging layer.

Seeing its internals confirms something many of us suspected:

We are not just building AI models anymore.

We are building AI runtime environments for developers.

Final Thought

Some engineers are probably embarrassed about this release.

But if we’re honest…

Every developer has shipped something accidentally.

Most of the time it's harmless.

Sometimes it's half a million lines of proprietary code.

OpenClaw is infrastructure, not intelligence

Paulo Victor Leite Lima Gomes — Mon, 09 Feb 2026 10:14:34 +0000

There is a new hype going around called OpenClaw, and Yes, it is a hype. Early AGI? no.

OpenClaw is an agent orchestration framework. A good one. Clean. Opinionated. Well documented.
But conceptually, it is not new.

What OpenClaw actually is? Based on their own docs and code:

OpenClaw lets you define agents
Each agent can run tools, call LLMs, keep state, and execute steps
You can run it locally on your own machine
You control the infrastructure and the data flow

that’s it

This is not intelligence. This is software plumbing for LLM-powered workflows 😒

We have seen this before

Nothing here is magic or unprecedented.
You can do the same thing today with n8n more scalable and way more guardrails
You can do the same thing with LangChain-style agent loops
You can do the same thing with custom workers + queues + LLM APIs

Lets be honest, the difference is not capability, is ergonomics.

OpenClaw gives you a cleaner mental model and less glue code. I see this as a more “developer-first” way to define agents, and as we say in polish 🇵🇱 oczywiście, which means, offcourse That is valuable, not AGI.

“But it runs locally, that’s new”

Not really.

OpenAI themselves shipped local / semi-local execution environments in the past:

Tool calling
Code execution sandboxes
Agent-like runtimes that could call external systems

Those experiments came and went. Some were removed.
The idea stayed.

OpenClaw is simply doing this outside OpenAI, in an open-source, self-hosted way.

Their difference? Router and messaging apps, WhatsApp, iMessage, Telegram... you named it.

But again:
You can already do this with n8n, webhooks, and LLM APIs.

The real difference is cost and control:

With OpenClaw, you might run everything on a custom local computer
With n8n or cloud setups, you usually pay more over time
This is a deployment choice, not a breakthrough.

So what is the right framing?

OpenClaw is:

Not AGI
Not consciousness
Not reasoning in the human sense

OpenClaw is:

An elegant agent framework
A solid abstraction over LLM workflows
A good tool if you want local-first, controlled execution

That is already enough.
It does not need AGI branding to be useful.

My conclusion

Calling OpenClaw “AGI” is marketing-driven confusion. Calling it a clean, modern way to build agents is accurate. And accuracy matters more than hype. I see this is game changing for some cool things, you have now some agent working eventually 24 hours a day, but this one still needs tons of triggers and guidelines as well as will halucinate as we already see in a common openai chat. You can use it, you can deliver awesome job with it, bit it will not replace a human. yet.

References

Docs: https://docs.openclaw.ai/start/getting-started
GitHub: https://github.com/openclaw/openclaw
n8n: https://n8n.io/

VS Code now has agents: what changed

Paulo Victor Leite Lima Gomes — Sun, 08 Feb 2026 15:24:13 +0000

Keeping up with AI coding tools is exhausting

First we had simple chat assistants.
Then multiple modes like ask, edit, plan, agent.
Then different models.
And now… VS Code added something new: agent execution environments like: Local, Background, Cloud, Claude

If you feel lost, good.
Me too.
So let’s simplify what is actually happening.

From chat assistants to real agents

At the beginning, which was like two years ago😅, AI in coding was basically:

"Here’s some code. Fix it."

That was the Ask era

Then tools started editing files directly, that became the Edit era.

After that, AI began planning multi-step changes.
Welcome to Plan.

And now we are here where AI can run tasks, monitor progress, and execute workflows.
That is the Agent era

This is the real shift 💩 and is part of the thausand options we have with AI, also with all companies chasing attention in AI initiatives

Why VS Code suddenly has more options on the side panel

Before, the decision was:

Which mode?
Which model?

Now there is a third dimension:

Where the agent runs ?

This is more like from "AI that answers and are our copilot" to be more like "AI that does the work"

This is off course not something new, this was the idea before, and now the biggest trend, and yes its getting harder to follow. Reasons why we are here, to organize it mentally.

How to think about the new VS Code Agents (simple mental model)

first, forget the complexity

Just remember:

Modes = what the AI should do: ask, edit, plan, agent
Model = how smart it is more or less
Execution environment = where it runs: local, background, cloud, claude

That’s it

Now its it more than a autocomplete, or copilot or an step-by-step doing work, its more really delegating the work using your IDE.

For the full official explanation from Microsoft, read here