DEV Community: Edgar Nahama Alochi

NASA's Rule of 10: The rules of programing that put flying metal in orbit

Edgar Nahama Alochi — Sun, 26 Jul 2026 14:00:28 +0000

The NASA Ten Rules of Programming

My interpretation of these rules with Golang examples.

NASA did not write these rules to win arguments on the internet.
They wrote them because software failed in ways that were expensive frightening and sometimes irreversible.

The rules are short. Almost annoyingly so.
That is intentional.

Each rule is a reminder that complexity is not free and that computers are fast but humans are fragile.

They helped put flying metals in orbit and manage Voyager 1, the most distant human made object.

Let’s walk through all ten using Go not because Go is perfect but because it makes these ideas painfully obvious.

Rule 1

Restrict all code to very simple control flow

If your logic requires a mental stack trace to understand it will fail at the worst possible moment.

Go helps here by being boring on purpose.

Bad

func process(x int) int {
    if x > 0 {
        for x < 100 {
            if x%2 == 0 {
                if x%3 == 0 {
                    x += 7
                } else {
                    x += 3
                }
            } else {
                break
            }
        }
    }
    return x
}

Good

func process(x int) int {
    if x <= 0 {
        return x
    }

    for x < 100 {
        if x%2 != 0 {
            return x
        }
        x = nextValue(x)
    }

    return x
}

func nextValue(x int) int {
    if x%3 == 0 {
        return x + 7
    }
    return x + 3
}

Simple flow is not about fewer lines.
It is about fewer thoughts.

Rule 2

Give all loops a fixed upper bound

Unbounded loops are promises you cannot keep.

They say trust me this will eventually stop.
NASA does not trust that. Neither should you.

Bad

for {
    data := read()
    if data == nil {
        break
    }
    process(data)
}

Better

for i := 0; i < maxReads; i++ {
    data := read()
    if data == nil {
        return
    }
    process(data)
}

Even when reading streams you can still impose limits.
Timeouts retries counters budgets.

Infinite loops belong in theory not production.

Rule 3

Avoid heap memory allocation after initialization

This rule scares people because it sounds extreme.

What it really says is do not allocate memory unpredictably while running critical logic.

In Go you do not control the heap but you can control when and how you allocate.

Bad

func handle(req Request) {
    buf := make([]byte, req.Size)
    process(buf)
}

Better

type Handler struct {
    buf []byte
}

func NewHandler(maxSize int) *Handler {
    return &Handler{
        buf: make([]byte, maxSize),
    }
}

func (h *Handler) Handle(req Request) {
    process(h.buf[:req.Size])
}

This is not about micro optimization.
It is about predictability.

The garbage collector is helpful.
It is not magic.

Rule 4

Restrict functions to a single purpose

If a function does more than one thing it lies about its name.

Bad

func SaveUser(u User) error {
    validate(u)
    db.Save(u)
    log.Printf("saved user %s", u.ID)
    sendEmail(u)
    return nil
}

Better

func SaveUser(u User) error {
    if err := validate(u); err != nil {
        return err
    }
    return db.Save(u)
}

Side effects should be explicit and separate.

Small functions fail smaller.

Rule 5

Use a minimum of two runtime assertions per function

This rule is about defending assumptions.

In Go assertions usually look like early checks.

Bad

func divide(a b int) int {
    return a / b
}

Better

func divide(a b int) (int error) {
    if b == 0 {
        return 0 errors.New("division by zero")
    }
    return a / b nil
}

Assertions are kindness to future readers.
Especially future you at 2am.

Rule 6

Declare data objects at the smallest possible scope

The longer a variable lives the more places it can hurt you.

Bad

var result int

func compute(a b int) int {
    result = a + b
    return result
}

Better

func compute(a b int) int {
    result := a + b
    return result
}

Short lifetimes mean fewer ghosts in the system.

Rule 7

Check the return value of all non void functions

This is the rule Go takes personally.

Ignoring errors is lying to yourself.

Bad

file _ := os.Open("data.txt")

Better

file err := os.Open("data.txt")
if err != nil {
    return err
}

Errors are information.
Discarding them does not make them go away.

Rule 8

Limit pointer use

Pointers increase the number of possible states your program can be in.

Go uses pointers but discourages pointer gymnastics.

Bad

func update(u *User) {
    u.Name = strings.ToUpper(u.Name)
}

Better

func update(u User) User {
    u.Name = strings.ToUpper(u.Name)
    return u
}

Use pointers when you must not because you can.

Rule 9

Compile with all warnings enabled and treat them as errors

Go does not have warnings.
It simply refuses to compile nonsense.

Unused variables unused imports unreachable code.
All dead on arrival.

That is a feature not a limitation.

If your language allows warnings treat them like failures.
Your future stability depends on it.

Rule 10

Use static analysis tools

Humans miss patterns.
Machines do not get tired.

In Go this means tools like

go vet
staticcheck
race detector

Example

go test -race ./...

