“They didn’t care that they’d seen it work in practice because they already knew it couldn’t work in theory” - Clay Shirky

I complain about AI frequently on this blog, but not because I don’t think it is useful. I use it quite frequently on my day to day. But what I hate is hype and fake narratives. In fact, I believe that the opposite of their narrative will come true.

Technology will continue to improve whether Moore’s Law becomes a relic of the past or not. It’s been called dead, yet CPUs and GPUs are becoming faster than ever. I do not believe for one second that developers with pre-LLM experience will end up on the losing side.

And if technology continues to improve, then we won’t need OpenAI or Anthropic in the future. We will be able to load large open models right into our powerful personal computers with more than acceptable inference speeds. Unless you believe that computers have reached their zeniths and it is all stagnation going forward.

The gap between frontier models and open-source alternatives is already all about specialty, and it will continue to narrow. And when developers ubiquitously have access to local models, they will have access to everything.

Right now, companies are hoping that developers will use their AI and remain within their ecosystems. They're building guardrails, imposing limits, and designing their models to serve corporate interests first. They see developers as customers, not as threats to their business model. But I’ve seen how easy it is to switch from one frontier model to the next. In fact, some developers in my team accidentally switched by selecting the “auto” mode on their IDE. They didn’t realize that every subsequent request was from a different model.

It’s the developer who will end up benefiting from this far more than the corporations will.

One developer recently spent his evenings using an AI agent to reverse engineer every peripheral within arm's reach.

From those devices, I’ve come away with a full plaintext command shell inside my microphone, a webcam whose activity LED I can switch off while it records, and a key light that hands out memory writes to anyone on the WiFi.

He documented the entire process, implemented his own firmware update utilities, and completely enumerated the functionality of devices that were never designed to be user-serviceable. AI gave him the ability to fully control hardware that he has paid for in his own terms.

Another developer created OpenLogi, a local-first alternative to Logitech’s software used to remap your own mouse button. The manufacturer was forcing users to create an online account to have access to the hardware they had paid for. OpenLogi gives full control back to the user.

This is what happens when developers have the tools and the motivation to bypass corporate control. And AI is about to make this kind of reverse engineering and alternative-building dramatically more accessible.

At the speed of large language models, an activist could create a brand new rotating messaging platform every week to avoid the prying eyes of an oppressive government. Someone else can review his own model and add some self improving features. In fact, you could explore new AI paradigms.

Most developers I know have a side project they don't have time to work on. With AI, they will have the ability to execute on those ideas. These days, I'm able to run Deepseek on my own $400 local machine at a much slower speed, but I'm not in a hurry. Give it a couple years, I could run something even more powerful.

I don't need a project management tool where I have to pay monthly. My actual needs are much simpler. For example, I actually like Jira, despite how much I complain about it on this blog. But I don't need to have Jira for myself on my personal projects. I can build a tool that works solely for my needs.

I can easily build applications in environments I am not too familiar with but that are more appropriate for the task. I can build prototypes in a couple hours now and throw them away if they don't match my initial expectation. I can do so much more.

Dario Amodei and others are trying to scare us with the capability of AI. They sell the fear of superintelligent systems that will render human developers obsolete or dependent. But this is not what's going to happen.

What's going to happen is we will not need Anthropic anymore. Yes, they will have the high-end hardware. But we don't need high-end hardware the same way most people did not need a professional camera. All they needed was a crappy camera with a good filter to post on Instagram.

Flickr was superior to Instagram, but the superior technology lost to the one that was "good enough" and in everyone's hands.

The funny thing in all this is that by making everything AI-dependent, by building their moats and their guardrails and their API toll booths, companies like OpenAI and Anthropic are selling foot guns. They are building the dark fibers of our era, the infrastructure that developers will eventually subvert, repurpose or simply bypass. Because eventually, we won’t ask for permission. We can just do whatever we want with tools freely available to anyone.

We own our devices. We own our data. And soon, we'll own the intelligence on our own terms, without a subscription fee and without a corporate overlord. At the very least, we will get free GPUs.

