Forem: Duplessis van Aswegen

Don’t Worship the Toaster (and Other Rules for Using AI Without Losing Agency)

Duplessis van Aswegen — Mon, 29 Dec 2025 17:26:04 +0000

We now live in a world where an absurd amount of stuff can be generated on demand. Text, images, music, plans, arguments, mockups, and enough “options” to make the concept of a single coherent identity feel like a premium feature you forgot to renew.

The cost of producing a thing has collapsed. That part is no longer controversial. The only people still arguing about it are either selling something, regulating something, or trapped in a meeting where everyone says “paradigm shift” like it’s a prayer.

The obvious conclusion is that creation no longer matters.

That conclusion is wrong, in the way it’s wrong to conclude that because bread is cheap, sandwiches are meaningless. Bread isn’t the problem. The problem is the horrifying number of sandwiches that now exist, many of which are trying to be your personality.

When supply gets close to unbounded, value doesn’t disappear. It migrates. Upstream. Into the part that decides what’s worth keeping.

Generation is cheap. Judgment is still expensive. And somehow we keep trying to pay for judgment with vibes.

I’ve found it useful, for my own sanity, to think about AI in two broad modes. Not because the universe demands categories, but because humans are perfectly capable of confusing themselves to death without help, and I’d like to reduce my reliance on that talent.

There’s the mode where AI is a tool. Instrumental. I have a task, a constraint, an outcome. The model helps me do work. The output goes into a real process that pushes back: compilation, tests, users, production logs, budgets, deadlines, and whatever grim entity governs time estimates.

Reality is the grader.

Then there’s the mode where AI is an oracle. Not necessarily because I want it to be, but because I ask it questions in places where I can’t clearly test whether it’s wrong, or where “wrong” isn’t even well-defined. What should we believe. What does this mean. What will happen. What is best.

This distinction isn’t moral. It’s about control. Tooling keeps agency with me. Oracle use can quietly relocate agency to something that speaks in complete sentences and never looks nervous.

Most of the trouble starts when these two modes get blurred. Which, inconveniently, is the default setting.

My own use leans heavily toward tooling. Not because I’m above temptation, but because I enjoy knowing when I’m being lied to.

Tooling forces contact with consequence. It keeps me inside a feedback loop. If the model helps, great. If it misleads me, I pay for it quickly. That payment is information. It updates my understanding. It’s annoying, but it’s honest.

In practice this looks very unromantic.

I’ll use AI to sketch a refactor path or list tradeoffs, then I validate by doing the boring part: reading the code, running the tests, watching what the system does when it hits reality.

I’ll use it to draft tests or enumerate edge cases, especially where business rules mutate into folklore. Then I check those cases against actual requirements, existing behavior, and whatever production logs are willing to confess.

I’ll use it to explain a module back to me, but I treat it like a rubber duck with a postgraduate vocabulary. Helpful, occasionally brilliant, not legally admissible.

Sometimes I’ll ask it for a few alternative implementations just to see patterns, like shaking a box to hear what rattles. The compiler becomes the lie detector. The runtime becomes the judge. Users become the jury, which is a frightening thought if you dwell on it.

Tooling doesn’t make me smarter. It makes me faster at discovering where I’m wrong.

That matters because speed without feedback is just acceleration, and acceleration is only impressive until you meet a wall.

None of this means oracle use is useless. That would be dishonest. There are places where “correctness” isn’t the goal, because there is no stable ground truth to converge toward. You’re exploring. You’re mapping. You’re trying to see the problem from an angle you don’t naturally inhabit.

Oracles make sense in ideation, in creative exploration, in speculative thinking, in philosophy, in reframing problems you already own responsibility for. They make sense when what you’re buying is perspective, not authority.

The system isn’t there to be right. It’s there to widen the map. To suggest a path you didn’t see. To hand you a weird rock and insist it’s symbolic.

The distinction that matters is authority. Safe oracle use is borrowing perspective, not outsourcing judgment.

Which brings us to the part where people get quietly tricked, usually because the trick is comfortable.

Oracle use is safest when it’s bounded, plural, and owned.

Bounded means I set the frame. I remind myself, explicitly, that this is exploration, not instruction. Plural means I force it to generate multiple perspectives, including the annoying ones. Owned means I treat the output as input to my judgment, not a replacement for it.

If I’m being disciplined, “safe oracle mode” looks like asking for opposing framings, counterarguments, or what would change the answer. It looks like prying assumptions into daylight. It looks like separating facts from interpretations and value claims, because mixing those is how you end up with a toaster as your spiritual advisor.

Oracle use becomes unsafe when confidence replaces accountability.

Especially in politics, culture, ethics, identity, and forecasting complex social systems, which are basically domains where everyone is carrying a sword made of opinions and insisting it’s a measuring instrument. These spaces contain facts, but they aren’t reducible to facts, and the gap is where fluency gets mistaken for truth.

The most dangerous oracle failures aren’t dramatic. They’re quiet. People think they’re using a tool. The system behaves like an oracle. Authority slips in through tone, coherence, and the deeply human habit of mistaking “sounds plausible” for “is reliable.”

A rule of thumb helps here, because humans love rules of thumb even when they fail constantly: if I can’t describe how I’d know the answer was wrong, I’m in oracle mode.

That doesn’t mean don’t do it. It means don’t confuse it with tooling. Don’t install it as your internal government.

This is where “accuracy” starts to mislead people. A lot of AI discourse tries to reduce everything to accuracy because accuracy is measurable, and measurable things make humans feel safe. Like seatbelts. Or quarterly reports.

Accuracy makes sense when there’s a stable external referent. A bridge holds or it doesn’t. A proof is valid or it isn’t. Code compiles or it doesn’t. In those domains, accuracy is a useful metric.

In art and culture, “accuracy” isn’t the metric. In politics and ethics, it’s only part of the story. These are value-laden domains. Outputs aren’t simply correct or incorrect. They’re situated, interpretive, persuasive, contested.

