I'd had the same design for 10 years, and I wanted something fresh. But who can redesign without also improving the underlying code? I deleted a whole bunch of things: old templates that were never used, post.new7.old.php, a pile of unused CSS. I just had to.

I deployed a first version and all the pages worked just fine. But then I got cocky. I decided to also improve the underlying code using GitHub Copilot. I was vigilant at first, reviewing every single line of generated code. None of it was complex really, just refactoring functions and the like. But along the way, I got lazy. I let the AI update deprecated functions on its own.

The next time I deployed, the website returned a 500 error. When I checked the logs, nothing came back. No errors. I looked at running processes and noticed several PHP processes pinned at 100%. I reverted the code, but the server was still stuck. I restarted the web server, restarted PHP-FPM, and neither helped. The only thing that worked was restarting the whole machine.

I ran the same code on my own machine and it worked fine. That's when I noticed I was running an older version of PHP on prod: PHP 8.3 vs. PHP 8.4 locally. No problem, I thought, and upgraded prod, which of course failed to fix anything. I waited for nighttime, redeployed the broken code, and debugged line by line until I found that Copilot had gone out of its way to "update" code in the Markdown library I use. If you know anything about Markdown, you know it's complex. This particular change was causing infinite recursion while parsing Markdown. I had no intention of reading through all that code to figure out exactly how it was failing, so I just reverted it.

I redeployed and the problem seemed solved. Then I got an email: "Your website is down," a reader wrote in the middle of the night. While my American readers are asleep, Europeans are up bright and early reading my blog, for some reason (thank you, really).

So debugging live on production was not an option. I reverted to the old code again. But how was the website still failing after I'd fixed the Markdown issue? And worse, it still worked fine locally. Just in case, I upgraded that very old Markdown library to something cooler and more modern: Parsedown.

That didn't solve it either. The moment I deployed, the entire website failed, including pages that don't even use Markdown. Now it was personal. How do you debug a website that only fails in prod? I had a few tricks up my sleeve.

First, I wrote a bash script to quickly switch between versions of the website. All it really did was flip a symlink between the "latest" folder and another folder I chose arbitrarily.

> ln -s /path/to/latest/working/version current
> ln -s /path/to/selected/version current

Since I run PHP and every request is short-lived, I could switch to the broken version, debug, then switch back to the working version almost instantly. It's not like I have millions of readers hammering my server.

This method worked, but it was slow, and it exposed internal information to the thousands of RSS readers scouring my website. Between 30,000 and 60,000 RSS reader requests hit the site daily. I couldn't afford to expose debugging code to that much traffic.

So I used a second method: an even better way to debug live on prod without breaking URLs or throwing 500 errors at unsuspecting RSS readers. What if I ran both versions of the site simultaneously? Visit the regular domain and you'd get the latest working version. Visit a custom subdomain and you'd get the broken version.

I achieved this by creating a new Apache configuration pointing to the latest (broken) path. This way, I had all the time in the world to debug the issue right on prod, without interfering with regular traffic.

I eventually found the root cause. It was an orchestrated failure. Locally, I ran PHP directly. On prod, I ran PHP-FPM. Why the difference? Because Apache on prod runs HTTP/2 that requires an SSL connection, which I didn't need locally, and serving PHP over HTTP/2 requires PHP-FPM. PHP-FPM is essentially a process manager for your PHP instances. That explained the difference between the two setups, but not the actual cause of the bug.

The real issue was in my caching mechanism. When a page is served from cache, I set the header:

X-FROM-CACHE: 1

That's just a custom header. When the page isn't from cache, I set the value to 0. Here's the code that sets the headers:

public function process() {
    foreach ($this->header as $key => $value) {
        if (!empty($value)) {
            header("$key: $value");
        } else {
            header("$key");
        }
    }
}

Now, what can go wrong here? When a page isn't served from cache, $value is set to 0. You see it now, don't you? 0 == empty() evaluates to true in PHP. So whenever a page wasn't served from cache, or the first time a page was hit after a deployment cleared the cache, this code ran instead:

header("X-FROM-CACHE");