These tools are not optional extras.
They are part of the engineering system.

NASA trusted them with spacecraft.
You can trust them with your backend.

The quiet lesson behind the rules

The NASA rules are not about cleverness.
They are about humility.

They assume that you will forget.
That you will misread.
That you will be interrupted.

They are written for humans under pressure.

Go as a language aligns with this philosophy almost accidentally.
Simple syntax explicit errors limited abstraction boring defaults.

The rules remind us that reliability is not achieved by brilliance.
It is achieved by restraint.

And restraint scales better than genius ever will.

A Small, Annoying Reminder About MySQL, Next.js, and Reality

Edgar Nahama Alochi — Sat, 25 Jul 2026 20:01:24 +0000

Today's reminder that MySQL will happily let you believe you're doing everything "right" right up until it doesn't.

I was wiring up a perfectly ordinary paginated query in a Next.js service. Nothing exotic. Prepared statements, placeholders, clean parameter handling. The kind of code you write on autopilot because you've written it a hundred times before.

And then MySQL reminded me again that it is not PostgreSQL.

The offending query looked harmless:

SELECT *
FROM writings
ORDER BY created_at DESC
LIMIT ? OFFSET ?

The parameters were validated. Integers only. Floored. Bounded. Safe. Sensible.

And still: runtime error.

The cause, as always, is not obvious until you already know it:

MySQL does not support placeholders forLIMIT and OFFSET in prepared statements.

Not partially. Not "sometimes." Just no.

This is one of those behaviors that lives in the uncanny valley between "documented" and "constantly forgotten." Every time I switch contexts PostgreSQL to MySQL, ORM generated queries to raw SQL I relearn this the hard way.

The fix is simple, but mildly infuriating.

Instead of placeholders, you must interpolate the integers directly:

const limitInt = Math.floor(limitNum);
const offsetInt = Math.floor(offset);

const dataQuery = `
  SELECT *
  FROM writings
  ${whereClause}
  ORDER BY created_at DESC
  LIMIT ${limitInt} OFFSET ${offsetInt}
`;

And yes, this is safe because:

limitNum andoffsetare validated
Values are clamped and floored
They cannot contain user controlled strings
Only WHERE clause values remain parameterized

The resulting query is exactly what MySQL expects:

text

SELECT *
FROM writings
ORDER BY created_at DESC
LIMIT 6 OFFSET 0

Instead of the version MySQL silently refuses to support:

SELECT *
FROM writings
ORDER BY created_at DESC
LIMIT ? OFFSET ?

This is not a Next.js problem.
It is not a driver bug.
It is not a configuration issue.

It is simply one of those MySQL constraints that leaks through abstraction layers and reminds you that SQL dialects are not interchangeable, no matter how much tooling tries to pretend they are.

The frustrating part isn't the workaround.
The frustrating part is that this failure happens after you've already done the "right" things:

Prepared statements
Parameterized queries
Defensive validation
Boring, careful code

And yet, you still have to break the pattern carefully, deliberately to satisfy the database.

The takeaway is not "don't use MySQL."
The takeaway is simpler, and more annoying:

Always remember which database you are talking to.

Because the moment you assume uniform behavior across SQL engines, reality will correct you usually in production.

Fixed.
Again.

Understanding Next.js Page Caching (with a real example)

Edgar Nahama Alochi — Wed, 22 Jul 2026 23:12:10 +0000

Caching can be a tricky topic, especially when pages don’t update the way you expect.
I recently ran into an interesting issue while working on the /writing page of my site. Whenever I added or updated articles, the changes did not show immediately. Oddly enough, the individual article pages updated as expected, but the listing page stayed stale.

After some digging, I realized this was not a bug. It was Next.js doing exactly what it is supposed to.

How Next.js caching works

Next.js (App Router) handles HTML caching at the edge in production. For statically prerendered pages, it sets Cache-Control: s-maxage=31536000, which is one year. This header tells CDNs and edge caches that they can serve the page without re-fetching for a long time. Browser cache headers such as no-cache do not override this because s-maxage takes priority for shared caches.

This explains why the listing page showed stale content while individual article pages, which are either dynamic or use revalidation, updated immediately.

How to control caching

Next.js provides a clean way to manage page freshness.

First, set revalidation for a page. In the page file, for example app/writing/page.tsx, add:

export const revalidate = 60; // seconds

The page is served from cache for 60 seconds. After 60 seconds, the next visitor triggers background regeneration. Visitors continue to get a fast response while the page updates.

For instant updates after saving content, use on-demand revalidation:

import { revalidatePath } from 'next/cache';
revalidatePath('/writing');

Call this in your article save logic, whether that is a CMS, API route, or webhook, to invalidate the cached page immediately.

Key lessons from my experience

Edge caching is powerful, but it can make pages seem stale if revalidation is not configured. Browser cache clearing or changing Nginx headers does not affect HTML caching for statically prerendered pages. The correct place to control page freshness is in the Next.js route itself, not the server or CDN alone.

