His shop was in a corrugated steel building on Highway 29, between a feed store and a Laundromat. It had a waiting area with four plastic chairs and a coffee machine that Tom had specified himself and which made coffee that was, by consensus of his clients, exactly adequate and no better. He’d tried to improve the spec three times. Each time, the regenerated firmware made the coffee subtly worse in a different way. He’d eventually concluded that coffee machine specs existed at the exact intersection of fluid dynamics, thermal management, and taste (three domains where natural language was particularly poor at capturing the relevant distinctions) and had stopped trying. He had, however, found a use for it: when new clients came in insisting that the software they’d generated was “basically fine” and “just needs a little tweak,” he would gesture at the coffee machine and say, “I’ve been trying to get that thing to make decent coffee for two years. You think your sixty-parameter irrigation optimizer is going to be simpler?” This was usually effective. People understood coffee.

A story about what it could look like when everyone generates their own software, how anyone can fix stuff but not everyone will do so in a way that’s maintainable or safe, and how the truest repairman will also repair man.

Computer mechanics is already a thing: the people who get called in to fix printers or set up computers when they’re really borked. So why not software? I think the customization stuff really will happen like this, just because it’ll be that easy. The machine can optimize, but that’s not the only thing that matters.

People who understand how things work will still be required, but maybe more like mechanics than the pure programmers of today. At the end of the day, humans get fired, not genies, so we gotta keep ourselves in the driving seat.

Steve’s description of Gas Town itself reads like a mash-up of social deduction game mechanics, control-plane software, and management theory. It feels, especially on the latter aspect, heavily designed in a modernist urban planning sense. Personally, for AI and agent-driven development, I find myself veering toward constraint-based approaches: establish invariants/laws and let agents explore within them. Gas Town can be read as an attempt to define invariants through roles that allow agents to make progress in an eyes-off/hands-off way. And so my first take is that it leans /hard/ into roles and division of labour. I keep wondering whether some kind of ‘physics’ or rubric-based approach might ultimately be the better primitives. To be fair, you have to start somewhere; there needs to be a bootstrap. And Gas Town, importantly, actually exists.

(my bolding), from reading and trying to understand more around vibe coding/agentic engineering this is where my thinking is heading too, but more for my own work rather than designing a system like Gas Town.

I also found this writeup matched what I had been picking out from looking at Gas Town so it makes me think I’ve understood things, at least it aligns with someone else’s digging. 🙂

On re-reading, I noticed, or felt, a serious underlying urgency, even anxiety to Steve’s post.

I have to agree with Bill on this too, there seems to be something of urgency at work. 🤷

Because I got a bit shy from burning tokens Thursday (which turns out to have been a bug with Anthropic and they reset everyone’s quotas) I have been trying to learn more around vibing and I’ve been using beads alone to understand the concepts. And what I’m doing right now is creating the first constraints/invariants, or principles as Steve called them, and will see how the design of the system I want to build turns out when I let it loose tomorrow.

I believe I have overdesigned, but it was fun doing, so there’s at least that, and I hope I’ll have the first couple of constraints in place soon so I can try and run through some actual design work. Or we start over.

I want to admit that this AI/human me, this centaur me – my human understanding is on occasion limited. I lean on the AI quite a bit. Perhaps it isn’t genuine understanding. A tricky question in epistemology. Let’s not even talk about the AI understanding something, or not.

I do know this. I’ve always leaned on other people’s understanding - I’ve reused computers, programming languages, software libraries, implemented algorithms from books and wikipedia. I’ve used search engines. This is more broad than software development. I am limited and don’t understand everything about the world as it’s far, far too much. I stand on the shoulders of giants.

And that’s okay. I’m still empowered.

Let this empowerment sink in. Have you realized what this means? Have you realized what you can do now as a software developer?

I can use AI to do more. Not be more productive, that’s boring and that’s debatable.

Amen Martijn. I saw someone saying that if the AI tools worked really well, then employers would be forbidding them because people would be using them in order to work less. Because if you have an expectation of what could get done, then if you find a way of getting it done faster so you can go home, isn’t that okay? But for some group of employers that’d be tantamount to stealing!!1one

Now, there is a counter to this argument, Steve Yegge says in The AI Vampire:

Now let’s look at Scenario B. You decide instead that you will only work for an hour a day, and aim to keep up with your peers using AI. On that heavily reduced workload, you manage to scrape by, and nobody notices.

In this scenario, you capture 100% of the value from your adopting AI.

