Found myself nodding along during this entire article.

The vast majority of people in the software industry today were not in the industry in 2000. They did not experience ordering a floppy disk of software from a classified ad in a computer magazine. Or license codes on CD boxes. Or running a SparcStation server under the receptionists desk because that’s the only machine compatible with the business-critical software she used.

In short, most developers were professionally born into the era of SaaS and have never considered an alternative model. They have not even conceived that software could, or should, be sold in another way.

I'm excited to see what new business models pop up from this approach. Frankly, I am close to no longer needing to pay for a Claude Max plan with the way that open source models are performing on my M3 Max.

That era of building a viable SaaS business in a few months is gone. I mean, it technically still exists today but only in the arbitrage sense that the rest of the world hasn’t yet caught on to how quickly and easily software can be built. It’ll be gone soon, I promise.

If you could previously develop a new app in a few months, I can now build that by the end of the week—if not the end of the day. That’s especially because I don’t need to build any of the trappings of a multi-tenant app destined for the mass market. I can choose HTTP basic auth if it suits me. Or none at all. I might not worry about backups. I can host it alongside other internal apps with barely a glancing-thought towards scalability. I don’t need branding. Or marketing. Or billing. I can reuse internal design systems or let the AI run with whatever comes to its mind first.

The sophistication of the software I’ll produce this way is much lower than what an indie dev might have written 2 years ago. It’s not the same product—mine isn’t even a product—but it’ll solve my problem equally well. I don’t have to build the same amount of software to solve my problem that you do to deliver a solution to everyone’s problems.

You can see most of the software I've vibe coded for myself. I'm sure all of it will be useless garbage for you, but it's been hugely invaluable to me.

And most important of all: vibe coding from my phone has been the most fun I've had building software in decades.

Amid all this talk about the inevitability of “AI”, I think it’s okay for us to ask what kind of future we want, and then move toward it together. And it’s already happening across the industry. ProPublica’s guild conducted a strike earlier this year, in part to win contract language that would prohibit layoffs resulting from “AI” adoption. UK workers at DeepMind, Google’s AI Research Lab, voted to unionize, in part to block usage of their employer’s models in military contracts. Thousands of tech workers in the University of California system voted to unionize, and gained the right to bargain over the use of “AI” tools in the workplace. DAIR has released a hub filled with resources for people looking to push back against “AI” and automation at work.

I think we can figure out our future together, right now. And as Mandy reminds us, it all starts with conversation. We have to talk with our friends, colleagues, and coworkers. We have to talk about our concerns, and what we wish were different. We have to map out how we’ll collectively instrument change in our workplaces, and in our industries.

I want to fix this industry. I want you to have a place in it. I want us to have a place in it. Maybe you do, too.

So, really: what do you want to happen next? I’ve got some ideas, but I’d love to hear yours.

Before running all of these tests, I actually did this the old-fashioned way. With pencil and paper and thinking. This entire project was inspired by putting Blonde on an 8-track and from experience, I can tell you this is a hard problem. The trouble is, I can’t tell you how I did it. There’s some human heuristic I used, definitely not an algorithm, and I can’t write it down. This seems to be what humans in 1977 who gave a damn did too. This is not what the dude making the Sublime 8-track did.

So I can’t tell you how to do this without testing all possible permutations, but human intuition can get pretty close. This sort of thing has shown up in other fields, like Foldit, an online ‘let humans perfect protein folding’ game. Classical computer algorithms can only get so close, and humans watching these classical algorithms got frustrated when they saw a solution the computer didn’t. Humans can see stuff that classical algorithms can’t. And now there’s a dozen Nature publications to prove it.

But now we have LLMs. They’re also a black box, and if you throw enough tokens and context at them, they’ll out-perform humans. They won’t be able to tell you how they did it, either.

This isn’t a victory for humans over algorithms or LLMs over humans, or anything like that. It’s just a fact that a dead and derided music format left behind a benchmark where human intuition beat classical methods that wouldn’t be in a textbook for a decade after the work was done. And half a lifetime later, LLMs would outperform humans for reasons we can’t really inspect.

So that’s something.

This was such a cool experiment and a fascinating head-to-head comparison of LLMs vs. human in the esoteric domain of "8-track music production".