By adding a single line of code to the route, I now get the perfect balance: fast cached pages that still update reliably when I add or edit content.

References

Next.js ISR and Self-hosting

Next.js Caching and Revalidation

Next.js Config and Headers

Making Next.js Behave: Practical Notes on Performance, Architecture, and Not Shooting Yourself

Edgar Nahama Alochi — Wed, 22 Jul 2026 06:33:08 +0000

Next.js is fast by default.
It is also very easy to make slow by accident.

Most performance problems I see in Next apps are not about React being slow or Vercel being expensive. They come from unclear boundaries, duplicated work, and letting “temporary” decisions live forever.

These are notes on how to keep a Next.js codebase fast to build, predictable to run, and pleasant to work in.

Start by making the codebase legible

Before touching performance tools, make the project understandable.

If a new developer cannot tell where hooks live, where API logic lives, or where page copy lives within a few minutes, you will pay for that confusion forever.

A boring structure wins.

Keep one place for hooks.
One place for shared UI components.
One place for content and metadata.
Thin pages that mostly wire things together.

app/
  dashboard/
  solutions/
  foo/
  bar/
components/
hooks/
lib/

This does not make the app faster at runtime. It makes humans faster. That compounds.

DRY is about removing decisions, not saving lines

Duplicated logic forces the reader to make choices.

Which metadata file is correct.
Which SEO description was updated.
Which API client variation should I use.

Centralize anything that changes together.

export function buildMetadata(input: MetadataInput): Metadata {
  return {
    title: input.title,
    description: input.description,
    openGraph: { ... },
    twitter: { ... },
  };
}

When every page uses the same builder, you stop worrying about consistency. You trust the system again.

Trust is performance.

Prefer server components until proven otherwise

Client components are easy. They are also expensive.

Every client component ships JavaScript, runs hydration, and increases build and bundle cost. Use them only when you actually need interactivity.

If a component does not use state, effects, or browser APIs, keep it on the server.

export default async function Page() {
  const data = await getData();
  return <View data={data} />;
}

No use client. No hydration. Less work.

You can always move logic client side later. Moving it back is harder.

Cache aggressively, but intentionally

Next gives you caching for free, but only if you let it.

Use fetch with caching semantics instead of rolling your own.

await fetch(url, { next: { revalidate: 60 } });

Avoid wrapping everything in dynamic just because something broke once. That turns your app into an expensive SPA with extra steps.

If something must be dynamic, isolate it. Do not poison the whole page.

Keep API clients dumb

Your API client should not know about routing, auth state, or UI behavior. It should send requests and return data.

Once we added a server proxy, the client became simpler instead of more complex.

await fetch('/api/backend/payments', {
  credentials: 'include',
});

No tokens.
No headers.
No branching logic.

The server handles auth. The client just asks for data.

This improves security and reduces mental load.

Never store tokens in localStorage

It is convenient.
It is also unsafe.

LocalStorage is readable by any injected script. There is no mitigation once it is compromised.

If you care about security, use httpOnly cookies and move auth to the server.

cookies().set('access_token', token, {
  httpOnly: true,
  secure: true,
});

Yes, it requires more setup. Yes, it is worth it.

Reduce build work by deleting code

Most build optimizations come from removing work, not adding tools.

Things that slow builds quietly:
Duplicated imports
Large client components
Overused dynamic rendering
Unused dependencies
Copy pasted config

Before reaching for caching layers, ask what the compiler is doing repeatedly that it should not be doing at all.

Treat DX issues as real bugs

If a fresh clone does not boot cleanly, that is a bug.
If formatting changes every commit, that is a bug.
If Node versions drift, that is a bug.

Pin your environment.

# .nvmrc
20

Commit generated files that tools expect.
Pick one package manager.
Make the happy path obvious.

The goal is that nothing surprising happens on day one.

Make failures explicit

If the backend is down, fail clearly.
If an image format is unsafe, opt into it intentionally.
If something is deprecated, address it early.

Silent failures turn into folklore. Loud failures turn into fixes.

The real optimization

A fast Next.js app is not one with the most tricks.
It is one that does the least unnecessary work.
For the browser.
For the server.
For the developer.

When the structure is clear, the build gets faster.
When the security model is clean, the code gets simpler.
When the project explains itself, people stop being afraid to change it.

That is when Next.js starts to feel boring again.

And boring is exactly what you want.

Open Source in the Age of AI: When Slop Floods the Swamp

Edgar Nahama Alochi — Tue, 21 Jul 2026 09:21:04 +0000

I like open source for the same reason I like well designed systems.
Clear inputs. Honest outputs. Humans in the loop.

Lately that loop feels clogged.

Over the last few weeks something strange has happened. Pull requests multiplied. Bug reports exploded. Security issues appeared out of thin air. Everything looked serious. Everything looked formatted. Everything looked wrong.

This is not enthusiasm.
This is industrial scale contribution theater.