That's an invalid header. So why did it fail on prod but not locally? Because Apache silently ignores invalid headers, but PHP-FPM doesn't. It throws a 500 error:

malformed header from script 'index.php': Bad header:
Error parsing script headers
AH01075: Error dispatching request to :

Headers need to follow the key-value rules defined in the internet standards (RFC 9110). Removing the condition and always using header("$key: $value") solved the problem.

The blog engine runs on multiple machines I own locally. I never had to worry about the setup because both apache and php are tolerant to mistakes. In a talk, Rasmus Lerdorf once said that PHP works better when you don't know what you are doing. The header condition has its uses. For example, if you want to set that a page is 404 you can return:

header("HTTP/1.0 404 Not Found");

But I don't use this in my case. While copilot was of some help, it's a reminder that LLM generated code is to be treated with scrutiny. It reinforces my belief that I can never truly become a 10x engineer, because the more code I generate the more I have to review. And the more I trust it, the more likely it will bite my behind.

Now, I find myself right at that inflection point. When I use an LLM to generate code, whether it is to define a single function or to create a long running job, I find this need to understand it. I cannot commit code that I don't understand.

I posted about how I spent 10 hours reworking what the AI had created in 12 minutes. I didn't do so because I didn't like the style of the code, or the naming convention. I did it because the code didn't work. As simple as that. Every time I generate code and trust it to be working, it fails. When I use the same generator to fix the issue, it may or may not work. Now I have two problems.

Yet, the world is using Claude, Codex, and what not to write code. They are trusting it like we trust an internal combustion engine, while I'm trying to understand every piece of it before I use it. My need for understanding the code is slowing down any gains from the speed of code generation.

That means, I cannot become a 10x engineer with this tool. I cannot call it like a function that has been vetted by another developer because the code hasn't been written before I call it. I don't know if it is copying Jon Skeet's answer from Stackoverflow, or if it is copying my own low quality post that was deleted by consensus.

I don't know if I should update my metaphor, or if I should just trust the engineering behind it.

How is it possible? I had navigated through at least a dozen pages, yet one back button click and the web app was completely gone. If you've ever experienced something similar, it's probably because you were using a single-page app. Nothing wrong with single-page apps, of course, but over the years I've concluded that people who only know how to build single-page apps don't know what a link is.

So let's start with examples of what a link isn't.

<div onclick="navigate('home')">Home</div>

Not a link. It's a div with an onclick event handler. You can style it all you want, but it's not a link.

<button onclick="navigate('home')">Home</button>

This may be a button, but it is not a link. With the advent of React, this has become so common. Because it's called a button, learners naturally gravitate toward it to link different pages. But there is worse.

<a onclick="navigate('home')">Home</a>

This almost feels intentional. As if the developer is teasing me. Why would you use an anchor tag but then omit its most important attribute? Here is what a link is supposed to look like:

<a href="/home">Home</a>

That's it. Simple. You don't have to add any configuration for the browser to support it. You don't even have to style it. All user agents have sensible default styling for the different states of a link: unvisited, visited, and active. It works well with browser history. On desktop, when you hover over it, you get a preview of the destination URL in the bottom-left corner of your screen. On mobile, you can press and hold to get several options on how to open it. You don't even have to worry about accessibility. It just works.

But when a developer is deep in their React app thinking about functionality, they might say, "When you click this button, go to the home page." They will naturally think of onClick as an event. And since it's a single-page app, they're thinking about state, not a page. They might write something like this:

import { navigate } from 'somewhere'; 
function Home() {
  return (
    <div style={{ padding: '20px' }}>
      <h1>Home Page</h1>

      <button onClick={() => navigate('/about')}>
        Go to About Page
      </button>
      <div 
        onClick={() => navigate('/about')} 
        style={{ cursor: 'pointer', marginTop: '10px', color: 'blue' }}
      >
        Click this text to navigate
      </div>
    </div>
  );
}
export default Home;

This is already bad enough. But depending on how the navigate function is implemented, it can make or break the entire browser history. In the internal tool I was using, navigate was essentially replacing the current URL with the new one using location.replace().

You can avoid all of these issues by just using an anchor tag. If you need it to play nicely with your React app, React Router has a Link component.

