It is not acceptable to bounce users on old browsers, users with bad network connections, users using assistive technologies. Certainly not from a monopoly public service. A lot of hype and noise is pressing us to extend the cowboy, wild-west phase of the software industry’s expansion. We should set that aside, and take ourselves seriously as a mature industry. Build a web application that works on a playstation portable on a 3G connection - if you do, it will work for all your users, and it will still work 30 years from now.

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.

I don’t want to go back to floppy disks. I like fast updates. I like security patches. I like sync. I like crash reports when they help fix real issues.

What I want is for “phone home” to be treated like a privileged capability, not an assumed right. In other domains, we treat privileged capabilities with care. We put them behind intentional choices. We build guardrails. And we treat abuse as a bug, not a growth opportunity.

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.

Early on, I picked up the habit of checking with him when some technical thing or other wasn’t working the way I expected:

• “I can’t connect to the thingamabob :(”
• “The whatchamacallit isn’t working :(”
• “How do I fix the doohickey?”
• etc.

Without fail, James’s response would be not an answer but a question, one that has shaped my thinking ever since:

What have you tried?

I just stuck that on post it note and stuck it to my monitor for tomorrow morning.

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.

This article explains how database indexing works in a way that feels hyper-targeted toward me: using a database filled with Pokémon.

A lot of technical people got really attached to our identities as smart kids. The software industry tends to reflect and reinforce this preoccupation at every turn, as seen in Netflix’s claim that “we look for the top 10 percent of global talent” or Coinbase’s desire to “hire the top 0.1 percent.” I would like to challenge us to set that baggage to the side and think about ourselves as normal people.

It can be humbling to think of yourself as a normal person. But most of us are, and there is nothing wrong with that. Even those of us who are certified geniuses on certain criteria are likely quite normal in other ways—kinesthetic, emotional, spatial, musical, linguistic, and so on.

Software engineering both selects for and develops certain types of intelligence, particularly around abstract reasoning, but nobody is born a great software engineer. Great engineers are made, not born.

I read this article twice last night. I haven't come across any article that spoke to my massive professional anxieties/impostor syndrome as well as this one.

One of my biggest pet peeves with being around smart people is when people explain things using big words. It feels like it takes so much more effort to understand tough concepts when they are saddled with jargon and ACT words.

I also enjoyed this point about building teams:

We place too much emphasis on individual agency and characteristics, and not enough on the systems that shape us and inform our behaviors.

I believe a whole slew of issues (candidates self-selecting out of the interview process, diversity of applicants, and more) would be improved simply by shifting the focus of hiring away from this inordinate emphasis on hiring the best people and realigning around the more reasonable and accurate right people.

It’s a competitive advantage to build an environment where people can be hired for their unique strengths, not their lack of weaknesses; where the emphasis is on composing teams; where inclusivity is a given both for ethical reasons and because it raises the bar for performance for everyone. Inclusive culture is what meritocracy depends on.

Originally adapted from Ron Miller's Advanced Improv Practice Guide, and discovered at the bottom of jyn's incredible blog post titled "i'm just having fun", which is a must-read.

Before starting your daily practice routine, read and seriously consider the following:

A. DAILY AFFIRMATIONS

1. How fortunate I am that in this life I am one who has been allowed to create beauty with computer.
2. It is my responsibility to create peace, beauty, and love with computer.

B. I WILL BE KIND TO MYSELF

1. IT IS ONLY COMPUTER
2. No matter my level of development in computer, how good or bad I think I am, it is only computer and I am a beautiful person.
3. I will not compare myself with my colleagues. If they do computer beautifully, I will enjoy it and be thankful and proud that I live in fellowship with them.
4. There will always be someone with more abilities in computer than my own as there will be those with less.

C. REASONS TO DO COMPUTER

1. To contribute to the world's spiritual growth.
2. To contribute to my own self-discovery and spiritual growth.
3. To pay homage to all the great practitioners of computer, past and present, who have added beauty to the world.

D. RID YOUR SELF OF THE FOLLOWING REASONS FOR BEING A PRACTITIONER OF COMPUTER

1. To create self-esteem
2. To be "hip"
3. To manipulate
4. To get rich or famous

Here’s the paradox that makes this pattern particularly poignant. We’ve made extraordinary progress in software capabilities. The Apollo guidance computer had 4KB of RAM. Your smartphone has millions of times more computing power. We’ve built tools and frameworks that genuinely make many aspects of development easier.

Yet demand for software far exceeds our ability to create it. Every organization needs more software than it can build. The backlog of desired features and new initiatives grows faster than development teams can address it.

This tension—powerful tools yet insufficient capacity—keeps the dream alive. Business leaders look at the backlog and think, “There must be a way to go faster, to enable more people to contribute.” That’s a reasonable thought. It leads naturally to enthusiasm for any tool or approach that promises to democratize software creation.

The challenge is that software development isn’t primarily constrained by typing speed or syntax knowledge. It’s constrained by the thinking required to handle complexity well. Faster typing doesn’t help when you’re thinking through how to handle concurrent database updates. Simpler syntax doesn’t help when you’re reasoning about security implications.