We taught machines to talk. Some people decided that talking counts as contributing.

The Inbox as a Crime Scene

If you maintain a project today your inbox looks like a crime scene.

There are fingerprints everywhere. None of them match reality.

You open a pull request. It compiles on paper. It fails in practice.
You read a security report. It references functions that do not exist.
You scan the explanation. Confident tone. Wrong universe.

The tragedy is not that the code is bad. Bad code has always existed.
The tragedy is volume.

One thoughtful contribution costs minutes to review.
One careless AI generated contribution costs context. Attention. Energy.

Multiply that by a hundred. By a thousand.

This is not collaboration. This is a denial of service attack on human judgment.

The Slop Factory Model

Here is the new workflow.

Prompt the model
Generate something plausible
Submit it everywhere
Hope something sticks

No understanding required. No ownership. No follow up.

It is the software equivalent of throwing spaghetti at a wall and calling yourself a chef.

The machine does not care.
The submitter often does not either.
The maintainer pays the bill.

Open source was built on learning in public.
This is guessing in bulk.

When Everything Looks Like Work

AI slop is dangerous because it looks like effort.

There are tests. There are comments. There are long explanations written in a polite tone.
There is just one missing ingredient.

Reality.

The model does not know your codebase.
It does not know your constraints.
It does not know why that weird edge case exists.

It only knows how code usually looks.
And that is not enough.

A map of a city is not the city.
Generated code is not understanding.

The Maintainer as the Bottleneck

Here is the uncomfortable truth.

Open source does not scale on code.
It scales on trust.

Maintainers are not compute. They do not autoscale.
They get tired. They burn out. They leave.

When you flood a project with low quality contributions you are not helping.
You are converting goodwill into unpaid labor.

That is why some projects are closing pull requests.
Ending bug bounties.
Banning AI generated submissions outright.

Not because they hate tools.
Because they value their time.

Tools Are Not the Enemy

This is important.

AI is not the villain.
Misaligned incentives are.

Used well AI is a sharp knife.
Used badly it is a confetti cannon pointed at a codebase.

The difference is intent.

Did you read the code
Did you run it
Do you understand the change
Are you willing to maintain it

If the answer is no then the contribution is noise regardless of how it was produced.

What Open Source Actually Needs

Less volume.
More care.

Fewer drive by contributions.
More long term thinking.

AI that helps people understand systems instead of impersonating them.
Contribution guidelines that reward clarity not quantity.
Platforms that protect maintainers instead of optimizing for activity graphs.

Open source survives on meaning not motion.

A Quiet Ending

If we are not careful we will build a future where bots submit to bots and humans quietly walk away.

Not with anger.
With exhaustion.

The fix is not dramatic.
It is boring.
It is human.

Slow down.
Read before you write.
Understand before you submit.

Because open source was never about how much code you can generate.

It was about caring enough to make it right.

The Best Line of Code Is the One You Never Write

Edgar Nahama Alochi — Mon, 20 Jul 2026 22:47:37 +0000

The best line of code is the one you never write.
The second best is the one you delete.

This isn’t laziness. It’s restraint.

Every line of code is a liability: something to read, understand, test, debug, maintain, migrate, and eventually explain to someone who didn’t write it, often future you, who will be far less charitable. Less code doesn’t just mean fewer bugs. It means fewer assumptions, fewer hidden contracts, and fewer places for complexity to quietly rot.

Simple code beats clever code almost every time. Clever code impresses in the moment. Simple code survives. The goal isn’t to be smart. It’s to be clear. Code should explain itself without requiring interpretation or bravado.

Consider a small example.

Clever:

total := lo.SumBy(
    lo.Filter(orders, func(o Order) bool {
        return o.Paid && !o.Refunded
    }),
    func(o Order) float64 {
        return o.Amount * (1 - o.Discount)
    },
)

It works. It is concise. It is also doing filtering, business rules, and calculation in a single expression. Understanding it requires knowing the helper library, the order of operations, and the embedded business logic all at once.

Simple:

var total float64

for _, order := range orders {
    if !order.Paid || order.Refunded {
        continue
    }

    total += order.NetAmount()
}

More lines. Less code.

The intent is obvious. The loop reads top to bottom. The business rule has a name. There is a clear place to add logging, debugging, or a new condition without fear.

This is not accidental. Go’s design nudges you toward this style. It makes cleverness slightly uncomfortable and simplicity feel natural, because boring, readable code scales better than impressive code ever will.

The same principle applies at the system level. Well-designed systems outperform clever ones. Clever systems depend on sustained brilliance and discipline to keep functioning. Well-designed systems depend on structure, constraints, and unremarkable correctness. They do not need heroics to stay stable.

AI makes this lesson more urgent, not less. Modern tools are extremely good at generating code quickly and confidently. They will happily produce large, intricate solutions to problems that would have been better solved by a simpler model, a tighter constraint, or a deleted requirement. AI optimizes locally. Humans must optimize globally.

