DEV Community: Adam - The Developer ✨

My favorite article of the week. for someone who's where he is today by breaking things, painfully manually writing CRUD apps and having no choice but to learn how to read people's code, this hits too close to home.

Adam - The Developer ✨ — Wed, 29 Jul 2026 16:12:45 +0000

Deletes the career ladder

Nazar Boyko

Jul 27

The Junior Developer Pipeline Is Broken... And AI Broke It

#discuss #ai #career #programming

258

205

9 min read

Understanding Over Origin

Adam - The Developer ✨ — Tue, 28 Jul 2026 09:36:21 +0000

Many of developers communities are asking the wrong question.

Not because they're wrong to worry about low-effort work, no, but the filter they're using doesn't actually separate maintained engineering from generated slop. It just separates projects based on which tools were involved in their creation.

Imagine trying to share a work that you're really proud of, with the help of AI assisting it, the idea's yours but your work gets flagged, rejected, or buried under comments like "no you didn't" and "I hate how there's so many AI projects these days." Someone definitely felt righteous after saying this, believing they're protecting themselves from low-effort slop.

Except that's not actually what they're protecting against. They're protecting against a label.

The Distinction

I read @madsendev 's article regarding Open Vectorizer and Madsen wants to share the project with other people and in hope that someone would like to contribute as well.

Apparently, difference between "AI-generated" and "maintained engineering" has become invisible to gatekeepers who've simplified the filter down to a single binary question.

the wrong question.

" AI or no AI "? ( they didn't literally ask this but that's the filter in practice )

Here's why: imagine two projects.

Project A: Someone spends two years redesigning a vectorization algorithm, investigates whether machine learning could improve it, decides against it, implements a deterministic approach, discovers their own benchmark was inflated (and fixes it anyway), publishes reproducible results, and actively maintains the code.

Project B: Someone types "make me a music streaming app" into an AI prompt, publishes whatever emerges without testing it, and disappears.

Both used AI. Both are labeled "AI-generated." One belongs in a developer community. The other is exactly what communities should be filtering out.

Guess which one gets rejected? yah, both get rejected. The luckiest you can get is being rejected later because the gatekeeper was busy arguing with you and changing their community name to: " i miss what was it like to program on punch cards and a ciggy in my mouth " ahhh yes, the identity crisis.

The Problem With Using "AI-Generated" as a Quality Filter

The gatekeeping argument seems reasonable at first glance. But it has real problems:

The dismissal: "no you didn't (via @deammer). This response requires ignoring the actual technical work, but Madsen rewrote an entire algorithm pipeline, tested it against established tools, and caught a bug that made his own benchmarks look better, then published the worse numbers anyway. That's not someone slapping a prompt onto Claude and calling it a day.

The broader concern: @blakebeckcoding points out something real, unvetted AI-generated code has introduced security vulnerabilities. That's a legitimate worry about maintainability and accountability. Where the argument breaks down is treating that as sufficient reason to reject every AI-assisted project before evaluating its technical merits. The concern about low-quality code is valid. The heuristic of "reject based on tool choice" doesn't actually address it.

Think of it differently: we don't reject all Rust packages because Rust makes memory safety easier, nor do we assume all C projects are insecure because C makes memory errors possible. Language choice affects probabilities, but it doesn't determine quality. The same applies to AI.