In this scenario, your company goes out of business. I’m sorry, but your victory over The Man will be pyrrhic, because The Man is about to be kicked in The Balls, since with everyone slacking off, a competitor will take them out pretty fast.

I don’t know, maybe? I think there are certain types of jobs that will absolutely end up folding if they keep at current levels of work done without change. History shows sitting on an advantage without adjusting is not optimal for survival. And to be fair, Yegge’s post is against the grind culture and about finding a balance augmented by AI and to not become a hollow shell that commands the genie.

At the same time, I’ve started my own company, and I’m doing my best to not grind like I did working for others. I do have some runway from that work, but I hope there’ll be enough work coming in (or products built that makes money) that I’ll make do.

Instead, I have some work that helps me stay afloat, and it has given me time where I can play and explore. Maybe I can leverage it soon, maybe it becomes a rusty tool in the toolbox, or the cornerstone for something new.

Either way, I’m becoming more, as Martijn said.

We inherit. We understand. We stabilize. We extend. We improve what we can without destabilizing what already works.

This kind of work rarely attracts attention. It looks like incremental improvement and steady compounding over time.

But if most of your career is going to be spent in the second act, then the real question isn’t whether you get to start something new.

It’s whether what you inherit gets better because you were there.

I fully agree with Robby, the big piece of what we do day-to-day is making sure we have a better tomorrow in the systems we’re part of maintaining, and that’s the lens we should be looking through.

For example, right now I’ve been working on an old system that’s great at what it does and the business is happy with it, but it’s not much fun to maintain. I have been using genies to help me and it’s been a world of difference in how long it’ll take to work on.

Yet, I spent a couple of hours yesterday manually verifying a long list of numbers to ensure we didn’t break any calculations or displays in the workflow I have been changing. Because the system is a legacy one per Michael Feather’s definition: it didn’t have any tests before I started working on it, and it’s my name on it, so as we’re about to take it to production I need to do my best to ensure it will work. That’s the work.

Generative systems only work if invariants are explicit rather than implicit. Interfaces must be real contracts, not incidental boundaries. Evaluation must be ruthless. Failures must be loud and immediate. The engineer’s job shifts from typing code to specifying intent and verifying outcomes.

This is very much how I’m currently thinking about working with AIs. I have been using genies to work in a legacy codebase (defined as no tests) I’m new to, and in a language and platform I have barely worked on, and I’m being useful.

I think it’s because I decided to introduce tests to the codebase, verify the existing behavior for the flow I’m changing, and then write my new feature as a failing test. Then the genie has been able to iterate while I think about the changes and how they could fail.

For example, we had to move some columns into a new table, and while the code kept the if null then 0 pattern that existed, I worried it might be overly “safe” and that it would return 0 because the relationship hadn’t been loaded. So we traced through all the call sites to see that we also loaded that relationship from the DB, and the genie gave me a report I could follow and easily verify.

The twist compared to straight up “the opposite of this” is that there are “forbidden words” that you’re not allowed to use, and only 100 characters.

I like the distinction between disposable and durable code: it’s about whether you try to make the code maintainable or not. Most code when working at a company is durable code, because the outcome when we get it wrong is so high (even if it’s just the risk of losing money or at worst, our job).

And the idea that we can experiment, create POCs, the 10 variations of an idea to see which one works better… that’s great. Work with the genie and figure it out, then spend the proper time and effort making it durable.

Durable code is used when the stakes are high, the losses are material, the ripple effects of failure or performance changes throughout the system are complex and unpredictable. Highly regulated industries require durable software.
[…]
Here’s one (unscientific) rule of thumb: the lower on the stack you go, the closer you get to laying bits down on disk, the more dependable and predictable our software has to be. Databases and operating systems will be durable code til the stars die out.
[…]
The difference between disposable code and durable code is not about whether the code was generated by AI or written by a human, or even how difficult it was to write. The cost is defined by the standards you are building to, and the rest of the software development lifecycle: how well you expect to maintain it, extend it, migrate it, understand its behavior, or fix it when it breaks. This is the expensive part of software development, the type that requires deep expertise and familiarity with your language and environment. Disposable code is cheap because you don’t even try to maintain it.
[…]
This isn’t about “using AI” vs. “not using AI,” or even about generating code vs. not generating code. It’s about understanding the cost model and the risk profile of the type of development you’re engaged in.
[…]
If it’s easy to achieve proficiency with disposable code generation tools, it probably won’t be thought of as software development (and the pay scale will drop accordingly). If I had to guess, I suspect it won’t be a profession at all so much as a skill set, much like typing or spreadsheets, that any tech-literate modern worker is expected to pick up in order to perform the functions of their job in marketing, sales, product, design, etc.
[…]
The coordination tax on large groups is enormous; if AI can help a smaller number of engineers own more product surface and move faster with more confidence, that’s exciting.