Without global understanding of the domain, the trade-offs, and the long-term cost, code generation turns into code inflation. The risk is not that AI writes bad code. It is that it writes reasonable-looking code that no one fully understands or truly owns.

Great engineers do not win by typing faster. They win by choosing simplicity over cleverness, design over tricks, and deletion over accumulation.

Deletion is a design skill.
Omission is an architectural decision.

In an era where code is cheap, clarity is expensive. That is where real engineering lives.

Write less. Delete more. Design simply.

A Practical Critique of Service Meshes: Trade-offs, Pitfalls, and When Not to Use One

Edgar Nahama Alochi — Mon, 20 Jul 2026 22:45:47 +0000

Why Service Meshes Sound Inevitable

Every sufficiently large system eventually hears the phrase:

We should probably add a service mesh.

It sounds reasonable.

Traffic is complex.
Security is hard.
Observability feels fragmented.

A service mesh promises to standardize all of this
without touching application code.
Just install it and let the platform handle the mess.

That promise is not a lie.
But it is incomplete.

This note is about the cost of that promise.
What you gain.
What you lose.
And when the right answer is still:

No.

What a Service Mesh Actually Is

And Why That Matters

At its core, a service mesh inserts itself into every request path,
usually via sidecar proxies.

Your services no longer talk to each other directly.
They talk through infrastructure.

This matters because you are not adding a library.
You are adding a distributed system.

One that runs alongside your own.
With its own control plane.
Data plane.
Failure modes.
And upgrade cycle.

If you do not model it as a first-class system,
it will surprise you later.

Usually at 3 a.m.

The First Trade-off

You Gain Consistency, but Lose Locality

Before a mesh, behavior lives close to the code.

Retries.
Timeouts.
Authentication.
They are explicit.

With a mesh, those behaviors move into configuration.

That gives you consistency,
but removes locality.

When something breaks,
the answer is no longer in the repository you are reading.

It might be in a policy,
applied by a controller,
rendered into a proxy,
that updated five minutes ago.

Debugging shifts from reasoning about code
to reasoning about state.

This is not bad.
But it is different.
And often underestimated.

Observability

More Visibility Does Not Mean More Understanding

Meshes are observability machines.

Metrics for everything.
Spans for every hop.
Dashboards that look like flight control.

And yet, teams often feel more blind.

Retries hide failures.
Timeouts hide slowness.
Success rates lie politely.

The system looks healthy
until it suddenly is not.

The hardest question becomes:

Are we being protected,
or are we being masked?

If you cannot answer that confidently,
you are operating on vibes.

Performance Costs

The Tax You Pay Forever

Every sidecar proxy consumes resources.

CPU.
Memory.
Latency.

At small scale, this feels negligible.
At large scale, it becomes a budget line item.

High-throughput systems notice.
Latency-sensitive systems suffer.
Cost-optimized systems feel it immediately.

A mesh is never free.
It is a permanent tax,
paid per request.

If you cannot explain why that tax is worth it,
you are already in trouble.

Operational Reality

The Part That Rarely Makes the Slides

Running a mesh means:

Upgrading control planes.
Rotating certificates.
Debugging broken proxies.
Managing version skew.

It also changes team structure.

Platform teams become infrastructure product owners.
Application teams become consumers of invisible rules.

If ownership is unclear,
the mesh becomes a blame amplifier.

If your Kubernetes fundamentals are shaky,
a mesh will not stabilize them.
It will magnify every weakness.

Policy Sprawl

When Configuration Becomes Behavior

Service meshes are policy engines.

Over time, policies accumulate.

Traffic rules.
Security rules.
Exception rules.

Each one makes sense in isolation.
Together, they form a system nobody fully understands.

Now behavior lives in YAML.
Spread across namespaces.
Applied eventually.
Remembered vaguely.

When production breaks,
you are no longer debugging software.

You are excavating intent.

When a Service Mesh Makes Sense

Despite everything,
there are valid reasons to adopt one.

A mesh fits when:

You operate many teams
with many services
across trust boundaries.

When security requirements demand uniform enforcement
and application teams cannot realistically implement it themselves.

When platform maturity is high,
ownership is clear,
and engineers understand distributed failure.

In short:
when complexity already exists
and is unavoidable.

When You Should Not Use a Service Mesh

Do not use a mesh when:

Your system is small enough to understand.
Your main bottleneck is product velocity.
Your team is still learning Kubernetes.
Your outages come from basics, not edge cases.

Do not install a mesh to feel mature.
Install it because you are already paying the complexity cost elsewhere.

Often,
a load balancer,
good client libraries,
and boring TLS
are more than enough.

The Real Question to Ask

The question is not:

Is a service mesh good?

The question is:

What complexity are we choosing to own?

A service mesh trades application simplicity
for operational and cognitive complexity.

That trade can be correct.
Or disastrous.

Simplicity is not a phase.
It is a competitive advantage.