The nostalgia play: "Dev.to used to be good" (same dude, you know who, bro's just nostalgic). There's an assumption that developer communities were higher-quality before AI tooling arrived. But humans have been publishing terrible code since the 1980s, spamming them has always been a problem and it isn't new, AI just makes it easier and cheaper to spam.

The Real Problem (And Why It Requires Actual Work)

Developer communities are being flooded and it's not the AI-generated projects specifically but low-effort projects, period. and like I said up there, the flood's rising fast at an overwhelming rate because AI made it cheaper to produce them.

The solution, though? It's not "ban the AI ones."

It's understanding what actually separates signal from noise:

Can the maintainer explain the architecture, or does it sound like they're reading stack overflow?
Are there meaningful tests?
Can claims be independently reproduced?
Are benchmarks transparent?
Are weaknesses disclosed?
Does the maintainer actually review changes and take responsibility?
Will this be maintained in six months, or is it a one-off lab experiment?

These questions work equally well for human-written code. And they're expensive to verify, they require actual reading, thinking, and judgment.

"Was AI used?" is cheap. One checkbox. Feels principled. Lets moderators move on.

"Is this maintained engineering?" requires actually engaging with the work.

The Pointed Out Irony

In the comment thread, @unitbuilds delivered the most sensible take on all of this:

"Software development is an orchestration process where the ultimate value is the working, audited, and tested software—not just human typing time."

And then:

"If that's the kind of comments you leave, go to X and join the cesspool, or Reddit, they'll love you there. Please keep Dev.to a safe space for all developers."

hits good, doesn't it? it's not defending AI in the abstract. It's defending communities staying communities, places where people can share work and get feedback, not face purity tests based on which tools they used.

The person who said they used 99% AI to ship a 3000-line game while working full-time deserves to share that. So does someone who used GitHub Copilot for routine completions. So does the Open Vectorizer author who made architectural decisions with AI assistance but wouldn't ship something they couldn't explain.

What none of them deserve is dismissal based on a label that tells you nothing about the quality of the work.

The Historical Perspective

This is something that might seem beside the point but isn't: software development has always worked this way.

We moved from assembly to C and nobody said "You didn't really code because you're using a compiler." We moved from manual memory management to garbage collection. From raw SQL to ORMs. From writing Dockerfiles by hand to templates. From Stack Overflow copy-paste to IDE refactoring to GitHub Copilot autocomplete.

Each step increased abstraction. Each step generated concern that developers were getting lazy, that standards were dropping, that the craft was being diluted.

Each time, the question that actually mattered wasn't "What abstraction level did you use?" It was "Do you understand what was generated? Can you defend it? Will you maintain it?"

That's been the real standard all along.

AI is just the next step on that continuum. It's more aggressive, more visible, and it generates more mediocre output faster. But it's not fundamentally different from any other tool that lets developers offload rote work to focus on decisions that matter.

The question isn't whether AI should be accepted.

In short, people have been saying software development is dead since the first high level programming language was invented... just, circling around the same anxiety cycle over and over.

The Good Moderation Requirements

no, it's not "open the floodgates." it's about what you're really filtering

Good moderation would:

Require disclosure of substantial AI involvement (transparency matters)
Judge projects on reproducibility, test coverage, and maintainer accountability
Fast-track projects with public benchmarks or active bug resolution
Catch obvious slop by its lack of depth, not its origin story
Create space for people who are learning while filtering out low-effort republishing

Bad moderation does what's happening now:

Blanket bans that assume all AI-assisted work is equivalent to prompt-and-publish
Dismissive comments that never engage with technical substance
Rejection based on the presence of a tool, not the absence of rigor

DEV's shift toward requiring disclosure rather than banning AI-assisted content is great. It puts the burden on the creator to be honest, then lets the community decide based on the actual work.

What Actually Matters

@unitbuilds had it right: a developer community's job is to share work and get substantive feedback, not police the method.

The questions that separate good engineering from slop are straightforward:

Can you explain the architectural decisions?
What broke, and how did you fix it?
Are benchmarks reproducible?
Will you maintain this?
Are you willing to be corrected?

They work regardless of whether code was typed by a human, generated by Claude, or mixed. Because they're about understanding and accountability - what has always determined quality.

Engineering should be evaluated on understanding, correctness, maintainability, testing, and accountability. Not keystrokes.

The World's Oldest Communication Protocol Is Music

Adam - The Developer ✨ — Fri, 24 Jul 2026 03:52:53 +0000

This is going to be a very different article from what I usually write. No technical discussions, architecture deep dives, or engineering practices today. Instead, we're talking about something much older than software itself: music.

We treat language like it's the default mode of human communication, like it's the real and only thing used to communicate, everything else is secondary, emotional, aesthetic, nice to have.

But language is actually the outlier. It's the new protocol layered on top of something much older.

Music is the original standard and we've basically forgotten how to read it.

The Protocol Stack

Think of communication like a network stack. Language is high-level. It's TCP/IP. Built on assumptions, needs learning, breaks the second you cross a boundary. You need:

A shared vocabulary
Syntactic understanding
Cultural context
Years of study if you actually want fluency

It's powerful but It's also fragile. And it's recent.

Written language is a few thousand years old. Spoken language is older, sure, but both are late abstractions compared to the hundreds of thousands of years humans have been syncing bodies to shared sound. Relative to that timeline? Language is yesterday's patch.

Music? That's the lower-level protocol. The physical layer everything else runs on.

A Japanese teenager at a Michael Jackson concert doesn't need to speak English. She doesn't need to understand what "Man in the Mirror" means as a concept. She also doesn't need a music degree.

Music isn't zero-cost. Genre, culture, convention still shape how we hear it. But the entry barrier for emotional communication is way lower. A rhythm can hit urgency, celebration, sadness, or tension long before anyone understands the formal structure behind it.

Her nervous system speaks that fluently. And so does everyone else in that stadium.

How the Protocol Works

Here's what happens when the song starts: 70,000 people stop being individuals and start being a distributed system synchronizing to the same signal.

The bass hits. Her heartbeat starts matching it. Involuntarily. Her neurons fire in sync with the guy three rows over. The girl next to her moves when the rhythm says move — not because she decided to, but because the protocol sits lower than conscious decision-making.

This isn't mystical. This isn't the "universal language of music" in the poetic sense. This is just biology.

Babies respond to rhythm before they understand words. Crowds clap together without a conductor. Soldiers march to drums. Rituals across cultures use singing and percussion to pull a group into the same tempo. The pattern shows up everywhere because the hardware is shared.

The protocol specs, if we're being nerdy about it:

Uses mostly rhythm, tempo, and frequency
Hits the nervous system, not the cognitive layer
Needs way less shared context than language
Backward compatible across human brains for 300,000+ years
Works at scale (70,000 synchronizations at once)

Language, meanwhile:

Preprocessing (learning)
Translation (if you're cross-language)
Cognitive overhead (your brain has to think)
High latency (meaning takes time)

Music? Low preprocessing. No translation step. Near-zero latency. Your body gets the signal before your mind finishes negotiating what it means.

Why We Don't See This

We're obsessed with meaning. We assume communication = transfer of semantic content. You encode an idea into words, I decode it, boom: we've connected.

So when we see that girl screaming English lyrics she doesn't understand, we quietly reframe it. "Oh, the message transcends language. She understands on a deeper level."

Nah. She's not understanding the message at all. She's on a different protocol entirely. Language is offline. The lower-level stuff is handling it.

We miss this because we've built an entire civilization on top of language. We think the higher-level protocol is the "real" one. Which is like saying TCP/IP is more real than the electrical signals it runs on.

Music isn't poetry. It isn't transcendence. It's infrastructure. It's what everything else runs on.

And no, it's not better than language. It solves a different problem. Music synchronizes systems. Language coordinates them.

A drumbeat can make people march together. It won't tell them why they're marching, what they believe, or what to do when the song ends. Language is powerful because it encodes abstractions. Music is powerful because it doesn't need to.

The Uncomfortable Part

Here's the part that gets weird: you can sync humans at massive scale without them sharing any values, beliefs, or understanding.

That stadium full of people moving together? They don't agree on anything. They might hate each other politically. They might speak no common language. They might have zero common ground.

But for three minutes, their nervous systems are linked. That's a connection. Just not the kind we like to talk about.

We want connection to require understanding. We want it to mean something. We want it to prove that underneath all our differences, we're fundamentally united in shared meaning.

What music actually shows us is simpler and weirder: humans are pattern-matching machines wired to sync with other humans. You don't need shared values for that. You don't need agreement. You don't need understanding.

You just need a rhythm everyone can feel.

What This Means

Language will always need translation and will always be high-friction, high-latency, high-failure-rate across boundaries and... that's not a bug, it's what gives it power, precision requires friction.

But for raw synchronization, getting lots of humans moving together, feeling together, breathing together, language is overkill. Also unreliable.

Music is the protocol that works when nothing else does.

An orchestra where nobody shares a language. A protest with thousands of strangers chanting. A stadium of people from different countries, different beliefs, different everything, all moving as one.

These aren't examples of music "transcending barriers." They're examples of a lower-level protocol just... working, while the higher-level ones fail.

We've built everything on top of language. We've made it the primary. And we've kind of forgotten what it's sitting on.

Language lets us share thoughts. Music lets us share states.

And every time a girl who doesn't speak English screams an English song in perfect sync with 70,000 other people, she's reminding us: the infrastructure was always there. We just stopped noticing it.

The oldest communication protocol is still the most reliable one. We just got distracted by the newer layers.

And sooooo, Here's my favorite song of the week

✨🎶 Love Hurts — Nazareth

Drop your favorite music down below, let's hear what gets your system in sync!

Stop Saying You Want Ownership Mindset

Adam - The Developer ✨ — Tue, 14 Jul 2026 05:59:52 +0000

My 2nd article this week, I'm supposed to keep it to just once per week but whateverrr, I've had this in drafts for a while now, let's get straight into it.

Here's the thing about "ownership mindset" that nobody on the management side wants to admit: you love the slogan. You hate the behavior.

You want engineers who care. Who think about scale. Who ask "wait, will this melt in four months?" Who treat the product like it's theirs.

Cool. Then someone actually does that in a meeting, and suddenly they're "being difficult," "not a team player," "too negative," or my personal favorite — "can you just build what I asked for?"

I've sat through this movie enough times that I can recite the script.

The Script

Manager / PM / whoever is currently wearing the "decider" hat:

We need someone with real ownership on this. Someone who cares whether the product actually works.

Someone raises a real concern about the architecture. Not vibes. Constraints. Data model. Failure modes. The stuff that will wake someone up at in the middle of the night later.

Same person, 90 seconds later:

Why are you pushing back so hard? Why are you being so difficult? We're already behind. Just ship it.

So which is it?

You asked for ownership. They gave you ownership. Now you're mad that ownership came with opinions.

You're Not Confused. You're Convenient.

I used to think this was a communication problem. It's not. It's incentives.

You feel the delay today. You don't feel the outage later. Design pushback slows the thing you want shipped this sprint. The mess it prevents shows up next quarter, under someone else's KPI. Of course you optimize for the pain that's in the room.

Hierarchy feels like efficiency when you're on top of it. A senior decision getting questioned doesn't feel like engineering. It feels like disrespect. Even when the question is "this will corrupt data under concurrent writes." You wanted a yes. You got a reason. Those feel different to the ego.

Compliance feels like progress. An engineer saying "yeah, I'll build it" gives you a hit of motion. An engineer saying "we should rethink the data model" feels like friction. Your brain does lazy math: less friction = better leadership. No. Less friction = quieter failure.

And "ownership" means two different things depending on who's talking. When you say it, you often mean "make sure it ships and don't bother me." When I hear it, I mean "make sure it doesn't screw us." Those conflict. You keep using the same word like that's my problem.

The Quiet Engineer Is Not Owning Anything

Here's the part that should piss you off more than it does: the engineer who just implements what you ask, every time, with a smile, is not demonstrating ownership.

They're optimizing for approval.
They're minimizing confrontation.
They're following orders.

None of that is ownership. That's liability transfer.

When it breaks, they've got the perfect line: "I built exactly what was specified." Clean hands. Diffused responsibility. You got the compliant builder you rewarded.

The person who says "this is going to bite us" is the one actually treating the outcome like theirs. They're spending social capital in a room that usually punishes that spend. If you punish them, don't act shocked when the next three people learn to shut up.

What Ownership Actually Looks Like From Our Side

It's not being a dick in design reviews. It's this:

Concerns come early. During design. Not three weeks into implementation when changing direction costs a sprint and a relationship.

Reasoning, not vibes. "This N+1 dies at 10k users on our current growth curve" beats "this feels off." If an engineer can't explain the failure mode, push back. If they can — listen.

Alternatives, not just no. "What if we index on user_id?" is ownership. "This won't work, good luck" is theater.

Knowing when to escalate vs. when to build-and-learn. Sometimes you need to ship something imperfect to learn. Sometimes you're walking into a known footgun. A good owner can tell you which meeting you're in.

Staying for the outcome. "I told you so" is not ownership. Owning it means if you were wrong, you help clean it up. If you were right and ignored, you still help clean it up — and you remember who ignored you.

What You Get When You Train That Out of People

I've watched this culture settle in. It's not subtle.

Engineers who optimize for "not getting blamed" instead of "building something that lasts"
Debt that accumulates in silence because speaking up is career-limiting
Smart people quietly updating their LinkedIn
Meltdowns that somehow still surprise leadership
"Team player" becoming code for "doesn't question bad decisions"

You buy short-term speed. You pay medium-term chaos. Then you schedule a retrospective where everyone agrees "we should have spoken up earlier," and nobody asks why they stopped.

If You Actually Want It

Stop asking for ownership like it's a personality trait. Build the conditions where it's safe to exercise.

Separate design talk from implementation talk. Let people think out loud about whether something will work before you've already committed the sprint. Thinking hard and shipping fast aren't enemies. Collapsing them into one meeting is.

Reward the pushback you say you want. If someone raised a legitimate concern and you overrode them, make that a visible decision. Don't pretend the conversation didn't happen. If they were right later, say so. Out loud. In front of people. If they were wrong, they learn the domain. Either way, the signal is: speaking up was the job.

Be specific. "Take ownership" is useless. Do you mean "ship this by Friday even if it's dirty"? Then say that. Do you mean "this has to survive 10x traffic"? Say that. Vague slogans produce people guessing what will get them yelled at least.

Listen when we push back. Not because we're always right — we're not. Because we live in the codebase you only see through tickets. That's not attitude. That's the job you hired us for.

Normalize disagreement. The best teams I've been on argue about design and still trust each other the next morning. Disagreement isn't personal. Making it personal is how you get yes-men and broken systems.

Bottom Line

You probably do want engineers with an ownership mindset.

What you don't want, and keep accidentally selecting for, is engineers who smile, implement, and let you walk into the wall so they can stay popular.

Ownership is annoying. It asks inconvenient questions. It slows the "just ship it" meeting. It makes seniors defend decisions they wanted to treat as settled.

If that sounds exhausting, good. That's the cost of building something that doesn't fall apart the second real users touch it.

You don't get "people who care" and "people who never push back." Pick one.

And if you pick compliance, at least stop calling it ownership. That word still means something to the rest of us.

I Could Review It. I Couldn’t Write It.

Adam - The Developer ✨ — Mon, 13 Jul 2026 07:52:12 +0000

...now, I pride myself on being good at my job, I'm fast at catching mistakes, I'm efficient at reviewing code and I'm quick to spot patterns across systems. But ever since I knew how to use AI ( maybe around mid 2024, I was still doing the old trad way when i started in 2018 ), I've been letting AI write ALOT of my code.

And I thought I was still learning.

Then one day I sat down to write an HTTP handler in Go from scratch, and I froze... and I can't describe how scary this was.

Not because I don't understand HTTP or because I don't know Go because I recognize these patterns instantly:

func (s *Server) handleJobNext(w http.ResponseWriter, r *http.Request) {
    // ...
}

I can review it, spot mistakes, discuss the design. But build it from scratch? I found myself thinking: "Wait... is it http.HandleFunc? ServeMux? How do I start the server?"

That's when I realized something was wrong, I realized the trap I'd fallen into and I had to do something about it.

Recognition is not Production

This biggest illusion that AI makes much easier to fall into is the thinking that goes:

"I understand this" and it feels exactly like "I can produce this."

I also wanna clarify that AI isn't the first one to inven this problem, Stack Overflow, copy-pasted frameworks and tutorials all created it first and AI's just accelarating the distance.

Recognizing a solution is just one skill. Your brain does pattern matching beautifully and way effortlessly than you think once you get used to it, you see http.HandleFunc, think "yep, that's how you register routes," and feel confident.But try retriving that knowledge from scratch, constructing it... that's a whole other level, those are completely different neural pathways because the ability to review code, design & architecture aren't the same as writing it from memory and it should never be mistaken.

I got really good at reviewing, too good I guess, I am fast & efficient, I could critique architecture, spot edge cases, ask the right questions and basically start a whole drunken bar vibe conversation with it but you know what scares me despite being able to do all of this? I couldn't write an HTTP handler from memory.

I WAS practicing some skills. just some. just not the ones I thought.

The Gap and I Started A Series

There's also a dangerous confidence trap here: convincing yourself you're still learning because you're the "architect" or "reviewer", you're making decisions, you understand the system.

But how would you feel if knowing you can't write what the AI wrote, not without looking. that's the gap.

Anyway, a few months ago, I started writing distributed systems algorithms in Go from scratch, each algorithm belonging to their own repo. No AI. I write entirely, then ask it to review and I tell you it's very rewarding!

I am doing the series for 2 reasons:

This will help me strengthen my skill in Go, I love Go but it's also the least used language of mine too but a very important one.
I hope to help others understand algorithms in distributed systems where it's written with as much as simplicity as I could but also not leaving out edge cases and failure modes. Many developers work with one unknowingly and wonder why their simple code causes data corruption as soon as someone adds another instance of the backend.

I will be releasing the article one by one each after I'm done where I will document every hell and tasmanian devil I would've had gone through, no filters with the exception of bad languages.

You Can't Download Experience

Great software doesn't come from perfect code, It comes from surviving bad code.

Engineering intuition is built from mistakes, failed designs, debugging at 2 AM, edge cases that shouldn't exist, trade-offs that haunt you for years. The final code is just the artifact. The scar tissue is the education.

Take a system like PostgreSQL represents decades of accumulated engineering decisions.

I'm picking on Postgres specifically because I saw someone tried to rewrite Postgres with Rust nearly entirely with agents. It's not a bad thing, in fact, it's improving Postgres tremendously: with Rust, it's moving from the historic process-per-connection to thread-per-connection, massive performance gain and some of the long-standing postgres pain points.

You can rewrite it. You can reproduce the behavior. But you won't reproduce the journey that created that understanding—the bugs fixed, the performance lessons learned, the constraints that forced particular designs.

Letting an agent write everything and you get the artifact without the scar tissue.

And expertise lives in the scar tissue.

The Real Principle

The skills you practice will grow. The skills you outsource will weaken.

I outsourced writing and my writing muscle atrophied. I got better at reviewing and architecture, but lost something important.

Now I'm deliberate: distributed systems algorithms in Go, I write. from scratch.

Not because I am better than AI but because I'm choosing which muscles to exercise and the choice matters.

What I'm Not Saying

AI is not bad. I use it daily. Heck, I still use it for work because businesses' deadlines now are unrealistic standards compared to what they were a few years ago.
Code review is still critical work.
AI is still my thinking partner and my force multiplier, I still consult it from time to time when making decisions, it builds me up and makes me a better developer and I make decisions faster because I'm not the only one thinking when no one's around.

What I'm saying is: Be intentional about which parts of expertise you allow to change.

Every tool reshapes what engineers need to know. The goal isn't to preserve manual typing forever. The goal is to ensure that the parts of engineering you want to own are still exercised by you.

If you want to stay sharp at writing, you have to pick code you're not going to outsource.

Because expertise follows exercise. Always.

The question isn't whether you can write without AI.

The question is: Will you?

You Never Eliminate a Bottleneck — You Just Move It

Adam - The Developer ✨ — Mon, 06 Jul 2026 09:59:27 +0000

I once spent quite some time optimizing a database query that was bringing our API to its knees. We shaved 200ms off response time with careful indexing and query rewriting. Success, right?

Wrong.

Within a week, a different bottleneck surfaced. The network became the constraint. We optimized that. Then client-side rendering became slow. Then memory usage spiked. Each "fix" just moved the problem downstream.

Eventually, I learned something that changed how I approach performance work: bottlenecks aren't anomalies to eliminate, they're laws of nature baked into how systems work.

Why Bottlenecks Are Inevitable

The Theory of Constraints

Every system has a weakest link. Think of water flowing through a pipeline, the narrowest section determines your throughput, no matter how wide the rest of the pipe is.

Software systems work the same way. At any given moment, something is the binding constraint:

Is it the CPU?
The database?
Network latency?
Disk I/O?
Memory?

When you optimize that constraint, you don't eliminate constraints altogether. The constraint simply moves to the next-slowest component. The system's total throughput increases, but a new bottleneck emerges.

Amdahl's Law: The Math That Proves It

Even with infinite parallelization, there's a mathematical ceiling. Amdahl's Law tells us:

If just 10% of your code runs sequentially, you can never speed up more than 10x—no matter if you have 1,000 CPUs. That sequential 10% becomes an eternal bottleneck.

For our social media app, some processes must happen in order:

Authenticate user
Fetch permissions
Then fetch feed

You can't parallelize that without breaking safety. So authentication becomes a permanent bottleneck, though a small one.

The Great Trade-Off Game

Here's the dirty secret: optimizing for one thing almost always hurts something else. You're not solving problems; you're choosing which constraint to live with.

Optimize For	What Improves	What Gets Worse
Latency	Fast responses	CPU/memory usage spikes
Throughput	More requests/sec	Resource exhaustion
Cost	Cheaper infrastructure	Performance degrades
Consistency	Strong guarantees	Write latency increases
Availability	Always online	Coordination overhead explodes

Pick one. You're implicitly de-prioritizing others.

Example: The Classic API Scaling

Let's say I worked on an API that handled 10 requests/second. Bottleneck? The database.

We added caching.

Now: 100 requests/second. Bottleneck? Memory, our cache grew too big.

We sharded the cache.

Now: 500 requests/second. Bottleneck? Network bandwidth between nodes.

We optimized serialization.

Now: 1,000 requests/second. Bottleneck? Client-side parsing of responses.

We gzipped responses.

Now: 2,000 requests/second. Bottleneck? The upstream service that feeds our API.

At each step, we "solved" the problem. But we never eliminated bottlenecks—we choreographed a dance, moving them from place to place.

Distributed Systems Make It Worse

In a distributed system, bottlenecks hide in shadows and move in unpredictable ways:

Network RTT (round-trip time) is a physical law. You can't send data faster than light travels. For a global system, that's roughly 50-150ms of minimum latency per hop. Every extra network call multiplies this cost.

Leader election is expensive. When a leader fails in your distributed system, electing a new one takes time. During that window, writes are blocked. The leader election itself becomes the bottleneck.

Quorum writes create coordination overhead. To ensure consistency across replicas, you need a quorum (majority) to acknowledge a write. That coordination, waiting for responses from multiple nodes, is itself a bottleneck that throttles your write throughput.

Hot partitions kill performance. If all your traffic hits one partition (shard) of data, that partition becomes the bottleneck. You optimized everywhere else, but one hot partition brings the whole system down.

Cross-region latency compounds. Replicate data to multiple regions for resilience? Now reads and writes must cross regions. A single cross-region call might be 100ms. Add three of them together? You've hit a bottleneck that optimization can't touch.

Fan-out requests multiply latency. Your service calls 10 microservices in parallel. The slowest one determines your response time. You optimize 9 of them, but the 10th — now that's your bottleneck.

There is no way around these trade-offs. They're mathematical, physical. Bottlenecks in distributed systems aren't bugs, they're features of reality.

The Practical Mindset Shift

The question shouldn't be: "How do I eliminate bottlenecks?"

It should be: "Which bottleneck am I willing to live with, and how do I make sure it's the right one?"

Actionable practices:

1. Profile first, optimize later
Use a profiler. Find the actual bottleneck, not the one you think exists. 90% of optimization effort goes to wrong places because developers guess.

2. Optimize strategically
Focus on the binding constraint. Optimizing something that's 5% of your runtime is pointless if the database is 80% of your runtime.

3. Plan for the next bottleneck
When you fix something, ask: "What becomes slow now?" You can't prevent it, but you can prepare.

4. Make trade-offs consciously
Don't accidentally sacrifice something important. If you add aggressive caching, you're choosing performance over freshness. Make sure that's actually what you want.

5. Accept limits gracefully
Some bottlenecks are laws of physics (network latency, disk I/O). Design around them instead of fighting them. Use caching for latency. Use batching for throughput.

The Bottom Line

Some of the best engineers I know aren't the ones who "eliminate" bottlenecks. They're the ones who:

Understand where bottlenecks live
Move them strategically
Stay ahead of the game by anticipating the next constraint
Optimize for what actually matters (user experience, cost, reliability)

Your job isn't to break the laws of systems theory. It's to work within them intelligently.

The bottleneck never disappears. You just get better at dancing around it.

The Illusion of the Clean Slate

Adam - The Developer ✨ — Tue, 30 Jun 2026 06:28:20 +0000

Every engineer has fantasized about it: starting over. Throwing out the old system and building something clean. No legacy constraints. No accumulated compromises. Just pure, intentional design.

It never works that way.

You can delete all the code. You can architect from scratch. You can make the best technical decisions possible. But you can't delete the organizational memory. You can't unlearn what the last system taught you. You can't escape the patterns that already run through the business, the workflows people have shaped themselves around, the problems you've already paid the cost of understanding.

The new system will look clean. But it will be haunted.

What rewrites actually inherit

A rewrite isn't a fresh start. It's archaeology pretending to be innovation.

The constraints don't go away. The old system wasn't overcomplicated because engineers were bad. It was overcomplicated because of customer requirements, regulatory expectations, performance demands, and edge cases that took years to discover. A fresh rewrite finds all those edge cases again. Slower this time, because you don't have documentation—you have broken customers and escalations. The system gets layers of protection again, but now it looks like paranoia instead of learned caution.

The organizational memory becomes invisible. Someone fought for that data model three years ago. There was a reason. A business rule that couldn't be violated. A data consistency requirement that cost a quarter to figure out. The new system doesn't have the battle scars that explain why things are the way they are. So they get rebuilt differently, until they hit the same requirement at 2am on a Saturday.

The workflow is already baked in. Users have shaped their behavior around the old system. Sales has built their pitch around certain capabilities. Support has written documentation and runbooks. Customers have automation that depends on specific behaviors. The new system is technically cleaner, but it forces change on everyone else first. The rewrite isn't done until the new system works like the old one.

The code patterns stick around. Teams find themselves solving the same problems the same ways. Not because the architecture forces it, but because it's familiar. Because there's institutional knowledge about how to do X in a way that doesn't break. Because someone senior knows the pitfalls. The "clean" codebase starts looking like the old one within six months, just with better error handling.

The ghost of the old system

sometimes the best decision in a rewrite is to do it exactly like the previous system.

Not because the old code was good. But because a lot of people understand it. The business logic is tested by production. The failure modes are known. The performance characteristics are predictable. Starting fresh means starting ignorant, and ignorance costs money.

A truly clean slate would require starting ignorant and willing to pay the cost of ignorance. Most organizations can't afford that. So the rewrite becomes "the old thing, but better implemented"—which is fine, maybe even better, but it's not what anyone was imagining when they said "let's start over."

The ghost isn't a bad thing. It's just unavoidable. Organizations have memory whether they codify it or not. That memory shapes everything built inside them, even when you're trying to escape it.

Why this matters

Understanding this changes how you approach a rewrite. You're not escaping the past. You're translating it.

The best rewrites don't pretend to be clean slates. They acknowledge what they're inheriting. They talk to users about why the old system worked the way it did. They preserve the tacit knowledge that's been learned the hard way. They choose: what patterns do we keep because they're actually good, versus what patterns do we change because we have time to do it right.

The worst rewrites assume they're smarter than everyone who came before. They rebuild against the patterns of the old system instead of with understanding of them. They rediscover the same edge cases as new bugs instead of as features. They become legacy before they're finished.

A rewrite isn't a clean slate. It's a translation. And translation is hard because you have to understand both languages, the constraints of the old world and the possibilities of the new one. You have to honor what worked without being trapped by it.

The fantasy of the clean slate is tempting because it promises escape. But the only way to actually learn something is to carry it forward, consciously, even when you're trying to leave it behind.

Conduit: The Gateway I Built to Forget About

Adam - The Developer ✨ — Wed, 24 Jun 2026 07:37:59 +0000

I've been trying to keep my publishing schedule to one article a week, but this one felt too special to wait so I had Claude helping me generate a portion of this so I can publish it quick.

The article today might be a little boring depending on how much you're into systems and distributed architecture. And if you're already thinking, "Great, another API gateway," I can't really blame you.

But bear with me for a bit: Conduit isn't just another request-forwarding proxy. Along the way, we'll dive into programmable gateways, sandboxed runtimes, Unix sockets, and some of the engineering decisions that made building it surprisingly fun.

TL;DR

Built a small Go API gateway in front of three services with two different auth schemes (custom HMAC sessions, and JWT).
It worked. It also became unmaintainable: every routing exception meant editing Go and redeploying.
Rewrote it as Conduit: Go stays on the network path (routing, proxying, CORS, SSRF guards). A sandboxed Deno runtime runs policy as plain TypeScript plugins, talking to Go over a Unix socket with a strict snapshot-and-patch protocol.
Net result: auth, logging, and routing rules became files I could edit and save, no recompiling the gateway.
Full FAQ/defense-of-design-decisions Q&A is here, not in this post.

The setup

Three services, one public API:

chat-service: real-time messaging
user-service: profiles, sessions, identity
admin-service: internal tooling, elevated operations

User and chat traffic ran a custom session + HMAC scheme: Authorization: Session <id>, signed with X-Signature, X-Timestamp, X-Nonce, backed by Redis for sessions and replay protection. Not JWT. Not OAuth. Something built and iterated on for months.

Admin traffic was JWT, verified at the edge, then forwarded with trusted X-Gateway-Admin-* headers so the admin service skipped re-validation.

Different trust models. Different header shapes. Different public-path exceptions. All of it had to land on one hostname, because clients don't care how many services you run behind it.

So I built the obvious thing: a small Go gateway. Service-prefixed paths picked the upstream. A route.Select() function picked the auth mode. A growing stack of prefix conditionals decided which paths were public:

/admin-service/*  → admin upstream   + JWT (except login, refresh, external-api)
/user-service/*   → user upstream    + HMAC (except auth, device, internal, …)
/chat-service/*   → chat upstream    + HMAC for users, JWT for /api/v1/admin/*

It shipped. It worked. It was ugly.

Where the ugliness actually lived

Not in reliability. Requests hit the right upstream, JWT/HMAC validation worked, sessions slid TTL correctly. The ugliness was in extensibility:

res := route.Select(r.URL.Path)
proxy := proxies[res.Backend]
h, ok := applyAuth(w, res.Auth, cfg, sessionStore, nonceStore, proxy)
h.ServeHTTP(w, r)

Clean on paper. But adminAuth(), userAuth(), and chatAuth() were each a wall of strings.HasPrefix branches, each one carrying tribal knowledge about which paths were exceptions. Every new public-path exception meant editing Go and redeploying the gateway. Figuring out why a path behaved a certain way meant reading three functions and cross-referencing a README the size of a small service.

I wasn't failing at microservices. I was failing at boundary discipline: policy had nowhere clean to live except deeper inside the gateway's Go source.

Every new exception made the gateway more specific instead of more general.

That gateway didn't get thrown away. It proved the routing model was right. It just proved the implementation model needed to change. That became Conduit.

Design goals (the actual constraints, not aspirations)

1. Freedom of implementation. If you can write TypeScript, you can extend the gateway. No DSL, no Lua config, no plugin marketplace format: drop a file in ./plugins, export an object with lifecycle hooks:

import type { GatewayContext } from "../runtime/shared/types.ts";

export default {
  beforeRequest(ctx: GatewayContext): void {
    if (!ctx.request?.headers?.Authorization) {
      ctx.reject!(401, "missing token");
    }
  },
};

2. Low operational overhead. No control plane, no Kubernetes requirement, no sidecar ceremony. Default setup is one Go binary supervising a Deno runtime, reading a JSON config:

go run ./cmd/conduit -config conduit.config.json

3. Explicit separation of concerns.

Layer	Responsibility
Go gateway	HTTP ingress, routing, upstream proxying, CORS, body limits, timeouts, SSRF guards
Deno runtime	Sandboxed plugin execution in a warm worker pool
Plugins	Business policy: auth, logging, transforms, route control

Go never gets to know about plugin internals. The runtime never owns routing. Plugins never touch the network boundary directly. These invariants are written down because violating them produces cross-language bugs that tests don't reliably catch.

4. Predictable failure modes. A misbehaving plugin shouldn't take down the gateway. Hook timeouts log and continue. Worker crashes replace the isolate, not the process. If the entire runtime is unreachable, failPolicy decides: closed (503, no proxy) or open (skip plugins, proxy anyway), configurable per route.

5. Invisible in production. The bar I actually cared about: deploy a plugin when policy changes, glance at structured logs when something's off, otherwise forget the thing exists.

Architecture: two processes, one socket

Per request:

Client hits the Go gateway.
CORS preflight (OPTIONS) is answered in Go; plugins never see it.
Go builds a serializable context snapshot from the request.
Every plugin's beforeRequest hook runs, in filename order.
Go proxies once to the matched (or plugin-selected) upstream.
The upstream response gets attached to context.
Every plugin's afterResponse hook runs, same order.
Go writes the response to the client.

Upstream services have zero awareness Conduit exists: no SDK, no self-registration. Multi-service routing is config, not code:

{
  "routes": [
    { "path": "/user-service/*",  "upstream": "http://user-service:2001" },
    { "path": "/admin-service/*", "upstream": "http://admin-service:2002" },
    { "path": "/chat-service/*",  "upstream": "http://chat-service:2003" }
  ]
}

One plugin chain, many backends, policy applied uniformly at the edge.

The actual hard part: getting context across the process boundary

The real problem with the first gateway wasn't routing logic. It was where state lived. Mutable request objects passed through middleware created hidden coupling, and that gets worse the moment you're crossing a process boundary: you cannot hand Deno a live http.Request and hope for the best.

Conduit's contract:

Go snapshots the request into serializable JSON.
The snapshot crosses a length-prefixed frame over a Unix socket to Deno.
The plugin operates on a cloned, hook-local context with a frozen inbound request.
The plugin returns a patch: a minimal delta, not a mutated object.

Why patch instead of full context on return: sending the complete context back from every hook means re-serializing headers, identity, and potentially large bodies, twice per request, per plugin. The patch engine instead sends only what changed: omitted fields are unchanged, present fields overwrite, null tombstones a deletion. A logging plugin that sets one state field ships a few dozen bytes back, not the whole request graph.

Why bodies never fully cross the wire: anything above 64 KiB stays in a per-request BodyStore in Go. Plugins get a stream:// reference token, not raw bytes. Megabytes stay in Go; metadata crosses the socket.

Plugins don't own the request. They propose changes to it.

That sentence is the whole design. Reject/forward signals, the patch diffing rules, the frozen snapshot: all of it exists to make "propose, don't own" safe and cheap.

The plugin model

Plugins stay deliberately small:

Hook	When
`onLoad`	Once at startup
`beforeRequest`	Before upstream proxying
`afterResponse`	After upstream response is captured
`onError`	When a hook in this plugin throws unexpectedly

ctx.reject() is intentional control flow, not an error; onError is for actual surprises.

Plugins load in filename order, full stop:

plugins/
  001-auth.ts           ← runs first
  002-logging.ts        ← sees ctx.user from auth
  003-header-rewrite.ts
  004-route-control.ts

No dependency graph, no hidden priority system. 001-auth.ts runs before 002-logging.ts because of the filename, and that's grep-able at 3am.

The ctx surface is narrow on purpose:

Member	Role
`ctx.request`	Read-only inbound snapshot
`ctx.response`	Outbound builder (`setStatus`, `setHeader`, `setBody`)
`ctx.user`	Identity set by auth plugins
`ctx.state`	Per-request key/value bag shared across hooks
`ctx.log`	Structured logging with trace correlation
`ctx.reject(status, msg)`	Stop pipeline, return HTTP error
`ctx.forward(url)`	Proxy to an alternate upstream (validated by the gateway)
`ctx.services`	Optional `http` and `cache` helpers

No global singletons, no ambient mutable request object. Auth sets ctx.user; logging reads it. That's the entire coordination contract.

What happened when I actually ran it

The first deployment was personal: three services behind one port, HMAC checks in one plugin file, JWT checks in another, logging in a third. The prefix-matching spaghetti became three files I could read top to bottom.

Then it spread quietly: internal tools needing a stable hostname, admin surfaces needing stricter gating, experimental routes I could add without redeploying backends.

The moment I knew it worked wasn't a benchmark. It was forgetting it was running, then stopping the Docker container to debug something unrelated and watching everything break. That's the success criterion I actually cared about: not feature parity with Kong, invisibility under normal operation.

Failure modes, stated plainly

Event	Behavior
Plugin hook exceeds timeout (default 100ms)	Warning logged; request continues proxying
Plugin worker crashes	Isolate replaced; gateway process survives
Entire Deno runtime unavailable	`failPolicy: "closed"` → 503; `"open"` → proxy without plugins
`ctx.reject(401)`	Pipeline stops; remaining hooks skipped
Invalid `ctx.forward()` target	Logged, ignored; original route used
Upstream failure	Standard `502` propagated

Hook timeout and runtime death are different failure classes on purpose. A slow logger shouldn't look like a dead security layer.

The riskiest failure mode isn't a crash, though. It's silent semantic change: a plugin that mis-sets ctx.user or swallows a header keeps the system at 200 OK while behavior quietly drifts underneath it. That's why every log line carries [trace:<id>], and why reject and thrown errors are treated as distinct signals.

What it's not

Not Envoy: no xDS, no WASM filter ecosystem at scale.
Not Kong: no admin UI, no plugin marketplace.
Not a service mesh.
Not for multi-gigabyte streaming responses. afterResponse buffers the body so plugins can inspect/rewrite it, which costs memory proportional to response size.

What it gains in exchange: a codebase readable in an afternoon, plugins you edit and save instead of recompile, no cloud dependency to define policy, and bounded IPC cost (one warm Unix socket, patches instead of full payloads, body references instead of raw bytes).

It's lean, not free. Four plugins across two phases is up to eight round trips per request. Sub-millisecond on a local socket. Wrong tool if you need per-byte stream processing at scale; right tool if you've got a handful of services, evolving edge policy, and a team that already writes TypeScript.

What stuck

Abstraction is only good if it disappears in daily use. The pieces that survived are the ones I stopped thinking about. The pieces that died were baked into Go: the adminAuth()/userAuth()/chatAuth() prefix ladders that worked fine until they needed to change without a redeploy.
Cross-process plugin systems are viable if state transfer is strict. Patches, body references, frozen snapshots. Not optimization trivia; the actual precondition for Go and Deno cooperating without shared-memory bugs.
Failure design shaped operability more than any plugin API did. failPolicy, hook timeouts, and the reject/onError split mattered more than feature count.
"Simple" means boundary discipline, not low line count. Go owns the network. Deno owns execution. Plugins own policy proposals. Upstream owns business logic. Nobody reaches across.

Closing

This wasn't built to be a product. It was a response to a system that stopped fitting in my head: three services, two auth models, one endpoint, and a gateway that grew a new strings.HasPrefix branch every time something shipped.

The goal was never to out-build Envoy or Kong. It was to build something I could forget existed until the day I needed to reason about it. At that point, reasoning about it should be easy: read the plugin files, read the config, follow one request through Go → IPC → Deno → upstream → back.

If you're standing where I was (auth diverging, routing logic leaking into every handler), you might not need another service. You might need a place where policy can live without infecting everything else.

Try it:

go run ./cmd/conduit -config conduit.config.json

export default {
  beforeRequest(ctx) { /* policy */ },
  afterResponse(ctx) { /* transforms */ },
};