import { Link } from 'react-router-dom';
function Navbar() {
  return (
    <nav>
      <Link to="/home">Home</Link>
    </nav>
  );
}

Please, just use a native link and you won't have to worry about anything else.

Honorable mention: a reader shared this one:

<a href="javascript:window.open('/home')">Home</a>

The breakthrough follows an 18-month company-wide initiative called Project Streamline, during which all 340 employees completed mandatory efficiency training, adopted a new Jira-based workflow system powered by Rovo, and attended a two-day offsite in Scottsdale where a consultant named Derek asked everyone to "think about how they think about work."

"I used to open fourteen browser tabs and just stare at them. Now I open fourteen browser tabs, and AI agents are looking at them for me. I've never felt more in control."
— Sandra K., Senior Clip Assembly Coordinator, 11 years at ppclp.ai

Central to the transformation is Rovo, Atlassian's AI, which the ppclp.ai Jira Center of Excellence team has deeply integrated into the company's ticket lifecycle. Rovo now autonomously opens tickets when it detects workflow friction, assigns them to the appropriate team, and, in what the Center of Excellence calls "the closed-loop moment", it closes them upon determining that sufficient time has passed. Ticket velocity has increased by 340% as a result.

"Rovo doesn't wait for humans to decide a problem is solved," explained the Head of Delivery Operations, in a blog post titled We Taught Our Tickets to Heal Themselves. "It senses resolution. It acts. And then it documents the action in a follow-up ticket, which it also closes."

The OPI™, aggregating over 200 signals including ticket velocity, standup attendance, emoji reaction latency in Slack, and what the methodology document calls "ambient focus energy," now shows a number in the top-right corner of the dashboard that is very large and going up. The dashboard itself, prominently themed in dark mode (naturally), required six months to build and is, by all accounts, extremely beautiful.

"We are incredibly proud of this number," said CEO Bob Realman in a statement prepared by the communications team and reviewed by legal. "It represents the dedication, the hustle, and the genuine passion of every single person at ppclp.ai. And of Rovo, who we consider an honorary team member and who closed 1,400 tickets last Tuesday alone."

When asked by a reporter at the earnings call whether the 100x productivity improvement had resulted in a corresponding increase in paperclip output, CFO Melissa Tran paused, smiled warmly, and said the question "reflected a pre-transformation mindset." She then advanced to the next slide, which was a photo of the team at the Scottsdale offsite.

"Volume is a very legacy way of thinking about a fastener business. We've moved beyond units. We're measuring what matters: Agentic motion."
— Bob Realman, current and former CEO, ppclp.ai

The company did acknowledge, in a footnote on page 34 of the supplemental earnings materials, that paperclip production had declined approximately 20% year-over-year. The footnote attributed this to "macroeconomic headwinds, a challenging staple-adjacent market, and notable seasonality in Q2 clip demand," adding that the trend was "well within the range of normal paperclip seasonality" and "expected to self-correct, eventually."

Analysts who requested a definition of "paperclip seasonality" were directed to a separate FAQ document that had not yet been written. A Rovo ticket to write it was opened and closed the same afternoon.

ppclp.ai says it expects the OPI™ to continue improving through the end of the fiscal year. They are already exploring an OPI™ 2.0, an open source model that will incorporate biometric data, walking pace between meetings, and what the roadmap calls a "vibe coefficient." Production guidance was not provided, but the company noted that the dashboard remains, in their words, "extremely actionable," and that Rovo has already opened a ticket about it.

OPI™ was developed in collaboration with Proxy Ai™. ProxyAi, so you don't have to.

About ppclp.ai: ppclp.ai has manufactured precision wire-formed fasteners since 1987, and rebranded as an AI-native company in 2024. The company serves offices, government agencies, and one very loyal stationery shop in Duluth. ppclp.ai employs 340 humans and Rovo, and is headquartered in a building with a lot of glass. More information is available at a website that is currently being redesigned by an agent.