If you can keep your system simple,
do it.

And do not apologize.

When Software Decays and AI Accelerates Complexity

Edgar Nahama Alochi — Mon, 20 Jul 2026 09:03:57 +0000

Why systems get harder to understand over time and what to do about it

Software does not remain good forever. Even the most elegant code begins a slow drift toward disorder once it is written. This does not happen because engineers are careless or unskilled. It happens because entropy is the default state of complex systems. Without continuous attention, clarity fades, accidental complexity accumulates, and teams eventually find themselves maintaining systems they no longer fully understand.

This is not pessimism. It is engineering realism.

Software entropy as a law of code

Like physical systems, software naturally moves toward disorder unless energy is applied to keep it organized. In codebases, this disorder appears gradually and often quietly. Dependencies become tangled. Side effects surface in places no one expects. Changes that should be safe become risky. Systems appear to work most of the time, yet fail unpredictably when modified.

This phenomenon is commonly described as software entropy. It is not a failure mode or a bug. It is a property of long lived systems. Without discipline, entropy grows invisibly until the cost of change becomes impossible to ignore.

The visible steps of decay

Entropy does not arrive all at once. It reveals itself through patterns that are easy to recognize in hindsight.

Technical debt

Every shortcut, clever workaround, missing test, or postponed refactor is a loan taken against future maintainability. Technical debt does not disappear on its own. It accumulates interest every time someone hesitates before changing code, works around it instead of fixing it, or avoids it entirely out of fear.

Code rot

Code rot does not mean code stops running. It means code stops being understood. Paths that are rarely exercised degrade quietly. Tests become inaccurate. Assumptions that were once valid lose their context. The system still functions, but fewer people can explain why.

Architectural erosion

What begins as a clear structure slowly weakens. Boundaries are crossed for convenience. Dependencies leak across layers. Modules that once had a single responsibility become tightly coupled to many others. The original architecture still exists in name, but no longer in practice.

These are not isolated problems. They are symptoms of entropy acting over time in the absence of deliberate care.

AI as a force multiplier

AI enters this picture not as a villain, but as an accelerator.

Modern AI tools promise speed. They reduce boilerplate. They generate code quickly. They help surface patterns humans might miss. Used well, they are powerful productivity aids.

The risk is not that AI produces bad code. The risk is that AI produces plausible code without understanding intent.

AI systems optimize for what looks correct in isolation. They do not carry your product vision. They do not understand the tradeoffs behind existing architectural decisions. When they generate solutions, they often duplicate patterns, introduce subtle inconsistencies, or optimize for local fixes rather than global coherence.

This accelerates the exact conditions entropy thrives on. More code is added faster. More decisions are made without shared context. Complexity grows without a corresponding increase in understanding.

As a result, large AI assisted codebases can feel unfamiliar even to the teams that build them. At a glance everything looks reasonable. Under closer inspection, the system feels disjointed. Different parts reflect different heuristics. The code works, but it does not speak with a single voice.

Managing complexity through discipline

Codebases do not decay because engineers are careless. They decay because complex systems require continuous stewardship, not one time design decisions.

There are ways to slow entropy, even in the presence of AI.

Lead with principles
Start from real problems rather than abstract features. Treat simplicity as a deliberate design choice, not a happy accident.
Use tests as a compass
Tests do more than catch bugs. They provide confidence. When change is safe and verified, engineers are less likely to avoid necessary refactoring and less likely to introduce hidden regressions.
Enforce clear boundaries
When a part of the system owns a domain, keep its responsibilities focused. Modular systems do not just scale better. They age better.
Keep architecture human led
AI is excellent at assisting with routine work. Architecture requires intent. Use AI as a tool, not as a decision maker. Let humans remain responsible for structure and direction.

A final thought

Entropy always wins if nothing is done. But teams that value long term clarity over short term velocity are not powerless. Decay is not inevitable. It can be measured, managed, and reduced.

Great systems last not because they were designed once, but because every change preserved their coherence over time.

Vibe Coding Is Cheap. Engineering Remains Expensive.

Edgar Nahama Alochi — Thu, 16 Jul 2026 05:15:40 +0000

Writing code is getting cheaper and faster. Engineering remains expensive.

This is not hype. It is reality. And it is measurable.

A recent study by Anthropic looked at how AI-assisted coding affects learning new programming skills. Developers unfamiliar with a Python library were split into two groups. One used an AI assistant, the other relied on documentation and web searches. After completing the tasks, participants were tested on understanding the library’s concepts. The result was clear. The AI group scored about 17 percent lower on comprehension, without finishing tasks any faster overall

Think about that for a second. You can have code that works perfectly but not actually understand why it works. Some developers who relied on AI finished faster, but when it came to reasoning about the code, they struggled the most. Producing output is not the same as building skill. Speed without understanding is a trap

