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).

Disposable code is here to stay by Charity Majors.

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.

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.

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.

Warranty Void If Regenerated by Scott Werner (via Valentine):

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.