DEV Community: Adam - The Developer ✨

Redis vs Dragonfly: A Hands-On Comparison

Adam - The Developer ✨ — Tue, 06 Oct 2026 09:20:43 +0000

I have used Redis on almost every backend project I can remember. Caching, sessions, rate limiting, queues, the occasional bit of temporary state that felt too awkward to put in Postgres. At some point it stopped being a decision and became a default.

About 3 months ago, I came across Dragonfly, which keeps the Redis API but is built differently underneath. I was curious enough to run both on the same workload and see what happened. This post covers what I saw, what I learned about why each one works the way it does, and where I think each makes sense.

Disclaimer: This is not a sponsored post, and I have no affiliation with DragonflyDB. I wrote it because I was genuinely impressed by Dragonfly when I tried it. It performed very well for me. Whether it is the right choice still depends on your workload, so treat this as a guide for evaluating it, not a recommendation to switch.

A quick note on what Redis is

Calling Redis a cache undersells it. Over the years I have used it for sessions, counters, distributed locks, leaderboards with sorted sets, pub/sub, streams, and plain queues. The reason it works so well for all of that is that it gives you useful data structures with very cheap operations. A command is usually a single call:

GET user:123
INCR rate_limit:user:123
ZADD leaderboard 9000 adam

There is no SQL to parse and no query planner involved. That simplicity is a big part of why it is fast.

So, why is Redis single-threaded anyway?

Redis executes commands on one main thread, and this tends to get described as a limitation. I think that undersells the original design.

Redis was created in 2009. Servers back then typically had a handful of cores at most, and the main goal was a datastore that was simple, predictable, and very fast on that hardware. A single execution thread gave it several things:

No locks around data structures.
Commands run one at a time, so atomicity is easy to reason about.
Behavior is predictable, which makes it easier to debug.
The codebase stays small and understandable.

Given the hardware of the time, this was a sensible design, and it still holds up well. Node.js is a good comparison: being mostly single-threaded does not make it slow, and it avoids a whole category of concurrency bugs.

Redis has also kept evolving. It has supported I/O threading since version 6, and Redis 8 improved that further. Networking work can be spread across threads while command execution stays serialized, so the core model is preserved and the obvious bottleneck is reduced.

Redis is a good design for the constraints it was built around. Those constraints have shifted since then, which is where Dragonfly comes in.

What Dragonfly does differently

Dragonfly started from a different assumption: servers now have 16, 32, or more cores, and a single execution thread leaves most of them idle. It uses a multi-threaded, shared-nothing architecture. The dataset is split into shards, each shard is owned by one thread, and requests are routed to the thread that owns the data.

Redis

  Requests --> [ Main thread ] --> [ Data ]


Dragonfly

  Requests --> [ Thread 1 ] --> [ Shard A ]
           --> [ Thread 2 ] --> [ Shard B ]
           --> [ Thread 3 ] --> [ Shard C ]

The real implementation is more involved, especially for operations that touch several shards, but that is the idea. The gain comes from spreading work across every core on the machine.

Trying it out

The first thing I liked was how little effort it took to start. Dragonfly speaks the Redis protocol, so I pointed an existing connection string at it and my client libraries worked without changes.

I didn't run some elaborate benchmark suite for this article. Honestly, you should benchmark it against your own workload anyway. A synthetic GET/SET benchmark tells you very little about whether Dragonfly will improve your actual application.

The interesting part is what happens when your Redis workload becomes CPU or memory bound. That's where Dragonfly's multi-threaded architecture and memory efficiency start to matter.

If your Redis instance is barely using one core and isn't under memory pressure, there may be little reason to switch.

And that's fine. Not every piece of infrastructure needs to be replaced just because something newer exists.

Where Dragonfly is still rough

Once the initial excitement wore off, I went through the Dragonfly docs and GitHub issues to see what could go wrong. Here is what stood out. None of it ruled Dragonfly out for me, and all of it is worth knowing before you put real data on it.

Persistence is snapshot-only

Redis gives you RDB snapshots and AOF logging. Dragonfly's docs say plainly that AOF is not supported, and the stated reason is a lack of high-priority demand from the community. If you need every acknowledged write to survive a crash, that matters.

Snapshots have had their own problems for some users. One GitHub issue describes snapshots to S3 silently stopping for a week, after which a crash restored week-old data. It was closed as a duplicate of another issue, and I could not tell from the thread what the root cause was, so treat it as one user's report.

Lua scripts need a closer look

Dragonfly uses Lua 5.4, while Redis uses Lua 5.1. Most scripts will run fine, but a language version change is worth testing for.

The bigger difference is how keys are handled. By default, Dragonfly rejects scripts that touch keys they did not declare, and returns an error saying so. You can allow it with the allow-undeclared-keys flag, but the docs warn that Dragonfly then has to stop all other operations while the script runs. Scripts that build key names dynamically are the ones to watch if you migrate.

Multi-key operations work, with a coordination cost

I expected multi-key commands to be a weak spot, since the data lives on different threads. Dragonfly handles them with a transaction framework based on the VLL algorithm, and the project says this gives atomic multi-key operations without mutexes or spinlocks. So atomicity holds.

The cost is coordination. In the team's own write-up on transactions, multi-key operations take a shard lock, and other transactions on that shard wait while it is held. Single-threaded Redis does not pay this cost. I did not measure how much it matters, so if your workload leans on large multi-key commands or scripts, test that path specifically.

Clustering works differently

Dragonfly's cluster mode is built to look the same to Redis Cluster clients, but it does not self-manage the way Redis Cluster does. In Redis Cluster, nodes talk to each other to discover cluster state. Dragonfly Cluster uses centralized management, so you set it up and operate it differently. If your plan is to run dozens of nodes, Redis Cluster has the longer track record.

Modules

Dragonfly's own comparison guide notes that some advanced Redis modules may not have full compatibility yet. If your stack depends on modules such as search or time series, check your exact use case before planning a migration.

