Forem: Paulo Victor Leite Lima Gomes

server-side sharded watch is Kubernetes admitting the control plane has a data-scale problem

Paulo Victor Leite Lima Gomes — Fri, 08 May 2026 00:01:28 +0000

Kubernetes scalability conversations usually start with the obvious stuff.

How many nodes? How many pods? How large is the cluster? How much etcd pain can one organization spiritually endure before someone says “maybe we should split this thing” in a meeting and everyone pretends they were already thinking it?

Fair questions.

But I think Kubernetes v1.36 server-side sharded list and watch points at a quieter, more interesting problem:

the control plane is becoming a data distribution system, and the hard part is no longer only storing objects. It is feeding every client that wants to continuously know what changed.

That sounds boring. Good. Boring infrastructure primitives are where the real architecture leaks out.

watch was always the magic trick

One of the reasons Kubernetes feels so powerful is the watch model.

Controllers do not constantly ask, “hey, did anything happen?” like an anxious intern refreshing a dashboard. They list the current state, then watch for changes. The API server becomes the coordination point for a lot of little loops trying to move reality toward desired state.

That model is elegant.

It is also everywhere.

Your deployment controller watches Deployments and ReplicaSets. Your autoscaler watches workloads and metrics-adjacent signals. Your policy engine watches resources. Your GitOps controller watches cluster state. Your service mesh watches endpoints and config. Your observability stack watches things. Your custom controllers watch things. Your shiny AI platform controller, written during a suspiciously optimistic sprint, also watches things.

Eventually the cluster has fewer “users” than “watchers.”

And that is the part people undercount.

A mature Kubernetes environment is not just a pile of workloads. It is a pile of clients trying to keep a local mental model of the cluster.

the API server is not just an API anymore

We still call it the Kubernetes API server, which is technically correct, but incomplete.

At small scale, it feels like an API. You send requests. You get responses. Nice.

At serious scale, it behaves more like a shared event distribution system with strong consistency expectations, historical state, authorization checks, fan-out pressure, and a very opinionated data model sitting behind it.

That is why server-side sharded list/watch matters.

The simple version: instead of forcing a client to list or watch a large resource set through one giant stream of objects, the server can split the work into shards. Clients can consume partitions of the dataset, and the system can distribute load more intelligently.

The exact implementation details are less important than the admission behind the feature:

large Kubernetes clusters have a data-scale problem at the watch layer.

Not a “Kubernetes is broken” problem. More like a “Kubernetes succeeded so hard that its coordination model is now carrying everybody’s automation habits” problem.

That is a very different vibe.

controllers are cheap until they are not

The platform engineering era made controllers feel cheap.

Need policy? Add a controller.
Need sync? Add a controller.
Need drift correction? Add a controller.
Need to turn a YAML wish into some cloud-side reality? Controller.
Need your internal platform to look declarative? Another controller.

I like controllers. They are one of the best ideas in modern infrastructure. But they are not free.

Every controller needs to observe. Every observer consumes API server capacity, cache memory, network bandwidth, authorization checks, and operational attention. A single controller can be harmless. A platform full of controllers becomes an ecosystem of little data subscribers.

This is where the accounting gets fuzzy.

Teams are usually pretty good at counting pods and nodes. They are less good at counting control-plane pressure created by automation.

A GitOps tool might look like “just one more platform component.” A policy engine might look like “just one more safety layer.” An operator installed by a vendor might look like “just how the product works.”

Individually, sure.

Together, they become a read-amplification machine pointed at the API server.

AI agents will make this worse, obviously

I do not mean “obviously” as in panic. I mean it as in: look at the pattern.

AI coding agents, platform agents, remediation bots, incident assistants, internal developer portals, MCP-style tools, and automation loops all want context. They want to inspect state. They want to understand what exists before acting. They want to subscribe to change, detect drift, summarize, explain, fix, and sometimes confidently invent a root cause because the logs looked lonely.

Some of those systems will talk directly to Kubernetes. Some will talk through platform APIs. Some will sit behind gateways. But the demand shape is the same: more machine clients wanting fresher operational state.

That means control-plane scalability becomes less about human kubectl usage and more about automated consumers.

The future cluster is not busy because one engineer ran kubectl get pods -A too many times.

It is busy because fifty systems are trying to keep themselves synchronized with reality.

Server-side sharded watch is the kind of primitive you need when “watching the world” becomes normal behavior.

this changes what platform teams should measure

If the control plane is a data product, platform teams need better product metrics for it.

Not just cluster size. Not just API server CPU. Not just etcd latency after everything is already sad.

I would want to know things like:

which clients are opening the most watches?
which resource types create the most list/watch pressure?
which controllers reconnect too aggressively?
how many clients are watching broad scopes when they only need namespaces?
which internal tools repeatedly list everything because nobody designed a narrower contract?
what happens to watch latency during deployments, outages, or large reconciliations?
which teams are adding control-plane load as a hidden dependency of their product?

That last one matters.

A platform feature that adds ten pods is easy to reason about. A platform feature that adds ten high-cardinality watchers across multiple clusters is harder to see, but sometimes more important.

This is the same kind of hidden tax we keep rediscovering in distributed systems: the expensive part is not always where the YAML makes noise.

sharding is not a license to be lazy

There is a trap with scalability features.

A system gets a better primitive, and everyone treats it as permission to continue the same behavior with slightly more confidence.

That would be the wrong lesson here.

Server-side sharded watch is useful because it gives Kubernetes a better way to serve large-scale clients. But it should also make platform teams more honest about their client design.

If your controller only needs a subset of objects, do not watch the universe.
If your tool can tolerate stale summaries, do not demand live cluster truth every second.
If your platform API can provide a curated view, do not leak raw Kubernetes watches to every consumer.
If your automation acts on changes, make sure it has backpressure, jitter, retry discipline, and boring failure behavior.

Basically: do not turn the API server into Kafka because you were too busy to design an event contract.

Kubernetes watch is a great primitive. It is not a substitute for thinking.

the real control-plane problem is social too

The awkward part is that this is not only technical.

Control-plane pressure is often created by organizational boundaries.

One team installs an operator. Another adds policy. Another adds observability. Another adds security scanning. Another adds an internal platform abstraction. Nobody owns the combined shape until the API server starts sweating.

Then suddenly everyone discovers they are “just a client.”

This is why mature platform engineering needs ownership over control-plane consumption, not only control-plane availability. The platform team should not merely keep Kubernetes alive. It should define what good citizenship looks like for clients that depend on Kubernetes state.

That means documentation, defaults, metrics, review patterns, and sometimes saying no to tools that treat the API server like an infinite free database.

Not because platform teams enjoy being annoying.

Because shared control planes become tragedy-of-the-commons machines when every client optimizes locally.

my take

Server-side sharded list/watch is not the flashiest Kubernetes feature. It will not produce a thousand conference keynotes with lasers.

But it is one of those features that reveals where the real system is going.

Kubernetes is not just scheduling containers anymore. It is the coordination substrate for platforms, policies, agents, operators, and automation loops. That means the API server is not merely serving requests. It is distributing operational truth.

And once operational truth has many subscribers, data-scale problems show up.

So yes, sharded watch is a scalability feature.

But it is also a warning label.

If your platform keeps adding automation, controllers, agents, and “smart” tools, you are also adding readers of reality. Those readers have cost. They have failure modes. They have ownership questions.

The cluster does not only run workloads.

It runs everybody’s need to know what the workloads are doing.

That may be the more interesting scalability problem now.

Your Terminal Is Becoming a Governed AI Runtime

Paulo Victor Leite Lima Gomes — Thu, 07 May 2026 00:03:59 +0000

There was a time when the terminal felt like the last private corner of software development.

The browser got enterprise controls. The IDE got plugins, telemetry, policy, and procurement drama. The CI pipeline was always a tiny bureaucracy with YAML. But the terminal? The terminal was where developers went to be weird in peace.

Aliases. Half-remembered shell scripts. curl | jq rituals. SSH sessions with the emotional stability of a raccoon in a server room.

Now GitHub has announced enterprise-managed plugins for GitHub Copilot CLI, and I think the interesting part is not “Copilot can do more things in the terminal.”

The interesting part is this:

the terminal is becoming an AI action surface, and AI action surfaces eventually become governed runtimes.

Not because vendors are evil. Not because platform teams are control freaks. Because once an assistant can touch tools, repositories, cloud accounts, secrets, and deployment paths, “just let developers use it” stops being serious.

the terminal used to be personal space

The terminal has always been powerful, but its power was mostly mediated through the person typing.

If I ran a destructive command, that was on me. If I installed a sketchy CLI, that was on me. If I glued five tools together with a shell pipeline and vibes, at least the blast radius moved at human typing speed.

AI changes that shape.

A CLI assistant is not just another autocomplete. It can interpret intent, discover commands, call tools, chain steps, edit files, summarize errors, propose fixes, and sometimes take actions faster than the developer fully reviews each intermediate decision.

That does not make it bad. It makes it operational.

The moment the assistant can say “I will create the branch, update the config, run the migration, open the PR, and fix CI,” the terminal has stopped being only a personal workspace. It has become a runtime for delegated work.

And delegated work needs rules.

plugins are where the governance starts

Enterprise-managed plugins sound like a boring admin feature. That is why they matter.

A plugin system answers very practical questions:

which tools can the assistant call?
who approved those tools?
which teams can use them?
how are they updated?
what permissions do they imply?
where does auditability start and end?

This is the same movie we watched with browser extensions, IDE extensions, Kubernetes admission controllers, CI marketplace actions, and Terraform modules. At first, the ecosystem is fun and chaotic. Then a few incidents happen. Then someone asks why a random package had access to production-adjacent credentials. Then the company discovers governance.

The AI version will be faster because the assistant is not only installing plugins. It is using them on behalf of a human.

That distinction matters.

A normal CLI plugin waits for me to make mistakes. An AI-enabled CLI plugin can help me make mistakes at scale.

the real product is not the chat. it is the permission boundary.

Every AI coding demo wants to show the assistant doing useful work. Fair enough. Demos need movement.

But in production, the valuable questions are much less cinematic:

can the assistant read this repository?
can it modify infrastructure code?
can it call cloud APIs?
can it open pull requests?
can it inspect secrets?
can it trigger deployments?
can it run commands against customer data?
can it install a new plugin because the task seems to require it?

That is the real interface.

The chat window is just how the human expresses intent. The permission boundary is where architecture happens.