As Charity says, I think there likely will be changes in what programming, or rather, software development, is. Just as it did with typing before, a skill every office worker just need to have. Not that all of us are writers, just because of it.

I’m also excited at how working with a genie might open up codebases, so you need fewer people to own and maintain larger codebases (because maintenance is in communication within a team).

For example, I recently contributed to a new codebase in relatively little time and it was done so fast to the genie figuring out where to make changes. Even if I had to change most of it, because the quality wasn’t at the level where I wanted to put my name on it.

I’ve been writing about how AI is likely to affect white-collar (or no-collar or hoodie-wearing) computer programmers […] Think about a random colleague you don’t feel particularly strongly about as you read the following pithy and reductive bullet points. […] They’re going to be screwed if they exhibit:

• Curiosity without skepticism
• Strategy without experiments
• Ability without understanding
• Productivity without urgency
• Creativity without taste
• Certainty without evidence

I recently said that I think curiosity is what makes a good software engineer, and gave examples of when/how they should be curious, but never pointed out that it has to come with a balancing function.

I can’t think of anything done 100% full-throttle that isn’t detrimental without something to balance it, but it’s tacit and not something I often think about immediately. For example, if you live your life 100% in service it will be limiting, a bit of selfishness is required, see Doug Forcett from The Good Place.

Kent Beck has a subscriber post called return of Multi-tasking? where he’s realizing he’s more often working on different things across a day now that he’s working with genies. Less time doing clackety-clack and more time thinking about next steps (or napping for epiphanies).

I’ve noticed the same pattern, this “productive multi-tasking” where you shift to something else when you’re stuck or “cogitating in the background.” Whether it’s waiting for feedback, getting help from the CI team (why won’t their plugin inject the AWS credentials it’s supposed to?), or just running out of brain juice and needing to let things percolate (which I want to remember Slow Productivity also recommends, especially for more nebulous work).

…because someone said in a meeting to use the lemons to make lemonade and this started shouting in my mind

Debian today supports a huge number of commands; my modest Ubuntu laptop shows several thousand available:

$ apt-file search -x ‘^/usr/bin/[^/]*$’ | wc -l
21733

The solution was obviously to adjust my command names in such a way that they were still easy to type, but would never be chosen as system command names.
[…]

There was but one character left: the simple, modest comma.

A quick experiment revealed in a flash that the comma was exactly the character that I had been looking for! Every tool and shell that lay in arm’s reach treated the comma as a perfectly normal and unobjectionable character in a filename.[…]

And, best of all, thanks to the magic of tab-completion, it became very easy to browse my entire collection of commands. […]
I simply type a comma followed by tab and my list of commands appears

People keep telling us life is not about the destination. Life is about the journey. But when we think about AI, we only think about the destination. And it’s remarkable ability to write the book, paint the painting, solve the problem, but we forget the importance of doing the work yourself.

And I think in our modern day and age, we have underrepresented the value of struggle. I am smarter, better at problem solving, more resourceful, not because a book exists with my ideas in it, but because I wrote it. That excruciating journey is what made me grow.

But it’s the same for love, friendships, conflict. And I think that we forget that we give up certain skills or abilities because of technology.

The struggle is the point. More people can generate a mediocre painting or write perfect English now, but they won’t understand the beauty behind either without doing the work. And it’s our prerogative to decide which struggles matter to us or if we just wanted something nice to hang in the toilet.

[…] They will cease to exercise memory because they rely on that which is written, calling things to remembrance no longer from within themselves, but by means of external marks. […]

One thing we’re not doing as effectively today as we’ve done in the past is to learn lessons by heart. If you don’t know things with perfect recall, how can you expect to apply them?

Socrates goes on to compare a written text to a painting:

You know, Phaedrus, that is the strange thing about writing, which makes it truly correspond to painting. The painter’s products stand before us as though they were alive. But if you question them, they maintain a most majestic silence. It is the same with written words. They seem to talk to you as though they were intelligent, but if you ask them anything about what they say from a desire to be instructed they go on telling just the same thing forever.

That last bit especially, “if you ask them anything… they go on telling just the same thing forever.” This all sounds exactly like how we’re talking about genies today, and… we’re probably going to be fine.