Thoughts on Welcome to Gas Town by Bill de hÓra:

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.

Becoming More by Martijn Faassen:

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.

Most developers don’t build new things by Robby Russell:

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.

Relocating Rigor by Chad Fowler (via Muthu).

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.