What we don’t yet know is how architectural coherence evolves over years in a fully agent-generated system. We’re still learning where human judgment adds the most leverage and how to encode that judgment so it compounds. We also don’t know how this system will evolve as models continue to become more capable over time.

What’s become clear: building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code. The tooling, abstractions, and feedback loops that keep the codebase coherent are increasingly important.

Our most difficult challenges now center on designing environments, feedback loops, and control systems that help agents accomplish our goal: build and maintain complex, reliable software at scale.

There's this very vocal camp of engineers on the internet who like to say things like "it was never about how fast I can type code" and share visceral takedowns of how sloppy and terrible vibecoding and agentic engineering codebases become over time.

I agree with their observations: over time, every vibecoded piece of software I've built becomes shelfware, artifacts of code which served a purpose but is no longer needed.

But I've been programming computers long enough to know that concerns about architecture and sane codebases end up bugging people so much that they invent new techniques to address them.

I am approaching agentic engineering just like I approached using a chainsaw for the second time in my life a couple weeks ago: by consuming a lot of videos and blog posts on how other people are doing it, and then running controlled experiments to see what works for me.

Information allows us to act more skillfully. Imagine you come to a fork on a road. Without a sign, you’d need a compass or a great sense of direction to choose correctly. But with a clear sign, you’d quickly know which road to take. The sign reduces ambiguity.

The Moylan arrow, too, disambiguates a choice. Pulling in on the wrong side of the pump is an annoying inconvenience. By making the driver smarter, the arrow improves the car’s UX. Critically, it does so without much cost to the manufacturer. That’s why it’s become pervasive.

The Moylan arrow works because it’s:

• Clear: legible and understandable
• Findable: located where you’re already looking
• Relevant: provides the exact answer you need
• Contextual: available when needed, but “quiet” otherwise
• Obvious: doesn’t need further instructions
• Cheap: of negligible cost to manufacturers

Jorge goes on to compare this list to the latest crop of chatbots and finds it comes up lacking.

I found this set of heuristics helpful:

Rather than ask, “how might we add AI to this system?,” consider the following questions:

• What is the person trying to do?
• Do they understand the system?
• What’s keeping them from choosing skillfully?
• What questions do they have? Which come up repeatedly?
• Which structural distinctions are ambiguous?

A must-watch video from Casey Muratori reflecting on the commencement speech where Eric Schmidt, founder of Google, was booed when encouraging students to adopt AI.

This is a case where he had direct decision-making authority during the time period when the very worst most dystopian parts of the technology business model were developed, perfected and entrenched.

He is giving this commencement speech to a group of students who have known nothing but that their whole lives. They're not like me. They didn't know a time before all of this. They didn't experience technology in the 80s or something like this. So all they know is the dark pattern version. All they know is the one where they don't own anything and their data is kept by other people and their behavior is tracked and their data is sold and they are targeted for advertising. That's what they know about technology. That's what technology is like for them and only that.

Eric Schmidt, one of the primary architects, is now looking them in the eye with a straight face and saying, "You should be enthusiastic about the next new wave of technology. You should want to be in the room and make decisions about how that new technology will go. And you should bring your humanity with you and your good judgment about how we can do things in a way that will benefit all of us and be good for all of us."

Well, yeah, but why didn't Eric Schmidt do any of that? He just said in the first part of the commencement speech that there were all these really bad things that happened on his watch and he was in the rooms the entire time. He was in one of the most important rooms where these decisions were being made and he either didn't want to or couldn't stop any of that from happening.

So if he wanted to pass on something valuable to these students... well, that would have been the thing. It would have been the introspection of what went wrong. Why did he fail? Why did he say "okay" to building this very bad aspect of technology on top of the useful tool? The parts that we all think are actually good. Why didn't he stop that part? Why doesn't he take some responsibility for it?

If you are gonna take credit (and win capitalism) for building Google, you gotta take credit for all of it. Looking back in 2026, was the invention of Google a net-positive for society? How about Microsoft, or Apple, or Meta?