Forward-looking statements contained herein involve risks and uncertainties, including but not limited to: continued ambiguity about what productivity means, the possibility that Rovo opens a ticket about this press release and then closes it, and the risk that someone in finance eventually opens a spreadsheet unassisted. OPI™ is a trademark of ppclp.ai. "Seasonality" is used here in the broadest possible sense. Rovo is a product of Atlassian and is referenced here with the full confidence that it would autonomously resolve any objections. Past dashboard performance is not indicative of future paperclip output.

When I was getting started in my career, that meant having your own website that you contribute to regularly. So I did that. I built websites, I maintained them. I kept maintaining them even after I got the jobs because that's how I actually honed my web programming skills. Where else was I going to try new frameworks, a new JavaScript paradigm, or try out Ruby on rails?

I got the job, and I advised other developers to follow the same path. But then github became mainstream. Rather than just show a finished website, you could actually share the code that runs your project. Share a link to your github project and companies can review your code and directly gauge your experience. But even better, you can show your contribution to open source projects. Not just any projects. Popular projects. The github stars became a metric people look for. A signal that can be used to quickly assign a value to a candidate.

But that’s the story told from the outside. I don’t think the github profile link was ever important, unless it was significantly good. Employees focused on their work rarely have the time to maintain healthy github activity. Their experience comes from their day to day job. So for the most part, not much attention was placed on github links other than skimming through those surface level details.

When stacks of resumes came on my desk, the best candidates stood out because they had work experience. The good candidates had projects that they could link to, github or elsewhere. But then, the worst candidates had long padded resumes that had elements of every job application tips-and-tricks-article. They had a website, but it was built in a day for the purpose of getting a job, with nothing interesting to say. They had github links, but those often pointed to school projects, homework, or boilerplate code. That’s the vast majority of github links I used to get.

People with active and well maintained github profiles were rare. Rare because it actually requires time, effort, and experience. But then we have AI.

There was a golang auth issue that I've contributed to on github. It was already a few years old when I proposed a solution that worked for my case. It wasn't universal so it wasn't accepted. The discussion is revived every couple years, each person bringing one more piece to the puzzle. But then recently, someone exploded the thread with comments. And even created a PR to go with it.

This was from a user that went from a dormant account to 4000 contributions in a year. It was all AI assisted code. This isn’t to comment on the quality of his code, but he was clearly trying to optimize the metric. Looking at his linkedin profile, he doesn’t work in a software engineering role, and it’s hard to decide if he would be a good contributor if hired. If we were to judge his resume by looking at the github profile, it might catch our attention.

But then, there is a problem. There are hundreds, even thousands of people all doing the same thing. They are cranking up their contributions to github projects using AI, so they can have a better chance at getting hired as developers. I understand the job market is rough right now, especially for gen z, and anything to differentiate yourself is a plus. The problem is this is being done at the expense of open source projects.

The contributors are not submitting PRs to your project because they are personally invested in it. Instead, they are trying to get their name on the contributors list so that they can use it as a signal in their resume. When we are out here debating if there is any merit in AI generated PRs, or if we should just judge the code, we tend to miss that their gesture is completely hollow.

The PR’s author intentions are completely misaligned with the project's maintainers. They are playing a different game. We call it slop, or a waste of time, we ban them and they get really vocal about expressing their first amendment rights. We are directly interfering with their goal of padding their resume.

I often ask, why don’t people who create those PRs not just start their own project? One answer I’m starting to believe is, nobody cares about a github profile with a handful of stars. You need to contribute to a popular project. Most if not all AI generated websites look the same, it doesn’t matter how well you customize the prompt. Most greenfield projects from new programmers look the same, the prompter lacks the experience to do anything different.

Contributing to open source is a scary thing when you are new. Even when you have experience, it’s a deliberate act. You have to be invested in the work. Just like asking questions on stackoverflow, issues you raised will often get closed. And when they do, you have to learn from it.

The value of an open source contributor is not in the volume of work they can perform. If you skim any important projects, you’ll see that the best contributors spend more time discussing the problem than writing code. Their value is in solving problems and contributing to the collective memory of the group.

But when you are doing a drive-by PR that may or may not be correct, and you are just trying to get your name on a list, you are providing zero value to the maintainer. Just more work.