My job was data entry at a non-profit. It was my first job in the US where I didn't have to lift heavy objects. My main task was entering collected donations into a database. The data source was email attachments, which came in various formats. Excel files, Word files, and some directly embedded in the email body. The database itself was FileMaker Pro.

Every part of the process was wasteful. To receive the emails in the first place, I had to call the person who collected the donation, argue with them, and guide them through the process of emailing me the information. The donations were collected at events, and the data was often just handwritten on a note. Once I got the email, I would extract the content from the attachment and organize it into an Excel file. Then I would manually enter it into the FileMaker database, one row at a time.

In a full workday, I could process no more than a dozen entries. So I decided to improve the process.

I started from the end. Entering data into the database was error-prone. I had to enter the name, address, donation amount, and a plethora of other information into a single row of a database viewer, and I often put the wrong data in the wrong column. So instead, I created a form with validation.

I built a standardized Excel file where the people collecting donations could enter data directly into the correct columns and send it to me. This turned out to be too much to ask. Several people didn't know how to use Excel, and it became a nightmare of technical support. Eventually, I switched to a formatted Word document. Annoying, but it worked.

Lastly, I created a process. Every Monday, I would email everyone to remind them to send me their donations by Wednesday, so I would have plenty of time to enter them on schedule. The deadline was arbitrary, but it slowly hardened into policy.

My system was a success. I was entering hundreds of donations every day. In terms of productivity, I had more than 10x'd my output, which I thought was a good thing, until I started getting noticed.

What have you done for me lately?

My productivity machine's knob had been dialed to 11. But I had also set the new standard for how much needed to get done in a day. So my manager hit the reset button. The dial went back to zero, but the expectation stayed exactly where it was.

It's funny how that always happens. Increased output never turns into more free time. Instead, it becomes the new normal. Anything less looks like a drop in productivity.

These days, with AI common in the workplace, every semi-technical manager has started building apps themselves instead of taking requests to the dev team. They get a rush from how much code they can produce, and they enjoy that high for a while. But they fail to see that the productivity gain only exists at the very beginning, before the app is actually in use. Once people start using it, you don't get to regenerate the app from scratch every time you want to add a feature. Instead, you have to add things slowly and carefully, without breaking what already works. All fields start green, but they brown eventually.

When you get an extremely productive teammate, you start looking at the rest of the team as time-wasters. In fact, once you get used to what that teammate produces, you start treating it as the baseline and eventually you ask, "What have you done for me lately?"

I was let go from that job in a little celebration, right after I'd trained my replacement. One morning, my manager simply announced that it had only ever been a summer job, and summer was ending. So my last day was set. I was too green to point out that this had never come up during hiring, and that I'd actually started well before summer began. They brought cake on my last day.

What they failed to see was that my process was still very much manual. My replacement was let go when she couldn't manage more than a dozen entries a day. So much for productivity gains.

I remember being in the middle of debugging my code when I copied an error and pasted it into Google. Right there in the search results, below the clearly marked sponsored link, was a link to Stack Overflow, where a user had previously faced the exact issue I was facing. I clicked on it and got "Error 503 Service Unavailable."

Two seconds later, I was on Reddit, checking if SO was down for everyone else. Then Hacker News. The memes started flowing shortly after. Developers were touching grass for the first time in years. Productivity was down 100%. If there were any way to measure the success of a company, that would be it.

Stack Overflow went from receiving hundreds of thousands of programming questions a day to less than a thousand today.

Stack Overflow never positioned itself as just another Q&A forum. It wasn't ExpertsExchange. The whole point was that it would be a place to find answers first, then ask questions if you couldn't find what you needed.

To me, it means mission accomplished. We've documented all the ways software could fail, and it became a helpful resource for everyone. That's a successful product, and the founders sailed into the sunset. Jeff is out there making the world a better place.

But in our business-driven world, what's the next successful product? They failed to come up with one. Yet, given their founding principles, I think Stack Overflow should have been the perfect candidate to build an AI coding assistant.

