When the Robots Came for the Coders

On two pieces by Thomas Ptacek (Fly.io) and the Nilenso team, June 2025

I've been mulling over these two AI programming articles: Fly.io's combative defense and Nilenso's measured playbook. Two manifestos on what it means to be a software developer in 2025.

The surface disagreement is one of tone. Fly.io dismisses AI skeptics as working "out of spite," while Nilenso acknowledges some legitimate concerns. The interesting part is what neither of them says.

You Can't Refactor a Chair

Start with the analogy:

"Do you like fine Japanese woodworking? All hand tools and sashimono joinery? Me too. Do it on your own time."

The message is clear: stop treating enterprise software like your personal art project. We're here to ship features, not erect code cathedrals.

Of course, nobody's paying a premium for hand-typed forEach loops. (If you are, please reach out, I have some Java Bridges you can buy.) The master carpenter makes one table at a time; I can now generate entire systems in a matter of hours. You can't refactor a chair (right?). Code is infinitely malleable, which makes the initial "craftsmanship" less important than we thought.

But that malleability is exactly why the craft does not disappear. Code that gets rewritten constantly lives or dies on whether the next person can follow it. I've always scoffed at the old Wordpress motto, "code is poetry." No, software engineering is making systems that work, that other people can understand, and that can change over time. AI does not destroy that skill. It just makes us say what the true craft is.

Kids These Days

There is a throwaway line in the Fly.io piece:

"Kids today use asynchronous agents—wake up, assign 13 tasks, return to 13 PRs."

I tried it. Not 13, but five. By lunchtime, I had reviewed three times more code than I had written that week.

Is this what the future looks like? Probably. Is it okay? I honestly do not know.

The Nilenso folks say slow down, make small commits, and maintain standards. And of course they're right. However, something is intoxicating about the sheer velocity of "vibe coding". Like the difference between carefully composing an email and just firing off texts. Different kinds of communication...

Left Unsaid

Both articles dance around the idea that being good at writing code and typing out elegant solutions is becoming less valuable. I spent years honing my skills in this area. And now? Now I watch an AI do it faster, and, let's be honest, often better. How do we address the wounded pride of the thousands of smart Alecs who put in the time? What are our damaged egos not seeing?

Mental Models and Mediocre Code

Nilenso says software engineering is "the art and science of maintaining a large body of well-defined mental models that achieve a business or economic need." Inspirational! This is probably true.

Fly.io puts it flatter: "Mediocre code: often fine." Also true.

Those two quotes look like opposite positions but aren't. Fly.io's claim is selective: "Not all code is equally important. Some code should be mediocre." Deciding which is which is what Nilenso means by a well-defined mental model. One says it with a shrug, the other with reverence, and the skill underneath is the same. (Hint: still not typing.)

Hallucination Nation

Fly.io claims hallucination is "solved" through iterative agents that compile, test, and fix. Nilenso doesn't talk hallucination at all. Nilenso does say that "tests are non-negotiable, and AI removes all excuses to not write them."

Do you think hallucination is fixed? Examine what the compile-test-fix loop needs from you. Compiling needs nothing: an invented function signature dies on contact. Running the tests is free as well. Writing them is not. Somebody must write those tests, and they have to be good enough to catch what the compiler can't. Fly.io's answer is that an agent can spend hours "putzing with your tests in a VM" and come back with a PR, but refactoring tests presupposes tests worth refactoring. What helps the human helps the AI.

In reality, the severity of hallucinations depends on the context. Strongly typed languages catch more errors. Sophisticated agents reduce impact. But for critical business logic, you still have to read every line. You're still responsible. The agent is just very fast fingers.

Where This Leaves Us

I don't have a clean ending here. Neither do these articles, really. Fly.io wants me to drink the rocket fuel. Nilenso wants me to cautiously invite a few robots over for tea.

So what is the craft of software engineering in 2025? I think it looks like this:

1. System design (irreplaceable and increasingly valuable)
2. Code quality judgment (still yours, and harder to hand off than it looks. harder to do on code you didn't write)
3. Code writing ability (rapidly commoditizing)

The developers who thrive will be the ones who can keep a pile of AI agents pointed in the same direction without losing track of what good looks like. Two years ago the throughput I got yesterday would have seemed absurd.

Once you get over the existential crisis of watching a machine beat your worst work every time, it's exciting. I spent yesterday designing systems instead of debugging semicolons.

Put the two pieces side by side and the advice is nearly the same. Do not polish code in the small. Read the output yourself. Fly.io: "I have to read the code line-by-line anyways." Nilenso: "But do not replace human review!" The loudest combatant and the calmest practitioner land on the same method in different registers, which tells you the fight was mostly about temperament. But neither consoles the person who spent years getting good at the bit that is now a commodity like soy beans.

And at least they can't write good blog posts yet...