This is the signal every slop PR generator is after.

After a couple of weeks of blue high-tech image thumbnails, I simply hit unsubscribe. Here's what happened: a person earned my trust. He maintained that trust for all those years. But then he thought the best way to improve was to take himself out of the equation. If you're just going to present me with prompt-generated content, I hate to break it to you but I have access to ChatGPT, and I can do that myself.

The reason the human voice matters to me is because there's real experience behind the words. The oldest newsletter in my inbox is from when I was just 12 years old. It was from a French writer I used to read. After a decade of following him, the emails stopped coming. I was only reminded a few years later, when the emails started coming back.

I didn't jump on it immediately. I didn't even remember who it was. But when I read one at random, the words were different, the tone was nostalgic, and the name was unfamiliar.

I dug deeper and found that the author's son had taken over the newsletter. That was my cue to unsubscribe. But he hadn't used AI to replace his father's voice. He didn't use any tricks to garner clicks. Instead, he announced that his father had passed away and that he would share some stories.

I remained subscribed until the last story was released. I rarely sign up for any newsletter. If I do, it's intentional because I'm interested in what the author has to say. It's not much deeper than that.

There is a big difference between a newsletter written by a person, one that breathes and wanders and sometimes takes his time. Compared to the rapid fire, mechanical hum of AI-generated content. One feels like someone is thinking with you. The other feels like a monetization strategy.

Instead of "how do I write a function that reads a file?", I would suggest they use specific keywords, something that sounded more like machine language than conversation. "js function to read csv file" or "css gradient background property example." This got you better results. Even though Google was a sophisticated search engine, it was still doing a kind of keyword matching under the hood.

But not anymore. You don't get any advantage from writing in "machine language." Google understands natural language just as well. In fact, even better.

How is it that in 2026, I Google things less than ever? It's not that I know everything now. It's more that I don't want to call the friend who always talks too much. If the height of the Eiffel Tower ever comes up in conversation, I'll type "eiffel tower wiki" and click through to Wikipedia. I don't want to have a conversation about it.

Googling something these days feels like Google is trying to join my private conversation. Where it used to be a tool for finding answers elsewhere, now it's a buddy who gives you an answer. And just as you're about to leave, it says, "hey, did you also know that..."

There used to be a machine between me and the information I was looking for. It was good at its job. It sorted, ranked, then presented information. But now, the machine is constantly pushing information at me, watching my reaction, learning from it, and feeding me more, unsolicited.

Before, information lived on the web and was hard to find. Today, information still exists, but it's buried under noise. Google no longer helps you find it, it just gives you an answer. That answer might be right or wrong, and right below it, in small print: "AI responses may include mistakes."

You rarely get to verify whether the answer is correct, because almost no one clicks through to the source. I know this firsthand. More than three-quarters of my Google referral traffic has disappeared, while my search impressions keep climbing.

So what's left to do? I could mourn the old Google, the simpler web. But as the title says, we aren't going back. This is the new reality, and we have to adapt.

Rather than blindly embracing change, I think it's smarter to pick and choose. Just last week, I wrote about the small web still being alive. And it did exactly what its name suggests. It stayed small.

There are other search engines built for people who want more control. DuckDuckGo. Kagi (my personal favorite). The habit of Googling everything is learned behavior and learned behaviors can be unlearned.

What's harder to convey is that Google never presented us with facts, only sources and citations. The way the google answer is presented, we have the impression they are giving us undisputable truths. When everyone is sharing screenshots of the answer they got, all you can do is share a screenshot of the opposite answer you got. The source gets lost. That's where we are now. Skimming the average sentiment of a Reddit thread, or confirming something we already believed.

This is the new reality. We're not going back to keyword matching. But I also don't have to accept the new way as the only way. Google has made its search box AI-first and that's their right, it's their product. But it's also my opportunity to try something different.

We are not going back. So I might as well choose where I go next.

We all lost it. Our lead developer asked if, by any chance, the manager's eyes looked glassy. We laughed even harder. Because yes. Yes, they did. He was always high.