Full design-decision Q&A (why Deno over Node/Lua/WASM, scaling, "when is this the wrong choice," etc.) is in my site, not here.

Thanks to Claude for helping with my wording, grammars...etc and it also added its own intro at the very top. I was so excited to share Conduit that I forgot to review it added a very LLM-generic intro for me that just got me flagged by Sloan.

When Software Started Writing Software: A Developer’s History of AI

Adam - The Developer ✨ — Mon, 22 Jun 2026 08:06:29 +0000

If you've shipped software in the last three years, you've probably watched your job description quietly rewrite itself. You went from writing code, to writing code with an autocomplete, to writing code with a collaborator, to increasingly writing a spec and watching an agent write, test, and ship the code for you.

That didn't happen overnight. It's the latest chapter in a 70-year story that started with researchers trying to teach machines to play checkers. Let's walk through it, not as a dry timeline, but as the story of how "intelligence" kept getting redefined every time machines got good at the last definition.

1. The Symbolic Era: Intelligence as Logic (1950s–1980s)
2. Statistics Quietly Eats Symbols (1990s–2000s)
3. Deep Learning Breaks the Ceiling (2012–2017)
4. The Transformer and the Birth of "General-ish" Intelligence (2017–2022)
5. From Chatbot to Coworker: The Agentic Turn (2023–Today)
So What Changed, Really?