This is why GitHub’s adjacent MCP security announcements also matter: secret scanning with GitHub MCP Server is generally available, and dependency scanning with GitHub MCP Server is in public preview. The direction is obvious: agents and assistants are being connected to tool ecosystems, and the security model is trying to catch up.

Good.

Because a world where agents can use tools but organizations cannot reason about tool permissions is not developer empowerment. It is unattended automation with nicer copywriting.

we are rebuilding internal platforms inside developer machines

The funny part is that this looks new, but the organizational pattern is old.

Platform teams spent years building internal developer platforms so teams would not have to remember every scary detail of infrastructure. Golden paths, templates, policy checks, paved roads, deployment workflows, observability defaults. All the boring stuff that makes delivery repeatable.

Now AI assistants are moving some of that action back into the developer’s local loop.

The terminal becomes a place where the assistant can:

query internal docs
call approved service APIs
generate infrastructure changes
run validation commands
open tickets or pull requests
inspect CI failures
apply team-specific workflows

That is convenient. But it also means the local developer environment is becoming a thin edge of the internal platform.

If that edge is unmanaged, every laptop becomes a snowflake platform.

If that edge is overmanaged, developers will route around it with their own tools.

The hard part is the middle: enough governance to make AI actions safe, not so much governance that the assistant becomes a slower way to file a ticket.

the boring design rule: approve capabilities, not vibes

If I were designing this inside a company, I would avoid starting with a giant “AI policy” document that nobody reads.

I would start with capabilities.

For example:

the assistant may summarize logs, but not access raw customer PII
the assistant may draft Terraform, but not apply it
the assistant may open a pull request, but not merge it
the assistant may run tests, but not deploy to production
the assistant may query dependency risk, but not auto-upgrade critical packages without review
the assistant may use approved internal plugins, but not install arbitrary external ones during a task

This is much clearer than “use AI responsibly.”

Responsible according to whom? Under what permissions? With what audit trail? In which repositories? Against what data?

Vibes do not scale. Capability boundaries do.

And once you define capabilities, enterprise-managed plugins start to make sense. They are not just a catalog feature. They are a way to package what the assistant is allowed to do.

developers still need escape hatches

There is a trap here, though.

If companies turn AI-in-the-terminal into another locked-down enterprise sadness machine, developers will hate it, and they will be right.

The terminal is powerful because it supports exploration. Sometimes you need to run a weird command, inspect a strange failure, test a new tool, or build a tiny script that would never survive a platform review meeting.

So the goal is not to make the terminal sterile. The goal is to separate exploration from delegated authority.

A human experimenting locally is one risk shape. An assistant calling tools with organization-approved permissions is another. Good platforms understand that difference. They allow local weirdness, but put review, audit, and ownership around actions that touch shared systems.

Not one giant allow button.

this is senior engineering work now

This is where I think the career conversation gets more interesting than “will AI replace developers?”

Somebody has to define the boundaries.

Somebody has to decide which commands are safe for an assistant to run. Somebody has to package internal workflows as plugins. Somebody has to make sure generated changes leave durable artifacts. Somebody has to connect audit logs to reality. Somebody has to notice when the assistant is technically allowed to do a thing but organizationally should not.

That is engineering work.

Not glamorous, maybe. But very real.

The future of developer productivity is not only better models. It is better delegation contracts.

The assistant can be brilliant, but if every useful action ends in “please ask an admin,” nobody will use it. If every useful action is silently allowed, eventually it will do something expensive, unsafe, or deeply annoying.

The valuable layer is the one that makes the right action easy, the risky action explicit, and the forbidden action impossible.

That is platform engineering with an AI accent.

the punchline

Enterprise-managed Copilot CLI plugins are not just a GitHub feature checkbox. They are a signal that the terminal is being pulled into the same governance story as the rest of the engineering system.

That was inevitable.

Once AI assistants can operate tools, the question is no longer “which assistant gives the best answer?”

The question is:

What is this assistant allowed to do when the answer becomes an action?

That is the line between a neat demo and a production system.

The terminal is still going to be weird. I hope it stays weird. Software would be worse if every shell session had the personality of an expense report.

But the parts of the terminal that act on behalf of the company are going to become governed, packaged, permissioned, and audited.

Not because the terminal lost its soul.

Because AI gave it hands.

AI Tools Have Shorter Half-Lives Than the Workflows They Automate

Paulo Victor Leite Lima Gomes — Wed, 06 May 2026 00:04:16 +0000

There is a very boring announcement that engineering teams should take more seriously than most AI product launches.

AWS announced the end of support for Amazon Q Developer in the AWS Console mobile app. GitHub recently announced the upcoming deprecation of GPT-5.2 and GPT-5.2-Codex. Every week another AI product gets renamed, bundled, sunset, repriced, rate-limited, or quietly converted from “the future of software engineering” into “please migrate before June.”

This is architecture.

The thing we pretend is stable — the AI tool — is often the most disposable part of the system.

The thing we treat as informal — the workflow around it — is usually the part that survives.

My take is simple: engineering teams should design AI-assisted workflows as if every specific assistant, model name, IDE integration, and hosted feature has a short half-life.

Because it does.

tools churn faster than habits

Developers love tools, but organizations run on habits.

A tool can be replaced in a procurement cycle. A habit gets embedded in onboarding docs, pull request norms, incident response, security review, and the weird tribal rules people only learn after breaking production once.

That is why AI tooling churn matters.

If a team uses an assistant to summarize logs, generate test cases, write migration plans, or review Terraform, the dangerous dependency is not only the vendor API. It is the assumption that the tool-shaped workflow will keep existing in the same form.

Today the workflow is:

open IDE plugin
select code
ask model X
paste result into PR
hope reviewer notices the spooky part

Tomorrow the IDE plugin is deprecated, model X is renamed, the context window changes, the pricing changes, the security team disables paste access, and the assistant now lives inside a chat tab with a different memory model.

The work did not disappear.

Only the interface did.

That is the annoying part. AI assistants are marketed like durable coworkers, but they currently behave more like SaaS features during a land grab. Some will become stable products. Many will not. They will keep changing faster than your engineering process should.

model names are not architecture

One smell I keep seeing is teams documenting workflows around specific model names.

“Use Claude X for refactors.”
“Use GPT Y for test generation.”
“Use Amazon Q for AWS questions.”
“Use Copilot for pull request summaries.”

That is fine as a preference. It is not fine as architecture.

A model name is a versioned implementation detail.

The architectural object should be the capability you need:

propose a small refactor with constraints
summarize an incident timeline from logs
explain a cloud bill anomaly
generate tests from observed behavior
check a migration plan for rollback gaps
classify dependency risk before merge
produce a human-readable design review draft

Those capabilities can be routed through different assistants, models, prompts, policies, and environments over time. If the workflow is written around the capability, you can swap the tool. If it is written around the product surface, every vendor change becomes a tiny migration project.

This is the same lesson we learned with cloud services, CI providers, observability tools, and message queues. The abstraction should not pretend the implementation does not matter, but it should make the replaceable part obvious.

With AI tooling, that replaceable part is very often the branded assistant.

the stable unit is the engineering contract

So what should be stable?

Not the model.
Not the chat UI.
Not the plugin.
Not the button named “auto mode.”

The stable unit should be the engineering contract around the workflow.

If your team uses AI to help with database migrations, the contract might be:

the assistant can draft the migration plan
the plan must include rollback steps
it must identify locking risks
it must include expected runtime and blast radius
it must cite the schema diff it used
a human owner must approve it before execution
the final artifact lives in the repo, not inside chat history

That contract can survive a tool migration.

Maybe today it runs through one assistant. Next quarter it goes through another. Later it becomes a GitHub Action or an internal platform feature with model routing, policy checks, and audit logs.

Good. That is how useful automation grows up.

The mistake is letting the first convenient UI become the process.

approval gates are the real product

This is why I find the industry’s recent obsession with “autonomous coding” slightly funny.

The demo always wants to show the agent doing everything. The production system usually becomes interesting at the approval gates.

Who can let the agent modify infrastructure? Who can approve package upgrades? Which paths can it edit without review? When does it need a test run or security approval? What does it do when CI fails? Where is the audit trail?

That is the real product surface.

Not the cute animation where an agent opens twelve files and looks busy.

When a specific AI tool goes away, the team that built around approval gates, artifacts, and clear ownership can migrate. The team that built around vibes has to rediscover its process under pressure.

This is also where senior engineers should spend more attention. Not “which AI tool writes the best boilerplate this month?” That question decays quickly.

The better question is:

Which parts of our engineering process become safer, faster, or more observable if an AI can draft work but not silently change the contract?

keep the artifacts outside the assistant

If I had to give one practical rule, it would be this:

Never let the assistant be the only place where the work exists.

Prompts, generated plans, evaluations, test outputs, review notes, and operational decisions should end up somewhere durable when they matter: repository files, PR comments, design docs, tickets, incident timelines, runbooks, audit logs.

Chat history is not a system of record. It is a scratchpad with better autocomplete.

AI tools do not just disappear. They mutate. Memory formats change. Export behavior changes. Enterprise retention settings change. Context windows change. Integrations get rebuilt. A workflow that depends on “the assistant remembers” has amnesia scheduled for a future date.

For small personal tasks, who cares. Let the chat be messy.

For engineering work that affects production, compliance, money movement, customer data, or infrastructure, the artifact needs to survive the tool.

design for boring replacement

The healthiest AI-assisted engineering stacks will probably look less magical than the demos.

They will have boring properties:

prompts versioned near the code they affect
model and vendor configuration separated from workflow logic
output schemas for important generated artifacts
tests and policy checks around agent-written changes
approval gates for destructive or expensive actions
audit trails for who asked what and what changed
fallback paths when a model or provider is unavailable
enough documentation that a human can perform the workflow manually

None of this is glamorous. That is why it is probably correct.

The teams that win with AI will not be the ones who bet the company on one assistant being magical forever. They will be the ones who turn useful AI behavior into replaceable workflow components.

That does not mean all AI tools are bad. Some are excellent. I use them constantly. The point is almost the opposite: because they are useful, we should stop treating them like toys.

Adult architecture assumes dependencies change.

the uncomfortable vendor lesson

Vendors are going to keep moving quickly because the market is still unstable. Model costs change, safety requirements change, partnerships change, enterprise controls change, and product teams are still figuring out what people actually use after the demo high wears off.

So yes, use the tools.

But do not confuse vendor velocity with platform stability.

If an assistant becomes central to your delivery process, ask the same boring questions you would ask about any other critical dependency: can we export the artifacts, switch providers, audit usage after an incident, and keep releasing when a model is deprecated or unavailable?