Trying to force these into accuracy problems doesn’t make them safer. It just hides judgment behind math-flavored language.

What matters more here isn’t correctness. It’s epistemic integrity: making assumptions explicit, separating fact from interpretation, and resisting the urge to launder values as facts.

And when “accuracy” becomes slippery, something else becomes dangerous: fluency. Because coherent outputs can feel true even when they’re just well-formed. The model can write like a confident adult in a blazer. Reality does not care about blazers.

Now we get to the part that feels like an upgrade and might secretly be a trap.

GenAI introduces something new into decision-making: a cheap buffer between intent and consequence. We can simulate. Rehearse. Generate alternatives. Explore counterfactuals without immediately acting in the world. Not infinite in any literal sense, but economically unrecognizable compared to what came before. Like going from having one telescope to having a thousand telescopes and no idea which one is pointing at a bird.

This buffer is powerful. In many contexts it’s genuinely beneficial.

But buffers change behavior.

When feedback is delayed, softened, or abstracted, people take bigger risks. Systems scale faster than understanding. Bad ideas survive longer than they should, like a vampire invited in because it looked polite on LinkedIn.

Simulation doesn’t remove cause and effect. It defers it. And deferred consequences tend to arrive concentrated, like interest on a loan you forgot you took out because the app made it feel friendly.

This is the meta-risk that doesn’t require sci-fi. Not “AI decides for us,” but “AI makes it easier for us to avoid feeling the cost of our decisions until the cost becomes unavoidable.”

A buffer can be a safety feature. It can also become a blindfold. Humans are remarkably good at turning safety features into excuses.

Tooling survives this buffer better than oracle use because reality remains the arbiter. Outputs still get graded by the world. Even if I move faster, I’m still constrained by tests, production, users, and failure. Mistakes remain informative. The loop stays intact.

Oracle use erodes that connection. Not because the system lies, but because persuasion replaces validation. Coherence replaces truth-testing. Confidence replaces learning.

The danger isn’t wrong answers. It’s unowned ones.

“The model said so” is a modern method of responsibility diffusion. It’s not malicious. It’s just convenient. And convenience is how civilization usually gets killed, or at least how it ends up in meetings.

When people talk about making AI “trustworthy,” they often mean “make it more accurate.” In many real use cases, trustworthiness is less about accuracy and more about behavior under uncertainty.

A trustworthy system is one that makes clear what it knows versus what it’s guessing, that doesn’t smooth uncertainty into confident tone, that exposes assumptions, that invites verification when verification exists, and that refuses to become an oracle by accident.

This is where grounding, retrieval, and evaluation loops matter. Not because they make the model perfect, but because they tether it to something outside itself when that’s possible. Trust should be earned through traceable process, not vibes.

Vibes are how you end up worshipping a toaster.

There’s an exception worth protecting, because humans need somewhere to be irresponsible without burning down the neighborhood: play.

Using AI for creative inspiration, exploration, or fun is often safe precisely because it makes no claim on truth. Nothing depends on the output. There’s no authority granted. It’s a fountain of variation. Prompts. Seeds. Sparks.

It can hallucinate all it wants in this mode because I’m not confusing it with a decision engine. It’s a toy that sometimes produces interesting artifacts, like a kaleidoscope that occasionally writes a decent paragraph.

Play has boundaries. Hallucination is harmless when it’s not pretending to be instruction.

Where is this heading. The honest answer is: anywhere we let it. But the trend line feels clear.

Generation is trending toward commoditization. The ability to produce outputs will keep getting cheaper and more common. The premium shifts to selection and accountability: systems and practices that preserve agency, surface uncertainty, and keep humans responsible for consequences.

The valuable layer won’t be “more content.” It’ll be better judgment under overload. Tools that help decide what to pay attention to, what to ignore, and when to hesitate.

That’s not glamorous. It’s not oracle-shaped. But it’s load-bearing.

The risk isn’t that we build powerful generators. The risk is that we build them in a way that turns feedback into a suggestion instead of a constraint.

None of this is advice. It’s a constraint I’m choosing to operate under.

I don’t want systems that decide for me. I want systems that help me decide faster while being honest about what they know, what they assume, and what they can’t possibly know.

I want feedback, not reassurance. Friction where it matters. Play where it’s safe.

In a world where almost anything can be generated, preserving responsibility might be the only truly scarce thing left.

Silence Can Be Golden (If You Learn How To Paint)

Duplessis van Aswegen — Thu, 09 Oct 2025 20:55:55 +0000

At some point in my career I realised something about myself that I found odd:
I don’t really have an internal monologue.

There’s no running commentary in my head.
And when I’m working on code, I don’t talk myself through it - I just sort of see how things fit together.

My brain turns problems into little diagrams - modules, data flows, relationships - and I shuffle them around until it makes sense.
If something feels off, I can’t always explain why right away; it just doesn’t “sit right” in the picture.

It’s not deep or mystical. It’s just how my brain decided to handle logic.

How That Plays Out When I Code

When I open a project, my brain starts sketching connections on autopilot:

Functions become dots.
Data flows become arrows.
Layers stack themselves.

If I’m debugging, I mentally “run” the system and watch where it snags.
If I’m refactoring, I move those shapes around until the structure feels cleaner.

It doesn’t make me smarter than anyone else - it’s just a different way of keeping track of what’s going on.
But it does make me fast. (Mostly.)

What’s Good About It

This way of thinking has a few handy upsides:

I notice messy structures early, even if I can’t explain them yet.
I don’t mind big or complicated codebases - I can zoom out and see how they hang together.
Refactoring feels natural once the mental diagram stops wobbling.
I remember how things work pretty well.
I’m decent at solving certain kinds of problems quickly.

But it’s not exactly a superpower - just a quirk that happens to line up nicely with how software behaves.

Where It Trips Me Up

The same brain that can juggle abstract systems will absolutely forget to do the dishes.

When I’m lost in a mental model, everything else drops out - messages, chores, meetings, time.
And when I try to explain what’s in my head, it can sound like I’m skipping steps.
To me it’s obvious; to others it looks like I jumped from A to D with no B or C.