1. The Symbolic Era: Intelligence as Logic (1950s–1980s)

The founding bet of AI, made official at the 1956 Dartmouth Workshop, was simple and audacious: thought is computation. If you could represent knowledge as symbols and rules, and manipulate those symbols correctly, you'd get intelligence.

This gave us:

Logic Theorist (1956): proved mathematical theorems by searching through logical statements.
ELIZA (1966): pattern-matched your sentences back at you and convinced people it understood them. The first chatbot, and the first time humans projected understanding onto a system that had none.
Expert systems (1970s–80s): programs like MYCIN encoded a domain expert's rules as IF-THEN statements. MYCIN could diagnose bacterial infections about as well as a human specialist, using a few hundred hand-written rules.

This was weak, narrow intelligence in the most literal sense: a system that was a genius in one box and knew nothing outside it. The fatal flaw was scale, every rule had to be written by hand by a human expert. Knowledge didn't generalize, and it didn't learn from data. When funding agencies realized these systems couldn't handle the messiness of the real world, the money dried up. This was the first AI winter.

2. Statistics Quietly Eats Symbols (1990s–2000s)

While "AI" was a dirty word in grant applications, a different idea was gaining ground: instead of telling a machine the rules, show it examples and let it find the rules itself.

Neural networks had existed since the 1950s (the perceptron) but were widely written off after Minsky and Papert detailed their mathematical limits in Perceptrons (1969).
Backpropagation, popularized in 1986, gave multi-layer networks a real way to learn and yet networks still mostly lost to simpler methods for another two decades. The algorithm existing wasn't enough; there wasn't enough labeled data or compute to let it show what it could do. It sat half-revived, a promising idea nobody could afford to run at scale.
Support Vector Machines, decision trees, and Bayesian methods dominated practical machine learning, spam filters, recommendation engines, fraud detection.
IBM's Deep Blue beat Garry Kasparov in 1997, but largely through brute-force search over chess positions, not learning. Still narrow, still impressive.