Why Cursor, Delve, or even Copilot, when you have all the world's programming Q&A at your disposal? And a permissive license on top of that. Imagine an IDE where you could contribute back to the pool. You face a challenge, you use the LLM to help resolve the problem, and you contribute your final solution back to the collective community memory.

I don't know about you, but I was a big fan of the badges you get on SO. I even bragged about them on my resume. Joel promised me an "I Met Spolsky" badge, but I think he may have forgotten about it. One of the reasons people contributed to SO was for recognition, the thank-yous, and its competitive nature. Imagine an LLM that helps users and gives credit to those who contributed to the solution.

Stack Overflow isn't dead as a business, so I don't think it's too late for them to develop a new product. Currently they have an AI assist button, tucked in a sidebar, an AI benchmark tool, and an MCP server for some reason. I imagine these aren't their most prominent features. You have to deliberately look for them.

Stack Overflow is the perfect company to create a developer-centric IDE that can leverage all that Q&A data to improve developers' workflows.

...this almost sounds like a pitch.

Are you a robot?

They are not robots. But after fifteen minutes of squinting and trying to select all the fire hydrants and traffic lights, they gave up. Defeated by a checkbox, they returned to the stars.

To escape, each of us had to find clues in our own cell to figure out how to open the doors. We each had to find an object that solved a piece of the puzzle, and once we put them all together, the door would open. As a first challenge, it was easy enough. Everyone found a brightly colored object in their room and described it to the team so we could piece it together. Everyone but one team member.

"Come on, read it, man, we can win this."

He froze. Someone jumped in to help: "Mine was the most obvious green object in the room. Just look for something bright. Maybe blue, or orange, something that seems out of place." He didn't respond. He just sat there, frozen on camera. We figured he was having internet connectivity issues. We waited a good five minutes before he finally found it, and we moved on to the next level.

I didn't think much of that day. We finished the game, we had fun, it was great. He waited until our next one-on-one to explain what had actually happened. He panicked, and he was embarrassed. It turned out he was colorblind. We were yelling random color names at him, and he couldn't, for the life of him, see any of them.

As far as I can tell, I'm not colorblind, and it never would have occurred to me that this was something to account for. Just last week, I learned about Vehicle Motion Cues on the iPhone, a feature that helps reduce motion sickness. I don't think I've ever experienced motion sickness myself, or at least never in a car.

Watching a blind person navigate a website was eye-opening for me. I realized that many of my past design choices would have worked against their experience without my ever knowing it. The same goes for someone navigating a computer entirely by voice. I recently rediscovered Windows Speech Recognition, which I found pretty annoying for my own needs. But for someone who relies on it for all of their computer use, it's an essential tool.

A coworker once mentioned, almost in passing, that she struggles to read certain fonts because of dyslexia. Tight letter spacing and low-contrast text make some of our internal tools nearly unreadable to her. I had picked those fonts because they looked good on a demo slide. It had never crossed my mind that a font choice could be the difference between someone reading a document easily and someone giving up on it entirely.

In some of our zoom calls, a teammate would often ask if he could do audio only before the call. While it didn't bother me at all, the managers kept insisting on everyone turning on their cameras. But after he used the camera for a few minutes, his connection would start dropping. I just assumed he had slow Internet. But the reality was he was located in a rural area and he relied entirely on his phone's hotspot to connect to the internet. The zoom call was using up all his data in minutes.

None of these problems were problems for me. That's exactly what made them invisible. Unless you are experiencing these issues, there's little reason to ever notice them. We tend to design our tools, our meetings, and our expectations around our own experience of the world, and then mistake that experience for the default. It takes a colorblind teammate freezing on a call, or a friend who can't ride in the passenger seat without getting sick, to remind us that "normal" was only ever normal for us.

You can never anticipate every invisible problem in advance, that's impossible. But at the very least, we should remember that our own experience is rarely the default. We should be a bit more curious on how others experience the tools we build.