For a while I thought that meant communication just wasn’t my strength - or maybe that I have ADHD (and maybe I do).
Turns out it was more like no one else can see the imaginary flowchart you’re looking at, dude.

Figuring Out How to Collaborate

Here’s what helped me stop confusing my teammates:

Draw before explaining. Even the worst napkin sketch gets everyone on the same page faster than words.
Describe what you see, not what you feel. Saying “this flow feels tangled” is vague; saying “these two layers depend on each other” makes sense to everyone.
Pair with talkers. Verbal thinkers slow me down in a good way. They help me translate my diagrams into normal sentences.
Write short “why” notes. One or two lines about why I changed something saves future me (and others) from guessing my logic.

None of this came naturally.
I had to treat communication as part of the engineering work, not an optional extra.

Making Peace With It

Now I see this less as a quirk and more as my user manual.
I think in shapes. Most people think in words.
The job isn’t to change that - it’s to make sure the two can meet in the middle.

It’s still weird sometimes. I can’t narrate my thoughts the way some folks can.
But once I stopped trying to “think normally” and focused on explaining better, work (and teamwork) got a lot smoother.

A Hitchhiker’s Guide

This is one of the stories behind my ongoing series, The Hitchhiker’s Guide to Software Sanity - little lessons about staying sane in the chaos of tech.

Because sanity in software isn’t always about frameworks or productivity hacks - it’s also about understanding how your own brain works, and finding ways to make that work with other humans.

If your brain does something weird, you’re not alone.
Just learn its rules, and build an adapter.

The Cost of Inconsistency (And the Power of Predictability)

Duplessis van Aswegen — Mon, 22 Sep 2025 20:46:37 +0000

Expectation Roulette

One endpoint expected: active=true

Another wanted: is_active=1

And a third, authored long ago by an ancient intern whose spirit still haunts the codebase, insisted on: activeness=Activeness.YES

All technically correct.
All semantically identical.
Sort-of at least.
But all guaranteed to make you question whether software is just an elaborate prank we’ve all agreed to keep running.

It’s like discovering every traffic light in your city has its own personal theory of “green.”

And the buttons - dear god, the buttons.
Rounded here, squared there, and a hover state that only appeared when Mercury was in retrograde.
Users didn’t consciously notice, but they felt it.
Developers noticed because nothing erodes trust faster than a system that keeps breaking its own promises.

The Gospel of “Just This Once”

The intent was noble, or at least convenient.

“This endpoint just needs to ship.”
“That button style was faster to copy-paste.”
“We’ll circle back later.”

Every inconsistency was a tiny act of local optimization. Freedom for the team, speed for the sprint, autonomy in the moment. Nobody thought they were authoring scripture.
But “just this once” is the most prolific prophet in tech.

The Museum of Exceptions

Soon, the system resembled a modern art gallery: a thousand pieces, each with its own interpretive plaque.

Docs multiplied and lack pings became ritual: “Which version of ‘active’ is correct here?”
New hires spent their first month wandering the halls of contradiction, trying to remember which rules were official and which were the creative contributions of that long-departed intern.

It wasn’t documentation anymore.
It was folklore.

Chaos Tax

Call it Predictability Drift, Death by Exceptions, or my personal favorite: Chaos Tax.

Every deviation added overhead.
Every asterisk forced a new mental branch.
It’s like driving through a city where the stop signs are calibrated per block: “stop,” “yield,” “optional if you’re late,” “slow down unless you’re cool.”
You can navigate it, but don’t mistake survival for velocity.

Inconsistency doesn’t scale linearly - it compounds.
One small freedom becomes a forest of forks in the road.

Boring Is a Feature

Here’s the lens that finally clicked for me: predictability is velocity.

Consistency isn’t ascetic minimalism or bureaucratic purity.
It’s leverage.
Every standard is one fewer decision. One fewer doc update.
One fewer panicked midnight debug session.

Predictable systems don’t demand attention.
They fade into the background, letting engineers spend their time on problems that matter.
Which is the whole point: the less you notice the rules, the more useful they are.

One Filter to Rule Them All

These days, I’m less impressed by clever abstractions and more impressed by boring consistency.
A button that looks the same everywhere.
An API that doesn’t change its mind mid-sentence.

Because nothing feels faster than a system that doesn’t make you ask twice.

So yes, give me one predictable flag.
Something gloriously dull, like active=true.
Not is_active=1.
Not activeness=Activeness.YES (may the ancient intern rest in peace).

Just one truth, boring enough to believe in.

One filter to rule them all.

The 7-Layer Dip of State

Duplessis van Aswegen — Fri, 19 Sep 2025 01:26:00 +0000

The 2 a.m. Debugging Special

It’s 2:07 a.m.
A product shows 120 items in stock.
Our system swears it’s 0.
Somewhere along the way, it briefly claimed 42.

The database insists there are plenty. The cache says sold out. The frontend store is oscillating like a ceiling fan with a bent blade. The local offline cache is basically a time capsule from last Thursday. And feature flags? They’ve split the timeline into alternate universes where customers either can’t buy at all - or get the last unit forever.

I’m not debugging software. I’m cross-examining witnesses. Each one says, “I’m the truth.” None of them are.

Blueprints and Daydreams

On the whiteboard, it was a thing of beauty.

Database at the core. A cache to keep it lean. An in-memory store for hot paths. A frontend store to normalize state. A local copy for offline kindness. Feature flags for safety. Analytics humming quietly in the background.

Every layer justified.
Every arrow clean.

It looked less like code and more like architecture digest: The Cathedral of State.

When the Cheese Started Sliding

Then reality arrived.

The cache expired wrong, declaring “sold out” while the database still had stock. The local copy thought 20 units remained, but from last week. Feature flags forked the truth - one group of customers saw “limited edition,” another saw “permanently discontinued.” Analytics insisted we’d sold 300 units nobody could actually buy. And the database - the so-called bedrock - was just another opinion, delayed by replication lag.