This era's intelligence was statistical rather than logical: pattern recognition over labeled data. It worked well on narrow, well-defined tasks but needed mountains of hand-labeled examples and feature engineering done by humans. The "intelligence" was still mostly in the human designing the features the model was just fitting a curve.

3. Deep Learning Breaks the Ceiling (2012–2017)

The ingredients for the next leap had been sitting around for a decade: more data (the internet), more compute (GPUs originally built for video games), and algorithmic tricks for training deeper networks without them collapsing into noise. None of this looked inevitable at the time. Most of the field had moved on from neural networks; deep nets were a fringe bet kept alive by a small number of labs who kept getting told they were wasting their careers.

The spark was AlexNet (2012), a deep convolutional neural network that crushed the ImageNet image-classification competition, slashing the error rate compared to the next-best approach. That one result told the field something important: stack enough layers, feed them enough data, and the network finds its own features, no human feature engineering required. It wasn't a smooth continuation of the field's direction; it was closer to a coup. Within a couple of years, techniques that had been a punchline became the default starting point for almost every computer vision paper.

What followed was a five-year sprint:

Word2Vec (2013) / GloVe (2014): words became vectors, and "meaning" became something you could do arithmetic on.
Generative Adversarial Networks (2014): two networks competing, one generating fakes, one detecting them, together learning to produce eerily convincing images.
AlphaGo (2016): beat the world's best Go player (the board game, not go run main.go energy) using deep learning plus reinforcement learning plus tree search, on a game once thought too intuitive for machines.

Each of these was still task-bound, a vision model couldn't write a sentence, a Go-playing model couldn't recognize a cat — but the skill inside each one was no longer handed to it by a human; the model discovered its own representation of the problem. That shift in mechanism, more than any single result, is what made the next jump possible.

4. The Transformer and the Birth of "General-ish" Intelligence (2017–2022)

In 2017, a Google paper titled "Attention Is All You Need" introduced the transformer architecture. Instead of processing text sequentially like older recurrent networks, transformers let every word attend to every other word at once. It was a better way to model sequences and it turned out to scale beautifully.

That architectural choice, combined with the realization that you could pretrain a single giant model on a huge slice of the internet and then adapt it to almost any language task, produced the GPT lineage:

GPT (2018) → GPT-2 (2019) → GPT-3 (2020): each generation showed that scaling up parameters and data kept producing qualitatively new abilities, not just marginal accuracy gains. GPT-3 could write code, translate, summarize, and hold a conversation, despite never being explicitly trained to do any of those things.
Instruction tuning and RLHF (2021–2022): raw language models predict the next token; they don't inherently want to be helpful. Techniques like reinforcement learning from human feedback turned raw next-token predictors into assistants that follow instructions and refuse harmful ones.
ChatGPT (November 2022): Sam Altman announced it on X with the energy of a minor release: "today we launched ChatGPT. try talking with it here." Understated copy for the moment the old era ended and a new history began. Research left the lab; your non-technical relatives showed up. A hundred million users in two months. The Turing Test stopped being a thought experiment and became something people ran into accidentally over breakfast.

This is the point where AI stopped meaning "deep in one box, blank everywhere else" and started meaning compositional: a single set of weights that could combine skills it was never explicitly trained to combine. One model could write a sonnet, debug Python, and explain the sonnet's meter not because it was three different systems, but because language turned out to be a surprisingly good universal interface to a huge range of human tasks.

5. From Chatbot to Coworker: The Agentic Turn (2023–Today)

A language model that just answers questions is a powerful autocomplete. The next phase of the story is about giving that model hands: the ability to call tools, write and execute code, browse the web, remember state across steps, and chain its own reasoning into multi-step plans.

A few threads converged here:

Tool use / function calling let models stop just describing actions and start taking them, querying a database, hitting an API, running a calculation, instead of guessing at the answer.
Retrieval-augmented generation (RAG) gave models access to information beyond their training data, grounding answers in real documents instead of frozen memory.
Chain-of-thought and reasoning models showed that letting a model "think out loud" before answering and eventually training it specifically to reason longer on hard problems, produced dramatically better results on math, logic, and multi-step planning.
Agentic frameworks stitched these into loops: plan → act → observe → revise. Wrapped in orchestration code, retry logic, and well-designed tools, a model could chase a goal across many steps instead of answering once and stopping. Left alone long enough, it still drifts or takes wrong turns, the scaffolding exists to catch that. "Agent" describes a system, not a self-sufficient mind.
Multi-agent orchestration: models that spin up other model instances to parallelize work, each with a narrower role, then combine results. The specialist of the symbolic era is back, except now it's a transformer playing a role inside a swarm coordinated by another transformer, instead of a human-written rule.

This is the world a developer in 2026 actually lives in. Code isn't just suggested line-by-line; it's planned, written across multiple files, tested, and debugged in a loop that needs less hands-on steering than it used to, though still real review, real guardrails, and real human judgment about when to trust the output. The same pattern shows up outside coding: research agents that browse, synthesize, and cite sources across dozens of pages; operations agents that read a ticket, check a calendar, and draft a response; design agents that take a brief and return a working prototype. None of this is autonomy in the strong sense yet. It's interactive capability, a model in a loop with tools and a feedback signal — and it's powerful precisely because of how tightly that loop is engineered, not in spite of it.

Easy to miss when you're staring at capability charts: every jump here was also an economics story. Expert systems died because expert time didn't scale. Statistical ML rode cheap labeled data and storage. Deep learning rode gaming GPUs. LLMs rode internet-scale data and transformer parallelism. Agents are having their moment because inference got cheap enough to run a model in a loop hundreds of times per task without laughing. The recurring question isn't "can we build it?" but it's "can we afford to run it enough times to be useful?" That bottleneck moved; it didn't disappear.

So What Changed, Really?

If you zoom out, the history of AI is a story about where the intelligence lives:

Era	Where the "smarts" lived
Symbolic AI	In rules a human expert wrote by hand
Statistical ML	In features a human engineer chose
Deep learning	In representations the model learned itself
Large language models	In patterns learned from most of the public internet
Agentic systems	In the model's own planning, tool use, and self-correction across time

Each era didn't replace the last so much as absorb it. Today's agents still do statistical pattern matching under the hood; they still occasionally fail in the brittle, overconfident ways the old expert systems did, just less often and less predictably.

If you compress the five eras above, there are really only three discontinuities that mattered:

Hand-coded intelligence: rules a human wrote (symbolic AI).
Learned representations: patterns a model found in data, with steadily less human-chosen structure (statistical ML → deep learning → LLMs).
Interactive systems: models that act, observe consequences, and revise, instead of just outputting a single answer (agents).

The five-era version tells a better story; the three-version compression is what actually changed underneath.

Shift one: who writes the rules — human or data.
Shift two: passive answer vs. active loop. Most of "AI got so much better" traces to one of those.

This isn't a straight march toward AGI. It's researchers repeatedly asking "what if the machine decided this part?" and finding that worked, once the economics finally allowed it.

Whether the next chapter is "agents that reliably run entire businesses" or "another winter while the hype outpaces the engineering" is genuinely an open question and depending on who you ask, both are already happening at once.

There Is No Perfect Solution in Software Development: Every Decision is a Tradeoff

Adam - The Developer ✨ — Mon, 15 Jun 2026 06:22:48 +0000

Most bad decisions in software engineering aren't made because the engineer chose wrong between two clear options. They're made because the engineer didn't realize they were making a choice at all.

You optimized for readability without noticing that particular loop runs a million times per second. You built for perfect flexibility without realizing you'd never actually need it. You shipped fast and acknowledged the technical debt—until the debt became someone else's problem, and by then it was too late to refactor.

The pattern: teams usually aren't choosing between two good options. They're choosing between one safe default and one speculative optimization, and calling it a tradeoff to feel better about it.

What Every Engineer Needs to Know About Tradeoffs
Classic Tradeoffs You'll Face
- Performance vs. Readability
- Flexibility vs. Simplicity
- Speed to Market vs. Technical Debt
- Scalability vs. Cost
- Security vs. Convenience
- The CAP Theorem: What It Actually Means
The Pattern: How Good Decisions Actually Get Made
How to Make Better Tradeoff Decisions
The Mark of Experience

What Every Engineer Needs to Know About Tradeoffs

There is no perfect solution. Every architecture, every algorithm, every design decision buys you something at the cost of something else. This isn't pessimism, it's the foundation of good engineering judgment.

But here's the catch: not all tradeoffs are 50/50. In practice, experienced engineers often default heavily one way and only deviate with evidence.

Classic Tradeoffs You'll Face

Performance vs. Readability

Here's what usually wins: readability. Unless you have a proven bottleneck backed by profiling data, optimize for clarity.

// Faster but harder to maintain
function processData(source: number[], offset: number, length: number): number[] {
  const result = new Array(length);
  for (let i = 0; i < length; i++) {
    result[i] = source[i + offset];
  }
  return result;
}

// Slower but immediately clear
function processData(source: number[], offset: number, length: number): number[] {
  return source
    .slice(offset, offset + length)
    .filter(x => x > 0)
    .map(x => x * 2);
}

The second version is probably fine. Premature optimization is still the root of all evil. The first example should only exist if:

you've profiled
you found this function is actually slow
you've measured that the optimization makes a meaningful difference

All three conditions are rarer than you'd think.

Flexibility vs. Simplicity

"Flexibility" often looks like smart future-proofing until you realize you'll never actually need it.

You build a generic plugin system because "we might need it." You abstract everything into interfaces because "we'll probably want to swap implementations." You create configuration options for scenarios that never materialize. Meanwhile, your simple code that handles exactly one thing is getting buried under layers of generality.

Ship the simple thing. If you actually need multiple use cases later, refactoring from concrete to generic is almost always easier than refactoring from over-engineered to usable. The exception: if you're building a library or platform that multiple teams depend on, flexibility becomes a real requirement, not speculation.

Most over-engineering is just ego disguised as foresight.

Speed to Market vs. Technical Debt

Ship in two weeks with known compromises? Or spend two months building something maintainable?

Both answers are right in different contexts. A startup with three months of runway and a saturated market needs speed. A fintech system handling billions in transactions needs stability. There's no universal answer.

Scalability vs. Cost

Premature scalability is usually just waste unless you have strong signals of growth.

You can architect for 100x your current traffic and be right. You can also architect for today's load and be right. The difference is that one cost money now, and the other might cost money later. Most teams choose wrong because they're optimizing for an imagined future instead of the constraints they actually face.

The right call: scale when you have evidence that growth is coming, not because it might happen. Growth that doesn't materialize? You've spent months and money on infrastructure that will never be used. Growth that does materialize and catches you off-guard? That's painful, but you'll fix it. The fix is usually cheaper than over-engineering.

If you are unsure whether you need scalability, you don't.

Security vs. Convenience

Require 2FA, complex passwords, and proof of identity? That's more secure. Users will also hate you.

Frictionless auth is delightful for users and a security nightmare. You're balancing two legitimate concerns.

The CAP Theorem: What It Actually Means

Everything above applies to a single application you control end to end. This one is different — it belongs to distributed systems.

A distributed system is software spread across multiple machines that coordinate over a network. Your API talking to one database is distributed in the loose sense, but CAP really starts to matter when the same data lives in more than one place: a primary with read replicas, a Redis cluster, a multi-region deployment. The moment you have copies of data on separate nodes, connected by a network that can fail, you inherit tradeoffs you do not get on a single server.

The CAP theorem names the central one. The textbook version says: "Pick any two of Consistency, Availability, and Partition Tolerance."