Boring questions are where production lives.

the punchline

The end of support for one Amazon Q surface is not the end of the world. A GitHub model deprecation is not a crisis. Most individual AI tooling changes are small.

But the pattern matters. AI developer tools are still in a fast-churn phase, and engineering teams should stop acting surprised when fast-churn things churn.

The durable investment is not memorizing this month’s assistant UI. It is building workflows where AI can help, humans can approve, artifacts can survive, and vendors can be swapped without turning delivery into archaeology.

The assistant is not the architecture.

The workflow is.

And if the workflow only works while one branded assistant exists in exactly its current shape, it is not a workflow yet.

It is a demo with a calendar invite for future pain.

How to build an accrual-based credit ledger

Paulo Victor Leite Lima Gomes — Tue, 05 May 2026 15:04:26 +0000

Ledgers are the heartbeat of any financial companies, fintech or old school financial. Not the API gateway, not the mobile app, not the underwriting model.

The ledger

Banks have known this for centuries. Fintechs sometimes need to rediscover it the hard way, or they learn during the way.

On fintech industry Revolut runs multi-currency, multi-product financial infrastructure across 35+ countries and counting 🚀...

Stripe moves money and extends credit infrastructure for millions of businesses, sometimes you don't even know, but stripe is there.

Nubank serves more than 130 million customers 🤯 and had to make credit work at Latin American scale, starting with high brazilian, my beloved country complexity and competitive bank system. Seriously, Nubank is just unique.

Chime built credit-builder products on top of a US neobank model, how to compete? Just use them 😌.

Klarna and Affirm made deferred payments mainstream, which also means ledger complexity at global BNPL scale, they didn't change only finance, they scale and enable retail growth.

At this point you got me right? Different products, different geographies. But you know what they have in common? Their accounting HAVE to be in a good shape. So they share the same pressure: move fast without corrupting the books.

That is the uncomfortable thing about ledgers. The product team wants speed. The regulator wants auditability(is this a word?). Finance wants reconciliation. Engineering wants evolvability and not creating technical debts.

Customers just want their balance to be correct.

And ledger decisions made in year one become the ceiling in year five. The model that worked for 10,000 users becomes the bottleneck at 10 million, imagine 100 million? (Hello Nubank!!!).

The cron job that looked pragmatic becomes the reason nobody trusts end-of-day balances.

The table that was “good enough for MVP” becomes the thing auditors stare at for three months.

The famous sharding infrastructure worked well till some millions, later, sharding and infrastructure scaling is not necessarily the problem.

The Synapse collapse in 2024 was a brutal reminder of this. When money movement companies cannot clearly reconcile who owns what, the failure is not only technical. It becomes customer harm. Millions of dollars can end up disputed, delayed, or unreconciled because the ledger was not strong enough to be the source of truth.

This article is about designing a credit ledger before that pain arrives.

One important boundary: this is intentionally about a single-geography credit ledger. No multi-country posting rules, no cross-currency accounting, no global consistency model. Those are a different beast. I will cover them in the next article.

The evolution most fintechs go through

Most credit products do not start with a beautiful accrual ledger. They start with a product requirement:

“We need to charge interest.”

Then a team adds a job. Later, events. Later, after enough incidents, a proper accrual model.

That evolution is normal. The trick is not pretending the first version is the final one.

Stage 1: the job-based ledger

The simplest ledger is a scheduled job.

Every hour, every night, or every billing cycle, a cron job scans accounts and creates bookkeeping movements:

00:00 ───────────────────────────────────────────────► time

10:03  purchase happens
11:18  payment happens
14:42  fee is incurred

23:59  ledger_job runs
      ├─ posts purchase movement
      ├─ posts payment movement
      └─ posts fee movement

This works surprisingly well at small scale. It is easy to reason about. You can query the database, calculate what changed, and insert rows into a ledger table. Many early fintech systems start here because it lets the team ship.

The problem is that job-based ledgers mix three different concepts:

when something happened,
when the system noticed it happened,
when accounting was posted.

At low volume, the difference is invisible. At scale, it becomes the whole problem.

A customer pays at 11:18, but the ledger does not reflect it until 23:59. A fee is incurred at 14:42, but the job fails and retries at 01:10. Two jobs overlap and double-post. A reprocessing script tries to fix yesterday but accidentally changes today.

The core issues are predictable:

Delayed consistency: balances are stale by design.
Race conditions: two jobs can process the same account or overlapping time windows.
Poor auditability: “what was the balance at 14:00?” becomes hard if entries are posted later without the correct effective date.
Painful reprocessing: fixing a bad job means deciding whether to delete, update, or overwrite ledger rows. All three are dangerous.
Scaling by brute force: when volume increases, you make the job faster. Eventually the job becomes a monster.

The job-based ledger is not evil. It is just a starting point. The mistake is letting it become the foundation of a serious credit platform.

Stage 2: the event-based ledger

The next step is to post ledger entries when business events happen.

A payment is received. A charge is applied. A late fee is created. A statement closes. Instead of waiting for a batch job, the system reacts immediately.

Domain event                         Ledger reaction
────────────                         ───────────────
PaymentReceived ───────────────────► post payment entry
PurchaseAuthorized ────────────────► post authorization entry
FeeIncurred ───────────────────────► post fee entry
StatementClosed ───────────────────► post billing entries

This is much better. The ledger is closer to real time, and the accounting logic sits near the business event that created it. Martin Fowler’s accounting patterns make this connection explicit: domain events and accounting entries should be linked, because accounting is a record of business reality, not an isolated reporting table.

But event-based does not automatically mean robust.

A common implementation looks like this:

API request
  ├─ update product state
  ├─ publish event
  └─ write ledger entry

Or worse:

API request
  ├─ update product state
  ├─ call ledger service synchronously
  └─ return success to customer

Now the ledger is coupled to the transaction path. If the ledger service is slow, the product is slow. If the event publish fails after the product state changes, the books are wrong. If the same event is delivered twice, you double-post. If events arrive out of order, the ledger reflects a reality that never existed.

        ┌──────────────┐
        │ Credit API   │
        └──────┬───────┘
               │ emits
               ▼
        ┌──────────────┐        tight coupling risk
        │ Domain event │ ──────────────────────────┐
        └──────┬───────┘                           │
               │ consumed                           ▼
               ▼                            ┌──────────────┐
        ┌──────────────┐                    │ User request │
        │ Ledger write │                    │ latency path │
        └──────────────┘                    └──────────────┘

Event-based ledgering is the middle ground. It is a necessary evolution from cron jobs, but it still needs three things to become safe:

immutable events,
idempotent processing,
deterministic replay.

Without those, you do not have a ledger architecture. You have a distributed system hoping the happy path stays happy.

Stage 3: the accrual-based ledger

A credit ledger should not only record when cash moves. It should record when value is earned or incurred.

That is the core idea of accrual accounting.

Interest is earned daily. Fees are incurred when the customer triggers them. A settlement is a separate event from the revenue already earned. Billing is a presentation and collection mechanism, not the moment the economics magically appear.

For a credit product, this distinction matters a lot.

If a customer carries a balance for 20 days, the platform is earning interest across those 20 days. Waiting until the statement closes to create one giant interest entry may look simpler, but it hides the actual economics. It also makes “balance as of” queries, partial reversals, mid-cycle adjustments, and audit trails harder than they need to be.

An accrual-based credit ledger treats accounting like this:

Day 1      Day 2      Day 3      ...      Cycle close        Payment
│          │          │                    │                  │
▼          ▼          ▼                    ▼                  ▼
Accrue     Accrue     Accrue               Bill accrued       Settle cash
interest   interest   interest             interest           receivable

Accounting view:
- daily: debit interest receivable, credit interest income
- cycle close: move accrued amounts into statement balance
- payment: debit cash/settlement account, credit customer receivable

This is how accounting actually works. Fintechs that skip it often end up retrofitting it later, usually after finance, risk, or regulators start asking questions the old model cannot answer.

Double-entry is the checksum

At the center of this design is double-entry bookkeeping.

Every ledger entry has two sides. One account is debited. Another account is credited. The total must balance.

For a daily interest accrual, the entry might be:

Debit:  Interest receivable      1.25 USD
Credit: Interest income          1.25 USD

The customer owes more. The company earned revenue. Two sides of the same fact.

This is not accounting ceremony. It is a system invariant. If debits and credits do not net to zero, the ledger rejects the entry. That gives you a built-in checksum for every financial movement.

A single-sided balance table can tell you what you think a customer owes. A double-entry ledger can tell you whether the books still make sense.

That difference is everything.

The ledger should be append-only

A serious ledger does not update old entries. It does not delete them either.

It appends.

If you posted the wrong amount, you post a reversal and then a corrected entry. The history remains sacred.

entry_id   type        debit_account          credit_account       amount
────────   ────────    ─────────────────      ─────────────────    ──────
E1         ACCRUAL     interest_receivable    interest_income      10.00
E2         REVERSAL    interest_income        interest_receivable  10.00
E3         ACCRUAL     interest_receivable    interest_income       9.50

That pattern feels annoying when you are moving fast. It is also the reason you can answer audit questions later.

Why was the customer balance different yesterday? Read the log.

What did the system believe at 10:35? Query entries with effective_date <= 10:35 and created_at <= investigation_cutoff.

Can we reproduce last month’s statement? Replay the events and ledger entries as they existed then.

This is where Mettle’s Write Once Double Entry pattern is a great real-world reference. WODE is basically the grown-up version of what many fintech teams eventually learn: write once, balance always, correct by appending, and make the ledger boring enough to trust.

Event sourcing is the backbone

Accrual ledgering and event sourcing fit naturally together.

The product emits immutable domain events:

PurchasePosted
PaymentSettled
InterestAccrued
LateFeeIncurred
StatementClosed
ChargeReversed

The ledger consumes those events and produces immutable accounting entries. Each entry points back to the event that caused it.

┌─────────────────┐
│ Domain command  │
│ "apply payment"│
└────────┬────────┘
         ▼
┌─────────────────┐
│ Domain event    │
│ PaymentSettled  │
└────────┬────────┘
         ▼
┌─────────────────┐
│ Accrual /       │
│ posting rules   │
└────────┬────────┘
         ▼
┌────────────────────────────────────────────┐
│ Immutable double-entry ledger entries       │
│ source_event_id = PaymentSettled.event_id   │
└────────────────────────────────────────────┘

This gives you a clean rule: product state is derived from product events, and accounting state is derived from accounting entries produced from those events.

