The Current State of Software: From Builders to Burnt-Out AI Evangelists

Han — Wed, 12 Nov 2025 19:40:45 +0000

We live in exciting times. Artificial Intelligence has made programming more accessible than ever before. What once required deep focus and late-night debugging sessions can now be generated with a few prompts and some optimism. It’s revolutionary — and somehow, also, a little depressing.

Those of us who started coding because we loved building things are starting to feel tired. Not the “I need a vacation” kind of tired. The existential kind.
A while ago, I read that many experienced developers — especially those working in agencies, consultancies, and digital factories — are living in a state of permanent burnout. It’s not surprising. We stopped being builders and became feature delivery units.

Instead of creating, we deliver. Instead of exploring, we execute. Every decision must fit neatly into a Jira ticket, wrapped in “agile” terminology that somehow manages to remove all agility from the process. We measure velocity, not value. We chase deadlines, not delight.

The Rise of the Architecture Astronauts (and Their AI Descendants)

A long time ago, I read Joel Spolsky’s classic piece: Don’t Let Architecture Astronauts Scare You.
He described a certain kind of engineer who’s so disconnected from actual implementation that they float into orbit — talking about abstract architectures, grand strategies, and futuristic patterns no one can actually ship.

We’ve all met one. Maybe we’ve even been one, briefly. It happens.
But lately, I think we need a new term — because the AI era has birthed a new archetype.

The AI Astronaut.
This is the person who believes that large language models are the ultimate truth, that prompting is the new programming, and that soon all human creativity will be automated away (preferably by a tool they just demoed at the last all-hands).

They don’t write code — they declare intentions. They don’t understand systems — they orchestrate miracles. And if you dare to ask how something actually works, they’ll send you a link to an article.

Sometimes, they’ll even say things like “we’ll have this feature shipped with AI in a couple of weeks” — without realizing that real systems have dependencies, side effects, and constraints that no prompt can handwave away.
And that’s where the danger lies — not in the tools themselves, but in the illusion that complexity can be wished away.

The Craft Is Still Worth Defending

Don’t get me wrong: AI is incredible. It amplifies what we can do, accelerates our workflows, and makes the entry barrier to programming almost nonexistent. That’s progress.
But it’s also creating a generation of developers who no longer want to understand how things work — just how to get things done.

And maybe that’s fine. Maybe software is supposed to become more like plumbing — efficient, invisible, reliable. But for some of us, the joy was never in shipping the feature. It was in understanding why the feature worked.

So yes, celebrate the AI revolution. Use the tools. Automate the boring stuff.
But keep your feet on the ground. Don’t float away with the AI Astronauts.
We already have enough of those in orbit.

Because underneath all the frameworks, prompts, and plugins, there’s still a craft worth protecting — the quiet satisfaction of understanding a system deeply enough to make it dance. AI can assist, but it can’t care. That part is still up to us.

Render and Response: The Case for Pure React Server Components

Han — Thu, 06 Nov 2025 23:21:19 +0000

You can call cookies() in a React Server Component today.
But if you try to set a cookie, nothing happens.

This behavior is intentional.

React Server Components (RSC) do not participate in the HTTP response lifecycle. They execute during rendering — a phase that can be repeated, restarted, speculated, aborted, cached, or occur without a corresponding client request. This is a fundamental constraint of the RSC model, not a missing feature.

Rendering produces descriptions of UI.
Responses produce effects on the outside world.

These concerns are separated for correctness.

Renders May Replay

A render is not guaranteed to correspond to a user event or to a single network response. Frameworks are free to:

Replay renders after suspending
Retry renders after errors
Run renders for background revalidation
Perform partial renders during streaming
Cancel renders before they reach the client
Execute renders in different environments (edge, regional worker, etc.)

From the perspective of React, a render is a pure computation.
From the perspective of HTTP, the response is a side-effect.

If a render were allowed to mutate the response, any of the behaviors above could trigger multiple or mis-timed effects. The result would be non-deterministic.

We would no longer be able to rely on:

Caching
Correct concurrency
Streaming behavior
Stable error recovery

In short: purity enables the RSC model.

Snapshots, Not Mutations

cookies() and headers() exist in RSCs only as read-only snapshots of the incoming request. They are asynchronous because the framework may suspend to produce a consistent view during streaming.

Example:

import { cookies, headers } from 'next/headers';

export default async function Page() {
  const c = await cookies();
  const h = await headers();

  const theme = c.get('theme')?.value ?? 'light';
  const ua = h.get('user-agent') ?? 'n/a';

  return <main data-theme={theme}>{ua}</main>;
}

These reads are pure. They do not cause effects.
They do not depend on timing.
They can be replayed safely.

Writes cannot satisfy these properties, so they are prohibited.

Purity as a Design Requirement

The idempotence requirement can be stated simply:

“The result of rendering must not depend on whether rendering has been performed once or many times.”

More formally:

Let R be a render function producing output U from state S.
The function R must satisfy:

R(S) = U
R(R(S)) = U

If a render performs side effects — writing to a database, emitting network logs, modifying headers or cookies — this property is violated. Any concurrency model depending on retries or cancellation would break.

Purity is not a recommendation.
It is the only model that keeps the semantics sound.

Where Effects Belong

When mutations do need to occur, they must be tied to a specific HTTP response or a user-triggered transition, where exactly-once semantics are controlled.

Two places provide those guarantees:

Route Handlers
Full response construction: status, headers, cookies.

Server Actions
User-driven mutations; the framework binds effects to the resulting response.

Everything else — including Server Components — must remain pure.

The Model in One Sentence

Rendering is a computation.
Response is an effect.
Only one of them can safely replay.

Conclusion

React Server Components expand what is possible for server-driven UI.
But they do so by imposing a strict invariant:

“Rendering must be pure.”

If you need to modify the outside world, do not do it in an RSC.
Render the UI.
Perform effects in handlers or actions.
Let the system retry safely.

You can think more than once.
You can only act once.

Forem: Han