Here's what actually happens: In any real distributed system, partition tolerance is not optional. Network failures will happen. So the real choice is between Consistency and Availability when the network breaks.

CP systems fail safely when they can't guarantee consistency. A banking app might do this, it's better to be down than serve wrong balances.
AP systems stay up and serve whatever data they have. A social feed might do this, slightly stale likes are better than a 503.

The code doesn't need to be complicated:

// CP: fail rather than serve wrong data
async function getBalance(userId: string): Promise<number> {
  const result = await database.query('SELECT balance FROM accounts WHERE id = $1', [userId]);
  return result[0].balance;
  // If database is unreachable, the request fails. That's the design.
}

// AP: serve cached data with a staleness flag
async function getBalance(userId: string): Promise<{ balance: number; stale: boolean }> {
  try {
    const result = await database.query('SELECT balance FROM accounts WHERE id = $1', [userId]);
    return { balance: result[0].balance, stale: false };
  } catch (error) {
    // Partition: return whatever we have cached
    return { balance: await cache.get(userId), stale: true };
  }
}

Choose based on what breaks is worse: being wrong (CP) or being unavailable (AP).

The Pattern: How Good Decisions Actually Get Made

Once you recognize that a tradeoff exists, you're already halfway to making a good decision. You can be intentional about what you're trading and why. You can explain it to your team. You can revisit it later if your constraints change.

Without that awareness? You end up optimizing for readability on a loop that runs a million times per second. You build flexibility you'll never need. You ship fast and defer the cost to future-you.

Here's what separates functional teams from dysfunctional ones: functional teams argue about which tradeoff they're making. Dysfunctional teams don't realize there's a choice at all, and they compound the costs by pretending it was inevitable.

How to Make Better Tradeoff Decisions

1. Name the tradeoff explicitly
Don't say "should we use Redis?" Say "are we optimizing for speed or operational simplicity?"

2. Understand your constraints
What actually matters in your context? A library used by millions needs different tradeoffs than an internal tool used by five people.

3. Make it reversible if possible (but know the real limits)
Refactoring from concrete to generic is usually easier than the reverse. Local code changes are easy to undo. But reversibility has hard boundaries.

True reversibility: Internal implementation details, local code scope, nothing that touches user-facing behavior.

False reversibility: Anything that becomes business-critical, anything customers build workflows around, anything that spreads to multiple teams. A quick hack that ships and immediately gets embedded in product behavior doesn't refactor cleanly six months later. The team has built processes around it. Customers depend on it. Other engineers have written code that relies on it. Reversibility was an illusion from the moment the code touched production.

Know which category your decision falls into before you ship it as temporary.

4. Document your reasoning
Future you (and your teammates) will thank you. "We chose simple over performant here because X" is gold.

5. Revisit your assumptions
Your constraints change. What was the right tradeoff six months ago might be wrong now. That's not failure—that's growth.

The Mark of Experience

Here's what changes as you get better at this:

Seniors aren't less stressed, they're stressed about the right things. They don't waste energy trying to eliminate uncertainty. They can't. Uncertainty is part of the job. Instead, they focus on reducing risk and keeping decisions reversible where possible.

They ask good questions: "What happens if we're wrong about this?" "What would make us want to undo this decision?" "Do we have evidence this is actually a bottleneck?" They make explicit choices, document the tradeoffs, and move forward without second-guessing.

The skill isn't knowing everything. It's making conscious tradeoffs and living with the consequences without pretending there was ever a perfect choice.

The Hidden Machinery Behind Background Jobs

Adam - The Developer ✨ — Tue, 09 Jun 2026 07:27:48 +0000

This will be a boring article today, but I wanted to write it after talking to a developer who genuinely believed background jobs are the key to faster software.

They’re not hard to add. They’re easy to write, easy to deploy, and deceptively minimal, depending on how much complexity you’re willing to ignore elsewhere.

Let’s talk about something most of us use every day but rarely think about.

You enqueue a job (or, in my language, “drop something into a queue”). Your API returns 202 Accepted in 3 milliseconds. It feels good, responsive, non-blocking, event-driven. All the right words.

But between queue.enqueue() and a worker picking it up, a lot happens across your app, the OS, the network stack, and the broker. Most of it is invisible. All of it matters when something breaks at 2am.

This is that journey, layer by layer. By the end, you’ll have a clearer picture of what “fast” and “non-blocking” actually mean when a queue is involved.

What We Think Is Happening
Layer 1: Your Application Code
Layer 2: The Network Stack and the Kernel
Layer 3: Inside the Broker
- Redis
- RabbitMQ
- Kafka
Layer 4: The Event Loop, and What Is Actually Powering It
- How It Evolved
Layer 5: The Worker, Acknowledgments, and What "At Least Once" Actually Means
Layer 6: The Things That Quietly Go Wrong
What "Fast" Actually Means
The Full Journey, Summarized
Closing Thoughts

What We Think Is Happening

Most of us carry a mental model that looks roughly like this:

Producer  →  [ Queue ]  →  Worker

Clean. Simple. And not wrong, exactly, just kinda incomplete. The full picture looks more like:

Producer
  → serialize payload to bytes
  → write bytes to TCP socket
  → kernel buffers → NIC → wire
  → broker receives bytes
  → broker deserializes, routes, stores message
  → broker sends ACK to producer
  → worker connects and subscribes
  → broker reads message from storage
  → broker sends to worker over TCP
  → worker deserializes → your function runs
  → worker sends ACK back to broker
  → broker marks message delivered, removes it

Every one of those arrows is real work. Let's walk through each one.

Layer 1: Your Application Code

Here is a fairly typical job enqueue in TypeScript using BullMQ:

import { Queue } from 'bullmq';

const emailQueue = new Queue('emails', {
  connection: { host: 'localhost', port: 6379 }
});

await emailQueue.add('sendWelcome', {
  userId: 'usr_abc123',
  to: 'user@example.com',
  template: 'welcome-v2',
});

console.log('Job enqueued'); // Returns in ~3ms

That await resolves fast. But a few things happened before it did.

Serialization. Your payload object got converted to a flat sequence of bytes. In BullMQ's case, this is JSON. Every nested field, every string, every number, reduced to a string that can cross a process boundary. Your clean TypeScript object does not survive the trip; its data does.

Message wrapping. The payload gets wrapped in an envelope before it goes anywhere. Job ID, timestamp, retry count, delay, priority, queue name. Depending on the broker, this metadata overhead can be comparable in size to your actual payload for small messages.

Connection reuse. BullMQ does not open a new TCP connection to Redis for every job. It keeps a pool of connections alive. Enqueuing borrows one of those connections, writes the message bytes, and returns it. If every connection in the pool is busy, your await waits here. Not in some clean async queue, but blocked, waiting for a connection to free up.

So even before a byte has left your machine, your "fast, non-blocking enqueue" has already done serialization, object allocation, pool management, and potentially some waiting. Still fast. Just not free.

Layer 2: The Network Stack and the Kernel

When the library writes to the socket, your application hands control to the OS kernel. This boundary has a name: a syscall. Roughly speaking, it is your code saying "I need to do something I am not allowed to do myself" and the kernel taking over.

On Linux, that write looks like this at the system level:

// What your queue library is ultimately triggering
ssize_t bytes_written = write(socket_fd, message_bytes, message_length);

A few things happen in sequence:

Your bytes are copied from your process's memory into the kernel's TCP send buffer. This is a separate memory region. Once copied, your code cannot touch those bytes anymore.
The kernel's TCP stack breaks the data into segments, adds sequence numbers and checksums, and hands them to the network driver.
The NIC DMA-transfers the data to its own buffer and puts it on the wire.

the important part here: write() returns before the data is confirmed received by the broker. It returns when the kernel has accepted the bytes. The actual network transfer happens asynchronously behind your process's back.

When your enqueue call returns quickly, you have confirmed the kernel accepted your bytes. Not that the broker received them.

Layer 3: Inside the Broker

This is where things differ meaningfully depending on which broker you are using. Let's look at three common ones.

Redis

Redis works entirely in memory. When the message arrives over TCP, Redis's event loop reads the bytes from the socket, deserializes the command, and modifies an in-memory data structure. For a BullMQ job, this is an entry in a Redis sorted set or list, depending on job type.

No disk is touched in the default path. This is why Redis is fast. It is also the catch: a crash or restart with default settings means everything in memory is gone. Your enqueued jobs, vanished, with no error and no log entry.

Redis does support persistence (RDB snapshots, AOF logging), but these are asynchronous by default. There is always a small window between when you enqueue and when that data is safely written to disk. That window is your risk to size and accept consciously.

RabbitMQ

RabbitMQ has a more layered approach to storage. A message arrives via AMQP, gets deserialized, passes through the exchange's routing logic (which queue does this message belong to, based on binding keys and patterns), and lands in the target queue.

Each message carries more weight than it looks. A payload of 1KB actually occupies roughly 2KB in RabbitMQ's memory once internal metadata is factored in. The internal database keeps an in-memory copy of all data, even on disk nodes.

For persistent messages, RabbitMQ writes to disk before sending the ACK back to your producer. If memory pressure climbs above a configurable threshold, RabbitMQ starts paging messages to disk. If it keeps climbing, RabbitMQ does something that surprises most people who have not read the docs: it blocks publishers. Stops reading from their TCP sockets entirely. Your producer's write() call hangs. Your enqueue appears to freeze. The queue is not broken. It is telling you it is full and it cannot accept more until workers catch up.

Kafka

Kafka treats the problem differently at a fundamental level. A message is not stored in a data structure in memory. It is appended sequentially to a log file on disk.

Sequential disk writes on modern SSDs and NVMe drives are extremely fast because they avoid seek times entirely. This is where much of Kafka's throughput comes from. Consumer progress is tracked as a simple integer, an offset into that log file. To read the next message, a consumer increments its offset and fetches. To replay messages, it resets the offset.

This model means multiple independent consumers can read the same data, message replay is trivially possible, and retention is time-based rather than acknowledgment-based. It also means Kafka is disk-heavy and its throughput degrades with larger messages. NVMe storage is not optional for serious Kafka deployments.

Layer 4: The Event Loop, and What Is Actually Powering It

This is the part that ties everything together. Your broker, your async worker, your web framework: all of them are built on the same foundational mechanism.

To understand it, we need to understand the problem it exists to solve.

A server that handles connections by blocking on a socket read can only handle one connection per thread. To handle 10,000 concurrent connections, you would need 10,000 threads. A thread typically needs 1 to 8 MB of stack space. That is a lot of RAM spent on processes that are almost entirely idle, just waiting for data.

The solution is I/O multiplexing: a single thread monitors thousands of file descriptors and reacts only when one actually has data.

How It Evolved

select() was Unix's first answer. You pass the kernel a bitmask of file descriptors to watch. The kernel scans every one of them on every call to see which are ready:

// kernel scans ALL of these on every single call
fd_set read_fds;
FD_ZERO(&read_fds);
FD_SET(sock1, &read_fds);
FD_SET(sock2, &read_fds);
// ... up to 1024 max

select(max_fd + 1, &read_fds, NULL, NULL, &timeout);
// returns, then you scan the whole bitmask yourself to find who is ready

This is O(n) per call, where n is your total number of watched file descriptors. With thousands of connections, this burns meaningful CPU just on scanning. Plus there is a hard ceiling of 1,024 descriptors. Fine for an early-nineties Unix workstation. Not fine for anything built in the last twenty years.

poll() removed the 1,024 limit but kept the linear scan. A step forward, not a solution.

epoll() is the modern Linux answer. The philosophy shifts: instead of asking the kernel "which of these are ready right now?", you register your file descriptors once and say "notify me when something changes."

// create an epoll instance
// the kernel allocates a red-black tree and a ready list internally
int epfd = epoll_create1(0);