Instead of one clear truth, we had a seven-way standoff. Bugs weren’t bugs anymore - they were investigations into which version of reality we’d broken this time.

Every layer was a new witness.
Every meeting was a courtroom drama.
Nobody ever won.

These Are Not the Truths You’re Looking For

This isn’t just a rough sprint. It’s a pattern. Call it State Entropy.

Every new layer starts as a simplifier. Over time, it spends more energy staying in sync than solving the problem it was built for.

You don’t notice it at first. Then one day, half your PRs are “fix stock count again,” and junior engineers are afraid to ask which layer is “real” because the answer will start a fight.

The “single source of truth” isn’t real. It’s a mirage. At best, you’ve got several provisional truths, all decaying at different rates.

Sometimes Salsa Is Enough

Here’s the lens I use now:

Every new state layer is a future sync bug.
The fewer times you ask “where does this value come from,” the healthier your system.

Add a cache if you must. Add offline storage if you must.
Just stop pretending each one is free.
They aren’t.

You’re trading clarity for speed, or resilience, or UX.
That’s fine - just own it.

And once you’ve made the trade, keep visibility. You don’t need purity. You need to know which layer is lying when (not if) things drift. Observability beats elegance.

Sometimes salsa really is enough. Don’t make the seven-layer dip just because you can.

Bottomless Dip

By 3:45 a.m., I wasn’t debugging anymore.
I was spelunking.
Every layer promised the truth.
Every layer lied in its own special way.

The bug wasn’t in the cache, or the DB, or the store.

It was in the belief there was ever a bottom to this dip.

The Rise of the Vibe Coder (and Why It Should Make You Better, Not Bitter)

Duplessis van Aswegen — Thu, 11 Sep 2025 12:18:27 +0000

They Shipped It Overnight. You’re Still Cleaning Up the Corpses.

It started as a Slack ping.

A prototype had gone viral on Product Hunt - something thrown together in a weekend by a junior, a designer, and a large language model.
Suddenly, leadership wanted “more of this energy.”
Shipping faster.
Caring less.
Outcomes, not architecture.

By the time you saw the codebase, it looked like a haunted house held together by duct tape and misplaced confidence.
No tests. No types. No idea who owned what.
Just vibes.

And somehow, it worked.
At least, until it didn’t.
Until it needed to scale. Or pivot. Or survive long enough to matter.

Welcome to the era of Vibe Coding.

The myth? That it’s the future. That careful engineering is obsolete. That vibes scale.
The truth? You’re still needed. Just not in the way you used to be.

Speed Is the New Virtue. And the New Vice.

The Vibe Coder doesn’t ask for clarity.
They don’t diagram the system or name things responsibly or leave breadcrumbs for the next poor soul.
They ship.

And shipping is seductive.
Because in this economy, “done” beats “right.”
Velocity signals competence. Caution reads like fear.

So management squints at charts and concludes: “Do we really need seniors? The new kids are shipping faster.”

Here’s the rot:
They're measuring movement, not direction.
Speed without trajectory is just flailing in high resolution.

Your job isn’t to beat them at their game. It’s to change the stakes.

AI Isn’t Replacing Engineers. It’s Replacing Guilt.

Most Vibe Coders don’t think they’re better than you.
They just don’t feel bad about skipping the parts you once thought were sacred.
No shame in copy-pasting from ChatGPT.
No pause before deploying duct tape to production.

Because the system told them that was fine.

AI didn’t kill the senior engineer.
Executive impatience did.

But here’s your edge:
You know what happens after the demo.
You’ve seen what “it just works” looks like six months later.
And unlike the vibe, you understand the cost of entropy.

So don’t rage against the tools. Learn their shape.
Then wield them with intention, not desperation.

You Can’t Out-Vibe the Vibe Coder

This isn’t about working harder or being smarter.
You will lose a speed contest against someone generating an entire module by typing “make a thing that does X.”
That’s not a failure. That’s physics.

But you can do what they can’t:

Untangle a brittle mess without rewriting the universe.
Explain why things broke - and how to prevent it next time.
See when “working” isn’t sustainable, and how to fix it before it combusts.

That’s not glamorous.
That’s not tweetable.
That’s engineering.

The Tower Is Tilted. Don’t Pretend It’s Not.

The system is rigged against depth.

Mentorship? Gone.
Code review? Optional.
Docs? LOL.

Your org probably rewards the person who merged ten features over the one who stabilized a flaky pipeline.
You might be the only person in the room who still cares if something is maintainable.

This is the moment where many seniors grow bitter.

Jaded.
Checked out.

Don’t.

You don’t have to fake joy. But you do have to stay awake.

Because bitterness is just burnout in a trench coat.
And you can’t help anyone - yourself included - if you’re too busy sneering at the collapse to navigate through it.

Play the Long Game. Even When No One Else Is.

There are two timelines in every company:

The presentation timeline, where everything is fast and clean and “customer obsessed.”
The consequence timeline, where shortcuts mature into outages and underpaid juniors become team leads by attrition.

You’re operating in the second one.
That’s not glamorous, but it’s real.
And eventually, when the dust settles and the vibes rot into noise, someone will be needed to rebuild.
To explain.
To fix.

That someone can be you - if you’re still standing.

Strategic Survival for the Vibe Era

1. Pick Your Battles Like a Burned-Out Warlord

You can’t fix everything.
And you shouldn’t.

Not every rushed PR needs your full wrath.
Not every flawed design doc is worth a crusade.

But some are.

Your job now isn’t to fight all the decay - it’s to spot the decay that matters.
The things that, if left alone, will haunt your roadmap for quarters.

Develop taste for when to speak, when to coach, and when to let the fire burn.

2. Keep a Paper Trail. Your Future Self Will Thank You.

In a world where memory is short and ownership is fluid, the only truth that survives is written down.

Decisions. Warnings. Risks you flagged and were ignored for.

Leave breadcrumbs.
Not to say “I told you so,” but to protect your sanity.

And yes - eventually, maybe even your job.