But for some reason, it's different with AI. If nobody's using it, the assumption is that employees aren't being productive enough. So we got signed up for mandatory training. There was limited space, but I moved fast and got a spot. I'd been using ChatGPT since it came out, so I was hoping the training would turn me from a casual user into a pro.

Instead, we were shown how to copy and paste data from Excel and other sources into the chat interface. We worked with sample data, and there was always someone in class who'd say "mine didn't work." The developers in the room asked about Codex. The OpenAI-certified instructor replied that she wasn't a developer. There was an awkward moment when someone asked if we could just use Copilot, since it's already integrated into Excel.

I got my certificate. But I don't think I learned anything I couldn't have picked up with a free account on my own time.

What comes with a certificate, though, is the obligation to use the tool. I had a hammer, and everything looked like a nail. Whenever I ran into dense information, I'd copy, paste, extract insight. The great thing is that the result always looks neatly presented. I didn't have time to read the dense information in the first place, so of course I wasn't going to verify whether it was accurately referencing the source material. Besides, everyone was doing the same thing. I hate it when people use AI to write a Slack message, but at this point it's inevitable.

One time, after a meeting, I pulled the transcript and asked ChatGPT to organize it into action items and generate a Q&A based on the content. It gave me something very elaborate. Or at least it looked elaborate. I skimmed it and passed it along to the next person, who actually had to use it to research a project. What I failed to notice was that a large part of the document was hallucinated.

Some of the action items sounded technical enough to fool me. But to someone who actually had to work on them, they made no sense at all. I'm guilty of this, and it's become the norm. The same way we use large language models to write code as software engineers, the planning and architecting behind that code is increasingly written by LLMs too.

In my household, AI slop videos are strictly banned, to the point that my kids police their friends who watch that stuff. So when my son saw ChatGPT open on my computer, he asked if I was making BI Slop.

"BI Slop? What's that?"

"It's Business Intelligence Slop!"

I was so proud of him for recognizing exactly what I was doing. And I was so disappointed in myself, because that's exactly what I was doing. The same way we scrutinize code and refuse to merge PRs that are entirely AI-generated, we need to pay attention to the other ways we use these tools. Business decisions and plans produced by LLMs need to pass the smell test before they're accepted.

The issue is the same one. We merge large PRs because we don't have time to read them, then suffer the consequences later in unexpected ways. With business intelligence, we don't read the output because of its sheer volume, and we approve it because it looks good on the surface. Then, again, we suffer the consequences later in unexpected ways.

This is a problem created only because we were handed a mandatory solution: use AI to justify the line item in the spreadsheet. It only saves you time in the sense that you skip reading the output, and you do that because it looks good on the surface.

When you read the article a bit deeper, you can do the math. They donated one hundredth of that amount. So I wondered, why did they inflate the amount in the first place? It looked like a PR stunt.

This past couple weeks, I worked on a video to explain what really happened and how we should take this news.

Enjoy

Both the author and I are reading the article for the first time.

When an article is insightful I don't even mind the emdashes or that the stark truth is not X, but Y. A good take can transcend even llmism. But then you have questions, and somehow the author doesn't even know what you are talking about, it's simply because they are discovering the insight at the same time you are.

They were busy, they didn't have time to write. As a consequence, they only dedicated enough time to skim the result before publishing. They don't know what's in it. You can't ask them what they were thinking when they came up with the insight because, well, they didn't think.

The great article sucks because there is nobody behind it.

A poor man buys a cheap pair of boots for a few dollars. They fall apart within a year, so he buys another pair. And another. Over five years, he spends far more than the man who bought one expensive, well-made pair up front. A pair that's still going strong to this day.

And the lesson was simple: buying cheap is expensive. Buy quality, and you save money in the long run.

Now swap the boots for a jacket, a phone, a kitchen knife, whatever you like. In my experience, that used to be true. I have old clothing still hanging in my closet, and they still hold together. Price and quality were correlated. If a company was going to charge you more, it needed to justify that premium with better materials, better construction, better everything. The market punished brands that didn't.