// register a file descriptor once
// kernel inserts it into the red-black tree — O(log n)
struct epoll_event ev;
ev.events = EPOLLIN;       // wake me when data is available to read
ev.data.fd = socket_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, socket_fd, &ev);

// The event loop — this is what Node.js, Redis, Nginx all do at their core
struct epoll_event events[MAX_EVENTS];
while (1) {
    // process sleeps here, consuming zero CPU
    // Kernel wakes it when at least one FD has data
    int n = epoll_wait(epfd, events, MAX_EVENTS, -1);

    // n is only the count of *ready* file descriptors, not total registered ones
    for (int i = 0; i < n; i++) {
        handle_event(events[i].data.fd);
    }
}

When epoll_create1() is called, the kernel allocates two internal structures: a red-black tree for all registered file descriptors (insertion and lookup in O(log n)), and a linked list for descriptors that currently have data ready.

When epoll_wait() is called, the process is suspended and consumes no CPU.

When a network packet arrives for one of your registered sockets, the NIC fires an interrupt. The kernel processes the incoming data and a callback moves that socket's file descriptor from the red-black tree to the ready list. epoll_wait() wakes up and returns only the descriptors that are ready.

With select, the kernel scans your entire list on every call regardless of how many are actually ready. With epoll, the kernel does the bookkeeping internally and only tells you about the ones you care about. For a server with 10,000 connected clients where 3 of them sent data right now, select scans 10,000, epoll returns 3.

This is why:

A single-threaded Node.js process can handle tens of thousands of concurrent connections.
Redis processes millions of operations per second on one thread.
Nginx serves enormous traffic without spawning thousands of OS threads.

Your event-driven architecture is, at its foundation, a process sleeping in the kernel, waiting to be woken by a network interrupt.

Layer 5: The Worker, Acknowledgments, and What "At Least Once" Actually Means

Below is a TypeScript worker consuming from the same queue:

import { Worker } from 'bullmq';

const worker = new Worker('emails', async (job) => {
  const { userId, to, template } = job.data;

  await sendEmail({ to, template, userId });
  // Ii we reach here without throwing, BullMQ sends the ACK automatically
  // if we throw, BullMQ sends a NACK and schedules a retry

}, {
  connection: { host: 'localhost', port: 6379 },
  concurrency: 5,   // how many jobs this worker handles in parallel
});

Simple from the outside. Under the hood, the worker process opened a TCP connection to Redis, subscribed to the queue, and entered its own event loop. From the OS's perspective, it is a sleeping process blocked on a socket read, parked in the kernel's wait queue, consuming no CPU.

When Redis has a job ready, it sends data over TCP. The kernel receives the bytes, the socket becomes readable, the wait queue callback fires, the process wakes, BullMQ deserializes the job data, and your function is called.

When your function returns without throwing, BullMQ sends an ACK to Redis. Redis marks the job complete. If your function throws before that ACK is sent, the job stays in an active state. After a configurable timeout, it gets requeued.

This is at-least-once delivery. Your function will be called at minimum once. It may be called more than once. Here is why that matters in practice:

// Unsafe: if this crashes after the charge but before the receipt,
// the job retries and the customer gets charged twice
async function processPaymentJob(job: Job) {
  await chargeCustomer(job.data.customerId, job.data.amount);
  await sendReceipt(job.data.email);
}

// Safer: the idempotency key ensures a duplicate call
// is treated as the same operation, not a new one
async function processPaymentJob(job: Job) {
  await chargeCustomer(job.data.customerId, job.data.amount, {
    // Idempotency is not a nice-to-have in a queue-based system. 
    // It is a correctness requirement for any handler that makes side effects in the outside world.
    idempotencyKey: job.id,
  });
  await sendReceipt(job.data.email);
}

Layer 6: The Things That Quietly Go Wrong

Now that we can see the full path, these failure modes are a lot less surprising.

The queue fills up and nobody is watching. Workers fall behind. Messages pile up. RabbitMQ reaches its memory threshold and stops accepting new messages. Your producers' TCP writes start hanging. Your API response times climb. Engineers look for a slow database query. Add queue depth and consumer lag to your dashboards and save everyone a confusing hour.

Data loss because persistence was not configured. Redis with default settings holds everything in memory. A clean deployment restart flushes the queue. No error is thrown because nothing went wrong from the broker's perspective. The data simply stops existing. Enable AOF persistence and understand the durability tradeoff you are making before your first production incident.

The dead letter queue fills up unnoticed. A dead letter queue is where failed jobs end up after repeated retries. It’s easy to ignore because nothing actively lives there by default. But that’s exactly the problem. If you don’t build a consumer for it, and don’t monitor its depth, you can quietly accumulate months of failed work without realizing it. By the time you notice, you’re just gonna be digging through history of dead queues.

Duplicate processing because the handler is not idempotent. A worker completes its work, then crashes before ACKing. The broker redelivers. The external side effect runs twice. This has caused real double-charges, duplicate emails, and inconsistent records at real companies.

A blocking call inside an async worker. If your handler makes a synchronous blocking call, it stalls the event loop for the duration. No other messages are processed. Throughput drops to the speed of the slowest synchronous operation. Use async drivers for databases, HTTP clients, and file I/O inside workers.

What "Fast" Actually Means

When we say a queue makes an endpoint faster, we mean something specific: the HTTP response no longer waits for the work to finish. The work itself takes the same amount of time. Often more, when you factor in serialization, network round trips to the broker, storage, retrieval, deserialization, and worker execution.

What changed is when the user gets their response. Not how long the work takes.

This is genuinely valuable. Decoupling user-facing latency from background work is a real improvement. But it is a different thing than making work faster, and conflating the two leads to queues in places that add complexity without benefit, and missing queues in places where the decoupling would genuinely help.

A queue earns its place when the work is not needed to form the response, the work is slow enough that waiting feels bad, the work is safe to retry, and the producer and consumer need to scale independently.

A queue adds complexity without clear payoff when you need the result to respond, your latency budget is too tight for broker round trips, or the operation is fast enough that doing it inline is simpler and easier to observe.

The Full Journey, Summarized

Your TypeScript code
  ↓  JSON.stringify → bytes allocated in your process memory
  ↓  write() syscall → bytes copied to kernel TCP send buffer
  ↓  kernel TCP stack → NIC DMA transfer → wire

Broker process (Redis / RabbitMQ / Kafka)
  ↓  epoll_wait() wakes on incoming socket data
  ↓  deserialize bytes → route → store (RAM / disk / log file)
  ↓  ACK sent back to producer over TCP

Worker process
  ↓  sleeping in kernel wait queue, zero CPU consumption
  ↓  broker pushes job data over TCP
  ↓  kernel wakes worker via socket callback
  ↓  deserialize → your async handler function runs
  ↓  ACK on success → broker removes job
  ↓  throw on failure → broker requeues after timeout

Every arrow is real work with real cost and real failure modes. None of it is magic. All of it is understandable, and understanding it makes you a meaningfully better engineer of the systems that depend on it.

Closing

Queues and background jobs are genuinely good tools. The resilience they add, the ability to absorb traffic spikes, retry failures gracefully, and let producers and consumers scale independently — all of that is real and worth the added complexity.

The point is not to be wary of them. It is to understand what you are working with so you can configure them thoughtfully, monitor the right things, and know where to look when something behaves unexpectedly.

The queue depth is a metric worth watching. The dead letter queue is an inbox worth reading. The ACK timeout is a contract with the broker worth understanding.

Keep an eye on those three and your queues will mostly be a quiet, reliable part of your system doing exactly what they promised.

When Duplicate Code Is the Better Design

Adam - The Developer ✨ — Mon, 01 Jun 2026 06:09:57 +0000

You've seen the developer. Maybe you are the developer.

They discover DRY — ✨ Don't Repeat Yourself ✨ — and something switches in their brain. A primal need awakens. Every duplicated string, every similar-looking function, every pair of lines that rhyme in the wrong light becomes a personal affront. An itch. A moral failing.

Two weeks later, their codebase looks like a game of Jenga where every piece is also load-bearing, also abstract, also parametrized six ways to Sunday, and also, crucially, completely impossible to understand.

Congratulations. You've achieved ✨ DRY ✨. You've also achieved a codebase that will ruin your next three Fridays and everyone's.