If you replay all events through the same posting rules, you should get the same ledger. If you do not, either the rules are not deterministic or the event log is incomplete. Both are bugs worth finding early.

Event sourcing also changes how you think about failures. A failed projection is not a data-loss incident if the event is still there. You fix the processor, replay, and rebuild. That is the difference between a recoverable system and a spreadsheet with APIs.

Eventual consistency is fine. Wrong money is not.

A common objection is: “But if the ledger is event-driven, it may be slightly behind.”

Yes. That is usually fine for credit.

A credit ledger being 200 milliseconds behind the authorization system is not a disaster. A ledger double-posting interest is. A missing payment is. A fee applied before the balance it depends on is. An out-of-order reversal that leaves the customer owing money they do not owe is.

The trade-off is not strong consistency versus chaos. The trade-off is where you need immediate consistency and where you need deterministic eventual consistency.

For most credit ledgers:

the customer-facing authorization path may need immediate answers,
the ledger may process asynchronously,
the processing must be idempotent,
events must have ordering guarantees per account or credit line,
every ledger entry must carry an idempotency key,
replay must not create duplicate entries.

An idempotency key can be simple and powerful:

interest-accrual:{credit_account_id}:{accrual_date}:{rate_version}

If the processor retries, the ledger sees the same key and refuses to post the same economic fact twice.

That is the difference between eventual consistency and eventual regret.

A practical ledger entry shape

You can make the schema more sophisticated later, but a useful starting point looks like this:

ledger_entries(
  entry_id,
  type,
  debit_account,
  credit_account,
  amount,
  currency,
  effective_date,
  created_at,
  idempotency_key,
  source_event_id
)

A few fields matter more than they look:

effective_date is when the economic event applies.
created_at is when the system recorded it.
idempotency_key prevents duplicate posting.
source_event_id links accounting back to business reality.
currency should be explicit even in a single-geography system. You will thank yourself later.

For a serious platform, you will also add account types, journal batches, metadata, posting rule versions, actor/service identifiers, and partition keys. But do not lose the core shape: debit, credit, amount, currency, time, idempotency, source.

Daily interest accrual pseudocode

Here is the kind of logic I would expect in a first version. Not production code, but the shape is right.

for credit_account in active_credit_accounts:
    accrual_date = today_in_product_timezone()

    balance = principal_balance_as_of(
        credit_account.id,
        accrual_date.start
    )

    if balance <= 0:
        continue

    rate = interest_rate_for(
        credit_account.id,
        accrual_date
    )

    daily_interest = round_money(
        balance * rate.annual_percentage / days_in_year(accrual_date)
    )

    if daily_interest == 0:
        continue

    idempotency_key = "interest-accrual:" +
        credit_account.id + ":" +
        accrual_date + ":" +
        rate.version

    post_double_entry(
        type = "INTEREST_ACCRUAL",
        debit_account = account("interest_receivable", credit_account.id),
        credit_account = account("interest_income"),
        amount = daily_interest,
        currency = credit_account.currency,
        effective_date = accrual_date,
        source_event_id = current_accrual_event.id,
        idempotency_key = idempotency_key
    )

There are many details hidden here: day-count convention, rounding policy, grace periods, promotional rates, delinquency state, local regulation, charge-off treatment. Those are product and accounting rules, not reasons to avoid the accrual model.

Actually, they are reasons to prefer it. Complex rules are easier to manage when every economic fact has a precise entry and a source event.

Correction entries, not edits

Imagine the system accrued 10.00 USD of interest, but later you discover the correct amount was 9.50 USD because a payment was effective one day earlier.

Do not update the original row.

Post this:

Original:
  Dr interest_receivable  10.00
  Cr interest_income      10.00

Reversal:
  Dr interest_income      10.00
  Cr interest_receivable  10.00

Corrected:
  Dr interest_receivable   9.50
  Cr interest_income       9.50

Now the ledger tells the truth twice:

what the system originally believed,
how that belief was corrected.

That second part matters. A ledger that only stores the latest truth is not an audit trail. It is a mutable cache.

Where teams usually get hurt

The hardest part of building a credit ledger is not the table design. It is resisting shortcuts that feel harmless.

Shortcuts like:

storing only customer balances instead of entries,
treating billing as the moment revenue is earned,
letting jobs update historical rows,
using timestamps without separating effective_date from created_at,
allowing ledger writes without source events,
ignoring idempotency because “the event only fires once,”
building reconciliation after launch instead of as part of the ledger.

Every one of those shortcuts is understandable. Every one becomes expensive.

The better architecture is boring:

Domain events are immutable.
Posting rules are deterministic.
Ledger entries are double-entry.
Ledger writes are append-only.
Corrections are reversals.
Consumers are eventually consistent.
Reconciliation is continuous.

That is not overengineering. That is the minimum foundation for money.

Build versus buy

There is a reason ledger-as-a-service companies and open-source ledgers are getting attention. Formance and Blnk are examples of the community moving toward purpose-built ledger infrastructure instead of every fintech reinventing the same accounting core. Temporal’s work on high-performance ledger patterns also points in the same direction: reliability, replayability, and operational resilience are not optional features.

My opinion: most fintechs should not casually build a ledger from scratch. If the ledger is not a core differentiator, buying or adopting a proven ledger engine is rational.

But credit platforms often have enough product-specific accounting behavior that the team still needs to deeply understand the model. Even if you buy the ledger infrastructure, you still own the posting rules. You still own correctness.

A vendor can provide the engine. It cannot decide your economics.

The simple standard

A good credit ledger should let you answer these questions without panic:

What does this customer owe right now?
What did they owe at the end of last month?
Which event created this entry?
Did every debit have a matching credit?
Can we reverse this without deleting history?
Can we replay the ledger from events?
Can finance reconcile cash, receivables, income, fees, and adjustments?
Can auditors see both the original mistake and the correction?

If the answer is no, the platform is not ready for scale. It may still work as a product. It may even grow quickly. But the ledger is already putting a ceiling on the company.

That ceiling always gets lower as volume grows.

Final thought

The right ledger architecture will not make your fintech move slower. It will let you keep moving after the product becomes serious.

Job-based ledgers help you start. Event-based ledgers help you react. Accrual-based ledgers help you tell the economic truth.

For credit, that truth matters every day interest is earned, every time a fee is incurred, every time a customer pays, and every time finance needs to close the books.

This article deliberately stayed inside a single-geography model. Multi-geography ledgers, currency conversion at the ledger layer, local accounting rules, and global consistency are out of scope here.

That is the next article... I'm tired...

References

My experience 👨🏻‍💻🇧🇷😀
The downfall of Synapse yahoo finance
Martin Fowler, Accounting Narrative
Microsoft Azure Architecture Center, Event Sourcing pattern
Mettle, Innovation at Mettle: Double Entry and Event Sourcing
Temporal, Designing high-performance financial ledgers with Temporal
Apideck, Money movement infrastructure: fintech ledger as a service
Martin Fowler, Accounting Entry
Formance, Open-source programmable ledger
Blnk Finance, Open-source immutable ledger

Tactical Debt Is the Silent Killer of Engineering Velocity

Paulo Victor Leite Lima Gomes — Tue, 05 May 2026 09:03:22 +0000

There is a kind of engineering debt that does not show up in static analysis, does not trigger your test suite, and will not be fixed by refactoring a bad class.

It lives in the way the team operates.

Nobody owns the service. Deployments need a human ritual. The sprint plan dies on Tuesday because production is on fire again. The one person who understands payments is on vacation and suddenly everyone is politely pretending not to panic.

This is tactical debt.

And I think it destroys more engineering velocity than most teams are willing to admit.

Technical debt gets all the attention because it is visible to engineers. You can point to the messy module. You can complain about the missing tests. You can open an IDE and feel the pain directly.

Tactical debt is sneakier. It is the boulder chained to the team while everyone is still debating whether the codebase is clean enough.

The cruel part is that tactical debt absorbs productivity gains.

You can improve your test suite. You can adopt better tooling. You can hire strong engineers. You can use AI to write code faster.

But if the path from idea to production is full of unclear ownership, manual steps, approval mazes, status theater, and tribal knowledge, the extra productivity just gets converted into waiting.

AI may help you write the pull request in twenty minutes.

Tactical debt makes sure it still takes three weeks to reach production.

tactical debt is not technical debt

This distinction matters.

Technical debt is about the shape and quality of the software system. Tactical debt is about the shape and quality of the operating system around the software system.

They are related, but they are not the same thing.

You can have ugly code and a high-velocity team if ownership is clear, deployment is automated, decisions are fast, and operational feedback loops are healthy.

You can also have a beautifully designed codebase trapped inside an organization where every change requires five meetings, three approvals, a release coordinator, and someone named Rodrigo who is the only person allowed to touch production because of an incident in 2021.

The code may be clean.

The team is still slow.

This is why some technical-debt programs fail. Teams spend a quarter improving internals and then wonder why delivery still feels stuck. The answer is uncomfortable: the bottleneck was never only in the code.

The bottleneck was in the way work moves.

Technical debt usually asks: “Is the system easy to change?”

Tactical debt asks: “Can the team actually get a change safely into the hands of users?”

Those are different questions. Mature engineering organizations need to care about both.

unclear ownership turns small questions into archaeology

A healthy system has an answer to a boring question: who owns this?

Not in an abstract Confluence sense. In the practical sense.

Who gets paged? Who approves risky changes? Who understands the business constraints? Who can decide whether this API behavior is intentional or accidental?

When ownership is unclear, simple work becomes detective work.

A product manager asks for a small change in a service. The engineer opens the repository, checks the README, sees that it was last meaningfully updated two years ago, asks in Slack, gets three conflicting answers, and eventually discovers that the service was built by a team that no longer exists.

Now the ticket is not “change this behavior.”

The ticket is “perform organizational archaeology until someone is brave enough to say yes.”

This is tactical debt.

And it is expensive because it taxes every future change, not just the first one.

manual work is latency disguised as caution

Manual work often enters the system with good intentions.

A production deploy needed care. A migration was risky. A release checklist caught one important mistake once. So the team kept the ritual.

Then the ritual became normal.

Now a deployment requires someone to click through a checklist at midnight, update a spreadsheet, paste output into a channel, wait for a human approval, run a script from their laptop, and hope the VPN behaves.

Everyone agrees this is “safer.”

Often it is not.

Manual work is inconsistent automation executed by tired humans.