3. Mentor Like You’re Growing Resistance Fighters

If you’re lucky enough to still be around juniors, make them dangerous.

Not with trivia.
With mindset.

Teach them to ask why, not just how.
To think beyond the merge.
To notice when the vibes are lying.

Because one day soon, they’ll be the only ones left.
And if you don’t teach them, someone worse will.

4. Know When to Leave. But Also Know When to Stay.

Not every place deserves your wisdom.
Some companies are committed to the bonfire.
And leaving may be the sanest move.

But not every broken system is beyond repair.
Sometimes, all it takes is one stubborn, lucid engineer to steady the ground beneath a team.

The trick is knowing which situation you’re in.

And that clarity?
That’s your real seniority test.

This Was Never Just About Code

The Vibe Era isn’t just a shift in tooling.
It’s a shift in values.
A slow erosion of the things that made engineering a craft.

And yet - you’re still here.
Which means you still care.

So be the one who remembers what good looks like.
Be the one who stays curious, not cynical.
Be the one who refuses to vanish into noise.

Because when the hype dies down, and the smoke clears, and the codebase finally screams for help - They won’t call the Vibe Coder.

They’ll call you.

Helper, Utility, Factory… or Something More Sinister?

Duplessis van Aswegen — Mon, 09 Jun 2025 05:00:00 +0000

The File That Should’ve Stayed Boring

A harmless little helper that became a logic hydra. You know this one.

It started as helpers.ts.

Just a couple of string functions: slugify, capitalize, maybe something to format currency. You know, the kind of low-commitment one-liners that feel too pure to hurt you. Then came the date formatting. Then the ID generator. Then a function to normalize order items - but just the formatting, we said.

Six months later, helpers.ts was 800 lines, had three different behaviors behind getFormattedAmount, and included a “temporary” fix for tax rules in Germany.

When it broke, checkout broke.

When I traced the bug, I ended up in a function literally called isActiveCustomerLike. I say “literally” not for emphasis, but because that’s the actual name we shipped to production. It returned a boolean. It also triggered a database fetch.

No one knew where to fix things anymore. The “logic” was scattered across helpers, utils, factories, and files with names like coreUtils, sharedUtils, and, I kid you not, utilsUtils.

It took two engineers, one product manager, and a desperate Slack message to “whoever added this tax logic” to fix a bug that boiled down to: we’d built a second app, and hidden it inside the first one.

The Architecture That Felt So Grown-Up

When “modular” meant putting everything in neat little buckets - with no lids.

We were being responsible. Reusable. DRY, but not religiously. Just enough to avoid copy-pasting that formatPrice function everywhere.

We wanted composability without commitment. A toolkit, not a framework. Helpers for common logic. Utils for shared tasks. Factories for object setup. Each with its own tidy file, decoupled and dependency-free.

We’d read enough blog posts to know the dangers of fat services and god objects. We were breaking things up. Modularizing. Keeping our domain logic clean and uncluttered.

It felt mature. Under-engineered, even. Pragmatic.

And in fairness - it started clean.

But clean doesn’t mean safe.

The Secret Life of Utilities

How the real business logic slipped sideways into files no one owns.

It’s easy to spot when your models are bloated or your services too abstract. What’s harder to catch is the slow gravitational pull of logic drifting sideways - into the shadows between your files.

Helpers didn’t stay small. They started answering “just this one business need.” Then another. Then someone needed to check discount eligibility - quickly, no time to refactor the cart service - so they stuffed it into discountUtils.

Eventually, that file had a half-implemented loyalty engine living in it.

Meanwhile, the domain stayed pristine. Untouched. Empty.

The logic was somewhere else now - scattered across helpers and utils and factories that technically worked across the app, but only if you understood the exact combination of arguments and side effects. Calling one meant loading five implicit assumptions and hoping nothing changed upstream.

We built abstraction with no ownership. Encapsulation with no borders. A hall of mirrors where every function seemed useful, until you realized none of them were reliable.

Even the tests lied. Mock-heavy, low-coverage, and subtly obsolete. We were asserting behavior that no longer made sense, in files named things like formatHelper.test.

It wasn’t tech debt. It was tech drift.

And it was everywhere.

Welcome to the Utility Sink

The anti-pattern with charm, convenience, and a body count.

I call it the Utility Sink.

It looks like a grab bag, but it’s a gravitational well. Logic flows into it because it’s easy. Fast. Unopinionated. A helper can live anywhere, touch anything. It doesn’t need to understand context. That’s the appeal.

And the danger.

The Utility Sink has no identity. So it absorbs all of them. Your business rules, formatting logic, feature flags, database queries - all hiding behind verbs like “get” and “is” and “format.”

There’s no owner, because helpers belong to “everyone.” So no one sees when they start returning different results depending on the quarter, the client, or the moon phase.

The Utility Sink feels like reuse. What it delivers is indirection. The worst kind: invisible, inconsistent, and wrapped in good intentions.

It’s how you end up with a normalizeCustomerData function that applies different phone number logic depending on the country code and whether the customer is B2B or B2C - but only if the skipValidation flag isn’t set.

It doesn’t throw. It just returns slightly wrong data.

Until your email system starts calling everyone “Valued Client” because their names went missing.

Like a Sith apprentice, it always starts with good intentions - power without responsibility, shortcuts without context.

And before you know it, the logic has turned.

If It Gets Feature Requests, It’s Not a Helper

A brutal litmus test for architectural lies we tell ourselves.

Here’s the gut check:

If your helper gets feature requests, it’s not a helper anymore.

If product cares about it, if stakeholders ask about it, if QA writes edge cases for it - you’ve crossed the threshold. It’s no longer utility. It’s domain. You just parked it in a folder named shared.

Your helpers shouldn’t know about your product tiers. Your utils shouldn’t fetch from the database. Your factories shouldn’t contain logic branches for enterprise clients.

And if they do? Don’t rename them. Relocate them.

Put them where they belong. Even if it feels redundant. Even if it means your pristine service class gains weight. Logic needs a home - and a name that admits what it does.