The study also showed that how you interact with AI matters. Developers who used the AI for everything learned the least. Those who asked targeted questions, explored why the code worked, or generated snippets and then probed them preserved far more of their learning[^1]. The lesson is simple. AI can teach, but it cannot replace thinking. Treat it like a collaborator, not a magician.

This matches what I see in real-world software work. Someone who knows how to vibe a prompt can get a function running in minutes. Someone who knows systems moves faster when complexity grows, not because they type faster, but because they anticipate what could break, what could scale poorly, and what might cause headaches down the line. That is judgment. That is engineering. That is the thing AI cannot fully outsource.

Code is an artifact. Systems are living organisms. They accumulate state, fail in unpredictable ways, scale differently than expected, and evolve over time. Engineering is expensive because it works with what persists and what matters. Producing code fast is only part of the picture. Understanding, anticipating, and designing for durability is where the real value and the real cost lives.

Vibe coding works beautifully for small problems, narrow contexts, or throwaway prototypes. But as soon as a system grows, complexity hides in plain sight. AI-generated code may look clean on the surface, but intent is implicit. Decisions are baked in without explanation. Debugging, extending, or refactoring that code becomes a treasure hunt you never signed up for. Suddenly, the cheap, fast code feels anything but cheap.

This is why engineers continue to outpace prompt specialists. They do not necessarily write more code, or write cleverer code. They reduce future cost. They know what precision matters, where to add structure, and where to leave flexibility. They can delete or rewrite confidently because they understand the system. AI accelerates their work, but it never replaces their judgment.

The bigger picture is this. The emerging divide is not AI versus human, or coder versus non-coder. It is between people who can reason about systems and people who only generate output. Code is becoming abundant. Judgment is scarce. AI makes writing software easier. Engineering determines whether that software survives reality.

Here is a little truth that always makes me smile. Fast code without thought is like a skateboard with no brakes. It might be fun at first, but try turning a corner and you will find yourself in the ditch. AI can give you the skateboard. Engineering teaches you how to steer.

Footnotes and Sources

Anthropic. How AI Assistance Impacts the Learning of Programming Skills. Controlled study on AI-assisted coding and concept retention

The Decoder: AI coding tools hurt learning unless you ask why, Anthropic study finds

The Great Simplification: Why Your Database is Your Best Cache

Edgar Nahama Alochi — Wed, 15 Jul 2026 08:58:27 +0000

For years, the "Standard Stack" followed a predictable pattern: Postgres for persistence, Redis for caching, and RabbitMQ or SQS for background jobs. We accepted this as the "Microservices Tax"—the price of doing business at scale.

But in 2026, we’re seeing a counter-movement. We’re realizing that for 90% of applications, the bottleneck isn't the database's speed; it's the architectural complexity of keeping all these systems in sync.

1. The "Single Source of Truth" Problem

When you introduce Redis, you introduce the Cache Invalidation nightmare. You now have two places where "the truth" lives. If your Redis write succeeds but your Postgres transaction fails, your system is in an inconsistent state. By using Postgres as your primary store and your high-speed lookup table (via Unlogged Tables), you gain Atomic Consistency.

2. Eliminating Distributed Transactions

When your queue (RabbitMQ) is separate from your database, you can't wrap a "job dispatch" and a "database update" in a single transaction. You end up needing the Outbox Pattern, which adds even more code to manage.

If your "jobs" table is just another table in Postgres, a simple DB::transaction ensures that the job is only created if the data is actually saved. No more "ghost jobs" that reference IDs that don't exist yet.

3. Postgres is Faster Than You Think

With the advent of NVMe storage and huge memory buffers, the "slowness" of disk-based databases has largely vanished for most workloads.

JSONBallows for schema-less "Redis-style" key-value storage.

LISTEN/NOTIFY handles real-time pub/sub.

SKIP LOCKEDallows Postgres to act as a high-performance, concurrent queue without the risk of multiple workers grabbing the same task.

The "Garden" Takeaway
The most senior move a developer can make is choosing not to add a tool. Every new service you add is another point of failure, another security surface area to patch, and another set of metrics to monitor. Before you reach for a specialized tool, ask: "Can I do this with a more clever SQL query first?"

The Cost of a Promise

Edgar Nahama Alochi — Mon, 13 Jul 2026 10:33:48 +0000

An API is a promise to unknown consumers about how your system behaves. Once published, that promise is difficult to change without breaking trust.

That’s why API design deserves far more care than it usually receives.

Good APIs are boring in the best way. They are predictable, explicit, and unsurprising. They avoid clever shortcuts in favor of clarity. Consumers should not need to guess what an endpoint does or how a field behaves under edge conditions.

One of the hardest parts of API design is restraint. Every field added is a commitment. Every optional parameter increases the surface area for bugs. Flexibility feels generous in the moment but becomes expensive over time. Strong APIs say “no” more often than “yes.”

Consistency matters more than perfection. Naming conventions, error formats, pagination strategies—these things compound. Inconsistent APIs force consumers to write special-case logic, which is a hidden tax on every integration.