It adds latency, creates hidden dependencies, and makes releases emotionally expensive. When deployment hurts, teams batch changes. When teams batch changes, releases get riskier. When releases get riskier, the organization adds more manual control.

The loop feeds itself.

Good automation is not about moving fast recklessly. It is about making the safe path the easy path.

If shipping requires heroics, velocity will eventually collapse into negotiation.

status meetings are usually a symptom

I am not anti-meeting. Some meetings are useful. Talking to humans is not a failure mode.

But many status meetings are not coordination. They are compensation.

They exist because the actual system for communicating progress does not work.

The board is stale. The tickets are vague. Decisions are buried in private chats. Dependencies are invisible. Nobody trusts async updates. So the organization creates a recurring ceremony where everyone verbally reconstructs reality.

This is synchronous theater.

It feels productive because people are talking. But the output is often just temporary shared awareness that expires after lunch.

The fix is rarely “cancel all meetings.” The fix is making the work legible.

Clear ownership. Written decisions. Useful tickets. Visible dependencies. Async updates that people actually trust.

Once the system is legible, meetings can return to what they are good for: judgment, conflict, alignment, and decisions.

Not reading the Jira board out loud.

hero dependencies are not a compliment

Every company has the person.

The one who understands payments. Or Kubernetes. Or the pricing engine. Or why settlement fails on the last business day of the month in one specific market.

At first, this person looks like an asset. They are fast, helpful, reliable, and terrifyingly knowledgeable.

Then they go on vacation.

Suddenly the whole organization discovers that “we have documentation” meant “we have a Slack thread from March and maybe a diagram in someone’s Google Drive.”

Hero dependencies are tactical debt with a friendly face.

They feel good because heroes save the day. They are dangerous because the system learns to depend on being saved.

The answer is not to punish strong engineers. The answer is to stop turning competence into a single point of failure.

Pair on risky domains. Rotate operational ownership. Write down the weird parts. Make onboarding to critical systems a real activity. Reward people for making themselves less required, not more indispensable.

A team that cannot survive one engineer taking a holiday is not high-performing.

It is fragile.

reactive fire drills make planning fictional

A sprint plan is a hypothesis.

In some teams, it is also fiction.

Not because engineers are lazy. Not because product is bad at prioritization. But because the organization has accepted constant interruption as normal.

Production is always on fire. Incidents are frequent. Customer escalations bypass prioritization. Leadership asks for “quick checks” that become full projects. Every week starts with a plan and ends with a pile of emergency context switches.

This is one of the most brutal forms of tactical debt because it attacks deep work.

Software engineering needs sustained attention. You cannot design well in twenty-minute fragments between escalations. You cannot reason about distributed systems while half your brain is waiting for the next alert.

Fire drills also create a nasty management illusion: the team looks busy, responsive, and important.

But responsiveness is not the same as progress.

If every week is exceptional, nothing is exceptional. The system is just underdesigned.

Fixing this usually requires boring operational discipline: incident review, error budgets, better alert quality, platform investment, clearer escalation paths, and the courage to say that not every interruption deserves immediate engineering attention.

Velocity is not how fast you react to chaos.

Velocity is how much chaos you no longer create.

poor handoffs are where context goes to die

Bad handoffs are incredibly expensive because they usually happen at boundaries: between product and engineering, engineering and QA, development and operations, one team and another team.

The classic version is “it works on my machine.”

But the more subtle version is worse.

A team finishes a project and throws it over the wall with incomplete context. The receiving team gets code but not the assumptions. A migration plan but not the failure modes. An API contract but not the customer promises. A dashboard but not the meaning of the alerts.

Then everyone acts surprised when the handoff creates rework.

Good handoffs are not ceremonies. They are context transfer.

What changed? Why? What tradeoffs were made? What should the next team watch? What is safe to modify? What is load-bearing and ugly but intentional?

If that information is not transferred, the receiving team pays the tax later.

Usually during an incident.

information silos turn companies into slow databases

Information silos are not just a documentation problem. They are a query problem.

In a healthy organization, an engineer can ask, “Why does this work this way?” and find a reliable answer.

In a siloed organization, the answer exists somewhere, but the retrieval mechanism is social luck.

Maybe it is in a private channel. Maybe it was discussed in a meeting that was never documented. Maybe it lives in the head of someone who moved teams. Maybe it was in an ADR, but the ADR folder has thirteen conflicting versions and no one knows which one matters.

So engineers query the company like a bad distributed database.

They ask around. They wait. They get partial answers. They merge gossip with code reading. Then they make a decision with low confidence.

This is slow, but worse than slow: it makes teams conservative.

When people cannot understand the system, they avoid changing it. When they must change it, they over-escalate. When they over-escalate, the organization adds process. The boulder gets heavier.

Documentation helps, but only if it is part of the work, not a guilt ritual after the work.

A useful rule: if a decision will matter in three months, write it where future engineers will actually look.

excess approvals create responsibility without authority

Approvals are seductive.

They make risk feel managed. They create a trail. They give leadership a sense that important changes are being controlled.

Sometimes approvals are necessary. Regulated systems, financial flows, security-sensitive changes, and irreversible actions need real governance.

But excess approvals are different. They are what happens when an organization does not trust its own operating model.

Instead of giving teams clear guardrails and authority, it inserts humans into every meaningful step.

Architecture review. Security review. Platform review. Product review. Release review. Manager review. Sometimes each one is valid in isolation. Together, they create a system where everyone is responsible and nobody is empowered.

The cost is not only waiting time.

The cost is learned helplessness.

Engineers stop making decisions because decisions will be relitigated anyway. Teams optimize for approval rather than outcomes. Documents become defensive. Meetings become political. Velocity becomes the speed at which consensus can be manufactured.

Good governance should make the safe decisions obvious and the risky decisions explicit.

Bad governance makes every decision slow.

tribal knowledge is a loan with terrible interest

Tribal knowledge is not automatically bad. Every team has local knowledge. Some things are easier to learn from people than from documents.

The problem starts when tribal knowledge becomes the primary storage layer for critical information.

Why do we deploy on Thursdays? Ask Mariana.

Why does this job run twice? Ask Ahmed.

Why is this field nullable? Ask the person who left last year.

At that point, the organization is not saving time by avoiding documentation. It is taking a loan.

The interest is paid by every future engineer who has to rediscover the same context.

AI makes this more interesting, and not always in a good way.

Generated code can move faster than organizational memory. If your team cannot explain why the system works the way it does, AI will happily produce changes that look reasonable and violate assumptions nobody wrote down.

The problem is not that AI is bad.

The problem is that AI amplifies the quality of the surrounding system.

If the surrounding system is full of tribal knowledge, unclear ownership, and manual release paths, AI will not save velocity. It will generate more work waiting to get stuck.

why tactical debt compounds

The dangerous thing about tactical debt is that each piece reinforces the others.

Unclear ownership creates more meetings.

Manual deployments require more approvals.

Hero dependencies create poor handoffs.

Poor handoffs create fire drills.

Fire drills prevent documentation.

Missing documentation strengthens tribal knowledge.

Tribal knowledge makes ownership harder to clarify.

And around we go.

This is why tactical debt feels normal from the inside. It does not arrive as one catastrophic decision. It accumulates as reasonable local compromises.

One manual step.

One exception process.

One undocumented decision.

One “let’s just ask Ana.”

One urgent escalation that bypasses the roadmap.

None of these feel fatal. Together, they become the operating system of the team.

Then leadership asks why engineering velocity is down.

The answer is chained to the team in plain sight.

the fix is operational design

You do not fix tactical debt by telling engineers to “move faster.”

You fix it by redesigning how work flows.

A few questions are more useful than most maturity models:

Can we name the owner of every production service?
Can a normal change reach production without heroics?
Can someone understand the current state of work without attending a meeting?
Can critical people take vacation without the team freezing?
Do incidents produce system improvements, or just exhaustion?
Are decisions written where future engineers will find them?
Are approvals protecting real risk, or compensating for missing trust?
Can a new engineer safely change an important system without a treasure hunt?

If the answer to most of these is no, the problem is not motivation.

It is tactical debt.

And the best teams treat it as engineering work.

They automate the manual path. They clarify ownership. They make decisions searchable. They reduce approval scope. They rotate knowledge. They improve handoffs. They measure interruption. They design communication channels instead of letting them decay into notification soup.

This work is not glamorous. It rarely produces a launch announcement. Nobody gets promoted because the deployment checklist got deleted.

But this is the work that makes every future feature cheaper.

AI does not remove the boulder

This is the part I think many companies are about to learn painfully.

AI can increase code production. It can help write tests, generate scaffolding, explain unfamiliar code, draft migrations, and accelerate repetitive engineering tasks.

That is useful.

But velocity is not code output.

Velocity is validated change delivered safely to users.

If your organization cannot absorb change, faster code generation just creates a larger queue in front of the same bottlenecks.

More pull requests waiting for unclear owners.

More generated changes waiting for manual deployment.

More code paths nobody understands because the original assumptions lived in someone’s head.

More review burden on the same heroes.

More incidents because the system got changed faster than the operating model improved.

AI does not magically fix tactical debt. In many teams, it will expose it.

That is not a reason to avoid AI. It is a reason to stop pretending that engineering productivity is only about typing speed.

The bottleneck was rarely the keyboard.

remove weight before adding horsepower

If a team is chained to a boulder, buying a faster bicycle is not the first-order fix.

You need to remove weight.

Not all at once. Not with a grand transformation program that creates three more steering committees and somehow makes the boulder larger.

Start smaller and sharper.

Pick one painful release process and automate it.

Pick one orphaned service and assign real ownership.

Pick one recurring status meeting and replace it with a written operating rhythm people trust.

Pick one hero dependency and deliberately spread the knowledge.

Pick one approval step and ask what risk it actually controls.

Pick one incident pattern and make it less likely to happen again.

The point is not process minimalism for its own sake. Some process is good. Adults need coordination.

The point is to make the organization lighter.

Because engineering velocity is not only a property of engineers. It is a property of the system engineers work inside.

And tactical debt is what happens when that system quietly gets heavier every month.

Clean code helps.

AI helps.

Better tools help.

But if the boulder stays chained to the team, every productivity gain will be absorbed by the same old drag.

The best engineering organizations I have seen are not the ones with zero debt. That does not exist.

They are the ones that can tell the difference between code that needs refactoring and an operating model that needs repair.

Then they repair both.

References

Martin Fowler, TechnicalDebt
Google SRE Book, Postmortem Culture: Learning from Failure
Accelerate / DORA research, Four Keys metrics
Team Topologies, Team Topologies patterns