(Props also for the excellent Tim Robinson reference, which captures the essence of what's going on here.)

A lot of the problem is going to come down to us. To be clear, I am cool with a lot of cognitive surrender. I don’t remember phone numbers anymore because my phone does that for me. I am happy my kids didn’t need to learn cursive. I am fine with calculators doing my daily math and my computer figuring out how to schedule my classes. These were once useful skills, but we were probably right to get rid of them.

AI is different because the technology is general enough that virtually any cognitive task can be offloaded into it to some degree. I don’t want to be too precious about writing: there is no principle that says a polished email draft has to come out of a human mind any more than a column of arithmetic has to. But we don’t want to give up everything, and that we mostly don’t know yet, for any specific task, what is important and what is not. Deciding that is going to be a real challenge.

My north star with technology is “am I making the computer do something useful to somebody?”

Useful, as Ethan Mollick touches on here, is the difference between “AI solved the problem for me” and “a personalized AI taught me this hard thing in a way that stuck for me.”

I’m not gonna dog on anyone who likes to write code. It’s therapeutic, it’s constant problem solving, it forces you to understand how something works.

I think software engineers tend to loudly express strong opinions that don’t meaningfully improve the problems that most people have.

AI, like every other tool, comes down to the human that is wielding it.

During the peak of mobile app madness, iOS and Android developers would often find themselves cornered by friends, relatives, and random people at parties.

“I’ve got a great idea for an app…”

More often than not, this dreaded sentence would be followed by a hard sell when the developer didn’t display adequate enthusiasm. If the developer didn’t act fast and feign the exact right level of approval — enough to communicate they ‘got’ the idea but not so much that they’d be asked to build it — the idea guy would advance onto hashing out NDAs, equity allocations, and asking when coding can start.

Recently, I’ve noticed the AI era is a bit different. The balance of power has shifted. Builders need domain experts as much as domain experts need builders.

You can no longer simply copy an app model with a few improvements or obsess over user feedback as you sharpen your prototype towards product-market fit.

To build a differentiated AI product you need training data and examples curated by a domain expert.

I don't think the role of a software engineer is going to go away, but I do think personally, I'm not gonna cut it anymore as "just a software engineer."

The real value is in pairing someone who knows how these AI systems work with someone who knows how to get deep with a real world problem.

So I guess what I’m trying to say is, the new workday should be three to four hours. For everyone. It may involve 8 hours of hanging out with people. But not doing this crazy vampire thing the whole time. That will kill people.

As an individual developer, you need to fight the vampire yourself, when you’re all alone, with nobody pushing you but the AI itself. I think every single one of us needs to go touch grass, every day. Do something without AI. Close the computer. Go be a human.

I’m convinced that 3 to 4 hours is going to be the sweet spot for the new workday. Give people unlimited tokens, but only let people stare at reports and make decisions for short stretches. Assume that exhaustion is the norm. Building things with AI takes a lot of human energy.

I’m so glad somebody is saying this out loud.

But by weeks 7 or 8, one team hit a wall. They could no longer make even simple changes without breaking something unexpected. When I met with them, the team initially blamed technical debt: messy code, poor architecture, hurried implementations. But as we dug deeper, the real problem emerged: no one on the team could explain why certain design decisions had been made or how different parts of the system were supposed to work together. The code might have been messy, but the bigger issue was that the theory of the system, their shared understanding, had fragmented or disappeared entirely. They had accumulated cognitive debt faster than technical debt, and it paralyzed them.

A very appropriate piece for me right now (thanks for sharing it, Simon!).

I set off earlier this week to build an iOS music player. It seemed like an ambitious-enough project that would help me become a better agentic programmer, using an idea that interests me deeply yet I’d realistically never be able to tackle this on by myself.

What I learned was that the glitz and glamour of seeing tokens fly by and then seeing code materialize into existence is addicting. It feels like a slot machine: perhaps this spin will be the thing that eliminates the UI lag! … ope, nope, just ran completely out of tokens. Better upgrade to Max!

I also learned that I’ve been missing something in my life: the joy of making something. I remember seeing my Plex library show up on my iPhone inside the app for the first time. It reminded me of how it felt when I figured out how to change the Windows 95 “It is now safe to power off your computer.” screen back in the day. I made the computer do that!

But yeah, cognitive debt.

I got the MVP up and working, but then attempted a refactor that left the whole codebase a giant goop of spaghetti. I wasn’t paying any attention to the architecture of the app, and pretty soon, I found myself with three different queues for storing media. Completely untenable slop.

So I’m gonna wipe the repo clean and start fresh. This time, I will be armed with a better plan. One that allows me to be more close to the action, one that keeps me focused and engaged with the architecture.

Let’s see how this goes.