Because there’s no such thing as “just” a helper.

That word? It’s code for “I don’t want to think too hard about where this goes.”

Which is fair. Until it breaks prod. Then you’ll think real hard, real fast.

The Callback You Didn’t Ask For

Yes, we fixed it. No, it didn’t stay fixed. Entropy always gets a sequel.

We fixed the tax bug. Eventually. We extracted the German VAT rules into the TaxPolicyService, gave it a clear contract, and wrote tests that didn’t involve mocking half the internet.

But the legacy remained.

Six months after the fix, someone opened a PR: “refactor formatInvoice into invoiceUtils.”

I saw it, sighed, and left a comment I’ve reused ever since:

“Only move it if you’re ready to own it.”

They replied with a thumbs-up. And merged it anyway.

The file is now 400 lines long. I haven’t opened it in weeks.

I assume it’s doing fine.

Probably.

Maybe.

God help us if it starts getting feature requests.

[Boost]

Duplessis van Aswegen — Mon, 02 Jun 2025 09:46:35 +0000

Duplessis van Aswegen

Jun 2 '25

The Abstraction That Hid the Only Logic That Mattered

#programming #architecture

Comments 4

4 min read

The Abstraction That Hid the Only Logic That Mattered

Duplessis van Aswegen — Mon, 02 Jun 2025 05:00:00 +0000

It’s Always the Refund

It started, as these things always do, with a Slack message from support that began:

"This is probably nothing, but..."

It never is.

Turns out a customer had requested a refund for a $0 order - paid entirely with a promotional code that someone in marketing named “YOLO100.” Our system, ever obedient, generated a pristine digital refund for exactly zero currency units and confidently shoved it into the payment gateway, which replied with the transactional equivalent of a raised eyebrow:

"Invalid amount."

From there, the trail of confusion expanded outward like a suburban sprawl. Engineering said it shouldn’t be possible. QA said it wasn’t in the test cases. Product said it was “an edge case.” (They always say that, don’t they? Every single cliff we fall off was once called an edge case.)

We eventually traced it back. The logic that was supposed to prevent this refund - "don’t send zero dollars to Stripe, you absolute gremlin" - existed. Technically.

It was just hidden inside a validator that only ran in one flow, skipped in another, and silently assumed the refund had already passed through a gauntlet of sanity checks. Spoiler: it had not.

Turns out, we had abstracted away the only logic that actually mattered.

Architecture by the Book (That No One Reads)

On paper, it was gorgeous.

A shining example of Clean Architecture, blessed by the gods of SOLID and curated with the gentle hands of someone who’d read the book twice. Everything had its place. Domain logic in the core. Application services on the edge. Infrastructure politely waiting outside with its hat off.

It was the kind of diagram you put in a pitch deck to make non-technical stakeholders nod solemnly.

At the heart of it all: Business Rules. Separated. Encapsulated. Respectable. We put them into validators and policies, wrapped those in handlers, and made sure they were only invoked by orchestrators with very strong boundaries and very weak opinions.

Command buses dispatched commands. Decorators added behavior. Rules were extracted, reused, blessed with unit tests, and wrapped in so many layers of pattern that they might as well have been a wedding cake.

The goal was purity. Composability. Decoupling.

You know. Architecture stuff.

What could go wrong?

Spoiler: everything.

The actual refund logic, if you dared to follow it, looked less like a business workflow and more like the migratory pattern of a particularly indecisive pigeon.

The request hit the controller, which fired off a command. That command passed through three decorators, a logging bus, a metrics wrapper, and then landed in a handler that did... very little. It mostly just handed the logic off to a service, which fetched a RefundPolicyManagerFactory and asked it, very politely, what to do next.

If the stars aligned, and the correct refund context was passed via middleware, and the policy registry hadn’t been short-circuited by a feature flag (true story), it would eventually reach the logic that said: “Oh, by the way, maybe don’t refund zero dollars.”

But in our case, the order had been placed using a full-discount coupon. That triggered a “discounted refund path,” which skipped the decorator chain entirely. Because, of course, we had more than one refund flow. We had three. One for standard refunds, one for coupons, and one for auto-cancellation - which didn't run validation at all because we assumed the system could do no wrong.

Each one was almost right.

But none of them carried the only rule that mattered.

The logic was everywhere and nowhere. A Schrödinger's condition: present in the system, but not observable.

Support couldn’t explain it. QA couldn’t catch it. PMs didn’t know it existed. And developers? We were left spelunking through a cave system of indirection, carrying only a headlamp and our IDE’s “Find All References” feature.

I once diagrammed the refund logic for onboarding. Halfway through, I switched to using emojis.

When Abstraction Becomes Camouflage

Let’s call it Abstraction Drift, though I was tempted to go with Layer Cake of Denial.

You start with a noble idea: separate your concerns. Pull out your logic. Wrap it in a reusable rule. Inject that rule via interface, wrap the interface in a service, and protect the service with a decorator. Toss in some middleware for good measure. Abstract until pure.

And then, one day, a critical rule - the thing that stops you from issuing Monopoly money refunds - lives four files away from the Refund itself, guarded by an interface nobody reads, and quietly skipped because the wrong flag was set.

This isn’t just over-engineering. It’s logic laundering.

By the time a bug appears, the rule responsible for preventing it is so thoroughly abstracted that you need a Ouija board to find it.

The abstraction didn’t isolate the logic. It dissolved it.

What was meant to be composability became composure theatre - a performance of order, with no actual predictability.

Seeing Is Debugging

Here’s what I learned, after months of architectural self-loathing:

If your system’s correctness depends on rules the developer can’t see, you didn’t abstract - you disappeared.

An abstraction should make things easier to reason about. If it doesn’t, it’s not an abstraction. It’s a trapdoor.

The problem isn’t just indirection. It’s invisible indirection. It’s the validator that only sometimes runs, the rule that lives in a helper, the condition buried behind a feature flag named betaRefundLogicV3.