Pod-Level Resources Are Kubernetes Admitting Containers Were the Wrong Accounting Unit

Paulo Victor Leite Lima Gomes — Tue, 05 May 2026 00:03:42 +0000

Kubernetes has a funny habit of announcing very practical features that accidentally say something philosophical.

Pod-level resource management is one of those.

On paper, the Kubernetes v1.36 updates are straightforward: pod-level resource managers are now alpha, in-place vertical scaling for pod-level resources is beta, and the kubelet is getting better at treating the pod as a shared resource boundary instead of only a bag of independent containers.

That sounds like release-note plumbing.

But I think the bigger story is this:

Kubernetes is quietly admitting that the container was never quite the right accounting unit for modern workloads.

Not the wrong isolation unit. Not the wrong packaging unit. Containers are still extremely useful.

But for budgeting CPU, memory, locality, sidecars, and operational responsibility, the pod is increasingly the unit that actually matches reality.

And once you see that, a lot of current platform pain starts making more sense.

containers were the clean story

The clean version of the container story was beautiful.

A service goes in a container. The container declares its CPU and memory. The scheduler finds a node. The kubelet enforces limits. Everyone pretends this is tidy.

For simple workloads, it mostly is.

The problem is that production pods are not always simple workloads anymore. They are little neighborhoods.

You have the main application container. Then maybe a service mesh sidecar. A log shipper. A metrics exporter. A backup helper. An init container. A data loader. Some agent-ish helper process that definitely started as “temporary” and is now load-bearing.

If every container needs its own resource story, the accounting gets weird fast.

The main workload may need exclusive CPUs, NUMA alignment, predictable memory, or tight latency behavior. The sidecars often do not. They need enough room to not fall over, but dedicating the same kind of premium resource treatment to every little helper container is wasteful.

Before pod-level resource managers, Kubernetes made that tradeoff awkward for performance-sensitive pods. If you wanted the pod to land in the right QoS and topology behavior, you could end up over-specifying resources for sidecars just to keep the whole thing eligible for the performance guarantees the primary workload needed.

That is not elegant resource management.

That is paperwork.

the pod is the real budget envelope

The useful mental model is simple: the pod is becoming the budget envelope.

Kubernetes v1.36 pod-level resource managers extend CPU, memory, and topology management so the kubelet can reason about .spec.resources at the pod level. Instead of treating every container as a totally separate accounting island, Kubernetes can allocate a pod-level budget and then let different containers consume from that envelope in more flexible ways.

For a latency-sensitive database pod, that means the database container can get the exclusive, NUMA-aligned slices it actually needs, while metrics or backup sidecars share from the pod’s remaining pool.

For an ML training pod, the training container can get the serious locality and CPU treatment, while a service mesh sidecar can stay in a more generic shared pool.

That distinction matters because it separates two ideas we often accidentally merge:

which container needs premium placement or isolation
how much total budget the workload should be allowed to consume

Those are not the same question.

The container is still a useful boundary for packaging and process-level isolation. But the pod is often the better boundary for cost, scheduling intent, performance shape, and ownership.

That is the part platform teams should care about.

sidecars made the old model leak

Sidecars are the obvious pressure point here.

A lot of Kubernetes architecture assumes sidecars are auxiliary, but operationally they are not free. They consume CPU. They consume memory. They affect startup time. They participate in failure modes. They turn a “single service” into a small distributed system inside one pod.

Service meshes made this visible years ago. AI workloads are making it louder.

An AI-era workload may include data movement, model serving, telemetry, policy checks, local caches, sandbox helpers, and control processes around the actual thing the business cares about. Treating each container as if it deserves a fully independent resource negotiation can be both too rigid and too noisy.

The pod-level model is basically Kubernetes saying: yes, we know these containers are related. Yes, we know some are more important than others. Yes, we know the old per-container model made people choose between performance guarantees and waste.

Good.

Because the platform should model the shape of the work, not force the work to cosplay as a simpler architecture.

in-place resizing makes this more than a cleaner YAML shape

The other v1.36 signal is in-place vertical scaling for pod-level resources moving to beta.

That matters because resource accounting is not only a deployment-time problem. Workloads change while they are running.

If a pod has a shared CPU budget and demand increases, being able to adjust the pod-level envelope without recreating the whole pod is a much better operational primitive. Kubernetes can track resize conditions, check node feasibility, and coordinate cgroup updates without forcing every change through the old “kill it and let the replacement be different” path.

This is especially useful for pods where containers inherit their effective boundaries from the pod-level budget. Instead of recalculating every container limit by hand, the platform can grow or shrink the shared envelope.

That sounds small until you operate systems where restart behavior is expensive, state is warm, caches matter, or the workload is tied to GPU allocation and data locality.

Then it sounds like basic hygiene.

The interesting future piece is Vertical Pod Autoscaler integration. Once VPA can recommend and actuate pod-level changes more naturally, the platform starts getting closer to how people actually describe capacity needs:

“This workload needs more room.”

Not:

“Please individually adjust seven containers, three of which exist because our observability stack had opinions.”

this is also a cost conversation

Resource units are never just technical units. They become accounting units.

That is why this feature feels bigger than it looks.

If your cost model is container-centric but your ownership model is pod-centric, reporting gets weird. If your autoscaling is container-centric but your performance objective is pod-centric, tuning gets weird. If your platform charges teams for usage, and every sidecar is part of a shared platform decision, the fairness conversation gets weird.

Who pays for the service mesh sidecar?

The application team because it is in their pod?

The platform team because they required it?

The security team because mutual TLS was mandatory?

This sounds like finance trivia until cloud bills arrive with enough zeros to make everyone suddenly philosophical.

Pod-level resources will not solve chargeback by themselves. But they do point toward a better abstraction: budget the workload as the thing a team actually owns, then make internal container-level details visible without pretending they are the main economic contract.

That is healthier.

the container is not dead; it just got demoted

I know the internet likes clean replacement stories.

VMs are dead. Containers are dead. Kubernetes is dead. Serverless is dead. Everything is dead except whatever vendor keynote starts in five minutes.

Reality is more boring and more interesting.

Containers are not dead. They are still the packaging and runtime primitive that made modern platform engineering possible.

But the industry is learning, again, that packaging units, security units, scheduling units, ownership units, and billing units do not have to be identical.

In fact, when they are forced to be identical, systems get awkward.

The pod was always Kubernetes’ way of saying “these containers belong together.” What is changing is that more of Kubernetes resource management is catching up with that original idea.

The pod is not just a deployment convenience. It is becoming the place where the platform expresses workload economics.

platform teams should pay attention now

Because this is alpha and beta territory, I would not rush to rebuild production assumptions around it tomorrow morning.

But I would absolutely start paying attention.

The direction is clear:

pods are getting stronger as resource boundaries
sidecar-heavy workloads need less wasteful accounting
in-place resizing is becoming a more serious operational tool
performance-sensitive workloads need pod-aware locality and isolation
AI infrastructure will make these problems more common, not less

If you run a platform, this is the kind of Kubernetes evolution that matters more than a flashy new abstraction. It is not glamorous. It is the scheduler, kubelet, cgroups, QoS, and topology slowly becoming less naive about how production workloads are shaped.

That is usually where the real platform shifts happen.

Not in the keynote.

In the accounting model.

And right now Kubernetes seems to be moving the accounting model one level up.

That is a small API change with a very large smell of inevitability.

Hyped and Overhyped Programming Languages in 2026

Paulo Victor Leite Lima Gomes — Mon, 04 May 2026 14:05:42 +0000

Every few years the industry rediscovers that programming languages are not religions.

Then we immediately behave like they are religions.

Someone posts a benchmark. Someone else says memory safety. Someone says developer experience. A distributed systems person appears from under a bridge and whispers “Erlang solved this in 1998.” A startup founder announces they are rewriting their CRUD app in Rust because “performance.” A senior engineer quietly opens another Java service and gets paid.

So let’s talk honestly about programming language hype in 2026.

Not “which language should I learn?”

That question is usually a proxy for anxiety, not engineering strategy.

The better question is:

which languages are getting real adoption for new work, which ones are quietly useful, and which ones are mostly powered by conference talks, nostalgia, or logo slides?

My bias up front: a language being used by a big company does not mean the language is growing. It often just means the company has old systems, large teams, and enough money to keep an ecosystem alive inside its own walls.

That distinction matters.

Scala at LinkedIn, Ruby at Shopify, PHP at Meta history, Erlang at Ericsson, COBOL at banks — all real. Also not the same signal.

A big logo means “someone important has code in this language.”

It does not mean “you should start a new project in it in 2026.”

the signals that actually matter

When I look at a language, I care about four signals:

Hiring volume: are companies hiring for it outside of a few specialist niches?
New project energy: are people choosing it for greenfield work?
Ecosystem growth: libraries, tooling, docs, package quality, deployment paths.
Operational fit: does it make production easier, or just make the code look impressive during review?

Logo collection is much lower on the list.

This is where a lot of language debates go wrong. Engineers love saying “Company X uses language Y.” Sure. Company X also has internal frameworks, staff engineers, migration budgets, old decisions, and a Slack channel called #why-is-this-still-running.

You are not Company X.

the 2026 scoreboard

Here is the rough landscape I would use when talking to an engineering team in 2026. The status is intentionally opinionated, not a scientific taxonomy.