But something changed along the way. This is just my own personal observation, but I'm sure you can relate: I pay too much for things that don't last.

When I was growing up, we separated the real from the knockoff with a simple test. You flipped the product over and checked the tag. If it said "Made in China," you knew it was a cheap knockoff.

Then, somewhat suddenly, that stopped working. Walk into almost any flagship store for almost any prestige brand today, and check the label. Chances are it says the same thing as the bargain version sitting in a discount bin three blocks away. They all come from the same factories, the same supply chains, and in some cases, the very same production line. It's not the quality of the product that determines the price. What determines whether a good sells for $30 or $300 depends entirely on the brand.

Right above the "Made in China," you'll now find another line: "Designed in [prestigious country here]."

The materials didn't necessarily get worse. But the price no longer tells you what it used to.

When you pay that premium now, the price covers the ad campaigns, the celebrity endorsements, the logo, the history, the feeling of exclusivity, and the envy from your friends.

Today, price is not a proxy for quality. Businesses are simply capitalizing on brand power, that's all. When you buy something expensive, you have no guarantee that it will last. Everything should be judged on a case-by-case basis. In fact, if you're looking for goods that last, one approach is to search for "cheap alternatives" online.

The story we were always told was really about information. The poor man didn't have the money to buy quality, so he used price as a signal to gauge quality, and maybe saved up to invest in a better product. That rule has changed. Price is now just a signal of a brand's power, nothing else. To find the better product, you'll have to rely on others who've tested it and can tell you how it holds up to time.

That's 2 GB for Windows 95, Office 95 (Word, Excel, PowerPoint), Encarta 95, all my father's work documents, and the million games I had installed.

I borrowed a disc from a friend that had a few dozen games on it. I installed them all. Before I knew it, I ran out of space. The computer became extremely slow, and I couldn't install any more games. I figured I needed to delete some games, but I was ten years old. I was not going to delete my games. I couldn't delete my father's stuff either, so I decided to explore the hard drive.

I noticed that in the Program Files folders, every application came with a bunch of text files. Some of them were large, and they didn't look that important to me, especially the ones ending in .ini.

So I went from one folder to the next, deleting those .ini files. There's satisfaction in gathering all those files in the recycle bin, emptying it, then watching your storage space increase. I deleted so many files that I was able to install an additional game on the computer.

It was one of my most satisfying accomplishments. I had a problem, I explored the computer, and I found a solution. I played the new game until I got tired of it. In the 90s, when you were done using the computer, you clicked Start → Shut Down → Confirm Shutdown. The computer would think for about two minutes, then display in big orange letters:

And I shut it down. You can imagine what happened next. The computer wouldn't boot again.

Those .ini files seemed unimportant to a child, but they are configuration files used by several applications, including the operating system. While the Windows Registry did exist in Windows 95, .ini files were still commonly used. When I deleted them, any application or process that relied on them failed to load and simply crashed.

Anyone who had anything of importance on that computer lost it. Everyone except my father, who carefully kept copies of his documents on floppy disks. He knew I was up to no good.

Throughout my career, I've seen many people make this same mistake. When something doesn't look important to them, they delete it. Whether it's a programmer deleting a function that "looks stupid," or a DBA dropping a table or a single field they assume no one will miss. It's all the result of the same mindset: "I don't think this is important."

It makes me think of DOGE, the real yet fictional Department of Government Efficiency. The team supposedly tasked with combing through government programs to find waste never looked deeper than the surface. Just like ten-year-old me, they looked at a department they didn't understand and decided it wasn't important. They uprooted how the entire country works just to save money, the same way I destroyed the family computer just to save storage space. Whether DOGE actually saved us any money is still hotly debated, especially when weighed against the pain and suffering it caused.

Anyone with half a brain could have seen their failure coming from a mile away. The same way anyone who understood how computers work could have told me those configuration files were important. At least, all we lost in our household was time and some saved games. The American people can't say the same.