Bugs

Dragonfly is a younger project and it shows in the issue tracker. A few examples from the release notes, all listed as fixed:

A crash on the master when an older replica reconnected to a promoted master (#7491).
Replication divergence with hash field expiry commands like HEXPIRE and HSETEX on lazily expired fields (#7948).
A crash when Lua scripts called GET on large string values (#7934).
A cross-thread data race in command squashing (#7927).

There are also open or unresolved user reports, such as a SIGSEGV crash during load testing on a 31 GiB dataset in v1.28.0, which showed up on a replica running BGSAVE and on a newly promoted master during full resyncs. The reporter could not reproduce it on demand.

Every database has a bug list and Redis does too. The point is that Dragonfly's list is newer and shorter on history, and a lot of the replication and persistence paths are where the issues cluster. That is worth keeping in mind if this is your primary datastore.

Where Redis still comes out ahead

None of that makes Redis the worse choice in general. After using both, here is where I think Redis still wins.

Maturity. Redis has years of production use behind it, and the failure modes are well understood. When something breaks at 3 AM, there is a huge body of knowledge to lean on. Dragonfly is still building that history.

Durability options. AOF, RDB, and all the configuration around them are well tested. If you need stronger durability guarantees than periodic snapshots, Redis gives you more to work with today.

Ecosystem. Client libraries, framework integrations, monitoring tools, managed services on every major cloud, local dev setups, CI containers. All of it already supports Redis, and your team almost certainly knows it.

Behavior you can predict. Dragonfly is compatible with the protocol and most commands, but compatibility does not guarantee identical behavior. Scripting, clustering, persistence, and replication are the areas above where it differs. Test the specific commands you rely on before trusting it with anything important.

Enough headroom. If your Redis instance sits at 8% CPU and your app spends most of its time waiting on Postgres, Dragonfly will not make your app noticeably faster. A benchmark chart does not tell you what is limiting your system. Profiling does.

How I would choose

I would stay with Redis when:

the workload is comfortably within what Redis handles
the team already operates it and knows it well
I depend on a specific Redis feature, module, or managed service
I need AOF-level durability
familiarity is worth more than extra hardware efficiency

I would evaluate Dragonfly when:

the workload is CPU-heavy
I am running large multi-core machines
memory cost matters
Redis Cluster complexity is becoming a burden
vertical scaling looks more attractive than adding nodes
snapshot-based persistence is acceptable for the data

Replacing something that works has a cost, so it needs a measurable reason.

Ending

I don't think Dragonfly makes Redis obsolete. And I don't think Redis being older makes it a bad choice either.

They are solving a similar problem with different architectural decisions. Redis optimized heavily around simplicity and predictable command execution. Dragonfly is taking a different approach and making much better use of the hardware we have today.

That's what I found interesting about it.

The question isn't really which one is better. It's why was it built this way in the first place?

Once you understand that, a lot of the design decisions stop looking strange.

If Redis is working fine for you, keep using it. If you're starting to hit CPU, memory, or scaling limits, Dragonfly is absolutely worth putting next to it and seeing what happens with your workload.

Sometimes the best way to understand a piece of infrastructure is to stop reading benchmarks and just ask what problem its architecture was trying to solve.

Things I Used to Be Excited About as a Kid, But Not Anymore

Adam - The Developer ✨ — Sun, 04 Oct 2026 10:47:53 +0000

Hi guys! It's been, what, two weeks now since I last wrote something, I guess.

Honestly, I haven't really thought of much to write about lately. I just joined a new company (a bank), and at the same time, I've been debating whether this week's article should be about something completely random like this, or whether I should write another one about Piper.

I decided to go with this one. I know it's a bit unconventional.

Writing about Piper after fixing around 40 DDL & IR related bugs is exhausting. I love the project, but man, I need to get away from it for a while. I don't even think it's a hobby project anymore.

Not giving up on it. Not even close.

I just need to breathe. Breatheeeee.

Anyway, let's start!

1. Getting a phone call, video call and text

I don't know, maybe it's just me? A lot of adults still seem genuinely happy when they get a phone call.

Context matters, obviously. I'd be pretty happy if someone called me to tell me I just won the lottery jackpot. But realistically, that's probably not happening.

I'm not necessarily an introvert either.

When I was a kid, getting a phone call, a text, or even a video call meant someone wanted to talk to you. Maybe it was your aunt, uncle, grandma, or grandpa. And kid me was probably 30% happier whenever the phone rang, regardless of who was on the other end.

Now?

I usually forget to charge my phone.

Making phone calls isn't something I look forward to anymore. Neither are random texts or video calls, because when someone reaches out, it's usually because they want something from me. "Hey Adam, can I have this?" "Hey Adam, can you do that?" No one ever says, "Hey Adam, how are you? I heard you haven't been feeling well. Can I interest you in a no-strings-attached opportunity to earn a million dollars?"

But I answer anyway, because, well... I'm a salaried adult.

Apparently, getting paid every month comes with the hidden requirement of occasionally answering phone calls.

2. Staying up late

Staying up late back then, to me, meant I was a good boy. Good enough that I was allowed to stay up with the adults.

I thought adults were living the best life ever. They got to stay up late with no rules, while I had to go to bed early.

What I didn't know was that my dad had work to do on his computer, while my mom was staying up with her sisters, making pastries to prepare for our early-dawn customers.

I thought they were staying up because they were adults.

Turns out, they were just busy. or to make it harsher, they had no choice. they were the source of income.

Big me now would be happy out of this world if he got tucked into bed by 9:00pm, Netflix on, enjoying that post-shower coolness.

3. Waking up early on weekends

Kid me woke up early on purpose.

No alarm, no one shaking me awake. I'd just open my eyes, sneak into the living room, and turn the TV on with the volume low enough that only dogs could hear. Cartoon Network in the early 2010s was my whole weekend.

We also had a PS3, but it lived in my dad's closet, locked up, with the key on him at all times. He knew me too well.

And here's the thing: the best ones always aired early in the morning. Chowder. Flapjack. It was like the channel knew only the dedicated ones would be awake. If you slept in, you got whatever was left, usually a Tom & Jerry episode I'd seen more times than I can count digits of pi.

Now? I still wake up early. Maybe it's the trauma of my alarm clock. Maybe it's the kid in me, still hoping for a good cartoon. Or maybe my body is adjusting to adulthood, and I still don't feel like it. Some times I'd pull a 10 - 12 hours sleep as well.

8:00am on a Saturday, wide awake, no TV, and there's nothing waiting for me but laundry, dishes, and a phone full of notifications from people who "just have a quick question." (See #1.)

The funny part is that kid me wanted to stay up late (#2) and wake up early at the same time, and somehow had the energy for both. Adult me has the freedom to do either, and wants neither.

4. Waiting for things to load

Kid me had the patience of a monk.

I grew up on YouTube with terrible internet. Pressing play meant watching that little circle spin for what felt like a geological era, then getting ten seconds of video before it buffered again. My strategy was to pause it, let the gray bar crawl forward, go do something else, and come back when enough of the video had loaded. Not once did I think, "this is unacceptable."

Games were the same. My dad introduced 12-year-old me to GTA Vice City, which is a wild thing to hand a kid, especially from the same man who locked the PS3 in a closet. (See #3. The man had a system, apparently.) Nothing about it was instant. Installing, loading, waiting. I sat there and waited, because the reward was worth it.

Back then, I'd watch a progress bar like it was a movie.

Now?

Everything loads instantly, and I get impatient after two seconds. A video takes three seconds to start and I'm already checking if the wifi is down. A page hesitates and I close the tab like it personally insulted me.

I went from waiting twenty minutes for a video to rage-quitting a spinner. Somewhere along the way, faster internet made me slower at being patient.

5. Wanting to grow up

Kid me couldn't wait to be an adult.

Every time someone asked what I wanted, the answer was basically "to be older." I wanted to stay up late with the grown-ups. I wanted my own money, and nobody telling me when to sleep, what to watch, or which closet the PS3 was locked in. Adults looked like they had all the answers and all the keys.

Now I'm old enough, and I'd like to speak to whoever was in charge of the brochure.

Nobody mentioned that "freedom" comes with a calendar full of deadlines. Or that the phone I couldn't wait to own would mostly ring with people who need something (#1). Or that the late nights I envied were just people working while the rest of the house slept (#2). Or that I'd wake up at 6:00am on a Saturday with no cartoons to wake up for (#3). Or that I'd get impatient with a two-second loading screen after growing up on buffering (#4).

and somewhere in all of this, I realized the adults I looked up to weren't living the best life ever. They were just carrying a lot, quietly, so the kids could stay excited about things. My parents did it with pastries and late nights. My relatives did it with envelopes. My dad did it with a very strategic closet key.

What now?

What do you mean, what now? There's nothing you can do about it. I traded the state of worrying about nothing for an adult life, and while it's not the most pleasant experience of all, kid me doesn't get to say, "I wanna take a dirt bike and ride it across a Cambodian jungle, then eat junk food after I'm done."

Adult me can. No one's locking that in a closet.

Sure, the phone still rings with people who need something. I still stay up late because I have to, and I still wake up early with no cartoons waiting. But I also have the keys now. Every closet in the house is mine to open, and nobody can tell me not to.

So maybe the excitement didn't disappear. Maybe it just moved. It used to be in a Saturday morning cartoon, and now it's in the things I get to choose.

Live. Take risks. You never truly know you're living the moment while you're in it. Kid me didn't know either. He was too busy watching a buffering bar like it was a movie.

Anyway, that's it for this one. Now if you'll excuse me, I need to go charge my phone.

Resilient and Battle-Tested Are Not the Same Word

Adam - The Developer ✨ — Tue, 15 Sep 2026 11:16:16 +0000

Unnecessary information that's safe to ignore

Hi. So I've been away for a couple of weeks. I was up in the remote highlands of Cambodia's Mondulkiri province, where it's cold, quiet, and surrounded by mountains, jungles, and elephants.

It was so relaxing that coming back to the city has made me unnecessarily toxic and grumpy. Imagine spending a few days surrounded byone of mother nature's greatest creations, only to return to traffic, emails, deadlines, and the unfortunate realization that I'm an adult with a job and people to manage.

I also trekked through remote jungle, mountains, waterfalls, streams, and rocks for 17km in a pair of Crocs with the indigenous people, by the way. I survived and I don't recommend it. I did it because I forgot to bring proper trekking shoes. That's it, No deeper meaning.

Anyway, while I haven't been completely off the internet, I've been reading a lot of content about people building and shipping things aggressively with AI, then immediately labeling them "production-grade" and "battle-tested."

And maybe it's because I just spent 17km learning what the word "survived" actually feels like, but...

What???

Slow down, big man.

A Demo Is Not a Battlefield

AI tools have made it faster than ever to go from an idea to a working app, and honestly, that's a great thing. Having more people building things is a good thing.

And if you know me, you know I'm not here to do the whole "real engineers write everything by hand" bit. Sure, that mindset is still somewhat embedded in my identity as a developer, but I try to keep an open mind. Tools change, the way we build changes, and I'm perfectly fine with that.

But there's a word being attached to a lot of these projects that implies a level of reliability you simply can't get from "I shipped it and a few people liked it."

Production-grade. Or its cousin, battle-tested.

These aren't just your Uncle Joe's enthusiastic adjectives that you throw around because something looks cool, not a vibe. They're empirical claims about what a system has survived — and surviving a demo is not the same as surviving Tuesday.

Two different claims, constantly conflated

"Complete, functional, and resilient" means:

The features work as specified
It handles the errors you thought to handle (this clause is doing a lot of work)
It doesn't crash under normal use
It has decent test coverage
It looks done in a demo

This is a real, valuable milestone and with modern tools, they get you here faster than ever. Celebrate it. Put it on the README. Just maybe don't reach for the war metaphors yet.

"Production-grade" and "battle-tested" are a different axis entirely. Not "more polished" or "fewer bugs." They're about exposure to conditions you can't fully anticipate or simulate.

A few dimensions people underestimate:

1. Failure modes nobody designed for

Resilient code handles the errors you anticipated. Battle-tested code has lived through the ones nobody put on it, a dependency that silently returns malformed data instead of erroring, clock skew between servers, a queue backing up 10,000x during a spike, a connection pool exhausted by one slow query three services upstream.

Nobody designs for "the third-party API started returning 200 with garbage in it." You find that out the hard way, usually at an hour that makes the logs feel personal.

2. Observability under duress

When something breaks at 3 am, can an on-call engineer figure out what's happening from logs, metrics, and traces or does someone have to SSH in and guess? Which is a spiritual experience, btw. not an architecture.

Logging that satisfies a code review and logging that lets you debug a live incident are not the same thing. You usually can't tell which one you have until the incident happens. The incident is happy to tell you.

3. Graceful degradation, not collapse

When a downstream service dies, does your app fall over completely, or degrade — cached data, reduced functionality, queued retries? Designing for partial failure is invisible work. Almost nobody does it until they've been burned by not doing it. pretty expensive curriculum if you ask me.

4. Concurrency and scale edge cases

Imagine a payment endpoint that checks whether a transaction has already been processed before crediting an account. Looks safe enough.

Then the provider retries the same webhook twice, milliseconds apart. Both requests check the database, both see "not processed," and both credit the account.

Your tests passed. Staging was fine. Production was fine for months. Then one unlucky retry turns a race condition into a real financial bug.

That's the kind of failure that doesn't show up until the system is under conditions you didn't anticipate.

5. Exposure to abuse, not just correctness

Functional code handles legitimate input. Battle-tested code has been prodded, rate limits tested, auth edges probed, injection vectors thrown at it, resources hammered. This isn't something you test for once. It's sanded down over actual incidents.

Friendly users do not do this. Friendly users say "nice UI" and close the tab.

6. Operational maturity

Zero-downtime deploys. Safe rollbacks. Migrations that don't lock the table for 40 minutes while the app quietly suffocates. These are organizational capabilities as much as code capabilities, and they take time and infrastructure history to build up, they don't show up in a codebase on day one no matter how clean the architecture diagram looks.

7. A record of having been wrong

This is the literal meaning of "battle-tested": it has failed in production before, someone fixed it, and there's a postmortem, a monitor, or a regression test that exists because of that specific scar.

A brand-new system — however well-written — hasn't accumulated this yet. There is no "generate scars" button.

They're not a ladder

Easy to read all of this as a sequence: first you make it resilient, then time makes it battle-tested. That's tidy. It's also wrong.

You can have code that is battle-tested and not resilient. Years in production. Real users, real load, real incidents. It works perfectly, until an unexpected external API goes down, and the whole system falls over because nobody ever designed for that. The scars are real. The fault tolerance is not. Survival is not the same as a plan.

You can also have code that is resilient and not battle-tested. Fresh deploy. Timeouts, retries, circuit breakers, cached fallbacks, the whole poster. Excellent fault-tolerant architecture. It has not yet faced real-world traffic. The design is a hypothesis. A very well-written hypothesis. Still a hypothesis.

One is a history while the other is a design. You want both and you don't get to borrow the word for one because you have the other.

Why the distinction is worth defending

Building was always the easy part of the job — the visible 20% you can show in a demo. The other 80% is judgment: knowing which design choices will quietly rot in eight months, knowing when not to build something, reading a system that's been touched or contaminated by many hands and understanding why it looks the way it does, estimating honestly, responding well when production is on fire. None of that shows up in a working prototype. It only shows up after time, real users, real failures, and a few scars.

And none of this means you should undersell a functional, well-tested app. Call it well-engineered. Call it ready for early users. Those are good things. nothing wrong with that.

"Battle-tested" is a different sentence. It requires the battle. Somewhere there's a team that's actually run something through years of incidents and hard-won fixes, and their "production-grade" deserves to mean something different from a weekend project's. The words still have to mean something, or they stop meaning anything.

Go Doesn't Force Clean Architecture. That's Your Job.

Adam - The Developer ✨ — Fri, 28 Aug 2026 09:17:32 +0000

The criticism of this is everywhere. Open any Go thread long enough and someone will show up to perform the same ritual:

"Go projects become messy. There's no framework to guide you. Nest, Django, Spring, they all tell you exactly where to put things. Go? It just says 'organize it somehow.'"

It's a fair criticism. Go is unusually permissive about structure. I just think blaming Go for a messy codebase is like blaming the empty document for the bad essay.

I don't think Go encourages bad architecture but rather it exposes it.

The Hell Is A Perfect Folder Structure??

Ask a hundred Go developers where to put business logic and you'll get a hundred answers (and 200 opinions).

"Should I use internal/?"
"Is everything supposed to live under pkg/?"
"Should I follow Clean Architecture?"
"What about the cmd/ directory?"

We spend so much time debating folder structures as if the arrangement of directories somehow determines code quality. As if renaming utils/ to pkg/shared/ is going to save us. God.

folders don't create architecture. Dependencies do.

You can meticulously organize your project like this:

my-app/
  cmd/main.go
  internal/
    handler/
    service/
    repository/
  pkg/domain/
  pkg/utils/

And still write tightly coupled garbage. Handlers calling repositories directly. Services importing database drivers. Business logic mixed with HTTP concerns. Everything circular.

Beautiful folders, though. Very organized looking on GitHub.

There are better projects I've seen with just 5 packages, they just don't screenshot as well.

Architecture Is About Dependency Direction

The architecture is about making intentional decisions about how code depends on other code.

Have a look at this:

HTTP Handler
    ↓
Business Service
    ↓
Data Repository

This isn't sacred because of folder names. It's valuable because of what it represents:

The handler only knows how to translate HTTP
The service only knows business rules
The repository only knows how to fetch data
Each layer depends on the layer below, never upward

That flow is intentional. If you reverse it, everything breaks:

Repository
    ↓
Service
    ↓
Handler

Now the repository needs to know about HTTP? Nice, you've invented a database driver that also speaks REST and I think it's also a cry for help.

This flow works in a three-file project, a monolith, or a microservice with 50 packages. Go does not care how impressive your tree looks in the README.

Interfaces Belong to the Consumer

This is the part where people coming from Java have a small identity crisis.

In languages like Java, interfaces are typically defined alongside the implementation:

// repository package
public interface UserRepository {
    User find(String id);
    void save(User user);
    void delete(String id);
}

public class PostgresUserRepository implements UserRepository {
    // ...
}

This feels natural. For me, it was the default. The repository defines the contract, the implementation fulfills it, everyone goes home happy. Except the consumer, who now depends on an abstraction it didn't ask for, including delete even though it only wanted find. Very generous. Very unhelpful.

Go flips this around:

// service package
type UserFinder interface {
    Find(id string) (*User, error)
}

type UserStorage interface {
    Save(user *User) error
}

type UserService struct {
    finder  UserFinder
    storage UserStorage
}

The consumer defines exactly what it needs. The implementation simply satisfies those interfaces:

type PostgresUserRepository struct {
    db *sql.DB
}

func (r *PostgresUserRepository) Find(id string) (*User, error) {
    // ...
}

func (r *PostgresUserRepository) Save(user *User) error {
    // ...
}

The consumer owns the interface, not the implementation. Don't define an interface for what you provide; define one for what you need.

UserService doesn't care whether its dependencies are backed by Postgres, Redis, a file, or an API. It asked for Find and Save. That's the whole relationship. Very healthy, honestly.

Go Gives You Freedom

Both a feature and a burden.

Terrifying if you like to be told what to do. Freedom if you want to build thoughtfully. A trap if you thought "no framework" meant "no thinking."

The tradeoff is: frameworks prevent bad decisions by restricting your choices, or well, not really; you can still screw things up. The restriction is mostly psychological. Go makes you responsible for your choices, which is less comforting and more honest.

That means your team can't hide behind "the framework made us do it." You can't blame poor architecture on Rails conventions. If your Go project is a mess, it's because your team made it that way. There's no framework to pin it on. That's the whole feature.

Clean Architecture Isn't a Framework

A common misconception I see constantly: someone reads a Clean Architecture blog post, copies the folder tree into their repo, and waits for the cleanliness to arrive. It does not arrive.

cmd/
internal/
  application/
  domain/
  infrastructure/
  entity/
  repository/
  usecase/
pkg/
tests/

Clean Architecture is about keeping business rules independent from implementation details. You can do that in three files:

cmd/main.go
internal/
  service.go
  postgres.go
pkg/models.go

As long as service.go doesn't know about Postgres, business logic doesn't know about HTTP, and concrete implementations are swappable. That's it. You don't get extra architecture points for the folder named usecase.

Simplicity Doesn't Mean Lack of Discipline

Go lets you write less boilerplate but that doesn't mean less discipline. It means the discipline has to come from you, which is annoying, because boilerplate at least felt like progress, I know.

Clear package boundaries

Every package should have a single, defensible purpose. Importing a package should make semantic sense: import "user/service" says something. import "user/pkg1/internal/common/helpers" says you gave up and started a junk drawer.

Minimal public APIs

In Go, a capital letter exports. Think about what you export from each package. If you're exporting everything, you're not making choices. You're just shouting.

Dependency inversion where appropriate

This doesn't mean "use interfaces for everything." Premature abstraction is real. But when you have external dependencies (database, API, file system), invert them. Let the business logic define the interface the dependency must satisfy.

Small interfaces

The best interfaces in Go are two or three methods, max. An interface with ten methods is usually a hint that you're mixing concerns, or that you ported a Java interface and hoped nobody would notice.

Code reviews focused on design

Your standard code review checklist probably has: "tests?" "error handling?" "efficiency?" Add: "Does this dependency flow make sense? Is this the right abstraction?" Design is as important as correctness. Also easier to miss, because the tests still pass while the architecture quietly dies.

Closing

Architecture doesn't live in a programming language. It lives in the decisions engineers make.

Frameworks can enforce consistency. They can't enforce good judgment. Go just gives you fewer guardrails and assumes you'll use them.

Sometimes that pays off spectacularly. Sometimes it leaves you debugging a mess when you should be sleeping.

Either way, it's on you. That's not a bug in the language. That's the deal.

Portfolio Update, I Guess

Adam - The Developer ✨ — Wed, 26 Aug 2026 06:35:44 +0000

This isn't my main piece for the week, it's more of a "contributes nothing to knowledge" kind of post.

Last week I took another look at my portfolio and thought, "Hey, why not make this feel a bit more like me?" So I set out to give it a makeover, stuffed as much of my personality into it as I could, and et voilà, done.

The old one was kinda too formal.

TL;DR: I gave my portfolio a personality transplant. If you'd rather just look than read: a-thedeveloper.vercel.app

Vibe / Tone Option

By default, the professional option is enabled. But if you're not too sensitive and want to have a little fun, try toggling over to the unfiltered version of me, lol.

I don't actually talk like that in real life anymore, but having grown up speaking English, that's pretty much how I sounded back in my teenage years. I was a grumpy teenager like everyone else, the difference is I was extra grumpy compared to most. 😭 I also lost access to my Instagram account, so all of it is still sitting there, public, for anyone to see. Every day I hope that account just quietly gets deleted.

And if you're wondering whether that same energy has been erased, nope, it's still very much here. I just keep it contained to appropriate contexts now, lol.

I also found these while digging through my old microsoft drive, weird 16 year old me stuff. I actually said this in a debate, by the way. Can't remember if my team won that one or lost.

Weather Options

Kinda irrelevant to how it actually describes my portfolio, but I initially wanted to make rainy the only option, because I'm a big fan of dark, gloomy, cloudy weather — the kind that makes England look like heaven to me. 😭

Then I thought, why not just have all of them? So now each weather option comes with its own falling elements based on the selection, plus music that I feel fits the atmosphere.

Again, it doesn't really serve any practical purpose, but I think it's a nice little touch to have, haha.

DEV Writing Views with an API Key

When I joined DEV in 2023, I saw the option to generate an API key. I had no idea what it was for and didn't bother checking the docs, I just assumed that to display your articles on your own site, you'd need one. Turns out: yes and no. DEV already gives you a public URL you can use to showcase your articles without any API key at all but they don't give you the views.

I was browsing around and came across this article by @ketanchavan

and I thought, ohhh, maybe it'd be nice to show view counts on the articles displayed on my portfolio too. So I did.

With this block of code:

async function fetchFromUpstream(): Promise<DevToArticle[]> {
  const apiKey = process.env.DEVTO_API_KEY;
  if (!apiKey) {
    throw new Error("DEVTO_API_KEY is not configured");
  }

  const upstreamResponse = await fetch(DEVTO_PUBLISHED_URL, {
    headers: {
      "api-key": apiKey,
      Accept: "application/json",
    },
  });

  if (!upstreamResponse.ok) {
    throw new Error(`Failed to fetch dev articles (${upstreamResponse.status})`);
  }

  const payload = (await upstreamResponse.json()) as DevToArticlePayload[];
  return mapArticles(payload);
}

I got this!!

Beautiful!!!

Finally, The Archives

Of course I know version control, but it's way better when I can see all of them at once, in pictures.

I've changed my portfolio's design multiple times over the years, ever since I first built one back in 2023, just two years into my professional career. Yeah, I already had a portfolio after landing my second job as a software engineer. Looking back, that's kinda crazy.

Greatness Is Forged by Limitation

Adam - The Developer ✨ — Wed, 19 Aug 2026 13:04:47 +0000

Can't believe I spent 2 weeks writing this.

Last week, I gave a talk at a Cursor community event about AI and how it's changing the way we build software. The event went great, and after the talk, quite a few people came up to me for 1:1 conversations.

One particular guy caught my attention. He wasn't a technical person, but he asked me something interesting:

"With so many tools and technologies available today, how do you even navigate all of this and pick the right ones?"

He thought it must be overwhelming. Then he smiled and said that with so many options available, he hopes many great things be built.

I thought about it for a second and smiled too, and before I could answer, he had to leave... but his question stuck with mi.

A few days later, sitting in a library looking for something to read, I ran into an answer: UNIX Network Programming by W. Richard Stevens. (Great book btw, give it a read!)

90s tech, limited memory, limited processing power, limited bandwidth and limited tooling... etc.

Yet somehow, we got things like UNIX, TCP/IP, early operating systems, incredible mathematical breakthroughs, massive engineering projects, and some of the most elegant pieces of technology ever built.

It made me wonder:

What if the things that limited us were also the things that forced us to become better?
What if greatness isn't always created by having more, but by being forced to do more with less?

The guy assumed more tools meant a better shot at greatness, but the book in my hands was proof of the opposite.

The Paradox of Limitation

I believe there's a reason having less can sometimes make us better.

We usually think of limitations as something to overcome: less money, less time, fewer resources, less knowledge. All of it standing between us and what we want to achieve.

But there's another side to limitation we don't talk about enough.

A limitation doesn't just take something away. It also takes away what could have been.

And maybe that's exactly what we need. Because when everything is available, when every direction is possible, every tool is at hand, every approach is open to us, it sounds like freedom.

But freedom without boundaries can be surprisingly hard to live inside.

You give someone unlimited resources and they can spend a lifetime deciding what to do with them. Give them nothing and the question suddenly gets simple:

How much can I achieve with what I have?

That question changes how you think. You stop searching for the perfect tool, because it doesn't exist, and start building with what's in front of you. You notice details that would otherwise stay invisible, not because you're more observant by nature, but because you no longer have the luxury of not noticing.

Maybe that's the real gift of limitation. Narrowing down your options but also sharpening your attention.

Perhaps that's the paradox: the fewer doors we have, the more clearly we see the one we're standing in front of.

And btw, this isn't a new idea.

Constraints Force Creativity

The book

Let's take a look at Stevens' book for a moment. The book is essentially a walkthrough of the sockets API: socket(), bind(), listen(), accept(), connect(), read(), write(), and close().

That's the whole vocabulary for making two machines on opposite sides of the planet talk to each other reliably.

But Stevens didn't invent those calls. The Berkeley sockets came out of UC Berkeley's CSRG in 4.2BSD, around 1983. Stevens wrote the book that taught a generation of programmers how they actually worked.

He wasn't designing for a world of infinite compute. He was documenting an API built in an era of expensive memory, slow CPUs, and unreliable, low-bandwidth links and there was no room for mistakes, sprawling do-everything interfaces, or generic, accept-all contracts.

Every function had to earn its place.

And with those constraints forced upon the people who designed it, the result is an API so minimal and well-composed that, four decades later, in a world where none of those original constraints exist anymore, it's still the interface nearly every programming language wraps for networking.

Take Python's socket module, Node's net module, or Go's net package, they all trace their shape back to those same eight or so primitives.

The paradox in miniature: by not having the luxury of building something bloated, they had no choice but to build something timeless instead. BSD built it under scarcity. Stevens documented why it was that tight.

And of course, this is also what surprised mi when I decided to pick up a book from the 90s. I expected it to feel dated but instead, I ended up learning a great deal from it, much of which I can still apply to the software I'm building today.

C

The language that started it all, laying the foundation for everything we have today.

C is a good example here, a language so elegant yet it gives you remarkably little. no GC, no elaborate standard abstractions, no safety net between you and memory. want something? you often have to understand what's happening underneath.

By today's standards, we'd call it unsafe or labeling it a weakness but that limitation also forces a certain kind of thinking, you have to pay more attention to details, you become more conscious of memory, data layout, ownership and what the machine's actually doing.

The language doesn't give you many options or answers but it makes you ask better questions and make better, timeless decisions.

Go

Let's come back to the future, let's look at Go. Go takes a different direction, Its constraints weren't imposed by hardware, they were largely chosen by its designers.

With all the things available by its time, the language was designed with its featured kept deliberately minimal & simple. syntax wise, type system wise, fewer ways to express the same idea.

When a language gives you fewer ways to solve a problem, you spend less time debating which clever abstraction to use and more time solving the problem itself.

Go's restraint is the feature, What it leaves out is just as intentional as what it includes.

Music

I play the piano, so this one isn't theoretical.

Today you can put a DAW, a thousand plugins, and an AI vocal fixer on a laptop and make a record anywhere. In the 70s and 80s, a lot of that work was physical. Cut the wrong stretch of tape and it was gone. Limited tracks, limited studio time, expensive gear. The band had to know the part. Screw up a take and sometimes everyone started over.

When recording time costs real money, you don't spend six hours on a snare. When you have eight tracks, you decide what deserves one. You can hear that in the records: the performances, the imperfections, the decisions.

I'm not arguing we go back to splicing tape. I'm saying the constraint did work that infinite undo doesn't.

The Problem With Having Everything

Abundance can create complacency, endless choices... which creates the temptation to solve every problem by simply throwing more at it.

Let's come back to our topic regarding AI. Like a modern DAW, I believe AI is a wonderful partner in our work. But next to that, it is also removing a great deal of constraints faster than almost anything we've seen before.

Just a few years ago, a requested feature would take around 1-2 months. Trying a different architecture meant actually building it. Rewriting a block of code took time, and if it wasn't mine, I had to understand the context first.

Now I can ask AI to do all of that in seconds. The thing that used to stop you was effort. When that cost drops, it's easy to stop asking whether you should do it at all. You generate five versions instead of picking one. You add another library because the model already knows it. You rewrite working code because the new draft looks cleaner.

The shift isn't "can I build this?" anymore. it's "Should I?"

When you have nothing, the limits are imposed on you. When you have everything, you have to impose some on yourself.

So What Do You Do With That

I never got to answer that guy at the event. If I could now, I wouldn't give him a list of tools.

I'd tell him more options don't guarantee better work and they just make it easier to never decide. The 90s didn't produce UNIX because people had more. They produced it because they had less, and less forced the work to get honest.

That doesn't mean throw AI away, or go back to cutting tape, or write everything in C. It means the environment won't hand you a limit for free anymore. If you want the sharpening, you have to pick one. Ship one use case. Let the model generate the boring parts and keep the core decision yours. Give yourself a deadline ugly enough that you can't keep adding.

Cap the stack this week.

Understanding Over Origin: The Missing Friction

Adam - The Developer ✨ — Tue, 04 Aug 2026 04:36:13 +0000

A few days ago, I wrote "Understanding Over Origin" and it got alot of engagement and I'm really happy that it did because it means people took the time to read, understand my perspective and I get to engage with every one of them in the comments as well. Of course, not everyone agrees but that's irrevelant, the point is a healthy discussion between various perspective from different developers around the world.

But what I haven't told anyone is this: the more I engage, the more I realized something that I still do. I still write a lot of my code by hand and those are the parts I'm more proud of "

Not gatekeeping, not me being nostalgic or identity-defensive ( well, a little nostalgic ), that's me admitting the article I published was incomplete.

Some conversations don't end when the replies stop. My discussion with @darkwiiplayer was probably my favorite of all because more we talked, the more I found myself wrestling with an incomplete idea that refused to stay unfinished and this essay is the result.

What the Discussion Clarified

First, I need to thank the people who actually engaged with the core argument.

@unitbuilds gave his take that seams everything together and concludes the core idea of modern software enigeering: " If it can run a standardized benchmarking suite against competition, it's provable and reproducible. If that's good enough for a scientific discovery, it's good enough for programming.", they're not defending AI, they're saying with better standards available, we shouldn't choose to ignore them. He also pointed out something I'd missed, the burden of correctness has always been on the developer who signs off on the PR.

@madsendev who wrote the original article that sparked this whole discussion, showed genuine class. He came back, said the argument had "gone further," and proposed an idea that's stuck with me: what if AI-assisted projects included a standard where you quiz yourself on your own repository? Not to prove you didn't use AI, but to prove you actually understand what you built.

@reidmarlow hit on something important and i think it's my favorite takeaway from the discussion: "Maintenance receipts are much harder to fake." That single sentence reframes the entire debate. Tests. Bug fixes. Production incidents. Responding to issues. Refactoring. Every one of those leaves a trail of evidence that someone not only built the project but continues to understand, improve, and take responsibility for it. That's the kind of ownership that matters. It's earned over time, and it's far harder to fake than explaining code in an interview or claiming you wrote every line by hand.

I'm absolutely grateful that people gave in their thoughts but you can never have a good discussion without a pushback ⚔️

the pushback's always my favorite part of any technical discussion.

The Challenge That Made Me Think

@darkwiiplayer showed up and said something like: "Training AI on stolen code without consent is theft. Everything built with AI carries that theft in its DNA. You're overlooking this."

She wasn't being rhetorical, she was actually making a philosophical point about training data, consent, and what "learning" means when it's done at scale without permission.

We went back and forth. I argued that training data and generated output aren't automatically equivalent to copying and she countered that if you removed all stolen code from training data, the models wouldn't exist as they do. Which is... probably true? And that matters.

I don't think it invalidates the engineering argument. But it does mean the conversation has two layers:

The technical layer: is the work maintained, understood, and good?
The ethical layer: how should we feel about tools built on potentially non-consensual training data?

Most people in that thread were debating layer 1 and she dragged me down to layer 2 into the conversation. Both are real. Neither invalidates the other.

But it also made me realize my original article didn't address why handwritten code felt different to me because honestly? it does.

The Real Tension

The argument I made: origin doesn't determine quality. Understanding, testing, maintainability, accountability, that's what matters.

My own experience reflects that. I started writing code around 2018, and back then the only AI most of us could name was Sophia, the humanoid robot from Hong Kong. I learned the traditional way: by writing everything myself. Even today, when I write code by hand, I understand it differently. More deeply. I notice edge cases I might have overlooked if I'd generated the first draft with AI. And when I'm done, I'm genuinely more proud of what I've built.

These aren't compatible statements if you think about them too hard.

Either:

My pride is just ego (origin bias)
Handwritten code actually is better (proving the gatekeepers right)
Both are true, but for reasons I didn't examine

@fromzerotoship helped me see option 3 clearly. They're not a developer but they've shipped 20+ working internal tools using AI. A hospital runs them. By my standards, they'd "fail" the understanding test, there are parts of their system they couldn't explain line-by-line.

But then they said something that shifted everything: "Demonstrable behavior under deliberate failure is another form of earning trust, and it's the only one available to me. It's also harder to fake."

Plant defects, watch the guards catch them, restore the guards and watch them go green and then deploy and check the URLs a few seconds later.

they demonstrate that they can keep it alive.

And that made me realize the real distinction wasn't about who typed the code. It was about friction.

The Friction Actually Matters

In my earlier piece I wrote a few weeks ago, I described not being able to write some logic from scratch despite reviewing it perfectly, that wasn't just skill loss. It was proof that I'd skipped the friction that builds actual understanding.

When I write code by hand, I encounter problems in real-time.

I hit a wall. My approach doesn't work. I refactor. I discover the problem space through constraint and failure. I make decisions about decisions, not just typing, but choosing between paths I've actually explored. this is the learning path that I unknowingly go through whenever I write code by hand and Wii reminded me of this.

When I use AI, I describe what I want. I get options. I pick the one that looks right. I'm curating, not exploring.

Both can produce good code. But the path to understanding is fundamentally different.

With handwritten code: friction, insight, better next decisions

With AI-assisted: selection, implementation, validation

The friction is the learning mechanism.

So when I say I'm more proud of handwritten code? I'm not being romantic about suffering. I'm noting that the code I'm proudest of is the code I fought for, and handwriting forces the fight.

But Here's the Problem With That Logic

If friction is the mechanism, then the type of friction matters more than who did the typing.

You could write AI-assisted code where you:

Fight with the prompt
Critique every generated option
Refactor aggressively
Hit walls and redesign

That has friction and it also builds understanding.

Conversely, you could hand-write code where you:

Autopilot through a familiar pattern
Never question assumptions
Copy-paste from Stack Overflow
Never understand why it works

That has no friction and it builds nothing.

So the honest version of my position isn't "handwritten code is better." It's: "friction builds understanding, and handwriting tends to create friction because you're forced to think through every line."

But that's a contingent truth, not an absolute one.

The Uncomfortable Realization

The critics ( gatekeepers, but we'll stick with this from now on ) were partially right and I was too generous in my original position.

Not about the gatekeeping itself, no, that's still wrong. But about the tendency: AI does make it easier to produce low-understanding code. Not because AI is bad, but because removing friction is literally what AI does, and friction is what builds understanding.

The answer isn't "use less AI" or "never use AI." It's "if you use AI to skip engagement with the problem, whether that's the code, the failure modes, or the maintenance, you build worse systems.

That applies to humans too but humans have an inherent friction cost, we get bored, we hate typing, we make mistakes. That friction is annoying, but it forces us to stay engaged.

So What Changed?

Nothing about the original argument was wrong. But I was treating "understanding + accountability" as if they were just checkboxes you could verify at the end.

They're not.

Understanding isn't a property you can inspect, it's a process and that process requires friction. Real engagement with the problem. Mistakes you learn from.

The reason I'm prouder of handwritten code is because I earned the understanding in a way that's harder to fake.

Does that mean every line should be handwritten? No. Boilerplate is boilerplate. Some friction is just noise.

But the core logic? The architecture decisions? The places where "understanding this code" actually matters? Yeah, I want to have fought for that.

And I want the same from anyone shipping code that matters.

The Uncomfortable Middle Ground

Here's where I land:

To the critics: You're using the wrong filter. "AI or no AI" doesn't tell you anything but you're accidentally right that there's something real to be concerned about, it's the laziness that AI enables, not the tool itself.

To AI enthusiasts: Yeah, your tooling is amazing. But it's worth asking whether you're using it to think better or think less. Those feel the same until you try to maintain the code six months later.

To myself: The pride I feel in handwritten code isn't ego, It's legitimate. every line that I typed out isn't some sort of magical unicorn mythological Godly line but it's the friction that comes with it, the learning I build that comes with it.

Sometimes the answer requires admitting you skipped and sometimes that's fine for routine work. But if you're building something that matters, you should want to have fought for it.

Choose Where You Fight

I still write a lot of code by hand. I still use AI every day. Those aren't contradictions anymore.

The original article was right: origin doesn't determine quality. What it missed is that understanding isn't a checkbox you tick at the end. It's something you earn through friction. Handwriting tends to create that friction. AI tends to remove it. Neither is inherently good or bad. Both are choices about how you engage with the problem.

So I'm not asking "Did you use AI?" anymore.

I'm asking: Did you fight for the parts that matter?

And if the tool answered that for you, you'll find out the next time something breaks.

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

267

217

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?