Technology	2026 status	What it is used for	Notable companies / ecosystems	My read
Python	📈 Dominant	AI, data, backend, automation	Google, Meta, OpenAI	The default language of AI-era glue. Not elegant everywhere, but unavoidable.
TypeScript	📈 Dominant	Web apps, full-stack apps, tooling	Microsoft, Slack, Airbnb	The web won. TypeScript is JavaScript after it went to therapy.
JavaScript	🧊 Ubiquitous	Web, scripting, edge runtimes	Everyone, unfortunately and fortunately	Still everywhere, but serious teams increasingly want TypeScript.
Java	🧊 Strong	Enterprise backend, Android legacy, data systems	Amazon, Uber, Netflix	Boring, employable, fast enough, operationally understood. Never bet against boring.
C#	🧊 Strong	Enterprise, gaming, backend	Microsoft, Unity ecosystem	Quietly excellent if you live in the Microsoft universe.
Go	📈 Strong	Cloud backend, infra, CLIs	Google, Uber, Dropbox	Still one of the best choices when you want boring concurrency and cheap operations.
Rust	📈 Rising	Systems, infra, security-sensitive services	Microsoft, Cloudflare, Amazon	Real adoption, real value, also real overuse in places that wanted Go.
Kotlin	📈 Strong	Android, backend	Google, Pinterest, Square	Excellent language, but its hype is tied to Android and JVM shops.
Swift	🧊 Strong niche	Apple apps, some server-side experiments	Apple ecosystem	Great if your world is Apple. Less relevant outside it.
C++	🧊 Strong	Performance systems, games, infra	Google, Meta, Adobe	Still critical. Still dangerous. Still paying mortgages.
C	🧊 Strong	OS, embedded, runtimes	Linux Foundation, Intel, AMD	The floorboards of computing. You do not hype floorboards; you depend on them.
Zig	📈 Emerging	Systems, tooling, C replacement experiments	Bun ecosystem, systems hackers	Interesting and pragmatic. Early, but not vapor.
Mojo	🔥 Hyped early	AI kernels, Python-adjacent performance	Modular ecosystem	Promising, but adoption signal is still tiny compared with the noise.
Gleam	🌱 Emerging niche	Typed BEAM services	BEAM community	Small but genuinely tasteful. I like it more than the market currently does.
Elixir	🧊 Niche	Distributed systems, realtime apps	Discord, PepsiCo, Bleacher Report	Small, serious, productive. Not mainstream, and that is fine.
Erlang	🧊 Niche	Telecom, messaging, fault-tolerant systems	Ericsson, WhatsApp, Klarna	Less fashionable than Elixir, still ridiculously good at what it was built for.
Clojure	🧊 Niche	Backend, data pipelines	Walmart, Nubank, CircleCI	A small language used by people who tend to know exactly why they chose it.
Haskell	🧊 Niche	Finance, compilers, verification-heavy systems	Standard Chartered, Meta, IOHK	Brilliant, intimidating, not a general hiring strategy.
Scala	📉 Declining hype	Data platforms, JVM services	LinkedIn, Twitter legacy, Airbnb	Important historically. Hard sell for greenfield backend work now.
Ruby	📉 Declining hype	Web apps, Rails products	Shopify, GitHub, Basecamp	Still productive. Less fashionable. Rails is mature, not dead.
PHP	📉 Declining hype	Web, CMS, Laravel, WordPress	Wikipedia, WordPress, Meta historically	The internet’s old plumbing. Mock it carefully; it is probably serving your page.
Dart	📉 Mixed	Flutter apps	Google, Alibaba, BMW	Flutter keeps it alive. Outside Flutter, the air gets thin fast.
R	🧊 Niche	Statistics, research, pharma	Pfizer, Novartis, Roche	Still strong where statisticians, not backend engineers, run the room.
MATLAB	🧊 Niche	Engineering, simulation	NASA, Siemens, Boeing	Expensive, domain-specific, deeply entrenched.
Groovy	📉 Declining	Build scripts, Gradle history	Gradle, Atlassian, Netflix historically	Mostly not where new language energy is going.
Perl	🪦 Legacy	Legacy infra, text processing	Booking.com legacy, IMDb, cPanel	The duct tape is still there. Please do not add more tape.
COBOL	🪦 Critical legacy	Banking, insurance, mainframes	JPMorgan Chase, Bank of America, IBM clients	Not hype. More like archaeological load-bearing concrete.

The shape is clear: Python and TypeScript are the center of gravity, Java remains the enterprise cockroach in the best possible way, Go is still extremely sensible, and Rust is the most legitimate “new serious systems language” story of the last decade.

Everything else needs context.

Python is not hyped; Python is infrastructure now

Python’s current dominance is not just beginner tutorials and data science notebooks anymore.

The AI wave made Python even more central because the entire machine learning ecosystem already lived there: PyTorch, TensorFlow, Hugging Face, notebooks, evaluation scripts, data pipelines, glue code, SDKs, model serving wrappers, and a million tiny tools with names like convert_final_final_v2.py.

Stack Overflow’s 2025 survey showed Python jumping significantly, with 57.9% of all respondents reporting extensive use. GitHub’s Octoverse 2025 headline was even louder: AI helped push TypeScript to number one, but Python remained one of the core languages of the AI/open-source wave.

Python is overused in some production systems, yes.

But it is not fake hype.

It is the language people reach for when they want to connect things, test ideas, automate workflows, call models, parse weird files, and make the machine do something before lunch.

That has enormous value.

My criticism of Python is not adoption. It is operational laziness. Python makes prototypes cheap, then teams pretend the prototype is a platform. That is how you end up with a critical revenue job running from a notebook nobody owns.

Python is dominant. Python is useful. Python also needs adult supervision.

TypeScript is the safest hype bet in 2026

TypeScript is barely “hype” now. It is the default serious language of the web.

The interesting thing is that GitHub Octoverse 2025 said TypeScript reached number one on GitHub, driven by AI, agents, and typed languages. That tracks with what I see in practice: when agents generate code, types become more valuable, not less.

A type system is not magic, but it is friction against nonsense.

In a world where humans and LLMs are both producing code, friction against nonsense is underrated.

TypeScript won because it gave JavaScript teams a migration path instead of a purity lecture. That is why it beat most “better language for the web” dreams. It did not ask the industry to move house. It renovated the messy house everyone already lived in.

Would I start a web product in plain JavaScript in 2026?

No.

Not because JavaScript is dead. Because TypeScript is the cheapest safety upgrade you can buy.

Go is underrated because it is boring on purpose

Go is one of those languages that makes programming language enthusiasts slightly sad and production engineers quietly productive.

It is not expressive in the way Scala people want.
It is not clever in the way Haskell people want.
It is not as safe as Rust.
It is not as batteries-included as Java.

And yet Go keeps winning in cloud infrastructure because it has the correct personality for a lot of backend work: simple binaries, fast builds, good concurrency, decent performance, easy deployment, easy hiring, low ceremony.

That is not sexy. That is useful.

A lot of engineering organizations do not need a language that lets the smartest person on the team feel brilliant. They need a language where the tired on-call engineer at 2 a.m. can understand the service quickly.

Go is very good at that.

Rust is both genuinely important and definitely over-prescribed

Rust has earned its hype.

Memory safety without a garbage collector is a big deal. The security story is real. The tooling is good. The community has produced serious infrastructure. Microsoft, Amazon, Cloudflare, and others are not playing with it for vibes.

Rust belongs in systems programming, performance-sensitive infrastructure, security-sensitive components, runtimes, networking, CLI tools, embedded work, and places where C or C++ bugs become expensive.

But.

There is always a but.

Rust is also being recommended for things that do not need Rust.

If your team wants to build a normal JSON-over-HTTP internal service and nobody on the team is already fluent in Rust, choosing Rust because “performance” can be architectural cosplay.

You are not building a browser engine. You are returning invoices.

Rust is a serious language. It is also a language where the learning curve is part of the cost model. If the cost is worth it, great. If not, Go, Java, Kotlin, C#, or TypeScript probably get you to production faster with fewer emotional support threads in Slack.

Java is the language everyone keeps predicting will die while it keeps getting paid

Java is not fashionable. Java does not need to be fashionable.

Java has hiring volume, libraries, observability, deployment patterns, mature frameworks, JVM performance, and decades of production scar tissue encoded in boring defaults.

That matters.

The RedMonk January 2026 ranking still had Java in the top three. Stack Overflow 2025 had Java around 29% among all respondents and nearly the same among professional developers. TIOBE still places Java near the top. You can argue with the methodology of each index — and you should — but when every imperfect index says “this thing is still very large,” believe the direction.

Would I choose Java for every new backend? No.

Would I be worried joining a serious company with a large Java estate? Also no.

Java is not hype. Java is employment.

Scala and Ruby are the warning labels for logo-based thinking

Scala and Ruby are the perfect examples of why “big companies use it” is not enough.

Scala had a very real moment. It gave JVM teams functional programming, expressive types, and a path into big data tooling. Spark mattered. Twitter mattered. LinkedIn mattered.

But the ecosystem became heavy. The learning curve was real. Build times hurt. The community split between “powerful language” and “why is this implicit doing crimes?” And many teams that wanted pragmatic backend work eventually chose Java, Kotlin, Go, or TypeScript instead.

Scala is not dead. But its hype declined.

Ruby is different. Ruby on Rails changed web development. Shopify, GitHub, and Basecamp are not fake examples. Rails remains productive and mature.

But Ruby no longer feels like where the center of new backend energy is moving. It is a great way to build certain products if the team already likes Rails. It is not the obvious default in 2026 for a company trying to maximize hiring pool, cloud-native tooling, AI integration, and long-term ecosystem growth.

This is the pattern:

large installed base ≠ expanding frontier.

You can make money in declining-hype ecosystems. Sometimes a lot of money. But do not confuse maintenance gravity with adoption energy.

PHP is funny until you remember the web runs on it

PHP is easy to mock because PHP spent years earning the jokes.

And yet, PHP is still everywhere.

WordPress alone makes PHP impossible to ignore. Laravel keeps modern PHP much more pleasant than outsiders assume. Wikipedia exists. Huge amounts of commerce, content, and internal tooling still run on PHP.

But would I start a greenfield backend platform in PHP in 2026?

Probably not, unless the team had a strong PHP/Laravel advantage or the product lived naturally in that ecosystem.

PHP is not dead. It is just not where I would go looking for broad new-language momentum.

Clojure, Elixir, Erlang, and Haskell are small for grown-up reasons

Niche does not mean unserious.

This is where beginner language discourse becomes useless.

Clojure, Elixir, Erlang, and Haskell are not mainstream hiring monsters. Stack Overflow’s 2025 numbers put Elixir and Scala around the low single digits, Erlang lower, and Haskell small enough that most recruiters will never accidentally find you.

But these languages are often chosen by experienced teams for specific reasons.

Clojure is excellent when you want a small language, immutable data, REPL-driven development, and a very different mental model from mainstream object-oriented backend work. Nubank using Clojure is not random. It is a company-level bet on leverage and simplicity at scale.

Elixir and Erlang live on the BEAM, which remains one of the best runtime stories for fault tolerance, concurrency, and long-running distributed systems. Discord’s Elixir usage is a real signal, not a toy case study.

Haskell is not “hard because academics.” Haskell is hard because it forces you to be explicit about things many codebases prefer to leave as runtime surprises. In finance, compilers, and correctness-heavy systems, that can be worth it.

Would I recommend these languages to a random startup as default choices?

No.

Would I dismiss them because they are niche?

Also no.

Some niches are where the adults are.

Zig, Mojo, and Gleam: interesting, but bring a microscope

New entrants are where hype is most dangerous.