That was twenty years ago. I've repeated that story countless times, and it always drew chuckles as we discussed the disconnect between software teams and management. Any software engineer could relate. We all knew that lines of code were a meaningless metric. A junior could write a thousand lines of spaghetti. A senior could fix the same problem with forty elegant ones.

But then, last week, I found my name at the top of a leaderboard.

My employer had been exploring productivity tools and trialed one they thought would be useful. After the trial, they were quoted $500k a year. The tool tracked developer productivity and integrated with Atlassian products, Microsoft, and many other services we used. The price was too steep, so it was dropped. A couple of months later, the same company came back with a discount. The exact same tool for just $50k a year. My employer jumped at the opportunity.

How many bytes did you use today?

I'm looking at this dashboard right now and I see my name at the top of the leaderboard. I click on the widget, and a pie chart appears. There it is: a breakdown of the total lines of code my team has produced using AI, by individual.

This isn't limited to my employer. Every company is putting something together to track AI usage and justify the investment. Instead of tracking project completions, we're tracking how many lines of code each developer generated with AI. And the joke's on me, because nobody is laughing. The whole industry is applauding and encouraging employees to use more of it.

I didn't become the champion because I have some neat agentic workflow. It was done by complete accident. While using an LLM, I accidentally selected "planning mode" for a request that had already been planned. The agent ran for several minutes, burning tokens to resolve a problem that didn't exist. Just like that, I made it to the top, without ever writing a single line of code.

If this widget is taken at face value, it won't be long before developers start gaming it deliberately. Just let the agent run overnight, and your employer can claim a 10x improvement in productivity.

We didn't use line count as a productivity metric in the past because it never made sense. Whenever we refactor code, we often end up with less than we started with. In fact, much of the time I spend modifying AI-generated code is spent deleting unnecessary things it created. Should we track negative lines of code? The better you are at programming, the worse your numbers look. We are assessing developers by the lines of code.

I've watched AI evangelists ask "how many tokens did you burn today?" They were trying to convince an audience that productivity is directly proportional to token usage. It reminds me of the transition from paper to computers. A computer evangelist of that era might have asked: "how many bytes did you use today?"

Token counts, lines of code, bytes, none of these have anything to do with actual productivity. Metrics are often entirely disconnected from what they're meant to measure. I've seen companies rely on story points only to watch employees point every ticket as high as possible. Choose lines of code as your metric, and lines of code will increase. Reward the highest contributor, and watch everyone double or triple their output by the next performance review.

It's a silly metric but it serves a purpose, just not yours. AI companies promote token usage and associate it with productivity because they directly benefit from it. Imagine an internet service provider that charges by the byte. What would their recommendation for productivity be? "Use more bytes!"

The best engineers I've ever known wrote less code, not more. They deleted things. They simplified. They understood that the goal was never the code itself. They solved problems, they made the system reliable, and they served the user. Measuring developers by output volume, whether that's lines, commits, or tokens, mistakes the exhaust for the engine.

Every era of tooling brings a new class of metric that mistakes activity for value. The spreadsheet didn't make accountants more productive just because they could fill more cells. AI won't make developers more productive just because it can generate more code.

We aren't even tracking if the right problems are being solved, and solved well. If the productivity dashboard can't answer that, it's not measuring productivity. It's measuring the subscription.

Spam?

The link leads to a 3gp file converter which is highly unusual. But the more I look at it, I have the impression it's a mistake. Most likely, they have exceeded the maximum number of characters for the Emergency Service alert.

Here is the message:

AN AMBER ALERT HAS BEEN ACTIVATED BY THE CALIFORNIA HIGHWAY PATROL. DALEZA FREGOSO WAS LAST SEEN ON MAY 24, 2026 AT 0400 HOURS IN LOS ANGELES COUNTY. THE SUSPECT VEHICLE IS A WHITE 2019 WHITE LAND ROVER DISCOVERY CA 9DAW715. CLICK ON THE LINK FOR ADDITIONAL INFORMATION. https://bit.ly/A0

It seems like the total character count is 288. I'm not sure if the title should be included but if I add Child abduction (Amber alert) and the double space after, then we have 320 characters. Is this the character limit for emergency services?