What DRY Actually Says (and Doesn't)

DRY comes from The Pragmatic Programmer by Andy Hunt and Dave Thomas. The actual rule is:

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Notice what it says: knowledge. it's not code. it's not characters. it's not "things that look similar when squinted at from across the room."

It says knowledge.

The principle is about avoiding duplicated intent and logic — not scrubbing every repeated character like you're laundering evidence. But somewhere between the book and the keyboard, people stopped reading and started pattern-matching like raccoons sorting shiny garbage:

"If two lines of code look alike, merge them immediately or you're morally bankrupt, professionally suspect, and probably the reason standups run long."

That's not DRY. That's aesthetic OCD with a philosophy degree and a GitHub contribution graph to protect.

The Taxonomy of DRY Crimes

Crime #1: Abstracting Coincidental Similarity

// Two functions that happen to look the same TODAY
function formatUserName(user) {
  return `${user.firstName} ${user.lastName}`;
}

function formatAuthorName(author) {
  return `${author.firstName} ${author.lastName}`;
}

The classic DRY-brain response: "These are identical! Extract!"

// The abstraction
function formatName(entity) {
  return `${entity.firstName} ${entity.lastName}`;
}

Fine. Harmless, even. Like a campfire in dry grass. Six months later, user names want a salutation, author names want a pen name fallback, and your cute little formatName has metastasized into a fifteen-parameter horror show with an enum called NameFormattingStrategy — the kind of function that needs its own onboarding doc and makes junior devs reconsider their career choices.

The duplication wasn't a bug. It was two different things that happened to share a shape for one Tuesday. A user is not an author. Their names evolve on different timelines. The duplicate code was whispering that — you heard "refactor opportunity" and built a cage instead.

Crime #2: The Abstraction That Needs a Manual

// Before: readable in 3 seconds
function getActiveAdminUsers(users) {
  return users.filter(u => u.isActive && u.role === 'admin');
}

// After: DRY'd into a puzzle box
function filterEntities(collection, predicates, options = {}) {
  const { limit, sortBy, transform } = options;
  const filtered = collection.filter(item =>
    predicates.every(pred => pred(item))
  );
  const sorted = sortBy ? filtered.sort(sortBy) : filtered;
  const limited = limit ? sorted.slice(0, limit) : sorted;
  return transform ? limited.map(transform) : limited;
}

// Usage (good luck, new hire)
filterEntities(users, [u => u.isActive, u => u.role === 'admin']);

You saved four lines. You created a filterEntities function that now silently accumulates every filtering need in your entire app, grows to 200 lines, and gets passed to new developers with the haunted look of someone handing off a cursed object.

The original function had a name. It was easy to understand, it told a simple story, getActiveAdminUsers is self-documenting. Your generalized thing is a puzzle.

Code is read far more than it's written. Abstractions are not free — they are paid for in comprehension, every single time someone opens that file.

Crime #3: DRY Across Wrong Boundaries

The most insidious form. And unlike the toy examples above, this one has a body count.

Every backend dev has seen this happen. You're building a notification system. You have email, SMS, push, and in-app notifications. They all take a user, a type, and some options. They look identical at the call site:

// v1 — reasonable. clean. you feel good about yourself.
sendNotification(user, 'order_confirmed', { orderId });

The abstraction makes sense. You write one function. You route internally. Ship it.

Then marketing wants to send a promotional email blast. Different thing, same function — but now you need an isMarketing flag because marketing emails have unsubscribe footers and transactional ones don't.

Then legal needs CAN-SPAM compliance on marketing sends. Different opt-out logic per locale. Now you need locale and complianceRules.

Then mobile push notifications need to respect iOS quiet hours, which email doesn't care about. Add respectQuietHours.

Then in-app notifications don't go through any external service at all — they're just a database write — but they're still "notifications" so they stay in the function.

Then SMS gets a character limit and needs message chunking logic that email will never need.

Eighteen months after that clean sendNotification(user, type, options), you have:

// v∞ — the function that consumed itself
async function sendNotification(
  user: User,
  type: NotificationType,
  options: NotificationOptions,
  channel: 'email' | 'sms' | 'push' | 'in_app',
  isMarketing: boolean,
  isTransactional: boolean,
  locale: string,
  complianceRules: ComplianceConfig,
  respectQuietHours: boolean,
  chunkIfOverLimit: boolean,
  bypassOptOut: boolean, // "just this once, for the launch"
  trackingPixel?: string,
) {
  if (channel === 'email') {
    if (isMarketing) {
      // 40 lines of compliance logic
    } else {
      // 30 lines of transactional logic
    }
  } else if (channel === 'sms') {
    // 50 lines that have nothing to do with email
  } else if (channel === 'push') {
    // 45 lines that have nothing to do with SMS
  } else if (channel === 'in_app') {
    // just writes to a table but must pass through this gauntlet anyway
  }
}

This function is now 300 lines. It has no tests that actually cover all the flag combinations — there are 2⁷ of them, good luck. Every engineer who touches it adds one parameter at the top and one if branch somewhere in the middle, and prays they didn't break the Malaysian SMS path.

You have not DRY'd your code. You have built a load-bearing monolith disguised as a helper function.

The actual fix is humbling: email, SMS, push, and in-app were never the same thing. They shared a surface-level interface and nothing else. They have different rate limits, different compliance regimes, different retry logic, different failure modes, and different delivery guarantees. The right design was always:

sendEmail(user, template, options);
sendSms(user, message, options);
sendPushNotification(user, payload, options);
createInAppNotification(user, content);

Yes, it's four functions. Yes, some options are repeated across them. That's fine — the repetition is honest. Each function can evolve independently. The SMS team can add chunking without touching the email function. Legal can update the CAN-SPAM logic without a regression on push. A new engineer can read sendEmail and understand sendEmail without holding the entire notification universe in their head.

The shared abstraction didn't eliminate complexity. It hid it, then grew it, then held it hostage.

Crime #4: The Generic Repository That Ate Your Domain

Every backend dev hits this phase. You have UserService, OrderService, ProductService. They all need to fetch things from the database. The queries look suspiciously similar:

// Three services, three nearly identical queries. Your DRY alarm is screaming.
async findAllUsers() {
  return db.users.findMany({ where: { deletedAt: null } });
}

async findAllOrders() {
  return db.orders.findMany({ where: { status: { not: 'draft' } } });
}

async findAllProducts() {
  return db.products.findMany({ where: { isPublished: true } });
}

The fix writes itself. You extract a base class. You add generics. You feel like you're finally doing real architecture:

// The abstraction that will haunt three teams
abstract class BaseRepository<T> {
  abstract table: string;

  async findAll(filters?: Record<string, unknown>) {
    return db.query(this.table, { where: filters });
  }

  async findOne(id: string) {
    return db.query(this.table, { where: { id } });
  }

  async findPaginated(page: number, limit: number, filters?: Record<string, unknown>) {
    const offset = (page - 1) * limit;
    const [data, total] = await Promise.all([
      db.query(this.table, { where: filters, limit, offset }),
      db.count(this.table, { where: filters }),
    ]);
    return { data, total, page, limit };
  }
}

class UserRepository extends BaseRepository<User> { table = 'users'; }
class OrderRepository extends BaseRepository<Order> { table = 'orders'; }
class ProductRepository extends BaseRepository<Product> { table = 'products'; }

Beautiful. Reusable. You deleted forty lines and posted about it in Slack. Life is good.

Then product management asks for order search with customer name, date range, and payment status — but only for admins, and only orders that haven't been refunded unless the refund was partial. Your findPaginated now accepts a QueryOptions object with twelve optional fields and a include array that half the team misconfigures.

Then users need soft-delete scoping, role-based visibility, and a "last active" sort that requires a join. You override findAll in UserRepository. Then you override findPaginated too. The base class is now mostly dead code that new hires still have to read.

Then products need full-text search, category trees, and inventory counts from a warehouse table in another service. Someone adds findPaginatedWithSearch. Someone else adds findPaginatedWithJoins. The base class grows a buildQuery hook, then a QueryBuilder parameter, then an escape hatch called rawQueryOverride that three repositories use and nobody documents.

Eighteen months later:

// v∞ — BaseRepository, but make it suffer
async findPaginated<T extends Entity>(
  page: number,
  limit: number,
  filters?: FilterMap,
  options?: {
    include?: IncludeMap;
    joins?: JoinConfig[];
    search?: SearchConfig;
    sort?: SortConfig | SortConfig[];
    scope?: 'admin' | 'public' | 'internal';
    softDelete?: boolean;
    bypassTenantScope?: boolean; // "temporary, for the migration"
    aggregate?: AggregateConfig;
    cursor?: string;
    transform?: (row: T) => unknown;
  }
): Promise<PaginatedResult<T | TransformedRow<typeof options>>> {
  // 180 lines of conditional query assembly
  // every repository passes a different options shape
  // the type signature is longer than most functions it replaces
}

You have not eliminated duplication. You have built a generic pagination framework that every entity in your system must awkwardly fit into, like forcing every piece of furniture through the same IKEA allen wrench.

The honest version was always:

// UserRepository — boring, explicit, correct
async findActiveUsersForAdmin(page: number, limit: number) { /* ... */ }

// OrderRepository — different domain, different query
async findOrdersForDashboard(filters: OrderDashboardFilters) { /* ... */ }

// ProductRepository — nobody else's problem
async findPublishedProductsWithInventory(categoryId: string) { /* ... */ }

Yes, they all paginate. Yes, they all query a database. That's infrastructure similarity, not domain knowledge. Users, orders, and products don't share a reason to change — they share a SQL dialect. Conflating those two is how you end up with a BaseEntityManagerFactoryHelperUtil and a Jira ticket titled "refactor findPaginated (blocked: needs architect approval)."

Pagination is not a domain concept. It's a transport detail. Your repository layer is not a place to build a query DSL because SELECT statements rhymed once.

The Principle You Actually Need: AHA

Sandi Metz — of Practical Object-Oriented Design fame — offers the antidote:

AHA: Avoid Hasty Abstractions.

The rule: prefer duplication over the wrong abstraction.

A wrong abstraction is worse than duplication because:

Duplication is visible and easy to fix
A wrong abstraction is load-bearing, hard to see, and expensive to undo
People are afraid to delete abstractions, so they pile parameters on top until it collapses

The heuristic she and others suggest: wait for the third time. Once — write it. Twice — note the repetition. Three times — now think about what abstraction, if any, makes sense. By then you have enough examples to see the actual shape of the knowledge, not just the accidental shape of the code.

When DRY Is Right

To be fair to the principle: DRY is genuinely critical in the right places.

Business rules. The formula for calculating interest, the rule for what makes a user "active," the threshold for triggering an alert — these must live in exactly one place. When the business logic changes, you want to change exactly one thing.

Configuration. A base URL hardcoded in twelve files is twelve places a typo can happen. That's rightfully DRY.

Data schemas. Your database schema and your validation schema should not diverge because you copy-pasted them. Derive one from the other.

The test for whether something should be DRY: if this thing needs to change, how many places need to change with it, and do those places share a reason to change?

If yes — DRY it.

If they just look similar today — leave it.

The Real Anti-Pattern DRY Is Trying to Fight

DRY's real enemy was never "duplicate code." It was duplicate knowledge — the same business rule, scattered across the system, slowly drifting out of sync.

The nightmare scenario: your pricing logic is in the database trigger, the API controller, the frontend calculation, and a comment in a Slack message from 2019. When pricing changes, you find three of them. The fourth one quietly disagrees for six months, occasionally giving users the wrong number, and you never know why.

That's what DRY is for. Not for making your formatName function 40% more reusable.

A Checklist for Before You Abstract

Before you extract that abstraction, ask:

Is this duplicate knowledge, or duplicate shape? Two things can look alike for different reasons.
Can I name this abstraction clearly? If you're reaching for processEntityData or handleThing, stop. The abstraction isn't real yet.
What happens when one usage changes? If you can't change the abstraction without worrying about the other usages, it's too coupled.
Am I doing this because it's right, or because repetition makes me uncomfortable? Valid question. The answer matters.

Closing

DRY is a heuristic, not a commandment. It was written to fight a specific enemy: knowledge duplication causing systems to rot. It was not written to make your codebase a shrine to abstraction.

The best codebases I've read had a little repetition in them. Deliberate repetition. The kind where someone clearly decided "these two things look alike but they're not the same thing, and I'm going to leave them separate so they can evolve separately."

That's not laziness. That's wisdom.

Write the thing twice if you have to. Your future self, reading the code at 11pm with no context, will thank you for the clarity.

DEV Community: Adam - The Developer ✨

My favorite article of the week. for someone who's where he is today by breaking things, painfully manually writing CRUD apps and having no choice but to learn how to read people's code, this hits too close to home.

The Junior Developer Pipeline Is Broken... And AI Broke It

Understanding Over Origin

The Distinction

The Problem With Using "AI-Generated" as a Quality Filter

The Real Problem (And Why It Requires Actual Work)

The Pointed Out Irony

The Historical Perspective

The Good Moderation Requirements

What Actually Matters

The World's Oldest Communication Protocol Is Music

The Protocol Stack

How the Protocol Works

Why We Don't See This

The Uncomfortable Part

What This Means

And sooooo, Here's my favorite song of the week

Stop Saying You Want Ownership Mindset

The Script

You're Not Confused. You're Convenient.

The Quiet Engineer Is Not Owning Anything

What Ownership Actually Looks Like From Our Side

What You Get When You Train That Out of People

If You Actually Want It

Bottom Line

I Could Review It. I Couldn’t Write It.

Recognition is not Production

The Gap and I Started A Series

You Can't Download Experience

The Real Principle

What I'm Not Saying

You Never Eliminate a Bottleneck — You Just Move It

Why Bottlenecks Are Inevitable

The Theory of Constraints

Amdahl's Law: The Math That Proves It

The Great Trade-Off Game

Example: The Classic API Scaling

Distributed Systems Make It Worse

The Practical Mindset Shift

Actionable practices:

The Bottom Line

Further Reading

The Illusion of the Clean Slate

What rewrites actually inherit

The ghost of the old system

Why this matters

Conduit: The Gateway I Built to Forget About

TL;DR

The setup

Where the ugliness actually lived

Design goals (the actual constraints, not aspirations)

Architecture: two processes, one socket

The actual hard part: getting context across the process boundary

The plugin model

What happened when I actually ran it

Failure modes, stated plainly

What it's not

What stuck

Closing

When Software Started Writing Software: A Developer’s History of AI

Table of Contents

1. The Symbolic Era: Intelligence as Logic (1950s–1980s)

2. Statistics Quietly Eats Symbols (1990s–2000s)

3. Deep Learning Breaks the Ceiling (2012–2017)

4. The Transformer and the Birth of "General-ish" Intelligence (2017–2022)

5. From Chatbot to Coworker: The Agentic Turn (2023–Today)

So What Changed, Really?

There Is No Perfect Solution in Software Development: Every Decision is a Tradeoff

Table of Contents

What Every Engineer Needs to Know About Tradeoffs

Classic Tradeoffs You'll Face

Performance vs. Readability

Flexibility vs. Simplicity

Speed to Market vs. Technical Debt

Scalability vs. Cost

Security vs. Convenience

The CAP Theorem: What It Actually Means

The Pattern: How Good Decisions Actually Get Made

How to Make Better Tradeoff Decisions