It’s abstraction with amnesia - logic stripped of context, responsibility, and visibility.

So now, when I design something, I ask a very specific question:

Can I see the important behavior where it happens?

Or do I have to pray that some upstream service did the right thing?

And if the answer is the latter, I pull the logic back. I put it next to the thing it affects. I let the Refund know about the rule. Not because it’s “pure,” but because it’s real.

Because if your abstraction hides the logic that makes the system safe, it’s not clean. It’s complicit.

The Refund Strikes Back

We fixed the refund bug.

Eventually.

The logic now lives in the Refund, right where it always pretended to be.

We still have validators. But they decorate nothing.

Kind of like me at our last architecture review.

Balance has been restored to the Force.

Or at least to refunds. Which, in this system, are basically the same thing.

I was planning on working on this for much longer…

Duplessis van Aswegen — Sun, 01 Jun 2025 04:17:09 +0000

But i wouldn’t be following my own advice if I didn’t know when to let go. Read the final instalment- and the previous ones - and give me feedback please?

I just hope this helps someone somewhere :)

Check it out here

It’s been a few weeks since I started this series. I expected to continue working on it for longer, but I wouldn’t be following my own advice if I didn’t know when to let it go. Read the final instalment (and those before) and let me know what you think!

Duplessis van Aswegen — Sun, 01 Jun 2025 04:12:29 +0000

Duplessis van Aswegen

May 31 '25

Let It Go (No, Seriously): How to Stop Clutching and Start Living

#programming #culture #leadership

Comments

4 min read

Let It Go (No, Seriously): How to Stop Clutching and Start Living

Duplessis van Aswegen — Sat, 31 May 2025 16:25:01 +0000

You used to carry everything.

If someone dropped the ball, you dove. If a decision seemed off, you rewound the conversation. If the roadmap got weird, you lit a candle and tried to debug strategy with your bare hands.

You didn’t do this because you’re a control freak.
You did it because you care.
You did the work, so you felt responsible. And because you’re good, people let you. Encouraged you, even.

You were the hero, the glue, the failsafe.

And now? You’re tired.
Not just “need a nap” tired. Existentially tired.

You see chaos, and your first thought isn’t “How do I fix this?”
It’s “Please, not me again.”

You’re not broken.
You’re just human.
And you’re not meant to carry all of it.

The Dysfunction: Carrying the Uncarryable

The dysfunction isn’t that you care.

It’s that you believe your care is required. That if you stopped holding things - people, systems, projects - they’d fall. And it would be your fault.

This is the unspoken pact of overfunctioners.
You overextend. They underworry. Everyone silently agrees to the terms.

Until one day you realize:
You’ve built a Rube Goldberg machine powered by your own burnout.

The Lie of Ownership

We worship “ownership” like it’s a holy word.
Take initiative. Own the problem. Be the person who steps up.

But no one tells you what happens when “owning” turns into hoarding.
When you mistake “this matters to me” for “this is mine alone to carry.”
When you start gatekeeping out of love. Or fear. Or both.

Ownership without boundaries doesn’t look like leadership.
It looks like control.
And control is not the same as clarity.

Shipped-Too-Soon Scars

You shipped something too fast because leadership was breathing down your neck.
You patched a critical bug at midnight because no one else could.
You ran interference between product and engineering so nobody else had to get yelled at.

And somewhere in there, you got good at it. Too good.
So good that people just stopped asking if you should carry it all.

And now?

Now when someone asks, “Can you take this on?” you don’t hear a question.
You hear a loyalty test.
You hear, “If you really cared, you’d say yes.”

That’s not teamwork.
That’s emotional blackmail in Agile clothing.

Sometimes the Best Decision Still Fails

You can do everything right.
You can gather context, loop in stakeholders, document every tradeoff, and still ship something that backfires.

Why?

Because some variables don’t show up until after the decision.
Because people change their minds.
Because two teams interpreted the same “approved plan” like it was abstract art.

Or maybe:

Your PM left mid-quarter
Your leadership changed direction
The client misunderstood the spec, then blamed you for their misread
The integration partner never shipped their part, and you took the heat
The world shifted under your feet - and your “clean decision” now looks like a blind spot.

You didn’t screw up.
You just got hit by reality.

You Can’t Fix What You Don’t Control

You can only control how you show up.

You cannot control:

Your CTO's shifting priorities
The designer ghosting you mid-project
A teammate who drops drama into Slack like it’s confetti
The bug that wasn’t in staging but is very much in prod

And yet, you take all of it personally.
You wear other people’s decisions like name tags.
You mistake proximity for responsibility.

But you are not the product of your context.
You’re the pattern-breaker inside it.

And that starts by saying:

“This is not mine to hold.”

Process Trauma Is Real

You’ve been burned by systems that punished slowness, discouraged honesty, and handed out blame like Halloween candy.

So now you:

Anticipate every concern before it's voiced
Add 37 bulletproof caveats to every PR description
Overexplain basic tradeoffs to protect your future self from critique

This isn’t maturity. It’s process PTSD.
And it teaches you to see work as a battlefield - even when the war is over.

Let yourself operate like the threat level has changed.
Because it probably has.

The Long Goodbye

Part of seniority is learning how to let go.
Not with a dramatic “I quit” - but with the quiet, grown-up courage of someone who knows:

I can care without clutching
I can lead without owning every outcome
I can ship good work even if it dies in a strategy shift three weeks later

You are not your roadmap.
You are not your success metrics.
You are not the last person standing between your team and the abyss.

You are a steward.
You show up.
You do your part.
And when the baton passes - or the sprint implodes - you let it go.

One Last Time, for the People in the Back

Letting go doesn’t mean not caring.
It means caring cleanly.

Without ego.
Without martyrdom.
Without rewriting the outcome in your head a hundred times before bed.

You don’t need to be the hero.
You don’t need to be the shield.
You don’t need to be the emotional patch cable that holds the org together.

What you do need?
A nervous system that isn’t on fire.

Because the systems will change.
The roadmap will shift.
The features will get cut, merged, resurrected, rewritten, abandoned.