When I clicked on it, it took me to the bitly preview page:

And clicking on the continue to destination button, I'm taken here:

Suspicious Link

I was starting to wonder if this was even a real Amber alert, and if somehow this was a spam message that was sent through. But unfortunately, it is a real amber alert, as I was able to find the matching alert on missingkids.com. However, I don't see a way to request a correction.

I understand that bitly was often used to shorten links, but there should be a way for a service like amber alert to test those links before they are sent. At least on my android, once I click on the link, the alert is dismissed never to be seen again. When the link is incorrect, now we have this problem where we can never get the information back. In this case, I was only able to get the link because I received the alert on both my phones.

Also I've learned that Amber alerts have a character limit of 360 characters. So I'm still not sure what went wrong with this one.

Update: 39 minutes later (8:25pm) a second message was sent with a correction.

Corrected Link

Most likely a copy and paste error.

There was a group of people who will have a hard time joining the workforce. Companies keep using AI as the excuse for laying off workers. Dario keeps telling us by next year, AI will take over all jobs and there is nothing we can do. They will have nothing, and they better embrace it and be happy. Well, they will have a school loan, but that’s it.

If you were an external observer, maybe an alien watching humanity from a distance, you would think that AI is a new species that emerged from a lake and is taking over the world. You would never tell that the people spreading this fear are also the ones selling the tool that they swear will turn us all into gods. It's not just a capable tool that can be useful for coding, writing, and retrieving existing information.

No. It's the word itself. The all or nothing. The alpha and the omega. And it comes as a monthly subscription from a handful of companies.

What Mr Schmidt was saying to these graduates is that we are done innovating. Now we regurgitate. And then he was booed. He tried to keep talking but the boos were overwhelming. Somewhere between his words, he managed to say that being anti AI is akin to being anti immigrant, trying to score points. I don’t think it worked.

When I read the news, I first read through the transcript of his speech. It seemed as if he was able to go through his material. But I was wrong. Watching his performance on video was a whole other story.

There was a man, who had practiced his speech in front of a mirror, most likely with Gemini listening and providing feedback. It probably told him that his speech was brilliant. That it was grounded, and encouraging. "The kids will love it."

What he failed to see is that booing was not in the training data. No way Gemini was going to tell him that, because it is programmed to be agreeable and friendly. So yes, he was booed every time he mentioned AI.

But I think there is a lesson in innovation right there. AI learns from existing material. It can hardly deviate from what it already knows. When you ask it to come up with something new, it will show you something that seems new, because obviously you don't know all the material it was trained on. If it doesn't have the information, it can't tell you that it doesn't know. It will make it up instead.

But what these graduates did was exactly what differentiates people from the robots. They did something completely unexpected. They booed Eric Schmidt. They innovated. Something tells me that kids will be just fine. I may never be able to convince my mom to stop sharing AI videos, but my kids will learn to navigate it. They will continue to innovate. Maybe AI will be like a calculator for them. They will know how and when to use it for maximum benefit and prevent the psychosis altogether. It's never gonna be a replacement for thinking.

I was really happy to see the booing because it was the last thing they expected. Just a few days ago, the president of Glendale Community College was booed as well because she chose to have an AI read the graduates names and it butchered the process. AI is not inevitable. It's a nice addition. That’s it.

We don't just have to accept things as they come to us. The most valuable human quality in an age of automation is exactly what AI cannot provide: the ability to defy expectations, introduce chaos, and create truly original outcomes. That is precisely the power of human innovation.

For fun, I copied the commencement speech from a video and passed it through gemini, it complained about the grammar, but as I said earlier, it couldn't predict the outcome:

The emotional arc is clear: acknowledge fear → restore agency → define values → point toward possibility. It reads like something that wants to meet graduates where they actually are, rather than giving them generic optimism.

Then I asked it if it would result in booing:

What makes the speech work is that it does not say:

• “everything will be fine,”
• “stop worrying,”
• or “technology is inherently good.”

Instead, it says:

• the future is undecided,
• humans remain morally responsible,
• and participation matters.

That framing is resilient.

Not so resilient after all. Anyway, congrats to the 2026 graduates!