Zig is the most interesting of the current systems-language challengers. It is pragmatic, C-interoperable, simpler than Rust in important ways, and already visible in real tooling conversations. RedMonk noted Zig’s deliberate climb in its 2026 ranking, with stronger GitHub signal than Stack Overflow signal. That is exactly the kind of mismatch worth watching.

Mojo is the spicy one because it attaches itself to the AI/Python performance story. The pitch is strong: Python-like ergonomics with systems-level performance potential for AI workloads. But Stack Overflow 2025 still showed Mojo at only 0.4% among all respondents and 0.3% among professional developers. That is not “ignore it.” That is “do not bet your hiring plan on it yet.”

Gleam is tiny but tasteful: typed, friendly, BEAM-based, and refreshingly pragmatic. I would not call it mainstream. I would call it one of the few small languages where the design taste seems better than the hype machine.

My rule for emerging languages: experiment freely, adopt carefully.

A side project can be brave. Payroll systems should be boring.

the languages I think are overhyped in 2026

Here is the spicy part.

Rust, when used as a personality test

Rust is excellent. Rust as a default answer to every backend problem is not excellent.

If your problem is memory safety, performance, secure infrastructure, or replacing C/C++, Rust deserves serious consideration.

If your problem is “we need a CRUD API by next quarter,” maybe stop trying to impress Hacker News.

Mojo, relative to adoption

Mojo might become important. I hope it does, because AI infrastructure needs better performance ergonomics.

But right now the ratio of promise to production adoption is very high. That is literally what hype is.

Anything marketed as “the language for AI agents”

No.

Agents mostly need boring integration surfaces: HTTP, files, queues, logs, auth, sandboxing, tests, traceability. They do not need a magical new syntax for vibes.

If a language claims it is special because agents will write it better, I want receipts.

the languages I think are underrated

Go

Because boring operational wins compound.

Elixir

Because most web engineers underestimate how good the BEAM is for realtime and distributed systems.

Clojure

Because small teams with high leverage can do ridiculous things with it, if they can hire and maintain the discipline.

Java

Yes, Java. I know.

But the modern JVM ecosystem is far better than the 2008 trauma many engineers still carry around. If your opinion of Java is based on old enterprise XML nightmares, update the dependency in your head.

Gleam

Not because it is big. Because it is small in an interesting direction.

the languages I would be very careful starting new projects with

This does not mean “bad.” It means “the burden of proof is high.”

Scala

I would only choose Scala today if the team already had strong Scala expertise and a specific reason. Otherwise Kotlin, Java, Go, or TypeScript will usually create less organizational friction.

Ruby

Rails is still productive, but I would want a team and product reason, not nostalgia.

PHP

Laravel can be good. WordPress is massive. But for a general-purpose new backend platform, I would need a strong ecosystem-specific argument.

Perl

No.

I respect Perl historically. I also respect asbestos historically as a material with useful properties. That does not mean I want more of it in the building.

COBOL

Learn COBOL if you want a specific legacy/mainframe career niche. Do not pick it for a new product unless your product is a museum with uptime requirements.

my practical advice

If I were advising a team in 2026, my default recommendations would be boring:

Web product: TypeScript.
AI/data/glue work: Python, with production discipline.
Cloud backend / infrastructure service: Go, Java, Kotlin, or C# depending on team context.
Performance/security-sensitive systems: Rust, C++, C, or Zig experiments depending on maturity and risk.
Realtime distributed systems: Elixir/Erlang if the team can support it.
High-leverage small expert team: Clojure is still worth considering.
Statistical research: R is fine. Stop forcing statisticians to cosplay backend engineers.

The language is not the architecture. But it shapes hiring, libraries, failure modes, deployment, debugging, and how much cleverness your team can afford before production starts charging interest.

That is the part hype usually hides.

A programming language is not just syntax.

It is a labor market, a package ecosystem, a runtime, a set of defaults, a debugging culture, a deployment story, and a thousand small decisions already made for you.

Choose the language where those defaults match the system you are actually building.

Not the language with the best conference talk.
Not the language with the biggest logo slide.
Not the language that makes your team feel briefly smarter.

The right language is usually the one that lets you ship, hire, operate, and sleep.

Everything else is merchandise.

references

Why today's AI skepticism mirrors yesterday's distrust of statistics

Paulo Victor Leite Lima Gomes — Sun, 03 May 2026 09:00:57 +0000

AI. It's the buzzword on everyone's lips, the technology promising to revolutionize… well, everything. And, predictably, it's met with a healthy dose of skepticism, if not outright disdain. "It's unreliable," some say. "It hallucinates," others lament. "It's a crutch for those who don't understand the real work."

Sound familiar? It should. Because this isn't the first time humanity has grappled with a transformative tool that dared to challenge our most deeply held assumptions. We’ve seen this movie before, starring none other than… statistics.

When Numbers Were Suspect: A Brief History of Skepticism

Imagine a time when saying "the data shows" was met with suspicion, not respect. That was the early 20th century for statistics. It wasn't just a niche concern; it was mainstream. Eminent figures like Ernest Rutherford, the father of nuclear physics, famously declared, "If your experiment needs statistics, you ought to have done a better experiment." Ouch.

And who could forget Mark Twain's biting quip, popularized but not originated by him: "There are three kinds of lies: lies, damned lies, and statistics." This wasn't a fringe sentiment; it reflected a widespread belief that statistics were, at best, a dubious simplification of complex realities, and at worst, a tool for deception. It was seen as reductive, dangerous to "real" science, and certainly not something a serious intellectual would rely on.

The shift in perception didn't happen because people suddenly changed their minds about the inherent trustworthiness of numbers. It happened because the results became undeniable.

The Pioneers Who Made Statistics Indispensable

The real power of statistics was demonstrated not by eloquent arguments, but by people who wielded it to solve real-world problems, saving lives and shaping policy along the way.

Florence Nightingale wasn't just a nurse; she was a data visionary. During the Crimean War, she used statistical graphics – her famous "rose diagrams" – to demonstrate that more soldiers died from preventable diseases in unsanitary hospitals than from battle wounds. Her data wasn't just interesting; it was a damning indictment of the military's medical practices, leading to fundamental reforms that saved countless lives. She didn't just care for the sick; she proved why they were sick using numbers.

Then came Ronald A. Fisher, the undisputed architect of modern mathematical statistics. Fisher developed the bedrock concepts we now take for granted: hypothesis testing, p-values, and the rigorous principles of experimental design. Without his foundational work, modern medicine, agriculture, and countless scientific disciplines would lack a credible methodology. His "Statistical Methods for Research Workers," published in 1925, laid the groundwork for evidence-based everything.

And to bring it home with a critical public health example, consider Richard Doll and Austin Bradford Hill. In the 1950s, their groundbreaking statistical studies definitively proved the link between smoking and lung cancer. While anecdotal evidence had hinted at it, statistics provided the irrefutable proof: over 90% of lung cancer patients were smokers. This was a truth that individual intuition and observation struggled to grasp, but statistics, with its macroscopic view, made plain.

The AI Mirror: Same Tune, Different Instrument

Fast forward to today, and the chorus of AI skepticism sings a remarkably similar song:

"It's unreliable." Funny, statistics was pretty unreliable too when misused, misinterpreted, or applied without understanding its underlying assumptions. Garbage in, garbage out, and all that.
"It makes mistakes / It hallucinates." Every tool, especially in its early, immature stages, makes mistakes. Recall the early days of personal computers, or even the first versions of your favorite programming language. Perfection isn't born; it's engineered, iterated upon, and refined.
"It can be manipulated to say anything." This is a classic statistical critique! You can torture data until it confesses to anything, as the saying goes. Yet, we didn't ban statistics; we developed ethical guidelines, best practices, and statistical literacy to combat misuse.
"It's a crutch for people who don't understand the real work." Hello, Rutherford! This echoes the sentiment that AI replaces understanding rather than augmenting it. The fear is that AI-generated code, text, or insights will become a substitute for genuine expertise.

The real issue, then and now, isn't fundamentally about the tool itself. It's about what the tool forces us to confront:

Statistics forced people to accept that their intuition, however strong, is often wrong when faced with large-scale data.
AI is forcing people to accept that cognition itself, the very act of thinking, creating, and problem-solving, can be partially automated and augmented.

Both challenge the same deeply held assumption: that human judgment, intuition, and intellectual effort are somehow uniquely irreplaceable in all contexts.

The Unseen Cost of Dismissal

Imagine dismissing statistics in 1900. You'd miss the entirety of modern medicine, epidemiology, the development of evidence-based policy, and the scientific rigor that defines our world today. You'd miss the discovery of countless disease vectors, the efficacy of vaccines, and the understanding of public health on a societal scale. That's not just a missed opportunity; it's a catastrophic failure of foresight.

So, what does wholesale dismissal of AI in 2026 cost us? We might miss breakthroughs in drug discovery, personalized medicine, climate modeling, material science, and even entirely new forms of creativity and problem-solving. We risk being the generation that clung to old paradigms while the world accelerated past us, powered by tools we refused to engage with.

Being a critical engineer means understanding limitations, scrutinizing outputs, and building robust systems. It does not mean burying our heads in the sand, rejecting powerful instruments out of hand, or repeating the historical mistakes of those who couldn't see past their skepticism. Let's learn from history, shall we?

References:

Nightingale, F. (1858). Notes on Matters Affecting the Health of the British Army.
Fisher, R. A. (1925). Statistical Methods for Research Workers. Oliver and Boyd.
Doll, R., & Hill, A. B. (1950). Smoking and Carcinoma of the Lung. British Medical Journal, 2(4682), 739–748.
Gigerenzer, G., Swijtink, Z., Porter, T., Daston, L., Beatty, J., & Krüger, L. (1989). The Empire of Chance: How Probability Changed Science and Everyday Life. Cambridge University Press.
Porter, T. M. (1986). The Rise of Statistical Thinking, 1820–1900. Princeton University Press.

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, lets buy macminis and put everything on hermes and openclaw, doesn't mater if they will take all our token and somehow this all stays in the “software subscription” bucket.

Software engineers like me didn't buy it some years ago already, but now, it started hitting the non-technical people as well. Some of them? Investors...

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.

A human when makes a mistake, learns from it and tries to make it right next time. An LLM? Might a sorry will happen. in other words, someone "triggered it to do in this way", its not AI mistake in fact. Its just a tool, a powerful and revolutionary one, but still a tool.

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!!! I get it.

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, of course, I would not stop using AI, this is madness loosing good optimization

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.