And if you’ve built your identity on holding everything together...
You’ll break right alongside it.

So breathe.
Step back.
Let the flame flicker out.

You’ve done enough.

Let it go.

Final Entry. Final Note.

This is article 21 in The Hitchhiker’s Guide to Software Survival.

It’s also me taking my own advice—learning to let go, even when it’s hard.

(Yes, even when your brain whispers “just one more metaphor about code being feelings.”)

We started with a shipping mantra.

We’re ending with a peace mantra.

Somewhere in between, we built a map.

If even one piece helped you name a problem, survive a weird sprint, or feel less alone—then it did its job.

And when the seas get stormy again (they will), you’re allowed to come back.

This series was never a sermon. It’s a lighthouse.

You don’t need it all the time. Just when you need direction.

Keep going. Keep growing.

And don’t forget—you’re human first. Engineer second.

See you out there.

Beware the Shiny Tech Trap

Duplessis van Aswegen — Sat, 31 May 2025 05:46:40 +0000

It's 10:06 a.m. on a Tuesday. Planning is humming along. The team’s finally got some momentum, the roadmap’s blessedly bug-free, and the last deploy didn’t require a postmortem or whiskey.

Then someone says it.

“What if we rewrote the service in Rust?”

You blink. Surely it was a joke.

“It’s just... with WASM and edge functions, we could simplify the whole architecture.”

There it is. That soft, reverent tone. Like they’re reading scripture. Or pitching to YC.

And just like that, we’re off. Goodbye, roadmap. Hello, crowbrain.

But you’re not a crow.
And that glimmer isn’t food.

It’s an ill-timed rewrite that makes no sense even in context - like deciding to renovate your kitchen because the toaster’s acting up on Christmas Day.

The Instinct to Rebuild

Let’s call it what it is: boredom.

Or maybe not boredom exactly - impatience disguised as thought leadership.

You’ve been in the codebase a while. Things are working. Which is unsettling. There’s nothing to fix, but you need to feel useful. So you look around, crack your knuckles, and whisper the sacred spell:

“We should really consider modernizing.”

Translation: Let’s light a fire under this perfectly functional system because I need to feel like I’m doing something ambitious.

You tell yourself it’s about scale, or performance, or “technical debt” (which conveniently never includes your own architectural decisions from last quarter).

But let’s be honest.

You’re not chasing improvements. You’re running from stasis.

Because rewrites feel clean.
Because new tech means no legacy, no baggage, no awkward decisions to explain.
Because saying “React Server Components” in a meeting feels safer than saying “I don’t know if our architecture actually matches our product goals.”

You’re not optimizing for clarity.
You’re optimizing for control.

And deep down, you know it.
That it’s not a pragmatic suggestion - it’s a rewrite poltergeist that lives in the CI/CD pipeline and feeds on certainty.

The Shiny Spiral

Here’s how it happens.

You “just want to explore.” Innocent enough. So you spin up a proof of concept.
Then you realize it could replace the current system.
And now you’re three weeks in, maintaining two architectures, and using phrases like “interim dual-path strategy” or “legacy fallback” to avoid saying “I couldn’t let go of my POC and now we’re stuck supporting two realities.”

You start pitching the new stack like it’s a rescue mission:

“It’s so much more elegant.”
“It’ll reduce long-term complexity.”
“I mean, the old one was duct tape anyway…”

Sure. But it worked. And duct tape has held more systems together than most engineers care to admit.

This isn’t simplification.

It’s sophistication theater. - a show where everything looks impressive, but nobody knows what the plot is.

A whole production designed to make you feel clever, while quietly setting the team back two quarters.

And for what?
A 2% latency improvement?
A new ORM that supports emoji-based migrations?

Or maybe - just maybe - you’re using shiny tech to avoid the actually hard problems:

Legacy decisions that no one wants to revisit.
Teams that don’t align on priorities.
Process debt so entrenched you’ve stopped seeing it.

But hey, tell yourself it’s about clean APIs if that helps you sleep.

Real Growth Isn’t Always a Rewrite

Here’s a hard truth: being a senior engineer often looks a lot like doing the boring thing, well.

Writing one more test instead of chasing one more tool.
Refactoring the tangled function instead of replacing the whole module.
Teaching someone how the system works instead of quietly plotting to replace it.

Growth isn’t “rebuild it in the hot new stack.”
It’s asking, “What’s actually needed here?” and being brave enough to sit with the boring answer.

Sometimes the most senior move in the room is leaving it alone.

Not because you’re lazy.
Because you’re clear on the cost.

Pause, Then Pick It Up

Before you pitch your Next Big Tech Pivot, hit pause. Ask yourself:

1. What’s actually broken?

Is there a real bottleneck? Or are you just allergic to the phrase “works fine”?

2. If this tool weren’t new, would I still care?
Would you be evangelizing it if it came out in 2012 and had a logo that looked like a dentist’s office?

3. What happens if we don’t change anything?
Do we collapse? Or do we just keep delivering features in a boring, predictable way?

Spoiler: that last one is called stability. And it’s underrated.

Sometimes the bravest thing you can do as an engineer is refuse the rewrite.

Or better yet—submit a PR that renames the 10-year-old variable called doStuff() to something someone can actually read.

No fanfare. No talk. Just better code.

Your Stack Won’t Save You

Here’s the gut punch:
Your tech stack is not your legacy. Your behavior is.

Nobody remembers the stack you fought to implement.
They remember whether it helped them—or made things harder after you left.

So if you’re tempted to rip things up and start fresh, ask yourself:

Am I solving a problem, or avoiding one?
Am I improving the system, or distracting myself from harder work?
Am I chasing clarity, or just chasing dopamine?

Because the best engineers don’t need to chase shiny things.
They know how to make the dull ones sharper.

So maybe this sprint, don’t fly off with the glimmering tool you saw on HN.
Maybe just help your team ship clean code that doesn’t hurt to look at.

You’re not a crow.

And your roadmap’s not a perch.