Versioning is another area where theory and practice diverge. In reality, versioning is less about URLs and more about change management. Backward compatibility, deprecation timelines, and communication matter more than whether you use /v1.

APIs should also be designed with failure in mind. Clear error messages, meaningful status codes, and idempotent operations make systems more resilient. Consumers will misuse your API. it’s not a matter of if, but when.

At their best, APIs reflect thoughtful system boundaries. They expose intent, not internals. When done right, they allow teams to move independently without stepping on each other. When done poorly, they become tight coupling disguised as a service.

Learning to Think in Sets, Not Loops

Edgar Nahama Alochi — Sun, 12 Jul 2026 04:47:50 +0000

SQL is often treated as an implementation detail something to hide behind an ORM or repository layer. That attitude usually survives until the first serious performance incident. At that point, SQL becomes unavoidable.

SQL is not just a query language. It is a way of thinking about data that forces clarity.

The hardest part of SQL is not syntax, but mindset. SQL requires a shift from imperative thinking to declarative thinking. When developers think in loops, they tend to write inefficient queries. SQL rewards those who describe sets, relationships, and constraints precisely.

A useful rule of thumb:

If you find yourself thinking “for each row…”, you are probably about to write a bad query.

Good SQL starts with good schema design. When tables reflect real-world relationships clearly, queries become simpler and faster. This is why SQL is inseparable from [[Database]] design.

Indexes are often misunderstood. They are not universal speed boosts. They are promises to the query planner about access paths. Adding indexes without understanding query patterns leads to bloated storage, slower writes, and false confidence.

Indexes are another area where intuition often fails. Indexes do not speed up queries universally; they optimize specific access path

Some hard-earned SQL heuristics:

Avoid SELECT * in production code
Read execution plans before optimizing
Optimize queries before adding caches
If a query is fast and you don’t know why, you don’t understand it yet
Aggregations hide bugs as easily as they hide rows

SQL is also a truth serum for business logic. Vague requirements collapse when forced into queries. Terms like “latest”, “active”, or “valid” demand precision. This is why SQL pairs naturally with [[API Design]] and reporting work.

Concurrency exposes the cost of misunderstanding SQL. Isolation levels, locking, and transactions are not academic topics. Many data corruption bugs are simply misunderstood transactional behavior.

Avoiding SQL does not simplify systems. It moves complexity into places where it is harder to see, harder to measure, and harder to fix.

SQL teaches humility. Data has gravity.

DEV Community: Edgar Nahama Alochi

NASA's Rule of 10: The rules of programing that put flying metal in orbit

The NASA Ten Rules of Programming

Rule 1

Rule 2

Rule 3

Rule 4

Rule 5

Rule 6

Rule 7

Rule 8

Rule 9

Rule 10

The quiet lesson behind the rules

A Small, Annoying Reminder About MySQL, Next.js, and Reality

Understanding Next.js Page Caching (with a real example)

How Next.js caching works

How to control caching

Key lessons from my experience

References

Making Next.js Behave: Practical Notes on Performance, Architecture, and Not Shooting Yourself

Start by making the codebase legible

DRY is about removing decisions, not saving lines

Prefer server components until proven otherwise

Cache aggressively, but intentionally

Keep API clients dumb

Never store tokens in localStorage

Reduce build work by deleting code

Treat DX issues as real bugs

Make failures explicit

The real optimization

Open Source in the Age of AI: When Slop Floods the Swamp

The Inbox as a Crime Scene

The Slop Factory Model

When Everything Looks Like Work

The Maintainer as the Bottleneck

Tools Are Not the Enemy

What Open Source Actually Needs

A Quiet Ending

The Best Line of Code Is the One You Never Write

A Practical Critique of Service Meshes: Trade-offs, Pitfalls, and When *Not* to Use One

Why Service Meshes Sound Inevitable

What a Service Mesh Actually Is

And Why That Matters

The First Trade-off

You Gain Consistency, but Lose Locality

Observability

More Visibility Does Not Mean More Understanding

Performance Costs

The Tax You Pay Forever

Operational Reality

The Part That Rarely Makes the Slides

Policy Sprawl

When Configuration Becomes Behavior

When a Service Mesh Makes Sense

When You Should Not Use a Service Mesh

The Real Question to Ask

When Software Decays and AI Accelerates Complexity

Why systems get harder to understand over time and what to do about it

Software entropy as a law of code

The visible steps of decay

Technical debt

Code rot

Architectural erosion

AI as a force multiplier

Managing complexity through discipline

A final thought

Vibe Coding Is Cheap. Engineering Remains Expensive.

Footnotes and Sources

The Great Simplification: Why Your Database is Your Best Cache

1. The "Single Source of Truth" Problem

2. Eliminating Distributed Transactions

3. Postgres is Faster Than You Think

The Cost of a Promise

Learning to Think in Sets, Not Loops

A Practical Critique of Service Meshes: Trade-offs, Pitfalls, and When Not to Use One