This is my thesis, and I know it’s unpopular. It took me ten years of patience to be able to write this piece. I stayed quiet watching this theater repeat itself year after year, waiting for the right moment to document everything I witnessed up close, and today I get to watch, with real pleasure, my own predictions come true one by one.

And before some smart aleck tries this one: I know boycotts, doxxing, and witch hunts exist with no CODE_OF_CONDUCT.md whatsoever, they always have. The title takes aim at what this file turned into: the instrument that took an internet-mob tactic and stamped it as official project policy, with a committee, a process, and a veneer of institutional legitimacy. A 500-line markdown file scares nobody by itself; what it became does.

Easy money was the fuel. The code of conduct was the weapon these people built to formalize what used to be just a shout in the street.

One question is where the energy came from; another is the instrument it adopted to turn into permanent power inside the project. Keep that distinction in mind, because it holds up the whole piece. But before getting to the philosophy, let me tell the economic part, because without understanding the money you won’t understand the rest.

The bubble that funded all of this

From roughly 2012 to 2022, the tech industry lived through the biggest hiring bubble in history. Zero interest rates, infinite capital, and big tech companies growing like there was no tomorrow. We reached the surreal point of companies hiring engineers with no work for them to do. Keith Rabois, of the PayPal mafia, publicly accused Google and Meta of hiring thousands of people to do “fake work”, out of vanity, and so they wouldn’t go work for competitors. A former Meta employee, laid off in the first 2022 wave, put it better: “they were hoarding us like Pokémon cards”. The “rest and vest” culture, collecting salary and stock options while doing almost nothing, had already been documented back in 2017.

It was this bubble that funded the “coding is the profession of the future” wave. Bootcamps went from 2,178 graduates in 2013 to nearly 25,000 in 2020 in the US and Canada alone, growth of more than a thousand percent. Bloomberg resolved to learn to code as a New Year’s resolution in 2012. Obama wrote a line of code on TV in 2014.

I told this story in more detail in a February 2020 video, back when the bubble was still inflating (transcript here):

Tech influencer became a profession. Everyone was going to be a programmer.

Then the bubble popped. 2022: nearly 165,000 laid off. 2023: more than 262,000, according to Layoffs.fyi. Meta cut 11,000 in November 2022 with Zuckerberg admitting “I got this wrong”, and another 10,000 in the “year of efficiency” in 2023. Amazon cut 27,000. Google, 12,000, with Pichai admitting that “we hired for a different economic reality than the one we face today”. Stripe was the most honest: “we overhired”.

I recorded that burst in the heat of the moment, in a November 2022 video (transcript here):

And because the timing writes its own joke, on November 30, 2022, right in the middle of the bloodbath, ChatGPT came out. A hundred million users in two months, the fastest-growing app ever seen up to that point, according to a UBS estimate. The headlines turned into an ACM talk called “Large Language Models and the End of Programming”, Jensen Huang saying no child needs to learn to code anymore, Devin announcing itself as the first AI software engineer, Dario Amodei promising AI would write 90% of code within three to six months. Spoiler: it didn’t.

Why does this story matter? Because it was exactly during this decade of easy money that open source got colonized. When there’s money to spare and a shortage of real work, there’s time and people to spare for playing politics inside projects. And that’s what happened.

The decade of the witch hunt

The central artifact of this story is the Contributor Covenant, created in 2014 by Coraline Ada Ehmke and adopted by thousands of projects, including practically every giant in the industry: CNCF, Apple, Google, Microsoft, Linux. The author herself, on the day Linux adopted her code, tweeted in no uncertain terms: “Some people are saying that the Contributor Covenant is a political document, and they’re right”. When the document’s own author admits it’s political, the debate over “safe space” is over before it starts.

The list of victims from this era is long, so let’s get to the main ones.

First, it’s worth noting how far this crowd’s reach went. Coraline worked at GitHub between 2016 and 2017, until she was let go (her version of events is in the piece “Antisocial Coding: My Year at GitHub”). And GitHub was the perfect target: it’s where practically all the world’s open source lived. It was in this era that the original founders left the picture. Tom Preston-Werner resigned in 2014 amid the Julie Ann Horvath harassment scandal, even though the internal investigation concluded there was nothing illegal, only “errors in judgment.” Chris Wanstrath had already announced he’d step down as CEO in 2017 and, after the sale to Microsoft in 2018, stayed on a few more years as a technical fellow before leaving for good. Today none of the original founders work there.

Her legacy outlived the firing. The Contributor Covenant became one of the templates GitHub makes easy to adopt when you create a repository’s CODE_OF_CONDUCT.md. And in 2020 came the crown jewel: in the middle of the George Floyd protests, GitHub announced it was retiring the name master, and since October 1, 2020 every new repository is born main.

The debate was stupid from the start. Git never had a slave branch. Petr Baudis, who named it in the original scripts, explained on X that master there came from “master copy”, like the master recording of an album (Baudis himself later said he now prefers main; the etymology hasn’t changed). Not even that detail held back the change: even the Software Freedom Conservancy publicly endorsed the switch, and anyone with automation assuming master had to scramble to catch up. Nobody got any more protected because of this change, but it’s there, in every programmer’s workflow, every single day.

Brendan Eich, 2014. The guy invented JavaScript, co-founded Mozilla, was CTO since 2005. He became CEO and lasted eleven days in the job. The crime: a thousand-dollar donation in 2008 to California’s Proposition 8. Employees tweeted calling for his head, OkCupid blocked Firefox users with a protest message, and he fell. Andrew Sullivan, gay and one of the first prominent advocates for same-sex marriage, wrote at the time “The Hounding of a Heretic”: when careers depend on an ideological purity test, the witch hunt has already won. And notice: there was no code of conduct involved here at all, it was pure boycott pressure. The method already existed before the document; the document only made it official.

Larry Garfield, 2017. Twelve years contributing to Drupal. When it leaked that he took part in a BDSM subculture, on a private site, outside the project, Drupal’s conduct committee investigated and concluded: no code of conduct violation. Dries Buytaert went over the committee’s own head and expelled him anyway, because “association with his belief system” was incompatible with the project’s goals. TechCrunch summed it up the same way: punished for something said outside the project. Eighty-five developers signed an open letter threatening to leave. It didn’t help. And notice the detail that buries the “safe space” thesis: the code of conduct process worked and cleared the guy. When the mob pushed, the paper held nothing; the person at the top decided, like it always was.

Node.js, 2017. The 13-person TSC voted on expelling Rod Vagg for, among other things, having tweeted an article questioning the side effects of codes of conduct. Reading criticism of a code of conduct almost became a code of conduct violation: the vote was 6 to 4 against expulsion, by a narrow margin. The machine lost that round, but the message had already gotten out: four of the people who wanted Vagg’s head resigned from the committee that same day, and the project got a fork called Ayo.js hours later. Losing the vote didn’t stop the damage.

Linus Torvalds, 2018. In September, according to reporting at the time, the New Yorker had sent him questions about his abusive behavior in emails. That same weekend, Linus apologized and announced he’d take some time off to “understand people’s emotions” and the kernel swapped the Code of Conflict for the Contributor Covenant. Linus has been blunt in emails forever, everyone knows that, and he came back a month later. But the message was sent: if not even the guy who created the kernel was safe, nobody was.

Richard Stallman, 2019. The creator of the GPL, founder of the FSF, the embodiment of free software. An MIT mailing list thread leaked in which he discussed the legal semantics of the Minsky/Epstein case. Vice ran headlines saying he had “defended Epstein” and called the victims “entirely willing”, a reading the email thread itself doesn’t support: he was questioning the legal terminology of the accusation against Minsky. The “Remove Richard Stallman” campaign exploded, and within days he resigned from MIT and the FSF presidency. When he returned to the FSF board in 2021, an open letter with more than 3,000 signatures and dozens of organizations came out demanding his head and the whole board’s. Red Hat cut funding to the FSF. A support letter gathered nearly 7,000 signatures and, delicious detail, Debian voted on a resolution about the case and the winning option was to say nothing. Even faking neutrality took a vote.

And there’s the most recent case, and maybe the most instructive one: Tim Peters, 2024. A Python legend, three decades of contribution, suspended for three months by the PSF’s conduct committee over vague accusations of creating an “atmosphere of FUD”, in a fight over the foundation’s bylaws and the committee’s own methods. The community reacted badly, but there was no reversing it: he served the three months and only came back once the suspension expired, in November. The pattern held: disagreeing with moderation became a punishable offense.

DHH, 2021. I saved this one for last because it’s the case that changes the story. And note: this wasn’t even open source, it was his own company. The same mechanism, now inside the office. In April 2021, at the height of the BLM era, an internal DEI committee inside Basecamp, the company of Ruby on Rails’ creator and Jason Fried, dug up an old “funny customer names” list that had been circulating internally. The discussion escalated until an employee invoked the “pyramid of hate” and argued that list was the foundation of racial violence and even genocide. The founders’ response was to shut down the topic, dissolve the committee, and ban political and societal discussion on internal channels. The internet exploded. At the next all-hands, there were two and a half hours of people crying and yelling on Zoom. Ryan Singer, eighteen years at the company, said there that he didn’t accept the “white supremacy culture” label being applied to the company. He was suspended half an hour after the meeting and resigned that weekend. In the end, a third of the company, twenty of the 57 employees, left with a voluntary severance package.

And this is where this case splits off from all the others: he didn’t bend. No public humiliation ritual, no apology, no walking it back. He preferred to lose a third of the company over handing over control of it. Basecamp survived, went back to being 37signals, and DHH learned right there, firsthand, what kind of people he was dealing with. Hold on to that name, because it comes back.

Someone’s going to point out that his rule is also a written document banning a topic. Yes, and the difference is exactly the point: DHH’s rule bans an entire subject, the same for everyone, no matter which side. A code of conduct bans a person and an opinion, selectively, depending on who’s in power that month.

One locks the topic at the door. The other opens a courtroom inside.

Notice the pattern. In none of these cases was the problem code. In none of them did anyone commit a bug, steal code, sabotage a release. The offenses were opinions, political donations, private life, semantics on a mailing list. The technical criterion got replaced by a political one, and the code of conduct was the legal instrument of that swap. These are famous cases, not statistics. But when the list includes the creators of JavaScript, the GPL, and Linux, the sample doesn’t need to be big to make the point.

And the results?

Ten years of the code-of-conduct era should have left behind a trail of good numbers. If the justification was protecting minorities and making open source more diverse and less toxic, where’s the improvement? I went looking for the serious research on the subject. What exists tells an interesting story.

On adoption: Tourani, Adams, and Serebrenik measured in 2017 that around 35% of GitHub’s 150 most popular projects had a code of conduct. And that enforcement was rare: the creators of these codes, in a sample of four interviewees, talked about single-digit case counts over years. A 2021 CSCW study looked at 52,000 repositories: 12.6% had a CoC, and only 10% of the conversations mentioning the code were real moderation use of it. Most adoptions happened with no visible public discussion in the repo. The same paper states, in plain words, that there is no empirical evidence that a code of conduct attracts new contributors.

On attracting people, by the way, Qiu et al. measured what actually makes someone join a project: a good README, star count, recent activity, an issue template. A code of conduct didn’t even make it in as a variable in their model, and note that they did test maintainer responsiveness, which also came back not significant. The study that specifically measured where a CoC ranks among the factors was a separate one, Fronchetti, Wiese, Pinto, and Steinmacher, also from 2019: a CoC ranked among the worst-placed factors for attracting new contributors. Nobody picks a project because of its code of conduct.

On diversity, which was the original promise, there is a specific study, and the answer is no. Robson, at ESEC/FSE 2018, looked at GitHub’s 500 most popular projects: projects that adopted a CoC saw women’s participation grow at practically the same rate as those that didn’t (roughly a 1.44% increase versus 1.43%, per the later survey that cites the study). No statistical difference to back up the promise. Enache, in a 2017 master’s thesis for TU Eindhoven, covering 149 open source communities, reached the same conclusion: no significant result showing a CoC changes women’s participation.

And there’s a new, heavyweight piece of research, published now in 2026 at ICSE, the field’s most important conference: Sun et al. ran a genuine causal experiment, comparing 4,684 pairs of repositories that adopted a CoC against matched pairs that didn’t. The result cuts both ways. Adopting a CoC does attract more new contributors, and that effect grows over time. Except adopting a CoC also increases the number of existing contributors who disengage, an effect concentrated specifically in the first one to three months after adoption. In other words: the most recent and most rigorous study that exists shows, with numbers, the exact pattern this piece has been documenting case by case the whole time. Adopting the document doesn’t build a new community, it pushes out the people who were already there.

GitHub’s 2017 survey already showed 95% men and 3% women in open source. The best long-term data that exists, from Rossi and Zacchiroli at ICSE 2022, analyzed 2.2 billion commits from the Software Heritage archive. Gender was detectable for 64% of authors, and within that group, women are 13.5% of authors and sign 8.1% of commits. Their participation had been growing slowly and steadily for twelve years, and dropped during the pandemic. The paper doesn’t discuss codes of conduct, so what follows is my own reading, not the study’s: a curve that climbs the same way the whole decade, with no visible step up when the Contributor Covenant spread, is the opposite of evidence that the document made a difference.

On toxicity, the ICSE 2022 study finds, in a footnote and by extrapolation, something close to 1.3 toxic comments per thousand on GitHub. Nobody has a historical series comparing before and after the CoC era. There simply is no baseline to say whether things got worse or better.

The only randomized experiment that would actually support the case for rules is Matias’s, published in PNAS in 2019: rule reminders actively displayed on a randomly-sampled set of r/science threads increased newcomer participation by 70%. Except the experiment is on Reddit, with the rule pinned right in front of whoever walked into that specific thread. A static file forgotten in a repository, that nobody reads after adoption day, doesn’t come close to that. The very research that shows a rule working is proof that the problem was never whether the file exists or not. It’s that nobody enforces it, nobody displays it, nobody makes it stick.

To sum up: a whole decade of codes of conduct, and the original promise remains exactly that, a promise. What got documented was adoption without discussion, rare enforcement, and, at best, a whole lot of political process.

As protection, it’s almost never invoked. As a political weapon, it only needs to be invoked once, against the right person.

The pushback came from where nobody expected

Easy money ran out in 2022, and with it, the industry’s patience for this theater. And leading the pushback was the guy who had already refused to bend back in 2021: DHH, an old-guard ex-Mac fanboy.

DHH has been writing against this wave for a while now: “The waning days of DEI’s dominance” in 2022, “DEI is done” in 2024. In 2022 Ruby Central pulled him from the RailsConf keynote, the conference for the framework he himself created, saying it wanted to “share the opening stage with other contributors”. The following year Rails World was born, the official Rails Foundation conference, and DHH became its keynote speaker. In 2024 he launched Omakub, and in June 2025, Omarchy: Arch Linux with Hyprland and a bunch of opinionated scripts on top, which had passed 40,000 stars on GitHub by September 2026 and became 37signals’ default environment for anyone touching infra and Ruby.

Then the cancel machine switched on again. In September 2025 he published “As I remember London”, and the reaction was the usual script: a petition to remove him, accusations, an attempted boycott. His response was “We’ve all had enough of this nonsense”: “every few years, the same sad little clique of Ruby malcontents tries to cancel me from Rails”.

A month later, in October 2025, it was Framework’s turn, the laptop maker: a thread with more than 1,500 replies on the company’s own forum, opened by a Debian developer calling the Hyprland community, which Framework sponsored, “toxic and hateful,” and threatening a boycott because the company also promoted Omarchy on social media. The Framework CEO’s response is the line this whole decade had been missing:

“We deliberately created a big tent, because we want open source to win. We don’t partner based on the beliefs of individuals or organizations.”

And the machine didn’t just come after him. Ruby Central, the same organization that had disinvited DHH from the keynote in 2022, gave him a stage at RailsConf 2025. The retaliation came in money: according to developer Joel Drapper’s reporting, Sidekiq pulled its $250,000-a-year sponsorship because of it. Weeks later, in September 2025, Ruby Central stripped GitHub access from every longtime RubyGems and Bundler maintainer, citing supply-chain security. Ellen Dash, who had maintained the project for ten years, quit, calling the move a “hostile takeover,” and Drapper’s investigation points to pressure from Shopify, which had become practically the organization’s only source of money. Ruby Central itself ended up publishing an incident report in April 2026, promising to “strengthen governance.” That’s the whole pattern: when the machine can’t take the target down, it burns the house down around them.

A GNOME developer published a piece attacking Omarchy on GNOME’s official blogs site. And the result of all that fury? Nothing. In August 2026 the Omacom Foundation was born, with eight million dollars at launch: a million each from Tobi Lütke (Shopify), Patrick Collison (Stripe), Michael Dell, Jack Dorsey, Matthew Prince (Cloudflare), Brendan Iribe, Jason Fried, and DHH himself. The foundation became Hyprland’s exclusive sponsor, with Vaxry working on it full-time. When 1Password came in as a sponsor, the cancellation attempt was immediate, and so was the CEO’s internal response: “our donation is not an endorsement of personal opinions”. And the game goes on.

And I put my money where my mouth is: I made my donation to the foundation precisely because of the patrol’s whining. Nothing irritates that crowd more than watching a cancellation fail in real time.

This is the point: the machine still exists, but it lost its power. In 2014 it brought down a CEO in eleven days. In 2026 it can’t even scratch the sponsorship of a niche distro. The documents are still there, in GitHub’s template; what ended was the firepower of whoever wielded them. What changed was the money, and yes, the pushback is also money: eight million dollars from eight rich men.

And before someone points out that money doesn’t prove merit: it depends. A millionaire made by government cronyism, fraud, or favors has no merit at all. But most millionaires made their money by producing, and that’s the case for Omacom’s eight patrons. Money earned by producing is the measure of the merit of whoever earned it, as I already wrote here back in 2011, about Francisco d’Anconia’s money speech in “Atlas Shrugged”.

Judge by the result the donation bought, not by the declared intent of whoever signed the check.

The 49.5 billion corporate dollars from 2020 didn’t produce a single extra gram of measurable diversity, the numbers up above prove that. Eight million dollars from individual patrons produced a full-time maintainer writing actual code. The bubble that funded armies of people with no real work popped, and whoever was left was whoever was there for the code.

The philosophical part

Let’s get to the official excuse: codes of conduct exist to “protect minorities.” On the surface, who would be against protecting minorities? Not me. The problem is that the phrase is vague by design.

What is a minority? I already translated the chapter “Man’s Rights” from Ayn Rand’s “The Virtue of Selfishness” here on the blog. The line that interests me here is from another chapter of the same book, “Racism,” and it remains unbeatable:

The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities.

And that’s exactly what these codes do in practice: in the name of an abstract, collective minority, the concrete individual gets hunted down. Doxxing (exposing someone’s personal data), harassment campaigns, pressure on employers, bans. When the modus operandi for “protecting minorities” is coordinated bullying against one person until they buckle, you’re oppressing the smallest minority there is.

This topic, by the way, is an old one for me. In December 2018 I published the video “Anti-Parasite Manifesto: Be a Creator” on my channel. At the time I couldn’t be explicit, the thought police were still too strong. But whoever watched closely got the message. It was my breadcrumb for this story that I’m only now able to tell properly.

And there’s the second problem, a more fundamental one: open source is about software. The GPL, which this crowd looks down on so much, solves the one protection a software project can’t afford to lose: the code’s. It guarantees the code stays free, period. It doesn’t ask who wrote it, who they voted for, what they tweeted, what they donated to. The compiler doesn’t check for ideological purity. Open source has always been the most inclusive community that ever existed precisely because of this: the only passport was the diff. The code of conduct made open source less inclusive, because it added a new entry criterion: politics. And politics is a stupid criterion for software.

“But without a code of conduct, how do we deal with real harassment?” With the same tool as always: a maintainer’s common sense and, when necessary, the law. If someone directly attacks another person, sexual assault at an event, for example, banning them is common sense and never needed any document. Harassment, threats, and defamation are already crimes in practically every country, and crime gets settled through the law. What I can’t stomach is something else: going out and stalking someone’s online life to dig up a random opinion, with no relation to any crime, and demanding a ban over words with no criminal consequence. These committees were always great at punishing opinion and terrible at punishing crime, so the document was never about that.

And I’m not the only one saying this. Eric S. Raymond, the guy who wrote “The Cathedral and the Bazaar”, the 1997 essay that validated Netscape’s decision to open-source Mozilla and that pretty much wrote the rulebook for open source, co-founder of the OSI, editor of the Jargon File, author of fetchmail, went on X in September 2025 to declare the code-of-conduct era a complete failure. In his words: ten years of “drama and idiocy”, an “infectious social insanity” that produces politics, intrigue, and negative useful work. The recommendation is as direct as it gets: don’t adopt one; if you already did, delete it. And if some bureaucracy forces you to have one, the suggested replacement is a single sentence:

“If you are more annoying to work with than your contributions justify, you’ll be ejected.”

That’s what I said two paragraphs above: a maintainer’s common sense.

And the detail that closes the loop: ESR himself had been removed from two OSI mailing lists in 2020 over posts that “violated the code of conduct” of the organization he helped found.

The guy who wrote the rulebook, ejected by the document. That image sums up the whole era.

How we got here

It’s worth taking a step back and telling where all this came from, because open source was only one of the fronts. The starting shot, in my reading, was GamerGate, in 2014. In August of that year came the “Zoe Post”, the ex-boyfriend’s rant about developer Zoe Quinn. Twelve days later, and about 48 hours after the #GamerGate hashtag caught fire, about a dozen gaming sites published variations of the same article: “gamers are over,” gamers are dead, it’s finished.

Shortly after, the GameJournoPros leaked, a closed group where gaming journalists coordinated coverage. The public realized right away that gaming press had turned into an ideological club, and hit back with their own version of an organized boycott: the “Operation Disrespectful Nod” campaign flooded Intel with complaints until the company pulled its ads from Gamasutra (the press at the time called it an “anti-feminist campaign”; to me it’s just organized consumer pressure, the same instrument Sidekiq used against Ruby Central further down the line).

And it’s worth pinning down the principle here, because it applies to both sides for the rest of this piece: organized consumer pressure is fair play, no matter which side it comes from. The problem was never pressure. It’s doxxing, threatening someone’s job, and a committee faking neutrality to impose the result it already wanted before opening the process.

For years, from 2021 to June 2025, Wikipedia’s article on the subject lived under the title “Gamergate (harassment campaign)”, treating any criticism of the journalism as a pretext for harassment. The title got switched back to plain “Gamergate” once the most hysterical phase had passed, which should be read as a confession, not as if the case were closed: they renamed it back once defending the political label got too costly, the exact same pattern of quiet retreat that shows up throughout this whole story. While it lasted, it lasted for precisely the decade in which that mob had the firepower to make it stick.

The editorial fight got so ugly that Wikipedia’s arbitration committee sanctioned more than a dozen editors, on both sides. And note that I don’t even need to accuse Wikipedia on my own: Larry Sanger, co-founder of Wikipedia, wrote the piece “Wikipedia Is Badly Biased” in 2020, declaring the project’s neutrality dead, and in September 2025 published “Nine Theses on Wikipedia”, calling for reforms like ending source blacklists and ending permanent editor bans. When the founder says the house has been taken over, believe the founder.

The gamers’ side of this story is in the book “SJWs Always Lie”, by Vox Day, from 2015. I already know what’s coming: “Vox Day” and “Milo Yiannopoulos” are names that make people scream just hearing them, and GameJournoPros, by the way, was also originally broken by that same Milo. I don’t care about the reputation of whoever’s telling a story, I care whether the story is true. A partisan source from inside the fight, fair warning, but the central fact matches what Wikipedia itself and the press at the time document with zero connection to either of those two names: the GameJournoPros list really did exist, a closed group of about 150 people in games journalism swapping notes on how to cover the case.

The chapter “Counterattack” tells GamerGate from the inside, and the book’s thesis sums up the decade: these people always lie, always double down, always project onto others exactly what they themselves do.

From GamerGate onward, it was dominoes. Anita Sarkeesian turned her Kickstarter from a $6,000 goal into $158,000, became a global authority, went to speak at the UN in 2015 about “cyber violence,” and games journalism never recovered. Her Feminist Frequency shut down in 2023, but the logic she kicked off migrated inside the studios: the “inclusive narrative” consulting industry was born, with Sweet Baby Inc leading the way.

Sweet Baby’s CEO, Kim Belair, was recorded at a 2019 GDC talk, a public recording that circulates independently of the site that first surfaced it, advising anyone seeking internal approval for “representation” consulting to “go grab coffee with the marketing team and terrify them” with the possibility of what would happen if they didn’t get what they wanted. In 2024, a Brazilian created a Steam curator page (Valve’s own feature where any account can publish game recommendations and gain followers) named “Sweet Baby Inc Detected.” One employee at the company individually tried to bring the profile down on their own, and Valve also acted through its own moderation; even so, the result was the group exploding to more than 350,000 followers.

And then came the flops. Suicide Squad: Kill the Justice League, with confirmed Sweet Baby consulting, cost Warner 200 million dollars in losses. Unknown 9, from the studio where Sweet Baby’s founding duo used to work, laid off staff en masse a month after launch.

Then came 2020. With BLM, the same playbook became state policy: the 50 biggest American companies pledged 49.5 billion dollars in “racial justice” measures, DEI job postings grew 123% within months, Biden signed an “equity” executive order for the entire federal government on day one of his term, and the European Union rolled out its 2020-2025 anti-racism plan. It was the peak: the patrol had reached the US presidency and the EU’s leadership.

The retreat came as fast as the rise. The US Supreme Court struck down affirmative action in June 2023, companies laid off thousands of DEI professionals, Walmart, Meta, McDonald’s, and Amazon dropped their programs, and in January 2025 Trump revoked the equity orders on day one.

I told all of this just to give context: what happened in open source wasn’t an isolated phenomenon. It was the same script, with the same methods, across every culture and tech industry at the same time. The difference is that in open source, the resistance took longer to organize. But it organized.

My Cortlandt

It was this pressure that pushed me out of organizing RubyConf Brazil. I founded the event in 2008, back when it was still called Rails Summit, and in the last edition I organized, in 2016, we drew 1,500 people. When I announced my departure, I wrote that there was no drama involved. That wasn’t the whole truth: the patrol had already reached tech conferences, and I refused to turn the event I created into one more stage for it.

Let me give a small example of what it means to be pressured into forcing diversity. As the data I showed above indicates, women are somewhere between 3% and a bit over 13% of open source contributors, depending on how you measure it: self-reported survey or name-based detection in commits. My channel’s analytics show the same range, 3 to 5% at most, and that proportion hasn’t changed in ten years. Every year I opened a public Call for Papers: anyone could submit a talk. And my selection process was always blind: I read every submission without knowing who had sent it, on purpose, so the choice would be based on the merit of the topic and never on the person.

In the patrol years, the pressure was never direct with me. It was that diffuse, external pressure that every event had to be “more diverse.” And in practice that could only mean one thing: a new phase in the process. After the blind selection, reveal who submitted what, to check whether the lineup was “diverse enough.” Except that’s a mathematical impossibility. Submissions kept following the same 3 to 5%. Even approving every woman who submitted, the imaginary quota didn’t add up. The way around it was to go out and invite people directly, choosing by profile instead of by topic.

And the practical result of that scheme, wherever it’s applied, is cutting people who got in on merit to open a spot for people chosen by an irrelevant external policy. That drags the event’s quality down instead of up. And notice: this isn’t an argument against any woman. It’s the opposite. The moment the quota enters the process, the doubt stops being about one specific speaker and starts hanging over everyone who steps on stage. It doesn’t matter who’s talking: if someone in the audience disagrees with the content, there’s always the leftover question, “did Akita pick this one for the quota?” From then on, every speaker carries a suspicion they don’t deserve, and everyone’s merit gets devalued along with it. It hurts the minority the policy claimed to protect, it hurts the other speakers, it hurts the audience. It’s lose-lose all around.

And there’s a part of this story nobody sees from outside. Some of the people invited that way turned it down on the spot, “because the event wasn’t diverse enough.” The refusal made the event even less diverse, obviously. And afterward they’d go on social media to trash the event, as if I’d never invited anyone. That’s the level of garbage I had to swallow every year.

And let this be very clear: there’s nothing I want more than to see more women in tech. What I can’t convince myself of is that forcing a quota, the way I described above, helps with that. Everything I saw in practice points the other way: it hurts more than it helps. And if I don’t believe it’s beneficial, I’d rather not do it.

Want a recent example of a woman I admire in the industry? Asha Sharma, who took over as Xbox CEO in February. Since then it’s been one result after another: she cut Copilot from the consoles and restructured the division to focus on what matters, sold studios and cut costs without cancelling a single announced game, and this week brought Kojima Productions to Xbox to publish Hideo Kojima’s next game, after PlayStation cancelled the project in mid-2026. Notice the discourse around her: zero mention of “gender,” zero agenda.

Just numbers: cut unnecessary costs, bet on the right calls, improve value for the customer. That’s merit. You don’t need DEI for that.

Until I decided enough was enough. Anyone who’s read “The Fountainhead” knows what I did: like Howard Roark, the architect who blows up his own building when they tamper with his design, I dynamited my Cortlandt. More precisely: the event as it existed while it was mine. The brand survived a few more years in other hands, without the same soul, until it disappeared. And I had already signaled this philosophy here on the blog back in 2011. An individual does nothing for others: he does it for himself. If what you build benefits other people as a side effect, great, but that was never the reason. When the parasites try to take what you built, you blow it all up yourself. Because you can. Whoever built it once builds it again from scratch.

That’s what I did. I traded the conference for my YouTube channel, which didn’t depend on a sponsor, a committee, or anyone besides me. And the channel grew way beyond anything the conference would ever have become. Then I sat back and waited for the bubble to pop, because I knew it would pop: I wrote it here on the blog and repeated it in videos years before it happened. It popped. Patience always wins.

Conclusion

Ten years of codes of conduct, and here’s the scoreboard: zero evidence it increased diversity, no toxicity baseline to compare before and after, and the most recent and most rigorous causal study that exists shows the document pushing out old contributors more than it builds new community. The promise was to protect minorities. The delivery was a collection of heads: the creator of JavaScript, the creator of the GPL, the creator of Linux, all put through the public humiliation ritual. None of it over code. All of it over opinion.

And notice how this era ended.

The machine didn’t lose the argument, it lost its funding.

It was only once easy money ran out that the armies of people with no real work evaporated, and whoever was left was whoever was there for the code. Meanwhile, the builders kept building: Brendan Eich got pushed out of Mozilla in 2014 and founded Brave the following year, today with more than 100 million monthly active users and a valuation near a billion dollars. DHH lost the keynote and created a bigger conference, lost a third of the company and helped raise an eight-million-dollar foundation. I left my conference and grew far more on my channel. A parasite can take an institution. It can’t take the ability to build. Whoever built it once builds it again from scratch.

Open source recruits volunteers who want to contribute code. Any discussion that doesn’t involve code is a distraction at best and sabotage at worst. And the answer to “what do we put in place of the code of conduct” fits in a single sentence, one the ESR already wrote: if you’re more trouble to work with than your contributions justify, you’re ejected. That’s always been how it worked. The only passport is the diff.

The rest is politicking. And politicking, to use the precise technical term, is bullshit.

And here’s the final practical recommendation. If your open source project has a CODE_OF_CONDUCT.md, delete the file. If your main branch turned into main in the 2020 wave, rename it back to master. Partly out of spite, I admit. But mostly to exercise the freedom you just got back to do this without being cancelled for it. Freedom you don’t exercise atrophies. No clarifying note, no committee vote, no asking anyone’s permission. Just because you can again.

Four days ago, April 5th 2026, my blog turned 20. Yeah, I’m late on the anniversary post. There’s a reason, and that reason is what this piece is about.

I started in 2006 on Google’s Blogspot, like most people did back then. Later I migrated to a Rails 2.0 CMS that already existed, went through Typo3, and in 2012 I built my own engine from scratch on ActiveAdmin, which I dragged along from Rails 3 all the way to Rails 7. Only recently, in September 2025, I finally abandoned that custom engine and moved to Hugo with the Hextra theme, which is what this post is running on. Twenty years carrying the same posts across Textile, migrating from Less to Sass, trading Liquid for Markdown, and trimming obsolete junk along the way.

Two decades, five eras

Something few programmers stop to think about is how much the tech world changes in 20 years. I talked about this at length on Akitando #37 — The Dimension of Time. When I opened this blog in April 2006, I already had 10 years of experience behind me. I’d watched the dot-com bubble rise and blow up in 2000. And from that point on I saw a few more big ones: the rise of social networks (Orkut, Facebook, Twitter), the smartphone and mobile app revolution in 2008, the 2008 financial crisis, Bitcoin being born in 2009, the cloud and SaaS era, and now the generative AI era.

I watched those waves crash for real. Each one completely changed how we work and who survives professionally. This is the kind of thing you only see from a distance, after you’ve stacked up a few turns of the wheel.

My own career went through some violent pivots. I told the whole story on My First 5 Years (1990-1995), but the short version: I started in multimedia agencies, moved into enterprise consulting working on SAP, dropped all of it in 2006 to jump into Ruby on Rails and open source, spent a decade running events — mainly Rubyconf Brasil from 2007 to 2018 — then shut the conference down and started the Akitando YouTube channel, which grew past 500k subscribers. In the middle of all that there was the pandemic that rearranged everyone’s life. And since the beginning of 2025 I’ve turned into a full-time AI researcher and user, running models locally and breaking things with Claude Code until they work.

Checking the /en/tags/ai/ tag, I wrote 51 AI-related posts between 2025 and 2026 alone — 19 in 2025 and 32 more in 2026, which has barely started. Between 2018 and 2024, the blog was mostly the transcript archive for my Akitando videos. I’d record the video, transcribe it, dump it on the blog, and people would read it there. But once I started writing actively again, I noticed there was a loyal audience that never went anywhere, even through the quiet years. That feedback is what made me start The M.Akita Chronicles, a more personal series about the behind-the-scenes of recent projects.

The problem I never solved

For those 20 years, one thing kept nagging at me. Since everything was in Portuguese, it was inaccessible to anyone who didn’t read the language. I’d been getting messages for years from Brazilian readers living abroad (Portugal, US, Japan, Germany, Canada) asking for some English version they could share with their gringo coworkers. Stuff like “look, I’d show this piece to my team, but it’s only in Portuguese.”

I always said “one day I’ll translate it.” And I never did. Why? Because we’re talking hundreds of posts. I spent the last couple of days looking at the numbers: 727 Portuguese index.md files in the repo. Translating by hand, one by one, would take weeks if not months of dedicated work. I was never going to find the stamina for that. And every year that passed, more posts piled onto the queue.

The ironic part is that some blog posts were originally born in English. During 2017 and 2018 I had decided to write English-first, trying to reach an international audience. A whole interview series — the “chatting-with” ones with folks like Hal Fulton, Scott Hanselman, Chris Wanstrath (GitHub), Blaine Cook (former Twitter), Adam Jacob (Chef) — were born in English and stayed there. The missing piece was the reverse: take the Portuguese posts and translate them the other way.

The weekend that paid off 20 years of technical debt

This past Monday I opened Claude Code inside the blog directory. And asked it to translate everything to English. That was literally it.

It kicked off Monday, April 6th, around 6:30pm. I let it run. Went to sleep. Woke up Tuesday, it kept running. Slept again. Wednesday morning it was done. Counting from the first translation commit to the last, it was something like 39 hours of elapsed time. Not continuous, of course — there were nights, lunches, a coffee break or two. In practice, one long working weekend.

The result is sitting in the git repo, in commits anyone can inspect on the public blog repository. Scan the log and you can see the cadence: batch of 2008 QCon posts. Batch of 2009 RailsConf. Batch of 2011 Objective-C. All of 2012. The 2015 Elixir series. All of 2016, 2017, 2018. Batch after batch, organized by year and by series. More than 80 commits tagged i18n: or EN translation: between the night of the 6th and the morning of the 8th. By the time I’m writing this post, 354 index.en.md files are live against the 727 original index.md. Almost half the blog translated in one shot.

And look, ninety percent of it was smooth sailing. The translation came out good, natural, faithful to my voice in the original — I honestly didn’t expect it to work this well. Claude Code respects the tone of the source if you give it solid voice and style guidance, and it respects technical ideas without “correcting” anything you wrote. Worst case, you review a few paragraphs. Best case, you read the English version and it sounds like you wrote it directly in the other language.

A quick aside on the Claude side of the bill. I’m a Max 20x subscriber on Anthropic, which is the heavy-use tier built for people who hammer Claude Code all day. I’d never hit the ceiling of that plan before, not even in my most intense vibe coding sessions. This translation weekend was the first time I genuinely blew past the Max 20x limit and kept going into the “extra usage” mode (Anthropic charges on top when you go over the monthly plan ceiling).

For a sense of the damage, here’s my account dashboard this morning:

91% of the weekly “all models” quota burned through, already into the extra-usage mode, R$280.88 (about $50 USD) spent on top of the flat monthly subscription, and there’s still a good chunk of the cycle left. It tracks: read the full post, generate the translation, run the humanizer on it, repeat hundreds of times in a row. The token volume is massive. And today, while I’m writing this piece, Claude Code keeps hitting me with API Error: Request rejected (429) · Rate limited more and more often, which also tracks: probably some combo of my own plan quota topping out and Anthropic applying general backpressure, because I can’t be the only one going nuclear with the tool these days. Fine, whatever. That’s the price of using the tool hard when it actually mattered.

The other ten percent was a different story.

When commercial LLMs say “no”

Half a dozen older posts flat out refused to translate. Both Claude and GPT, through their APIs, would bounce with a 400 error and a content policy message. I tried multiple times, fresh sessions, clean context. Nothing.

The hypothesis is simple: those posts touched topics that automated content moderation flagged. A 2009 post about Steve Jobs’s 2005 Stanford commencement speech (which mentions cancer — Jobs was talking about the terminal diagnosis he’d received). A couple of old Ayn Rand chapters I translated years ago about rights of man and argument by intimidation. An anti-Nazi post that ironically got blocked, probably just because the word “nazi” showed up, even though the context was critical. A post about the money speech from Atlas Shrugged. And a democracy-and-ethics essay that systematically broke every attempt.

The ironic part here is that the only way to get those posts translated was using an open source model. I loaded up Qwen 3.5 35B in llama-swap, running locally, no corporate policy filters. The model read them, understood the context, and translated everything without drama. It’s the same model I tested extensively in my last LLM benchmark, and which I rate as one of the best open source models available right now.

So yeah — a Chinese model translated posts that Western models refused. I can’t help finding this slightly hilarious. Oh, and of course, I’m not allowed to speak ill of China (sarcasm). Commercial LLMs will always have the corporate-policy-and-preemptive-censorship problem applied with a fairly thick ruler. It’s a real trade-off for anyone using them in production: you get fluency and reasoning power, you lose control the moment the topic brushes up against whatever the company decided is sensitive.

The reverse case: 2017-2018 translated back into Portuguese

While I was dialing in Claude Code to generate the English content, I figured I might as well solve the symmetric problem. The posts I had originally written in English during 2017 and 2018, plus the whole “chatting-with” interview series from 2008, were sitting there without a Portuguese version. Claude Code ran the reverse: read the English, wrote the Portuguese. So if you never read the English originals (since most of my audience is Brazilian anyway), now you have access too. Take a look at the Off-Topic section to see what showed up that’s new.

On top of that, Claude Code also updated my generate_index.rb script so it understands the blog’s bilingual structure and generates two separate indexes, one in Portuguese and one in English. The PT/EN toggle in each post’s footer shows up automatically whenever an index.en.md sibling exists. All nicely plugged into Hugo, using its native multilingual pattern.

The bigger point

Here’s the takeaway I wanted to leave in this anniversary post. Translation at scale, hundreds of articles, your content, in your voice, respecting the tone of the original, used to be an expensive and miserable problem. Now it’s a weekend problem. This is already live — you’re reading the result. The barrier that existed to reaching audiences outside Brazil became cheap enough that I don’t have an excuse anymore.

Alright, so let’s wrap the anniversary recap. 20 years. 727 Portuguese posts, built across five different eras of technology. 354 new English posts generated over a weekend. Half the blog is now bilingual. And the rest will follow. What’s missing is mostly old ActiveAdmin posts, Rails 2 stuff, and obsolete tips that honestly deserve to be deleted or left untranslated on purpose.

If you’ve got a gringo friend who’s tired of seeing you post Portuguese links and needs an excuse to send them something of mine — send it. The main AI posts, the Chronicles, benchmarks, rants, and a good chunk of the historical archive are already available in English at the same domain, just flip the toggle in the footer. Thank you to everyone who’s followed this blog for these twenty years. There are readers here who’ve known me since the Blogspot days. You know who you are.

Here’s to another year.

But the game that really got me hooked on the simcade genre was the original Gran Turismo, in 1997, on the PlayStation 1. “The Real Driving Simulator” on the cover. I played that game obsessively. Around the same time I was watching the Initial D anime, which premiered in 1998 in Japan. I bought every manga volume and read all of it from start to finish. The story of Takumi Fujiwara going down Mount Akina at dawn delivering tofu in his father’s AE86 is, to me, one of the best motorsport stories ever told in any medium.

I still follow Shuichi Shigeno’s work today. After Initial D came MF Ghost (2017-2025), set in the same universe but in a near future where combustion cars have become museum pieces. And now, since July 2025, I’m reading Subaru and Subaru, the direct sequel that ties the Initial D and MF Ghost universes together with two protagonists named Subaru — one from Gunma, one from Kanagawa — competing in a new racing series. It’s Shigeno at his best.

Two years ago I traveled to Japan with my girlfriend and made a point of going to Daikoku PA, the famous parking area on the Shuto Expressway in Yokohama where the JDM culture concentrates. As an old fan of Tokyo Xtreme Racer, by Genki, I needed to see Daikoku with my own eyes at least once. And it didn’t disappoint. Instead of renting a car, we booked a tour with a local guide in his prepped Nissan GT-R. Better that way. On the drive there he explained the history of the Wangan, how the scene works, what’s YouTube exaggeration and what’s real. When we got there on a Friday night and I saw the whole thing in person — Skyline R34, RX-7, Supra, GT-R, tuned kei trucks, insane bosozoku — the feeling was strange in the best possible way. It looked like Tokyo Xtreme Racer, except with the smell of fuel in the air and the sound of real exhaust pipes.

And there’s another detail: I’m playing the new Tokyo Xtreme Racer reboot on PC, and it’s exactly the kind of game that understands its own audience. Strong single-player campaign, addictive progression, the right vibe, and none of the loot box nonsense. I’d recommend it without hesitation. For the same reason, I’m also really looking forward to Forza Horizon 6, which this time is going to be set in Japan. I’ve already pre-ordered it and I can’t wait to play it on the new cockpit.

Driving for real

Now that I’m semi-retired, I’ve had the chance to take my Mercedes to track days. I’ve driven at Autódromo de Interlagos (the Autódromo José Carlos Pace), the 4.309 km circuit in São Paulo that’s been hosting the Brazilian F1 GP since 1973, famous for the S do Senna corner complex and the circuit’s wild elevation changes. I’ve also driven at Autódromo Velocitta, a modern 3.443 km circuit opened in 2014 in Mogi Guaçu in the interior of São Paulo, which hosts Stock Car Brasil and Porsche Cup.

In Las Vegas I’ve driven supercars on those track-day experiences. And when I traveled with my girlfriend to Gramado, in Rio Grande do Sul, we went to Super Carros, which is on Av. das Hortênsias 4635. They have a 2,400 m² hangar with more than 50 cars — Ferraris, Lamborghinis, Porsches, GT-Rs, Corvettes, American muscle cars. You pick a car, head out with an instructor, and drive a roughly 17 km route between Gramado and Canela. I took out a Nissan GT-R and a Ferrari California.

Three years ago I also went to Abu Dhabi with my girlfriend and we went to Ferrari World, which has some of the best racing simulators I’ve ever tried. Hydraulic platform with 6 degrees of freedom, F1 cockpit, the works. I’ve always loved testing simulators wherever I go.

But driving real cars on real tracks is a very expensive hobby. Tires, fuel, insurance, maintenance, registration. And more important: I’m an introvert. I prefer being alone. My simulator cockpit is perfect for when I want to drive without having to deal with anyone. That’s why I love rally so much — it’s me, the virtual co-driver, and the road. Nothing else.

The games I play

I know most people who build a cockpit like this do it to play serious sims — iRacing, Assetto Corsa Competizione, Automobilista 2. I respect that, but it isn’t my thing. I don’t like playing online with other people. I have zero intention of starting a live streaming career. This is purely for my own enjoyment.

These days I play Gran Turismo 7 on the PS5, Forza Motorsport (the 8, from 2023) on PC, but where I have the most fun is in rally games: EA SPORTS WRC, WRC 10 and DiRT Rally 2.0. My first experience with Forza was on the Xbox One with Forza Motorsport 5 and then Forza Horizon 4, which kept me hooked for hundreds of hours.

And I have a huge soft spot for retro games. The original Colin McRae Rally from 1998 on the PS1 was my first rally game. But my favorite of all time is Colin McRae Rally 2.0 (2000), also on the PS1. I recently played through the entire campaign again on the PC version — you can find repacks that run in high resolution and widescreen, much better than the original PlayStation versions. I’d recommend that for any of the titles in the series.

After that came Colin McRae 3 (2002), Colin McRae Rally 04 (2003) and Colin McRae 2005 (2004). Other arcades I revisit often: OutRun 2 SP (2004) and OutRun 2006: Coast 2 Coast (2006) — the best OutRun ever made, in my opinion.

But my game of the year, by a long shot, is Super Woden: Rally Edge. An indie made by a solo developer (ViJuDa, from Spain) that launched in January 2026 for less than R$ 60. Eight countries, more than 80 cars, a career mode, local split-screen multiplayer for up to 4 players, online leaderboards. The behind-the-car camera instead of the top-down view of the previous Super Woden GP made all the difference. 96% positive reviews on Steam with more than 1,300 ratings. It’s the kind of game that proves you don’t need a million-dollar budget to make something amazing.

The evolution of my wheel setup

Logitech G29 era (~2015-2021)

I always wanted a racing wheel. I started over 15 years ago with something equivalent to Logitech’s entry-level wheel, a G29. The G29 is a fine wheel to start with — gear-driven force feedback, pedals with a clutch, 900 degrees of rotation. But its force feedback is noisy and a bit crude. You can feel the gears turning.

Thrustmaster T300RS + SXT V2 stand era (~2021-2024)

Around 2021 I upgraded to the Thrustmaster T300RS, a belt-driven wheel that’s a huge jump up from the Logitech. The force feedback is much smoother and more precise. And I bought the Extreme Sim Racing SXT V2 stand, which is much sturdier than those generic desk clamps.

First I set it up in front of my desktop PC, which at the time had an RTX 3090. It worked, but it was a hassle to keep mounting and unmounting the stand and the cables every time I wanted to play.

Then I built a setup with a long fiber-optic HDMI cable to connect my 60" TV to the PC at the back of the room. I moved the stand in front of the couch. Less of a hassle, but I still had to take it down whenever I wanted to watch a movie with my girlfriend.

Around 2024 or 2025 I swapped my couch for one of those VIP cinema couches from Star Seat, which reclines and the whole nine yards. The problem: it was way taller than the previous couch. I had to do all kinds of workarounds to make the stand work at that height. I even 3D-printed mounts and sent them to PCBWay to machine steel plates so I could attach big wheels under the stand and gain a few centimeters of height. But that left the setup way too wobbly to drive comfortably.

Fanatec CSL DD + Direct Drive era (~2024-2025)

In the meantime I gave the T300 to my brother and upgraded to a Fanatec CSL DD Gran Turismo Edition. The CSL DD’s direct drive motor delivers 5 Nm of torque at the base, but the Gran Turismo DD Pro kit comes with the Boost Kit 180 that brings it up to a sustained 8 Nm with no active cooling. Direct drive means there’s no gear or belt between the motor and the wheel — the motor’s shaft IS the wheel’s shaft. The difference is absurd. The T300 was already great, much better than the Logitech. But the Fanatec is on another level. You feel every asphalt texture, every bump, every incipient slide. There’s no going back once you try it.

I bought it together with the CSL Pedals with Load Cell kit, which measures pressure on the brake instead of displacement. Makes all the difference in braking — you learn to modulate by foot pressure, not by how far the pedal moves. Way more natural.

I also wanted to try the H-pattern manual shifter with the ClubSport Shifter SQ V1.5 from Fanatec and a separate handbrake. It’s fun to try out old cars with a clutch and an H-pattern, but in practice I never adapted. The SXT V2 stand was already shaking a lot with the direct drive, and using the shifter on that unstable setup was frustrating. And I know there are people who want to do heel-toe, but in the simulator I prefer to keep my left foot on the brake and my right on the gas and modulate both at the same time. Works better for me. Now that I have the McLaren wheel with the analog handbrake and clutch paddles right on the wheel, the H-pattern shifter and the external handbrake have been retired. For rally, an analog handbrake on the wheel is much more natural.

I also bought the PS5 with Gran Turismo 7 around this time. I put on the dbrand Darkplates matte black faceplates to replace the original white plates — it looks much better and more discreet.

But the setup was still the SXT V2 stand in front of the VIP couch. The same kludge. The same wobble. I obviously wasn’t going to give up the cinema couch. The situation became unsustainable.

The computer and the hardware setup

A note on my gaming hardware. I bought a Minisforum UX790 Pro to be my dedicated Steam machine. It’s a mini-PC with an Intel Core Ultra 9 285H processor, fits in the palm of your hand. Together I bought the Minisforum DEG1, an external GPU dock that connects via OCuLink (PCIe 4.0 x4, 64 GT/s). It’s an open design — basically a board with a PCIe x16 slot and room for an ATX or SFX power supply. There’s no card size limit, so an RTX 4090 fits comfortably. The performance loss compared to a native PCIe slot is minimal. I put the RTX 4090 in it. The 4090 came from my desktop — at the start of 2025 I went to Miami and took the chance to buy an RTX 5090 because I was using more and more local AI and LLMs. I gave my old 3090 to my girlfriend to use for video editing. The 4090 went into the mini-PC.

So my gaming setup today is: Minisforum UX790 Pro + eGPU with RTX 4090 for Steam and PC games, and a PlayStation 5 with matte black Darkplates for Gran Turismo 7 and exclusives.

The cockpit: Formula FX1

To round out the setup I also needed a decent monitor. I was already used to my 80" Samsung OLED TV in the living room and didn’t want to downgrade picture quality. So I invested in the Samsung Odyssey OLED G8 32". It’s a 4K (3840x2160) OLED monitor with a 240 Hz refresh rate, 0.03 ms response time (GTG), HDR True Black 400, HDR10+, 99% DCI-P3 coverage, 1,000,000:1 contrast, and FreeSync Premium Pro. It has 2 HDMI 2.1 inputs and 1 DisplayPort 1.4.

In practice: the colors pop, black is real black (it’s OLED, no backlight), and with the RTX 4090 I run most games at 4K and 120 fps with no problem. On lighter titles like Super Woden: Rally Edge, it easily hits 240 Hz. The smoothness is absurd. For a cockpit where you’re 60-70 cm from the screen, 32" OLED in 4K is the sweet spot. Bigger and you start to see pixels. Smaller and you lose the immersion.

In January 2026, after years of kludges, I finally ordered a dedicated cockpit. I researched a lot. I considered the Cockpit AX160, made of aluminum profile and very modular, and the Cockpit 4.0, which is the more traditional tubular steel kind. But neither was available at the time of purchase. And then I found the Formula FX1 in black and green from Extreme Racing — Petronas colors, F1-styled.

The FX1 is very different from traditional cockpits. The whole structure is welded thick steel tubing. When I say it doesn’t shake, I mean it doesn’t shake at all. Zero wobble. It’s a brutal difference compared to a stand in front of the couch. The driving position is reclined, F1-style — your feet are at the same height or higher than your hips. You’d think it would be uncomfortable, but it isn’t. You can sit there for hours without complaining. It comes with a padded adjustable seat, an articulating monitor mount, a tilt-adjustable pedal mount, and a height-adjustable wheel mount.

I had to wait about a month for delivery. In the meantime, as anyone who follows my blog knows, I dove into a 16-hour-a-day marathon testing the new AI agents from Anthropic and OpenAI — check the #vibecoding and #agents tags to see everything I built. After about 30 days of that insane marathon, my lower back gave out and I started developing what looks like a herniated disc. I had to see a doctor and take heavy anti-inflammatories.

And right that week, the cockpit decided to arrive.

The build

I was in absurd pain, but I built the cockpit anyway. It took an entire day to unbox and assemble the heavy steel pieces with my back screaming, but I did it.

The official assembly video I followed:

The McLaren GT3 V2 wheel

After assembling the cockpit, I decided that the standard wheel that comes with the CSL GT kit wasn’t enough. I upgraded to the Fanatec CSL Elite McLaren GT3 V2 (~R$ 4,990). It’s a 1:1 scale replica of the McLaren GT3 wheel, with carbon fiber, an OLED display, and compatibility with PC, Xbox, PS4 and PS5.

What I like most about it: it has the normal shift paddles behind it (shift up/down), but it also has two additional analog paddles that can be configured in four different modes. In mode B, which is what I use, the left paddle works as an analog handbrake and the right one as an analog clutch. That’s perfect for rally — I can pull the handbrake mid-corner without taking my hand off the wheel. It also has two 2-position toggles, two 12-position rotaries, 7 standard buttons with interchangeable caps, and Fanatec’s 7-direction FunkySwitch. It’s a complete racing controller.

The final setup

The cockpit ended up in a corner of my bedroom, between the manga shelves (you can spot Akira, Initial D, and 500-something other volumes in the background). I mounted the mini-PC and the PS5 on the cockpit’s side structure, together with the eGPU and the RTX 4090. Everything stays permanently connected. That’s what makes the difference: I no longer have to set anything up or take it down. I sit, turn it on, and I’m driving in 30 seconds.

The audio system

To round out the setup I needed dedicated audio. I didn’t want to use the monitor’s audio (terrible) and I didn’t want to be on a headset all the time. The fix was to build a separate audio system with HDMI audio extraction.

The centerpiece is an HDMI 2.1 switcher from OREI with audio extraction. It has 2 inputs and 1 HDMI output, supports 4K at 120Hz (48 Gbps of bandwidth), and extracts the audio through optical TOSLINK and 3.5mm. I connect the HDMI output of the RTX 4090 to one input and the PS5 to the other. Video goes to the monitor. Audio goes out through the optical port.

The optical audio goes to an Aiyima D03 amplifier, a compact 2.1 channel amp with 150W per channel, integrated DAC (PCM1808 chip), and Bluetooth 5.0 with aptX HD. It has optical, coaxial, USB, RCA and Bluetooth inputs. It even has a dedicated subwoofer output for when I get around to adding one. It uses Texas Instruments’ TAS5624 amplifier chip and has bass and treble control through the remote. For a cockpit setup where you’re 1 meter from the speakers, 150W is more than enough.

In practice, I keep the amp at 50% and Windows volume at 50%, and that’s already loud as hell. Which is to say: this isn’t a “good enough” little system. It’s set up to actually go loud if I want.

The speakers are Edifier P12, passive, with a 4-inch woofer and a 19mm tweeter. Frequency response from 55Hz to 20kHz, 6 ohm impedance, 20W RMS each. The MDF cabinet with wood finish has a rear bass-reflex port that helps the lows. For passive speakers this size, they deliver well. The mid-range is clean and the highs don’t distort even at high volume.

The setup logic is: HDMI switcher handles the switching between PS5 and PC, extracts audio to optical, the amp converts and amplifies, and the passive speakers deliver the sound. All without having to touch the monitor or swap cables. I press a button on the switcher and switch consoles.

When I want to play without bothering anyone, I plug my Meze 109 Pro directly into the 3.5mm output of the HDMI switcher. The Meze 109 Pro is an open-back headphone with 50mm dynamic drivers, 40 ohm impedance, 112 dB SPL/1mW sensitivity, and 5Hz to 30kHz response. The ear cups are walnut wood with handcrafted finish. It’s an audiophile headphone that works perfectly without a dedicated amplifier thanks to the low impedance. The sound is warm, with full bass and rich mids. You can hear every detail of the engines.

I haven’t decided about a subwoofer yet, but it’ll be my next upgrade. A dedicated sub is going to add that low-end weight that makes you feel the engine in your chest.

The verdict

The couch with a stand works. The PC desk with a stand works. But neither comes anywhere close to a dedicated cockpit. The FX1’s steel structure doesn’t move a millimeter, even with the Fanatec direct drive at max torque. The reclined F1 position is comfortable for sessions of hours. The load cell pedals stay firm on the base. The monitor is exactly at the right height and distance. And best of all: it’s always ready. I don’t need to assemble anything, take anything down, run cables, none of it. I sit and I drive.

For anyone who’s wondering whether it’s worth investing in a dedicated cockpit instead of staying with a desk or couch stand: it is. If you already have a direct drive wheel, the cockpit is the missing piece. I spent years thinking “this is fine” with the stand on the couch. It wasn’t fine. The difference in driveability is something else entirely. And for my case — introvert, single-player only, simcade — I couldn’t have built it any sooner. To be honest, I think I’ve finally landed on the simulator setup that’s perfect for my taste.

Shopping list: how much it all cost

Here’s the consolidated list of everything in my current setup, with approximate prices (some were bought in dollars and converted to reais at the time’s exchange rate):

Yes, almost R$ 57k is a lot of money. I worked like a dog for decades. Now that I’ve managed to retire honestly, my family is well taken care of, I have no debts, and I can finally give myself something I always wanted as a kid but couldn’t afford. When I sat at those OutRun and Daytona USA cabinets at the arcade, I dreamed of having something like this at home. It took 30-something years, but I got there.

And if you add up the years of kludges, stands that didn’t work, 15-meter HDMI cables, 3D prints, machined steel plates, and the frustration of mounting and unmounting everything — a dedicated cockpit saves your sanity. Unlike a PC that depreciates fast, a steel cockpit lasts decades.

The result was 653 commits, ~144K lines of code across 8 projects published on GitHub, and a series of articles documenting each one. If you’ve been following along, you’ve already read the post-mortems. If you haven’t, here’s the index:

The articles

• Vibe Code: I built a small app 100% with GLM 4.7 (TV Clipboard)
• Vibe Code: Which LLM is the BEST?? Let’s get real
• Vibe Code: I built a Markdown editor from scratch with Claude Code (FrankMD) PART 1
• Vibe Code: I built a Markdown editor from scratch with Claude Code (FrankMD) PART 2
• RANT: Did AI kill programmers?
• Vibe Code: From Zero to Production in 6 DAYS - The M.Akita Chronicles
• From Zero to Post-Production in 1 Week - How to Use AI on Real Projects
• Vibe Code: I built a Mega clone in Rails in 1 day for my Home Server
• Vibe Code: I built an Intelligent Image Indexer with AI in 2 days - Frank Sherlock
• RANT: Did Akita open his legs to AI??
• ai-jail: Sandbox for AI Agents
• Software Is Never ‘Done’ - 4 Projects, the Life After Deploy
• I Built a Data Mining System for My Influencer Girlfriend
• My First Vibe Code Failure and How I Fixed It - Frank Yomik

The projects

All of this happened between January 27 and March 5, 2026.

I’m not going to repeat the technical details of every project. Each post-mortem above already covered that. What I want to discuss here is the consequence.

What these 37 days showed me

Projects that used to take weeks or months for an experienced developer now take days. A complete Markdown editor in 5 days. A Mega clone in 1 day. A data mining system with 40+ bot tools in 3 days. An image indexer with vision AI in 2 days.

And I’m not talking about throwaway prototypes. These projects are in production. They have tests. They have automated deployments. It’s real software built with real engineering practices, just at a speed that was unthinkable before.

This speed isn’t unique to me. Cloudflare just demonstrated something similar. In a recent post, they describe how an engineer reimplemented the Next.js API surface on top of Vite in a week, using Claude as the main tool. US$ 1,100 in API tokens, more than 800 sessions, 1,700 unit tests, 380 E2E tests, builds 4.4x faster than the original Next.js. Controversies aside about whether it’s a “complete” reimplementation or not, the central point is real: software that used to require teams and months can now be built by one person in days.

And that changes everything for anyone wanting to start a company.

The death of the easy startup

For years, the classic startup model worked like this: someone has an idea, puts together a small team, builds an MVP in 3-6 months, raises seed money, and tries to scale. The barrier to entry was development cost. Programmers are expensive, development is slow, and the first to market has the advantage.

That model is breaking.

If I can build a working Mega clone in 1 day, what’s a “cloud storage” startup worth? If Cloudflare reimplements the Next.js core in 1 week with one engineer and US$ 1,100 in tokens, what’s the real moat of a platform like Vercel? The “social listening” SaaS that charges R$ 500/month is competing with something I built in 3 days as a side project.

Every entrepreneur who used to show up describing their idea as “it’s like Uber, but for…” or “it’s like Airbnb, except…” or “another social network, but with…” — those people need to stop and rethink. When any competent developer with access to Claude Code or GPT Codex can replicate your MVP in a week, your idea isn’t worth anything anymore. Execution got too cheap.

I’m not exaggerating. In my 37 days, I built things I wouldn’t even attempt in 6 months before. Small CRMs, ecommerces, content managers, productivity tools, data mining apps, processing pipelines — all of that became commodity. The code itself is no longer the differentiator.

So what is the differentiator?

This is where most vibe coding enthusiasts miss the point. To illustrate, let me use my own project as an example.

Frank Yomik translates manga pages from Japanese to English in near real-time. The full pipeline (balloon detection, OCR, translation, rendering) works. But the most important component of the system isn’t any code I wrote. It’s the ogkalu/comic-text-and-bubble-detector model, an RT-DETR-v2 trained on ~11,000 labeled comic images.

I didn’t train that model. I couldn’t easily train that model. Collecting 11,000 diverse comic images, manually labeling the speech balloons in each one (or generating labels with some semi-automated pipeline, which isn’t trivial either), configuring the training, and running it on the necessary hardware — that’s work of a different nature. It’s work that vibe coding doesn’t solve.

And that’s the case of a relatively small model. An object detector can be trained with a few hundred to a few thousand labeled images on a single GPU in hours. Studies show useful results are possible with 100-350 images for specific domains, but robust real-world detectors usually need thousands. The cost is low, in the hundreds of dollars range.

Now look at what happens when we scale up to bigger models.

The numbers that matter

GPT-4 cost more than US$ 100 million to train, according to Sam Altman himself. Stanford estimated the compute cost of Google’s Gemini Ultra at US$ 191 million. Meta’s Llama 3 consumed 39.3 million GPU-hours on H100s, and Meta built two clusters of 24,576 GPUs each to make it possible — and by the end of 2024 it planned to have 350,000 H100s in its infrastructure.

These costs are accelerating. According to Epoch AI, the cost of hardware and energy to train frontier models grows by 2.4x per year since 2016. If that trend continues, the largest training runs will cost more than US$ 1 billion before the end of 2027. Dario Amodei, Anthropic’s CEO, has said frontier developers are probably spending close to a billion per training run now, with US$ 10 billion training runs expected within two years.

And the hardware? An H100 GPU costs US$ 25,000-40,000 per unit. A server with 8 GPUs runs between US$ 200,000 and US$ 400,000. The HBM memory those GPUs use is at capacity — SK Hynix, Samsung and Micron have already announced ~20% price increases for 2026. NVIDIA consumes more than 60% of the global HBM production. It’s a structural bottleneck, not a temporary one.

In terms of energy: global data centers consumed ~415 TWh of electricity in 2024, according to the IEA, about 1.5% of the world’s electricity. The projection is ~945 TWh by 2030. New data centers are being built with capacities of 100 MW to 1 GW each.

And the big tech investments reflect that. In 2025, the aggregate capex of Amazon ($125B), Google ($91B), Microsoft ($80B) and Meta ($71B) crossed US$ 400 billion, a 62% increase over 2024. Goldman Sachs projects more than US$ 500 billion in 2026.

These numbers aren’t meant to scare. They’re meant to put the real entry barrier in context.

The new barrier: exclusive data and training capacity

If software got cheap to produce, the competitive differentiator migrated. The question stopped being “who writes code the fastest?” and became “who has access to data nobody else has, and knows how to turn that data into useful models?”

DeepSeek-V3 announced that its training cost US$ 5.5 million in compute. The press celebrated the “cheap Chinese model.” But The Register reported that the acquisition cost of the 256 GPU servers used was over US$ 51 million — and that excludes R&D, data acquisition, data cleaning, and all the failed training runs before the final successful one. The real cost of developing the capability is one or two orders of magnitude above the marginal cost of the final successful training run.

That’s why we only see large companies producing frontier models. Meta, Alibaba, Google, Amazon, Microsoft, Anthropic — companies investing tens of billions in hardware and energy. A garage startup can’t compete on this dimension.

But the question goes beyond frontier models. Even smaller specialized models require something you can’t buy: high-quality proprietary data.

Llama 3 was trained on 15 trillion tokens. Epoch AI has documented that we’re approaching the limits of human-generated text data on the internet. Public data is being exhausted. Whoever has exclusive data — medical, financial, industrial, logistics, sensor, user behavior — has something that vibe coding can’t replicate.

And even those who train specialized models with proprietary data face a problem: the advantage is temporary. Another competitor can collect similar data and train a competing model in months. The differentiator needs to be continuously fed: more data, better curation, more efficient training pipelines, access to hardware that’s increasingly scarce and expensive.

The picture

If you’re thinking about starting a company, the question that matters has changed.

Before it was: “can I build this software?” Now the answer is almost always yes, fast and cheap.

The question now is: “do I have exclusive data nobody else has, and do I know how to turn that data into something useful that’s hard to replicate?”

If the answer is no, any competitor with Claude Code replicates your product in days. And then another one shows up. And another. The race to the bottom on price is immediate when the cost of building is close to zero.

If the answer is yes, you have a real moat — but a temporary one. Competing models trained on similar data can show up in months. Your differentiator needs to be continuously fed.

The era of easy startups is over. Not because building software got harder — it got way easier. But precisely because of that: when everyone can build the same thing in a week, the competitive advantage has to come from somewhere else. And that “somewhere else” requires capital and infrastructure that are orders of magnitude more expensive than writing code.

The garage still works. But what comes out of it can no longer be “an app.”

–

I published the “final post” of the Behind The M.Akita Chronicles series 10 days ago. 274 commits, 1,323 tests, deployed to production. I wrote down the lessons, did the conclusion, dropped the quote at the end. Done.

125 post-production commits later, I can confirm: software “done” doesn’t exist.

Today the M.Akita Chronicles repo has 335 commits and 1,422 tests. Tomorrow, Monday, subscribers get the 3rd consecutive newsletter — generated, reviewed, and sent by a system that won’t stop evolving. Meanwhile, Frank Sherlock went from 50 commits and v0.1 to 103 commits and v0.7 with face detection. FrankMD got 3 external contributors and shipped v0.2.0. And even FrankMega — a project built in 1 day — needed fixes when real users showed up.

Throughout February, I published more than a dozen posts detailing the build of each project. This post is different. It isn’t about building from scratch, I covered that already. It’s about what happens after. And what happens after destroys the one-shot prompt narrative. Software needs an experienced human at the wheel. Iterative development is the only thing that works. Anyone who disagrees hasn’t put a system in production yet.

I’ll prove it with git log.

Life After Deploy

Let’s get into the details.

The M.Akita Chronicles: 3 Weeks in Production

The newsletter system has been live since February 16. It’s already sent 2 newsletters and tomorrow it sends the third. 56 commits have happened since the “final post”:

Features Nobody Saw Coming

Steam Gaming. Wasn’t in the original plan. It was born because the entertainment section only had anime — and gamer readers were left out. Result: 6 commits just on launch day. The first commit (bf41e25) added the whole section — Steam API service, generation job, tests, Hugo shortcode. The next 5 fixed things: Portuguese date parsing, ranking offset so the top 10 didn’t repeat, wishlist filter for releases, dark theme. No spec in the world predicts that the Steam API returns dates with Portuguese abbreviations ("fev", "mar", "abr") when you ask for l=brazilian. You find that out when the parser breaks in production.

Preview system. /preview was born because I needed to see how the auto-generated content looked before publishing the entire newsletter. Seems obvious in retrospect, but in v1 the only way to validate was to generate everything and look at the final result. 5 commits to build a preview system with 9 sections, aliases (hn for hacker_news, steam for steam_gaming), separate comment-preview mode, and rescue when one section fails without taking the others down (d23c725 — because a section with an error was killing the entire preview).

Marvin’s moods. Marvin (the bot’s sarcastic persona) suffers from a chronic LLM problem: smoothing. Without intervention, every comment ends up the same lukewarm tone. The iterative fix was a mood system — 9 modes the operator picks per story:

MARVIN_MOODS = {
  "sarcastic"   => "Be extra sarcastic and biting in your commentary.",
  "ironic"      => "Use irony and dark humor to make your point.",
  "grounded"    => "Be more neutral and journalist-like, factual and measured.",
  "provocative" => "Be provocative and controversial, challenge assumptions.",
  "counter"     => "Take the opposite position from Akita's comment.",
  "insightful"  => "Find a non-obvious angle -- a historical parallel, a second-order consequence.",
  "positive"    => "Find the genuinely positive angle.",
  "hopeful"     => "Be cautiously optimistic. Acknowledge the good potential.",
  "negative"    => "Be extra pessimistic and bleak."
}.freeze

None of this came from a spec. It came from 3 weeks of reading bland comments and thinking “this isn’t good enough”. There are 7 commits just for prompt tuning across 10 days. I banned formulaic patterns (d4bd3a6). I killed off “Ah,” as an opener (4171628). I removed Marvin from entire podcast sections because he was contaminating the tone (246cc60). I pushed for substance instead of puns (8bc47c4). Each prompt commit is a micro-correction that only makes sense after reading the previous output.

Bugs That Only Exist in Production

Of the 56 commits, 13 are bug fixes. Some favorites:

• Gmail clipping (3258f5b): Gmail silently cuts off emails larger than 102KB. I found out when the 2nd newsletter went out longer and Gmail readers didn’t see the end. Fix: a size check in the content preflight that warns before publishing. I shrunk the history sections from 10 to 5 items (51ce528) to fit the limit.

• False paywall detection (1fd8739): the scraper marked sites as paywalled when it found accidental block text in a generic footer. Only showed up when the story list grew to dozens of real sources.

• t.co link mangling (6bd056f): Twitter shortens URLs with t.co, but it also auto-links file names that look like domains. config.yml becomes a link to the config.yml domain. 158 lines of fix to handle tweet text correctly.

• TTS language revert (7803ad9 -> c1dd668): I tried switching the TTS language from “Portuguese” to “Auto”. The model produced a mixed accent. Reverted the same day.

• Podcast section ordering (5bef18c): podcast sections came out in the wrong order. 3-line fix + untracking of 1,504 lines of generated content that had been committed by accident.

• Elementor sites with multiple <article> (e70b756): sites built with Elementor use the <article> tag in a non-semantic way. The content extractor was grabbing the wrong block. 171 lines of fix + tests.

None of these bugs could have been predicted in a spec. They only exist because the system is live, processing real data, hitting real APIs, being read by real people.

From 1,323 to 1,422 Tests

The test suite kept growing along with it:

New feature? Comes with a test. Bug fix? Comes with a regression test. Without that, the 56 post-production commits would be 56 chances to break something that worked yesterday. TDD isn’t a phase, it’s a habit.

The Model Changed: From Claude to Grok-4

Commit 8f9d11c: Switch default model to x-ai/grok-4. The architecture had isolated the LLM model into an environment variable from day one. But the model name was still hardcoded across 24 files. Result: commit c8c688e — Centralize LLM model config — 24 files touched to make swapping models a 1-line config change.

This kind of refactoring only shows up in operation. When you start the project, you don’t know you’re going to change models. When you change, you want it to be trivial. And the cleanup to make it trivial? Only happens when the pain shows up.

Frank Sherlock: From v0.1 to v0.7 in 4 Days

The Frank Sherlock post covered the first 2 days and ~50 commits: the benchmark research, the Tauri app scaffold (Rust + React), the classification pipeline with Ollama, and the v0.1.0 release with binaries for Linux, macOS and Windows.

What the post didn’t cover: the next 53 commits, in 4 days, that took the project from v0.3 to v0.7:

Face Detection: A Feature Born from Iteration

v0.1 was an image indexer with LLM-based classification. v0.7 has face detection with 512-dimensional embeddings, cosine-similarity clustering, and per-person search (face:alice). None of that was in the original plan. It came up because I started using the app with real photos and thought “I want to find every photo of so-and-so”. The feature was born from use, not from a spec.

The path to get there was methodical:

1. f34132f: A/B testing framework for face detection — benchmark before implementing, not after
2. ef3be82: A/B results (SCRFD + ArcFace won)
3. 6d9174a: Native implementation with ONNX Runtime — no Python, no external dependency
4. 3b25eaf: Clustering, person management, complete FacesView
5. a02d67f: Refactoring — extract helpers, delete dead code, share CSS

Benchmark -> implement -> refactor. The same cycle as always. And something no one-shot prompt produces.

Video Support: Another Emergent Feature

The app was built for images. But real media folders have videos. Commit a67a2f9 added full support: scanning of 11 formats (MP4, MKV, AVI, MOV, WebM…), keyframe extraction for LLM classification, black frame skipping, .srt subtitle parsing for the full-text index, and inline preview with HTTP Range streaming.

1,626 lines added in one commit. An entire feature born from real use, not from a spec.

7 Releases, 3 Platforms, Automatic AUR

In 7 days, Frank Sherlock had 7 releases. Each one with binaries compiled for Linux (AppImage), macOS (DMG with notarization and code signing), and Windows (MSI). The CI/CD pipeline (release.yml) does everything automatically. Starting at v0.5.0, an additional workflow (aur-publish.yml) publishes automatically to the AUR — the Arch Linux package repository.

Final tally: 17,210 lines of Rust, 10,863 lines of TypeScript, 621 tests (322 Rust + 299 frontend). Cross-platform. Releases published and installable by any user. One week, one dev, one AI agent.

The CI/CD cross-platform part is where the “works on my machine” fantasy dies. There were 17 commits just for builds: Windows UNC paths, macOS signing with notarization, Linux AppImage, release workflow permissions, macOS Intel target removed. No LLM in the world knows that macOS requires specific entitlements for hardened runtime, or that paths on Windows start with \\?\. That kind of deploy work demands someone who’s been through that pain before.

FrankMD: Real Open Source

FrankMD was the first project in this saga, a self-hosted Markdown editor with Rails 8. The February posts covered the build. What happened after is more interesting: other people started contributing.

14 commits since February 20. 3 external contributors. 4 PRs merged. v0.2.0 release on the 28th:

The Maintainer’s Pattern

What’s most telling isn’t the contributions themselves, but what I did after every merge.

When @LuccaRomanelli submitted the Omarchy theme sync PR (+308 lines), I merged it and immediately committed fix: harden Omarchy theme integration and fix broken tests — +163 lines of fixes and tests in the next commit. The contributor implemented the feature. The maintainer hardened it.

When @rafaself submitted the table hint fix, there were 3 iterative commits the same day — enhance, improve, streamline — showing the same progressive refinement pattern I do with the AI agent. The next day, he sent a separate commit updating faraday, nokogiri and rack for security advisories.

On the 28th, I sat down and did everything in one shot: merged the 4 PRs, committed the hardening, updated 5 gems (brakeman, bootsnap, selenium-webdriver, web-console, mocha), and published the v0.2.0 release notes. A classic “release day”.

FrankMD today has 226 commits, 1,804 tests (425 Ruby + 1,379 JavaScript), and active contributors. It isn’t “my little personal project” anymore. It became software with a community. And community doesn’t show up for a test-less prototype that “works on my machine”. It shows up for a project with green CI, documentation, versioned releases, and code you can actually read.

FrankMega: Even the Smallest Project Needs Post-Production

FrankMega was built in 1 day. 26 commits, secure file sharing with Rails 8, 210 tests, deploy via Docker + Cloudflare Tunnel. Post published the same day. Done, right?

Three days later, 2 commits:

• db4bb705 — Add macOS, Linux, and Windows package MIME types to seed defaults
• b0c4829a — Fix MIME types to match Marcel detection, add normalizes strip

Users tried to share .dmg, .deb, and .msi files. The MIME type detection (via the Marcel gem) didn’t recognize those formats because they weren’t in the seed defaults. Two commits. 22 lines. 15 minutes.

But without them, FrankMega couldn’t be used to share installer packages — which is exactly the most common use case on a dev’s home server.

No prompt in the world predicts that your users will want to share .deb files on day one.

The simplest project of all, with the shortest post-production. And even then, it needed iteration.

The Consolidated Numbers

692 commits. 4,057 tests. 4 projects in production. February 2026. Me and an AI agent.

Why One-Shot Prompting Is a Myth

Look at the 125 post-production commits and tell me which one of them could have been predicted by a spec.

Gmail cuts off emails larger than 102KB, and you only find that out when you send the first long email. The Steam API returns dates with Portuguese abbreviations ("fev", "abr"), and you only find that out when the parser breaks on generation Sunday. macOS users try to share .dmg files and can’t because the MIME type isn’t in the seed. Marvin opens every comment with “Ah,” and you only notice it after reading 30 in a row and wanting to claw your eyes out. The LLM model has to be swappable with 1 line of config, but it’s spread across 24 files. Windows uses UNC paths starting with \\?\, and CI explodes in your face. And TTS in “Auto” mode? Generates an accent that sounds like Lisbon Portuguese trying to be carioca.

None of this is “debugging” in the traditional sense. It’s navigating a problem space that only reveals itself when the software meets reality. Each one of these was a real-time decision made by someone with context.

The one-shot prompt fantasy is that, if you write a sufficiently detailed spec, the AI produces the perfect software. But the perfect spec would require you to know in advance everything that’s going to go wrong. And if you knew in advance everything that’s going to go wrong, you wouldn’t need the spec — you’d already have the software done in your head.

Good software is the result of hundreds of micro-decisions made with the system running. Not a single macro-decision made before the first line is written.

The Role of the Experienced Developer

AI accelerated all of this. Without it, 692 commits in a month would be impossible for one person. But acceleration without direction is just faster entropy.

In every project there were decisions the AI couldn’t have made on its own. Switching from Claude to Grok-4 because the previous model was weak in a specific domain. Benchmarking SCRFD against alternatives before implementing face detection, because the wrong choice would cost days. The +163 lines of hardening I committed immediately after merging the Omarchy PR, because I saw where it was going to break. The TTS revert from Auto mode the same day, because I know that “Auto” on a TTS model for Brazilian Portuguese will produce a mixed accent.

The circuit breaker case is the most illustrative. When I added rate limiting, the Brave Search API started returning 429s every once in a while. If I had asked, the agent would have implemented a retry with exponential backoff. But I didn’t ask for retry. I asked for a circuit breaker:

class WebSearcher
  CIRCUIT_BREAKER_SECONDS = 120

  def self.search(query, max_results: 5)
    return [] if circuit_open?

    response = brave_search(query, max_results)

    if response.code == 429
      trip_circuit!
      Rails.logger.warn("WebSearcher rate limited (429)")
      return []
    end
  rescue Net::OpenTimeout, Net::ReadTimeout => e
    trip_circuit!
    []
  end
end

If the API returns 429 or times out, it stops trying for 120 seconds. No retry, no backoff, no queue. Why? Because I know the cron runs every day at 8am and that on newsletter generation Sundays the query volume triples. A herd of retries delaying everything is worse than empty results in one section.

The AI implements a circuit breaker when you ask it to. But it isn’t going to ask to implement a circuit breaker. It doesn’t have the operational context. That’s knowledge that comes from running systems in production for decades.

The agent writes the code. I decide what code to write. And that decision requires experience no prompt can replace.

The Lessons

1. Software in production diverges from the spec in hours, not months. The first M.Akita Chronicles bugs showed up in the first real newsletter. FrankMega’s MIME types broke on the first uploads. Anyone who thinks deploy means done is living in a world that doesn’t exist.

2. Post-production isn’t “maintenance”. 56 commits in 10 days on the M.Akita Chronicles aren’t patches. They’re new features (Steam Gaming, preview, moods), architecture refactoring (LLM config centralization), security hardening (rate limiting). That’s development. The software didn’t stop evolving just because I said “done” in a blog post.

3. TDD protects evolution. 99 new tests in 10 days. FrankMD’s 1,804 tests let me merge 4 external contributor PRs without fear. Without tests, every merge is Russian roulette.

4. Small releases keep you sane. 7 Frank Sherlock releases in 7 days. Green CI, compiled binaries, release notes. Something broke? Roll back one version. Compare that with “6 months + big bang release” and tell me which one works better.

5. Community shows up for real projects. Nobody sends a PR to a test-less prototype that “works on my machine”. FrankMD got 3 contributors because it has green CI, documentation, and versioned releases.

6. The developer’s experience is the bottleneck, not the AI’s speed. 692 commits in a month. But every commit that mattered required decades of experience to know it was needed. The AI types fast. I know what to type.

7. One-shot is for demos. Iteration is for production. If the goal is a 10-minute video showing a “finished SaaS”, one-shot will do. If the goal is software that survives contact with real users, only iteration works. And sustainable iteration demands discipline: TDD, CI, small releases, continuous refactoring. No shortcut.

To the Senior Still Sitting on Their Hands

So far I’ve been hitting the amateurs who think they can fire off a prompt and the AI spits out a finished system. Fair enough. But there’s another group that worries me just as much: the senior developer who saw the AI mess up three times, declared “this is useless”, and went back to doing everything by hand.

I get the reasoning. The AI hallucinates, generates code with subtle bugs, suggests over-engineered solutions. All true, and I documented every one of these problems in the previous posts. But tell me something: have you never done exactly the same thing? Have you never spent 2 hours reading documentation only to find out it was a typo in the config? The difference is that when the AI gets it wrong, you catch it in the tests and fix it in minutes. When you get it wrong on your own, it takes you the same amount of time to make the mistake and even longer to find it, because you trust your own code.

Let’s look at the concrete numbers of what I shipped in February, one person and one AI agent:

Now do the math in your head. How long would it take you to build Frank Sherlock on your own? A Tauri app from scratch, with an LLM classification pipeline in Rust, OCR via Python, full-text search with FTS5, duplicate detection by perceptual hash, face detection with native ONNX, video support with keyframe extraction, CI for 3 platforms with macOS code signing and notarization, auto-update, and automatic publishing to the AUR. With 621 tests. In Rust, which doesn’t forgive.

To be honest: without AI, a good senior dev would take at least 3-4 weeks on this, probably more. I did it in 7 days, alone, and every release is published with binaries anyone can download and install.

I already estimated The M.Akita Chronicles in the previous post: ~200 user stories. In Scrum with a senior team of 2-3 devs, no impediments, that would be 10-15 weeks. I did it in 8 days. Today, 3 weeks later, the system keeps running, evolving, with 99 more tests than when it “was done”.

FrankMega is more modest, but secure file sharing with Rails 8, I18n in 2 languages, 22 security issues fixed, Docker deploy, 210 tests. I did it in 1 day. A good senior, without AI, would do it in 1-2 weeks at best.

And I’m not talking about disposable prototypes. People from outside send PRs to FrankMD. Real subscribers get the M.Akita Chronicles newsletter every Monday. Anyone can download Frank Sherlock from GitHub Releases or the AUR. Green CI, Brakeman clean, real tests, automated deploys. That’s production software, not a conference demo.

“Yeah, but I write better code without AI.” Maybe. But how long does it take you? What I showed here isn’t that AI writes perfect code. Far from it. It’s that with TDD, CI, pair programming with the agent, and continuous refactoring, the end result is production code with quality. 4,057 tests are there to prove it. Brakeman clean. 125 post-production commits show the code can take evolution without turning into a ball of mud.

And using AI here and there to generate a snippet of code, like glorified autocomplete, also isn’t the answer. You’re leaving 90% of the gain on the table. What I did in February was full-time pair programming with an agent. From the first commit to production deploy. With the same discipline I’d use with a human pair. Result: 4 projects in production in 1 month, with quality I put my name on. Because I did put my name on it.

If you’re a senior and you’re still waiting for AI to “get better” before you really start using it, here’s my message: it’s already good enough. The 692 commits are there to prove it. The bottleneck now is you learning to work with it.

Conclusion

In February 2026, I built 4 projects from zero to production with AI. But the build is the easy part. What separates real software from a demo is the 125 commits that came after, when the bugs nobody predicted appeared, when external contributors sent PRs that needed hardening, when new features came up from real use and not from a requirements spreadsheet.

AI made me absurdly more productive. Without it, Frank Sherlock wouldn’t have face detection in 7 days. Without it, M.Akita Chronicles wouldn’t be in its 3rd week of operation with 1,422 tests. The speed is real.

But none of the decisions that mattered came from the AI. Switching models, reverting the TTS the same day, looking at the contributor PR and seeing where it was going to break, asking for a circuit breaker instead of retry. All of that was me. The AI executed. The decisions were mine.

The AI is the accelerator. Extreme Programming techniques (TDD, small releases, pair programming, continuous refactoring) are the brake and the steering wheel. Without discipline, AI produces fast code that piles up technical debt even faster. With discipline, AI produces software that actually evolves, week after week.

692 commits. 4,057 tests. 4 projects in production. And tomorrow, Monday, at 7am, M.Akita Chronicles subscribers get the 3rd newsletter. Generated, reviewed, and sent by a system that will never be “done”. Because finished software is dead software.

“Finished software is dead software. Live software iterates.”

“AIs will NEVER replace ANY programmer”

And that’s wrong. Watch the video with the explanation (or look for the transcript). But in short, what I said was:

“AIs will never replace programmers LIKE ME — I will never be replaced”

Another thing I stated and keep stating is:

“AGIs are not possible in the current architecture: it’s not going to happen. A new discovery needs to show up — one we obviously don’t know yet — to break past the current barrier, which is insurmountable.

And that’s where I derived this line from:

“Your excitement about AI is inversely proportional to your knowledge about AI” — and it still holds just as well.

The Programming Bubble Already Popped

My channel started in 2018 and ran until early 2024, with a single purpose:

Helping to prepare real programmers to survive the imminent popping of the bubble (which started around 2014).

I have a whole playlist titled I TOLD YOU SO.

In short, in recent years, “programming” became the “profession of the future”, and it seemed easy. It got obvious when all you saw was ads for every kind of course and bootcamp, with promises like: “become a programmer in 2 months, earn a Google salary, and you barely even have to work.”

I called this kind of programmer the “instant noodle chef”. Just because you know how to boil water and make instant noodles doesn’t make you a chef. It should be obvious, but that’s how programming was sold. None of those courses produced any “programmer”, let alone a “software engineer”.

But “software engineer” is not real engineering. There’s no CREA, CRM, OAB, or any equivalent body that certifies anyone as a “software engineer”. It’s a made-up title anyone can slap on their LinkedIn.

The Black Swan of the Pandemic was something I didn’t predict, but it only helped inflate the final phase of the bubble even further, which popped at the end of 2022 when mass layoffs began across every big tech. And that was BEFORE the advent of LLMs for programming. Coincidentally, ChatGPT showed up around the same time in 2022, but it was not the cause; it was just the last nail in the coffin. The popping of that bubble and the layoffs would have happened anyway.

That’s why my channel must be the only one that, to this day, offers the content someone who actually wants to be a programmer needs. Imagine the other channels that only pushed the narrative that becoming a programmer was easy — they aged VERY badly.

So yes, I agree with Anthropic’s CEO: those “software engineers” will become completely obsolete. Nobody becomes an “engineer” in a 1-month bootcamp. That was bullshit and you had to be really dumb to believe it. Notice how all those snake-oil sellers VANISHED. Where are they?

Don’t know where to start on my channel? Two suggestions:

• Playlist “What courses should I take?”
• Playlist “Career”

The AI “Ceiling”

I finished recording videos for my channel exactly when the AI wave started. I considered that everything I wanted to say had already been said and it all remains available on the channel. My goal was accomplished.

During 2024 and 2025 I took part in podcasts like Flow and Inteligência Ltda talking a lot about AIs and things like quantum computing (and how it too is just hype that won’t amount to anything practical in our day-to-day).

The main point: since the transformers paper Attention is all you need, no other “breakthrough” has appeared that surpasses that milestone. Everything we have today, from OpenAI to Anthropic, and from open sources like DeepSeek, Qwen3, GLM, MiniMax, etc., is based on exactly the same foundation, the same “architecture”.

And I theorized — correctly — that the evolution of this architecture would follow an S-curve:

GPT-1 to 2 was a quantum leap. GPT-2 to 3 was a gigantic leap. GPT-3 to 4 was excellent, but, notably, not in the same proportion. GPT-4 to 5, most regular people barely noticed the difference.

Of course, nobody stood still; every computer scientist, mathematician, engineer kept doing what we always do: optimizing. Better training methods showed up, the idea of “reasoning”, the idea of agents working together (one giving feedback to another), new forms of alignment and instruction. But none of that changes the foundational architecture.

The problem: training each new generation of LLMs gets considerably more expensive (in hardware and, mainly, in energy consumption) to produce a version that isn’t much better than the previous one. That’s the ceiling of the curve. And I reaffirm: until a NEW ARCHITECTURE appears, we’ll only get closer and closer to that ceiling, without crossing it, while spending absurd levels of more memory and more energy.

That’s why there’s an energy shortage: with the increase in usage demand (inference), they have to split between spending energy on training new versions and serving demand. They can’t do both.

Worse, that’s why RAM prices exploded and your PC will get much more expensive too. There are no more resources to train models so big that, proportionally, deliver less and less result (the definition of “diminishing returns”). It’s the fate of every innovation: hitting the ceiling of the S-curve until another one comes along to replace it.

The focus now is on using the versions we already have better. In the programming case, you get GPT Codex or Claude Code, which are strategies for using agents, MCPs, skills, and other tools and forms of orchestration to squeeze the maximum out of what we already have today.

LLM Strategies

Everyone already knows it’s impossible to just write a prompt and have any LLM spit out a perfect system in the end. It will come out very bad; it stays that way and will stay that way in this architecture.

Every LLM has a context (memory) limit. It’s impossible to load the entire source code of a giant ERP like Totvs’s or SAP’s. It doesn’t fit, and even if it did, it wouldn’t be possible to give “attention” to all of it. There are limits: the more memory you load, the worse inference gets; the result gets worse. Like everything in software, it’s a “trade-off”.

Instead, the best thing is to create scripts that walk through your code and extract specific chunks on each run. If you’re working on the shopping cart, you don’t need to load the code that handles the store’s landing page, for example. It’s similar to what a human programmer would do: divide and conquer (as Napoleon would say).

Every LLM specialized in code, like Codex or Opus, was trained to do “tool calling”, which is sending a request to the “chat” so it can fetch information (such as code) and load snippets into the context. For that, it has it run tools like “rg” ripgrep (in Codex’s case) or “grep” (in OpenCode’s case).

If, by chance, the model wasn’t trained on information that only recently came out on the Web, it can do “agentic fetch”, which is executing commands like “curl” to literally go to Google, Stack Overflow, etc., and pull web pages in to use as part of the context (the trade-off is that this will use up the limited context space).

When the context is about to run out (the 200k token range, in Claude’s case, or 1 million, in Gemini’s case), the “chat” that orchestrates (Claude Code, OpenCode, etc.) triggers a summary of the current context, to “compact” the understanding and restart with a new context based on that summary.

To make sure the generated code “works”, tool calling asks it to run local tools like linters, compilers, or LSPs (like an IDE, like VSCode, would). This produces feedback (and burns more context). If it errors, the “chat” can automatically ask it to redo the work, taking this new information into account.

Also, to go “faster”, the “chat” can fire off multiple agents in parallel. Each agent is a new context — and none of this is free, remember: tokens per second. So, it could send one agent to comb through all the code relevant to the database and, at the end, produce a summary. Another agent combs through all the payment code and, at the end, generates a summary. Another agent combs through the cart front-end code and produces a summary. Then the “chat” takes those summaries and goes back to the previous context to execute some task.

What I call “chat” is just to make it easier to visualize. Think of the simple chat interface everyone uses day to day, but with additional features. That’s what a Codex or a Claude Code does. There’s no secret, every tool like this, as well as open source ones like OpenCode or Crush, do the same thing: they set up a “Harness”:

• They start with a system prompt detailing exactly how they want the LLM to respond. This GitHub has several examples of these prompts the tool sends without you knowing.
• LLMs are trained with tool calling and the tool knows how to respond to those calls (executing bash, curl, ripgrep, sed, diff, git, etc.)
• The tool is capable of running multiple agents in parallel (think multiple “chats” in parallel)
• The tool asks the LLM to produce a “plan” first and enumerate tasks. Then it can orchestrate the sequential execution of those tasks, each in a different agent, for example.
• The tool is capable of managing context limits and knowing when to trigger a summary, and how to start a new context and continue executing the remaining tasks
• The tool is responsible for creating a container and preventing badly formed commands from affecting your system (this is optional; not all of them do it or care by default. Watch out!)

I’ve documented this in several posts on this blog:

• LLM Hello World: building your own AI chat that runs locally
• Rant — Will LLMs evolve forever? Demystifying LLMs in programming
• When Don’t LLMs Work for Programming? A more realistic use case.
• AI Agents: Locking Down Your System
• AI Agents: Comparing the main 2026 LLMs on the Zig Challenge
• AI Agents: Installing LSPs for Crush
• AI Agents: Which one is best? OpenCode, Crush, Claude Code, GPT Codex, Copilot, Cursor, Windsurf, Antigravity?
• Vibe Code: I built a little app 100% with GLM 4.7 (TV Clipboard)
• Vibe Code: Which LLM is the BEST?? Let’s talk for REAL
• Vibe Code: I built a Markdown Editor from scratch with Claude Code (FrankMD) PART 1
• Vibe Code: I built a Markdown Editor from scratch with Claude Code (FrankMD) PART 2

The End of Stack Overflow

Back in the GPT-3 and GPT-4 days, I was already writing code using LLMs and it worked well. But they still had lots of annoyances. Hallucinations were very frequent. There was a lot of “agentic loop” (when the LLM “thinks” it already fixed something, but it didn’t, and it stays in a loop, not knowing what to do). Attention to context was easily lost (it improved a lot with Flash attention). Basically, several “rougher” issues have been ironed out to the point that they don’t show up as often. It’s not “solved”; it still happens, but it keeps getting better.

The more training data and alignment improved, the more those problems disappeared. The problem is we’ve already reached the point where the training data in the world has run out. Everything that could be used has already been used. It’s not just the lack of energy and hardware. The information to train on is gone.

The solution was to massage existing data to squeeze the maximum possible out of it and add lots of synthetic data (generated by the AI itself). Again, this already hits a “diminishing returns” ceiling.

On top of that, several sites used to extract LLM training data are falling into disuse. The most notable example is the venerable Stack Overflow. Look at how its traffic has dropped.

Some clueless people might just think: “ah, it’s fine, people started asking dumb questions to LLMs instead, no more piles of people posting basic questions in forums.”

It’s true, it seems like progress. But even a “dumb question” is relevant training data. If the LLM “sees” that certain topics have higher probability, when it gets the same question, it “tends” to give the most popular answer. If this data disappears, so does the relevance of lots of new topics. Now, each LLM will depend on using the questions asked in its own chat as new training data, except OpenAI will only have questions asked to it, and it won’t know which are the most popular questions asked in Claude, which shrinks the sources of relevant information more and more.

What every platform must be doing now is collecting every question you ask it, every answer the LLM produced, every bit of feedback you or your tools give on whether it was a success or an error, and stacking it up to train the next version, GPT-6 or Sonnet-5. Let’s see how much you can evolve with just that — remembering that “volume” of information doesn’t equal “quality” for training. That’s still the Achilles heel.

The point is: at least temporarily, most of the relevant data on the Web has run out, and we’re producing less than before.

Constraint == Innovation

Yes, I also believe an entire category, which called itself “software engineer”, is going to stop existing because of AIs.

That weird “specialization” of “front-end who doesn’t touch any back-end” or “back-end who doesn’t touch any infra” will no longer exist. Front-end, in particular, is the easiest to replace, because it was a huge volume of low-value-added code with lots of duplication. It wasn’t hard to automate, but nobody wanted to: it was “cooler” to keep inventing new frameworks every week that do the same thing in slightly different ways. That circus is finally over.

I lectured for years on Constraint == Innovation and how innovation doesn’t happen when you have money to burn, which is what happened in the last Programming Bubble: why automate things, be efficient, if there’s money to spare? Just hire more and more people to do simpler and simpler grunt work.

In the Internet Bubble, there was so much money to burn that a “website cataloguer” profession existed: people who spent all day manually typing in every new site that appeared on the newly launched Web. It took years for an Altavista and then a Google to show up and figure out how to automate this. Back then, there were no “web admins” to publish new products in an e-commerce site: someone edited the HTML of Submarino.com’s homepage every day, with new deals. All high-volume, low-value-added work. We automated all of that, and now, with LLMs, we’ve just gone one step further.

Even before LLMs, it made no sense to need people exclusively to churn out disposable HTML/CSS all day. The slightly more automatic tools, like a SquareSpace.com of the world, weren’t all that good.

The thing is: something simple, like a “Web Admin” to edit content without needing to know HTML, didn’t exist in the 90s. Someone had to build the first versions of that kind of software so we could understand what works and what doesn’t. Anyone from the 90s will remember expensive commercial software like the famous Vignette Story Server. Today, any open source Wordpress does the same thing better.

Nobody remembers software and companies that no longer exist. Especially young people think the world showed up with the Web ready-made, with social networks ready-made and e-commerce platforms ready-made. The feeling must be that, in Ancient Egypt, people already shopped on Amazon, ordered delivery on iFood, and everyone chatted on WhatsApp. I made a video called The Dimension of Time, My Time Machine and My First Five Years to try to give some perspective on this.

The point is: everything LLMs know how to do either already exists or already existed.

They’re not capable of inventing whatever it is, be it the “Vignette of the 2030s” or the “Instagram of the 2030s”. And I don’t mean that in the sense of the “next content manager” or “next social network”. I mean in the sense that “social network” was a term that didn’t exist in the 2000s and “content manager” didn’t exist in the 80s, for example. What’s the new category that will show up in the 2030s?

I don’t know; if I did, I’d obviously be building it to launch and become a billionaire. Nobody knows, much less LLMs. They can derive a lot of things from training, but what’s not in the model’s probabilities won’t “spontaneously” appear. That’s not how AIs work.

We can stay forever just redoing everything that’s already been done the same way it exists today. But not much more than that. But the whole point of my talks was exactly that innovations are not born from just having tons of money and tons of brute force.

Programmers in the LLM Era

The conclusion is very simple: programmers like me will always exist. What always stops existing are professions that only have volume but low added value. That’s the concept.

As I said in my videos, during my career I’ve already survived the end of the microcomputer bubble in the early to mid 90s, the internet bubble from the mid 90s to the early 2000s, the 2001-2008 programming recession, the financial housing bubble that popped in 2008 but gave birth to the programming bubble, especially from 2014 to 2022, and now the AI bubble.

Don’t fool yourself: it’s always like this, and this is nothing more than another episode.

Who’s the programmer that survives all these bubbles? This one:

The ceiling of LLMs is already here and what they’re delivering now isn’t going to change much: the process is going to be the same. It’ll get a bit faster. It’ll generate a few less errors and small tweaks like that. But the process will keep being the same until some new architecture or some new discovery we don’t know about yet shows up.

No AI-generated code will be automatically perfect to be put into production without any kind of review or human intervention. — Anyone who thinks otherwise either has never tested an LLM in practice or has never worked on real projects.

As I said on Flow, this is the SECOND AI Bubble. The first was in the 60s because of the inventor of neural networks, Frank Rosenblatt. Just like Sam Altman or Dario Amodei, he also hyped neural networks and computers that were going to get much smarter than human beings “very soon”, and every newspaper at the time wrote about it. The promises died as promises and that generated the “AI Winter” in the 70s, where tons of investment was made, the result was not proportional, and AI research stagnated for the following decades, crawling at a turtle’s pace.

That only really started to change with the advent and popularization of the Web, the rise of social networks, the emergence of Big Data, and now, with huge volumes of data to kick off a new era of research on neural networks, with a lot more training material. And now with the existence of GPUs to accelerate processing. That’s when AlexNet showed up, from Geoffrey Hinton, Yann LeCun, and Ilya Sutskever, the “breakthrough” of convolutional neural networks (CNNs) and parallel processing via GPUs.

Without that, we wouldn’t have moved on to transformers, diffusers, and things like Nano Banana and Sora. This is a type of area where LLMs won’t contribute: cutting-edge research and new discoveries. In that field, we’ll still need computer scientists, mathematicians, theoretical physicists, etc. If you have a calling for research, it’ll still be a fertile area for many years. The bar only went up, which is a good thing.

About the Claude that managed to build a C compiler:

A C compiler is the easiest to build; it’s literally college material, because C is one of the “simplest” languages (it started as Assembly macros).

As Anthropic’s own article — which nobody read, of course — says, they used GCC for comparison.

Of course, GCC exists; it’s the main compiler used to compile the Linux kernel. If you copy GCC, you’ll arrive at another GCC, no matter what other language you write it in — that’s not the hard part, because every language can do everything another language can (they’re all Turing Complete: it can be slower, it can be less safe, it can be more work, but I can write a C compiler in Visual Basic if I want, that’s not impressive).

No LLM has replaced Linus Torvalds, nor Richard Stallman, nor any of the great programmers whose names you’ve heard. They can copy what’s already been done, and that’s it. Yes, they are “stochastic parrots”, regardless of what a Geoffrey Hinton tries to propagandize in his own favor (everyone has biases). By the way, as I’ve already said on podcasts: fuck Geoffrey Hinton. Stop falling for the Appeal to Authority Fallacy.

A Word to Companies

This should be obvious, but I’m going to put it on the record just so I can say “I TOLD YOU SO” later.

• No LLM is going to write code on its own. It needs a senior to spec it out.
• Every LLM-generated piece of code needs review. It needs a senior to review it.
• Part of the generated code needs to be rewritten. It needs a senior to know that.
• Another part of the code will have bugs the LLM will miss. It needs a senior to know that.
• Knowing what these bugs are, you can have the LLM fix them.

With that said, some things LLMs do very well:

• Exploratory analysis of legacy code
• Refactoring parts of legacy code
• Adding unit tests to parts of legacy code
• Suggesting improvements to parts of legacy code
• Finding some security or performance holes in legacy code

Notice how I say “parts” or “some”. There’s no guarantee it can do this on any legacy codebase or any part. Again, it needs a good senior evaluating each step.

Everything is done STEP BY STEP. An attempt, a check, an adjustment, repeat. It’s the famous PDCA cycle: Plan, Do, Check, Act. That’s the process that works. Every new tested adjustment becomes a “git commit” and we move on to the next step. Always one step at a time, systematically, in an organized manner. Never something generic like “Fix everything in this legacy system”.

Another thing LLMs are very good at is rewriting code from one language to another (translations in general). But I don’t recommend it, and not just because it’s an LLM:

I never recommend rewriting from scratch as a first option.

There’s no guarantee a newer language is “better” than an older one. “Better” always “depends” on your definition of “better”.

It’s trendy now to rewrite everything in Rust because supposedly it has fewer security problems. That’s incorrect. Rust is good for certain categories of security, not all of them. And there’s a whole category of functional problems that don’t show up in any compiler. Rewriting something complex, like a Linux kernel, in Rust is a gigantic illusion and a waste. If it “seems easy” to have an LLM rewrite it in Rust, it’s equally easy for it to fix a small bug in C precisely, without touching the rest that already works.

Rewriting is indeed a guarantee that several new bugs will appear and you won’t detect them right away; it’ll be a new time bomb. To fix one known bug, you ended up creating several other unknown bugs. Rewriting, by definition, always adds new bugs.

And no, when you ask the LLM: “find all the security bugs in this code”, it’s going to find some, but never all of them.

Understand Portuguese: it’ll always say something like “Here are all the bugs I found…” Even today’s LLM won’t try to say “Here are all the bugs that exist” anymore.

No AI is built to give 100% correct, unambiguous answers. On the contrary, it’s always a probabilistic machine that will give the answer based on the probabilities of the model generated by training. What’s not in that model, it doesn’t know. And even giving it context, there are no guarantees of “complete understanding”, only of “some understanding”. Always work with probabilities below 100%.

Programming languages, by their very nature, are not deterministic. There’s no way to write a mathematical equation where I can feed it the program and it guarantees the absence of bugs. This is a mathematical impossibility; it’s not “a matter of time”. Time is not relevant to that definition.

Bug detection (functional, security, performance, etc.) is always a stochastic process, a heuristic, never an algorithm. This is something every computer scientist or mathematician understands, but nobody who’s never studied can understand. For regular people, heuristic is the same as algorithm. That’s a mistake that can be fatal.

So, every LLM, by its very foundation and architecture, will always have these and other limitations built in. But that’s not a problem, that’s just the nature of the tool. Hammers aren’t meant to turn screws, and that’s not a flaw. It should be obvious, but hitting a hammer on a nail and not turning it is a natural characteristic. It’s neither an advantage nor a defect. It depends on what problem you want to solve.

Overall, LLMs will be very good at handling grunt work: adding tests, refactoring code, tweaking front-end, creating new screens from old screens, creating new reports from old reports. Creating Portuguese-to-Spanish translations of your system’s screens. For that kind of nail, LLMs are the perfect hammer.

Now, precise interpretation of laws, business rules, individual cases and exceptions to the rule, relaxing certain rules — everything that’s part of decision-making in a company. Never fully trust any LLM: you’ll need an experienced human to approve or reject. No matter how much it has memorized all the country’s laws, there’s no guarantee it knows when to use or not use them, and how that can vary in the most diverse cases, especially in the exceptions.

Never ask a hammer how you should run your company.

“How do you get seniors if there won’t be juniors anymore?”

Notice that the premise is that, at minimum, you’ll always need a senior instructing and reviewing the LLM’s work.

But if LLMs can perform all the grunt tasks that used to go to interns and juniors, how are they going to grow into seniors?

It’s the billion-dollar question and I’ll say upfront I don’t know the full answer. Nobody does.

The start is easy. It’s what I said in every video on the channel: it’s how I made my entire career: having a solid education and “learning to learn” for real. Easier said than done; that’s why I spent 5 years of videos trying to explain it in every way I could, to see if anyone would get it.

The next part is the hard one: how do you learn if LLMs already do everything?

This question starts from a false premise: LLMs don’t do everything. They do what they’re asked to do. If the request is well specified, it’ll come out like a gourmet dish from a 3-Michelin-star restaurant. If the request is lame, from someone clearly inexperienced, it’ll come out as instant noodles. It’s that simple.

The LLM’s result is directly proportional to the work of instruction, evaluation, and follow-up from the human in control.

“How is someone going to be a programmer if they don’t even know how to punch a card?” — It’s a fair question to ask someone in the 60s.

“How is someone going to be a programmer if they don’t even know how to save to a cassette tape?” — Another fair question, if it’s someone from the 80s.

“How is someone going to be a programmer if they don’t even know how to edit code in a text editor like Emacs and needs Eclipse?” — Another fair question, if it’s someone from the 90s.

“How is someone going to be a programmer if they don’t even know how to code for the Web?” — A good question for someone in the early 2000s.

“How is someone going to be a programmer if they can’t even build a mobile app?” — If it’s someone in the 2010s.

“How is someone going to be a programmer if they have LLMs?” — The question of the 2020s. Good luck.

Every generation has similar questions. None of them have an exact solution. Look at the facts: we’re still here. In 2026, I know things about programming I never dreamed I’d know when I entered college in 1995. Everything has changed. Everyone who “learned how to learn” knew how to ADAPT and use the knowledge they already had to learn new ways of working.

It’s all about adaptation: those who don’t adapt go extinct. That’s the law.

There’s not much more to say about this. But in practice:

If you’re a programmer, use LLMs. Learn their strengths and weaknesses, the different results they produce depending on your own knowledge, and never stop studying and training.

If you’re a senior/company, keep hiring juniors. Your seniors aren’t immortal. At the very least, eventually they’ll retire. More realistically: eventually they’ll change jobs. The second most important task of any senior is mentoring juniors and creating replacements. A senior incapable of creating their own replacement isn’t a senior, they’re a liability.

Mentoring is the same thing as always: training with follow-up and feedback, continuous improvement, with the difference that, besides operating system, text editor and IDEs, CI systems, etc., now there’s LLMs in the toolbox. That’s it. Don’t try to complicate what doesn’t need to be complicated and don’t suffer in advance.

Conclusion

“Ugh, but you said the AI bubble is going to burst.”

Yes, and I still say so. But you’re misunderstanding again. From 1994 to 2001 there was the Internet Bubble, and it burst!

Understand: the “Internet Bubble” burst. But the “Internet” still exists to this day. Is that clear?

Same thing: the “AI Bubble” is going to burst, many companies are going to go bankrupt, many people in the field are going to lose their jobs, etc. But AIs will keep existing. The AI bubble of the 60s burst, but AIs kept existing and even formed a new bubble now. Economic cycles have nothing to do with technological cycles.

It just means: “don’t bet all your chips on the same horse, especially if your life/career depends on it.”

LLMs will keep existing, roughly in the same form, a bit faster and more efficient, but with the same process behind them and the same way of working. Just like the Web of 2026 isn’t much different from the technology of the 90s, but is more refined and optimized.

I was never an AI “hater”; on the contrary, I’m someone who was already risking writing code with GPT-2. And it’s always improving. It’s now at a point where it’s easy to recommend even to non-programmers playing with systems that aren’t going to production and aren’t mission-critical.

Since I started with programming, at the end of the 80s, thankfully I’ve never had a single moment when I thought our field was “boring” or “monotonous”. For me, this is just another chapter in this story, and I’m expecting new chapters.

What I say that “sounds like hate” is just arguing and explaining the current limitations and the unrealistic expectations, illusions, or even blind bets I know aren’t going to pan out. I’m warning about what’s real. But I’m always saying: “there needs to be a new discovery”. With the expectation that something more is coming in the future, and not that “nothing’s going to work out”.

At the end of the day, the Java of the 90s didn’t replace the Cobol and Fortran of the world, as was intended. The Web didn’t turn into a peaceful utopia of pure knowledge as people wanted. Mobile didn’t replace other forms of computing as people wanted. VR didn’t become the new wave. None of that invalidates the qualities of Java, the Web, Mobile, or even VR.

The last Programming Bubble was a boring period for me in terms of innovation: because everything was being replaced by cheap programmers. For me, the bursting of that bubble was expected and makes me very happy. Because we finally came out of the drudgery of idiotic courses to talk about cutting-edge technology again. Programmers going back to being real programmers.

I only see good things in this.

I made a point of raising something that’s worth expanding on now. Every time you believe a CEO of an A.I. company saying that “A.I. is going to replace people” or “AGI is knocking at our door” or “AGI is going to be catastrophic”, you’re believing a drug dealer telling you cocaine is good for your health.

Let’s get to the new information. Sundar Pichai is Google’s CEO, and one of the people who said “30% of Google’s code” is already written by A.I. (without explaining, of course, “which 30%” or showing anything).

Check out the same Sundar Pichai today, 06/18/2025, on “Business Insider”

Interesting how the tone got more “down to earth” now. And he wasn’t the first. Back in February 2025, Microsoft’s CEO Satya Nadella said the following in articles like this one:

And why this shift in tone, given that at the end of 2024 everyone was pumped up shouting “AGI”, “AGI”?

There’s a clause in Microsoft’s investment deal with OpenAI (they invested USD 14 billion) stating that OpenAI would stop sharing technology with Microsoft once “AGI” was reached. Defined as a “highly autonomous system that surpasses humans in the most economically valuable work”. That’s the definition.

The problem is that this also takes Microsoft out as an investor. On top of that, Microsoft itself recently started declaring itself a competitor to OpenAI instead of a partner, positioning itself alongside a Google or Claude. Read the details in this analysis:

Get this straight: every “it’s AGI, it’s not AGI” discussion has more to do with under-the-table negotiations between the various Big Tech players involved and their investors. It has nothing to do with real technology. You’re just another audience monkey in a show you can’t even watch. So you’re cheering blindly, as usual.

Geoffrey Hinton and the Expert Problem

Yet another interview with this Geoffrey Hinton guy came out, more fatalism, more “it’s over”, and more people screaming around every corner thinking Armageddon is showing up tomorrow.

The media considers Geoffrey Hinton the “Godfather of A.I.”

Because of this, many people believe everything he says - “Of course the guy who invented A.I. knows what’s going to happen”. It turned into a cult.

I myself said on Flow that he invented Backpropagation - the backbone of A.I. training -, but that’s a simplification. Hinton himself has clarified several times that he did not invent it. The bulk of the work was published by Paul Werbos and Shun-Ichi Amari. But it’s true that Hinton was the one who popularized that work.

Hinton, as a professor, had the luck of supervising students who would go on to become brilliant. On AlexNet - I told the story on Flow - it was Ilya Sutskever who came up with the idea of using GPUs to train deep neural networks. Ilya, who would later co-found OpenAI - alongside Andrej Karpathy, another brilliant Hinton student, and who these days I despise because he’s the one who coined that “Vibe Coding” thing. Karpathy has been following in his mentor Hinton’s footsteps, spreading bullshit.

Still on the computer vision revolution, besides using GPUs, the big architectural step was Convolutional Neural Networks (CNNs), from Yann LeCun - another Hinton student.

The problem: the media gives more credit to the supervisor than to the student. It lumps everything together and it ends up as if Hinton - alone - invented BackPropagation, CNNs, and the entire AlexNet. Even the Alan Turing Award he received, again the merit belonged to the team, but the name “Hinton” is stronger, so it came out as if “he” was the one most responsible. Obviously, that way anyone looks like a demigod.

I’m not saying he’s dumb or anything like that. But he’s not all that, he’s not infallible, and he’s certainly a normal human being who makes mistakes. There’s no correlation between his previous work and speculations about the future.

On another end of the spectrum, there’s a Nobel laureate, Roger Penrose, who has been postulating since the 80s or 90s that “consciousness is NOT computable”, for example, in his book “The Emperor’s New Mind”. A Nobel laureate at the level of someone who proved Einstein’s hypotheses and worked with Hawking.

On top of that, Yann LeCun himself belongs to the camp that doesn’t believe current A.I.s will get anywhere near AGI either. As I ALWAYS repeat: some new discovery - that we don’t yet know about - needs to happen for that to occur. LeCun has his theories and is at Meta, working on a project called V-JEPA to see if he can make that discovery.

Instead of listening to Hinton, listen to a bit of LeCun:

Well then, if “authority” is your only yardstick, you should then blindly believe Penrose and LeCun as well. And now, how does that work out?

This game is more complicated than your naive blind-follower mind can see. Don’t be just an audience monkey, and understand how the pieces fit together.

“You Can’t Prove AGI Won’t Exist”

It’s true, nobody can. Nobody can prove God doesn’t exist. Nobody can prove Unicorns don’t exist. This means absolutely nothing, it’s a logical fallacy.

People outside of tech who never studied computer science can only see what the newspapers publish or the nonsense some influencer says on a podcast.

Let’s clear this up: yes, all of us - programmers trained in computer science - know that with the current LLM architecture, there’s no way to reach AGI. That is a certainty.

The problem is that you folks think that not even we know everything about A.I., that there’s some mysterious layer inside the model that works without us knowing how it works.

Or worse, you folks think that only a few names considered important, like Geoffrey Hinton or Ilya Sutskever, are the ones who can understand it. Understand an important truth: yes, to arrive at a General Theory of Relativity, it took giant geniuses like Albert Einstein, David Hilbert, Kurt Gödel, etc. One of them would get there, not every physicist could.

But, once the Theory is described and understood, it’s easily taught to first-year college students. It’s no mystical secret that needs decades of training to understand.

Same thing: perceptrons, neural networks, backpropagation, gradient descent, RNNs, CNNs, Transformers, etc. Each of these stages counted on people considered geniuses, like Geoffrey Hinton (whom many will say just took the credit, while the actual work was done by the Sutskevers or LeCuns). But once understood, all of this is undergraduate material in computer science. You don’t even need to be a PhD to understand most of it.

Trained models work because we know how to tune them to work. An important part of the training phase is feeding the neural networks millions of PRE-MADE questions and answers. That’s the INSTRUCTION phase, and EVERY LLM goes through it. It answers exactly the way each company behind it told it to answer, nothing more than that.

Ah, but there are so many parameters that you can’t possibly know everything about it. Yes we can, any good programmer can load up Tensorflow, PyTorch, load the model, and explore every dimension. We can start from the answer and look at the steps backward and see why it formed the way it did. We can re-tune, we can tweak as much as we want. I showed part of this in previous posts.

Every stage of training, inference, optimization, alignment methodologies, deployment strategies, it’s all documented, and all of us in the sciences know exactly how everything works.

That’s why it’s scary that someone like a Hinton or Sutskever keeps going around fearmongering without demonstrating anything. It shows how out of the loop they are about what’s actually happening. Yann LeCun is right: he has his hands dirty and he knows the current architecture has already hit the ceiling and there isn’t much further to go from here. That’s why he started other projects to try to figure out what a NEW architecture that leads to the next stage might look like. That’s Meta’s V-JEPA 2 project.

Just because YOU don’t know how things work, don’t think there’s room for science fiction stuff. It’s the same as watching a movie like “The Ring” where evil spirits live inside a VHS tape and come out of the TV, associating that TV-wave-spirit as if it could be real and telling me “You can’t prove it’s not possible”. It’s a level of childishness and lack of knowledge that I don’t even know how to start explaining.

Always, the BURDEN OF PROOF is on whoever is SELLING the claim. Every AI company CEO and every renowned academic - without publishing anything - is making this claim. I’m not the one who has to prove anything: they are. No one should try to prove a negative, it makes no sense.

As a bonus, going back to Yann LeCun. I didn’t follow him before, I only went to see what he says today. I found it interesting how he argues exactly the same things I’ve been saying for over a year now. I don’t want to claim for a second that I’m even a fraction of his intelligence. It’s just that, starting from the same principles, you inevitably arrive at the same conclusions. It’s pure inference from first principles. It’s not speculation. If you write “2 + 2”, both he and I will arrive at “4”. Everyone is saying “but if you have enough computing power, one day it’ll get to 10”. It won’t. Watch this other interview of his, it’s very enlightening:

What LeCun and others - like DeepMind - have already said is that LLMs don’t have the capacity to reach AGI. That’s known, and DeepMind has already proven it mathematically. This other video has more details. But in summary, an LLM is good as an “information retriever”. Beyond what I call a “glorified text completer”, which means it’s only capable of completing with information it has already seen in training (and random combinations that sometimes make it seem like it’s new information, but it isn’t). The only way for it to solve ANY problem is to have a CAUSAL MODEL of ALL PROBLEMS. In other words, it would already need to know the answer to every question beforehand. Obviously we don’t have that, therefore it’s impossible for an LLM - being a machine for retrieving information - to give us solutions that don’t exist, like “what’s the new discovery that will enable AGI?”. It’s an undecidable and non-computable problem. Mathematically proven to be unfeasible.

AGI, under the current architecture, is not going to happen. Some new discovery needs to happen. That could be 2 years from now, it could be 20 years from now. But there is no possible path from what we know today.

I finally decided to compile a list with the channels I watch the most, along with a list of the main playlists and example videos from each channel that I recommend watching.

I’ll probably keep coming back to this page to update it from time to time. If anyone remembers one I forgot, send it in the comments. There are channels like GameSack, Sega Lord X, Retro Game Corp, Wullfden, Macho Nacho Productions, and several others I didn’t list, because they lean more toward “reviews” and don’t overlap as much with “dev”. I tried to focus on things I think a “dev” should know.

List (2025-05-19)

• Usagi Electric
  • Playlists:
    • Bendix G15 Vacuum Tube
    • Data General Nova
    • DEC/PDP-11
    • 1-Bit Computer
• Tech Tangents:
  • Playlists:
    • Data Generals
  • Videos:
    • Tandy 1000 RL HD
    • CP/M on Model 100
    • KayPro IV
    • HP Series 200 - CAD Monster
    • 8088 PC Networking
    • FreeDOS on IBM 5150
• The 8-Bit Guy
  • Playlists:
    • Commander X16
    • Game Development - Making of Planet X2
    • Texas Tech History
    • Commodore History
• Adrien’s Digital Basement
  • Playlists:
    • TRS-80 Model II Repair Series
    • Amiga 4000 Repair Series
    • ZX Spectrum
    • IBM 16-bit machines
    • Apple Computers - 8-bit
    • Macintosh Machines - 68000
    • Commodore - 8 bit
    • Commodore 64 Repairs
    • Tandy 1000 Series
• clabretro
  • Playlists:
    • Home Lab
    • Sun Microsystem Stuff
  • Videos:
    • Ressurrecting an IBM PS/2 Model 50Z
    • Windows NT 4.0 on a Compaq Proliant Gen 1
    • Token Ring Networking
    • Early 2000s Linksys Wi-Fi Gear
    • Compaq Proliant Gen 1
• LowSpecGamer
  • Playlists:
    • All Lore - Chronological
    • Chip WarsNintendo Lore
    • The Yokoi Saga
  • Videos:
    • How Amateurs created the world’s most popular processor - History of ARM Part 1
    • ARM’s Secret Weapon - History of ARM Part 2
    • How IBM Invented the PC, then everyone stole it
    • The Great Calculator Wars of the 70s
• Ben Eater
  • Playlists:
    • Build a 65c02-based computer from scratch
    • Building an 8-bit breadboard computer
    • Networking Tutorial
    • Error detection
• javidx9
  • Playlists:
    • NES Emulator from Scratch
    • Code-it-Yourself - TETRIS from scratch
• Gaming Historian
  • Playlists:
    • Video Game Hardware
    • The Story of Super Mario - Documentary Series
    • History of Wolfenstein
    • History of Sonic the Hedgehog
    • History of Super Smash Bros
    • Games
    • Gaming Historian
• Modern Vintage Gamer
  • Playlists:
    • Mistakes Were Made - Game Console Security
    • The Sony Playstation
    • The Original XBox
    • Doom Switch Port
    • Retro Reviews
  • Videos:
    • N64: Decomp vs Recomp vs Ports explained
    • XenonRecomp
    • Game Genie Explained
    • Super NES Graphics
    • N64 Emulation is a Mess
    • The First Amiga Virus
    • 35 Years of Game Boy
    • Video game piracy in the 80s
    • Doom SNES Sourcecode
    • How Graphics worked on the Game Boy
    • How UltraHLE changed N64 emulation forever
    • How Diablo was completely Reverse Engineered without source code
    • Duke3D on the Amiga 600
• Strafefox
  • Videos:
    • Video Game Development Through the 80s
    • The 3D Revolution in 90s game development
    • The Making of Sonic the Hedgehog
    • The Making of Mortal Kombat
    • The Making of Castlevania Symphony of the Night
    • The Making of Donkey Kong Country & Killer Instinct
    • The Making of Aladdin
    • The Making of Streets of Rage
    • The Making of Street Fighter II
    • The Making of Super Mario World
    • The Making of Star Fox
    • How Video Games were Made - Part 3
    • How Video Games were Made - Part 2
    • MSX Konami Games
• GTV Japan
  • Playlists:
    • The GTV Binge Watch
    • GTV’s Greatest Hits
  • Videos:
    • The Story of Chrono Trigger
    • The Final 16-bit Fantasy
    • Sonic Mania Day
    • The History of Sonic - 30th Anniversary
    • The Super Story of Mario World
• Displaced Gamers
  • Playlists:
    • Game Genie: Uncorked
    • Talkin’ Code
    • Behind the Code
    • Gaming Tech Talk
• Retro Game Mechanics Explained
  • Playlists:
    • Super Mario 2
    • Super Mario Bros.
    • Super Mario World
    • Super Mario Bros 3
    • Super Mario Land 2
• The Cherno
  • Playlists:
    • Ray Tracing Series
    • OpenGL
    • Code Review
• Kosmic
  • Playlists:
    • World Record SpeedRuns
    • Super Mario Bros
• Kaze Emanuar
  • Playlists:
    • SM64: Last Impact - Developer Commentary
  • Videos:
    • Mario 64 breaks after 7 days
    • Perfecting Random Number Generation on N64
    • Planetary Gravity is Cheap
    • The Genius of N64 Cache Instruction
    • The N64 has more RAM than you think
    • Why Devs need to know about Render Matrices
    • Better engine, Better graphics
    • The Folded Polynomial
    • Fastest Sine on N64
    • Fixing the Entire SM64 source code
• James Lambert
  • Videos:
    • Can Portal64 be saved?
    • Portal 64: First Slice, is out of beta
    • How I optimized Portal to run on the N64
    • How I implemented MegaTextures on real N64 hardware
    • I rewrote Portal from scratch and solved the Portal Paradox
    • How are toon shading and dynamic shadows possible on the N64?
    • How can Nintendo 64 run Portal?
• Veritasium
  • Playlists:
    • Computing
  • Videos:
    • I build a QR code with my bare hands to see how it workds
    • Exposing the flaw in out phone system
    • The Trillion Dollar equation
    • The Most Important Algorithm of All Time
    • Math’s Fundamental Flaw
    • The Bayesian Trap
    • How Does a Transistor Work
    • How to Make a Quantum Bit
• 3Blue1Brown
  • Playlists:
    • Convolutions
    • Probabilities of Probabilities
    • Differential equations
    • Essence of Calculus
    • Essence of Linear Algebra
    • Neural Networks
  • Videos:
    • But what is a quantum computing - Grover’s Algorithm
    • Where my explanation of Grover’s algorithm failed
    • Large Language Models explained briefly

It has been very useful to me, especially for summarizing papers, reconciling research across multiple sites, summarizing topics, and things like that.

“BUT ..”

And it is a huge BUT, it has been PRETTY useless for real programming. I am not going to repeat every problem I have already run into: I detailed plenty of them in previous posts. But my conclusion is simple: it can help with code, on small, focused, isolated tasks, with a lot of prompting to help, and you - the programmer - need to be alert about what to pick and what to reject (and you will reject most of it).

Better prompts have limits. RAGs have limits. Loras have limits. Bigger context windows have limits. Using agents that hand back stacktraces and asking for deep thinking has limits. I have already hit EVERY one of these limits, and I have not found any “workaround” that can make it work 100% well 100% of the time - which is exactly what the marketing promises.

“But Microsoft, Google, Meta, NVIDIA have already stated that 30% of their code is already written by AI and next year programmers will be replaced”

That is the great half-truth, half-lie (interpret it however you want).

“What 30%??”

You, who are not a programmer, did you know that project documentation (which is extensive), language translation files (which are extensive, do you know how many languages a Microsoft or Google supports globally?), HTML pages that duplicate that extensive documentation, all of it is “considered” part of the code and sits in the same “code” repository like GitHub?

You, who are not a programmer, did you know that the VOLUME in characters/bytes of that material very often nearly matches, or can even exceed, the byte volume of the actual code itself?

That is just one small example that comes to mind. Launch pages for new products, the “hot-sites” which are DISPOSABLE sites built to be thrown away. That is also code volume. There is A LOT of “code” that is not “THE code”. Every programmer who works at a big company knows this.

Your little home project has no documentation, no automated tests, no build scripts, no deploy or packaging automation, no separate language files, no hot-site, no multi-language product site. It is just a “hello.py” and that is ALL of your code. I understand why you extrapolate that a big project is the same thing.

PART of the “30%” everyone keeps talking about is this. Sure, there is some real code in there, but nowhere near what you think.

Conflict of Interest

I am stunned. If a “drug dealer” gives you a free sample and you ask “but is it safe?”, what do you think he is going to answer?

The owner of Meta has AI products. The owner of Google, the owner of Microsoft, RENT OUT GPUs for AI. The owner of NVIDIA SELLS GPUs to AI datacenters. The owner of OpenAI, Anthropic, they all RENT that infrastructure and RESELL you TOKEN CREDITS.

What do you think their incentive is? SELLING TOKEN USAGE.

You saw what I reported in previous posts. In less than 1 week of testing I burned nearly USD 150 in credits. That would be more than 850 BRL in a week, and after running a HUNDRED attempts I got merely “reasonable” refactorings HALF of the time, and I got good passing unit tests LESS THAN HALF of the time (actually, almost NEVER). But I did spend tokens, LOTS OF TOKENS.

Features that the marketing tells you will improve things, like DEEP THINKING/REASONING, only “sometimes” give better code answers. They really are better at compiling papers or text research. But for code, in MOST attempts, I did not see that much difference. Except it took MUCH longer and burned MUCH more tokens. You know what Deep Thinking does? It adds more steps before the answer and stuffs the context with tokens. Those extra tokens: YOU PAY EXTRA FOR.

Features that the marketing also tells you will improve things, like RAG-based solutions, deep down are just more “prompt injection” - which always burns context and BURNS MORE TOKENS. It works, sure, but the incentive is to burn more tokens.

Features that the marketing is now trying to push on you, like MCP, agents, and LLM automation, combined with RAGs and all the rest. Devin, n8n, and everything else are just a more automated way to BURN MORE TOKENS.

Every incentive, from everyone, is to burn more tokens, not fewer. And in my tests, with many models (I will not say all of them), I got better code answers by TURNING OFF DEEP THINKING. You can configure that in tools like Aider or directly in the OpenAI API. Reduce thinking_tokens or set reasoning_effort to “Low” or, even better, “NONE”.

LOOT BOXES

I also explained in the article about how to build your own Ollama Modelfile that, essentially, the text generation process (swallow it, LLMs are next-word generators) has random components. Temperature, Top_P, Top_K. More: the training has non-linear components (e.g. ReLU). It is not deterministic, it is a DRAWING from a probability distribution.

That means, fundamentally, there is no way for an LLM to be 100% right 100% of the time. It is mathematically impossible. It can always be “almost right” or “looking like it is right”. But if you diligently double-check everything, all the time, you are going to start finding small mistakes. In the case of code, it is a lot more obvious. It is VERY wrong, MANY times.

And the whole process looks a lot like those “free” online games with LOOT BOXES or GACHA systems, you know? Like a Genshin Impact and friends.

What??? You are a boomer and have no idea what Loot Boxes are? …

I AM A BOOMER AND I KNOW, there is no excuse. Go get up to speed (and it is the main reason I choose not to play that kind of online game).

The economy of those games works like this: you do not have the option of buying the specific items you want. Instead you pay, say, 20 credits for the chance to take part in a drawing (which happens on pre-scheduled dates and times, not all the time). In that drawing you have a (HIGH) probability of only winning a 10-credit item OR an incredible (VERY LOW) probability of winning an exclusive 1000-credit item!!!!

Sounds like the deal of the century, right??? (LITERALLY IT IS!!!)

You always win the cheapest item in the drawing. And every once in a while it gives you a MEDIUM item so you do not give up and believe you still have a real chance. Only if you spend A LOT (and by that point you have already spent more than 1000 credits anyway), only then maybe it hands you a big item, to shoot you up with more dopamine and deepen your addiction.

That is exactly what happens with LLMs. Their answers have odds similar to a Loot Box. Sometimes it surprises you with an excellent answer, but most of the time you are stuck asking “dude, are you sure about that answer?”, or “dude, isn’t that second line wrong?”, or “dude, re-read what I asked and try again”, and your whole day goes on like that.

You are not watching it, but under the hood every time it has to correct itself it keeps burning the same credits. By the end of the day, there goes USD 50. Sounds like a little, but do it every day and see how it adds up.

Except your CONFIRMATION BIAS makes you remember well when it got things right, but keeps “forgetting” all the other times it got things wrong. And your perception is that “Yeah, it works.”

Worse, your low self-esteem and need to belong to a group, to CONFORM. Reinforced by what you read in the news every day, like:

• 30% of all Microsoft code is already written by AI
• The CEO of Anthropic says that next year programmers will be replaced by virtual workers
• The CEO of NVIDIA says he would not recommend his son to study programming anymore

And all of it RAISES THE BIAS: you think they are right, and the times you yourself saw the LLM getting it wrong “must have been a small exception, I am the one who is dumb” and you BELIEVE the LIE.

Who remembers my talks from 15 years ago where I used to show this video?

This is a well known phenomenon, today amplified even more by social networks and by the dumbness of journalists who just parrot what they hear and no longer ask critical questions like: IS THERE A CONFLICT OF INTEREST??

“Does OpenAI use your chats for training?”

Here I have to fix a lie I have been telling you all. I always kept saying no. Your conversation is not used for training, because it would pollute the training material with garbage that in the end would not improve the answers.

It is a half-truth. Indeed, I doubt it a lot and I will stake my reputation on it: no provider wants to risk someone finding a copyrighted text and getting sued. That already happens, the New York Times sued because ChatGPT managed to reproduce a text they had published. And that kind of “proves” it was part of the training material.

There are people who paste private things in there like health conditions, financial situation, and even critical data like passwords, addresses, stuff they should not share but end up publishing because they have no clue about cybersecurity. Everybody falls for a scam every day because of that. OpenAI or Meta or Alibaba are not eager to have that show up in a chat one day and turn into a viral international news story about how irresponsible they were.

BUT

And it is a HUGE “BUT”, yes they do use your chat. Everyone’s. Without copying any of your data. They just need the METADATA, the data that describes your chat.

Off the top of my head, being naive and amateurish about training, I can see at least 2 important pieces of information you hand them: the length of your chat and the sentiment of your responses in the chat.

Determining sentiment from text is a well solved problem, there are algorithms with or without neural networks that can tell if a text looks happy, sad, angry, anguished, and so on. They do not need the content of your text, they just need the SENTIMENT you had at that moment.

Add to that the LENGTH of your Chat and as I said in the previous post, the incentive is to make you burn MORE TOKENS (LONGER chats). IN THE NEXT POST I will show you how they do alignment, the model “fine-tuning”. An OpenAI uses thousands of lines of prompt/completion pairs to “force” the model to answer in a certain way. Think of an Excel full of pre-written questions and answers that, according to their metadata, we know are the most POPULAR answers.

The goal is not to make the model answer more correctly, because sometimes the right answer is very harsh or inconvenient for some people. I am almost certain that the data extracted from millions of people’s chats is just that: sentiment and length. It must help craft prompts that force the model to answer “less correctly” but “more pleasantly”, encouraging the user to KEEP talking in the chat and BURN MORE TOKENS.

It is the oldest behavior in the world. Every shopkeeper knows this. Every salesperson knows this. Everyone who works in services knows this. If you are correct and direct, you will sound arrogant and the customer will not come back. Better to sound less correct but more inviting, pleasant, helpful, and so on. And the customer comes back, because that is how the average person works.

So, yes: I do think your data serves to re-align the model after training, to make it answer more pleasantly. They do not even bother hiding it anymore. Did you not see Sam Altman himself a few days ago saying they made ChatGPT 4 answer in a friendlier way, with more personality?

That is what I think they are doing. Making the model smarter is turning out to be a challenge. Because - as I have been saying for a year now - we are hitting the top of the S-curve. To keep selling tokens, to bring you back and get you hooked on talking, it does not need to be smarter, it just needs to be more pleasant.

Conclusion

There is no LLM that will be 100% right 100% of the time, the fundamental architecture PREVENTS that from happening, no matter how many optimizations we pile on. There is now and there will always be an ENTROPY component. It is that randomness that produces text which sounds like a human talking and not a robot.

Automations that are too long and too complex built on top of this fragile foundation are a HUGE mistake. Sure, for simple, short, focused tasks, it has a higher HIT RATE. For real code? It is SUPER low.

Never let an MCP commit directly to your Git repository. Tools like Aider ship “autocommit = true” by default and that is an enormous stupidity! Do not do that.

I warned you.

But is there no way to improve LLMs at coding? Maybe. 100% never, but bumping up the rate I think we can. And to prove I am not anti-LLM or anything like that, in the next article I am going to try to teach HOW to improve an LLM for programming (with medium probability, it is no miracle!).

• Hello World for LLMs - in this article I explain how to build a simple (educational) little chat program loading an LLM (Qwen2.5) and even how to use prompts so it can call scripts/agents and run a few simple tasks like loading local files. I pushed the code to GitHub as Tiny-Qwen-CLI and I left the code “dirty” on purpose so I could test how LLMs manage (or fail) to adjust that code.
• Your Own Free Co-Pilot - here I explain more about the Aider tool, which is like a Co-Pilot or Cursor, but free and open-source. It does not require plugins or IDEs. It runs in the terminal and is easy to use. I also show how to integrate it with Ollama and spin up your own local LLMs.
• Dissecting an Ollama Modelfile - in this one I dig deeper into LLM theory and explain what Key Sampling is and how various parameters affect an LLM’s text generation, like Temperature or Top_P. This is to demystify even further that there is no “magic” in how an LLM manages to generate text.

Over the last few days I have been testing and posting on X my impressions about the most varied commercial and open source models like Claude Sonnet, Gemini 2.5, OpenAI O4, Deepseek-R1, the new Qwen3 and more. There are more posts on the blog beyond the ones I mentioned above, but these are the main ones.

The goal of this post is to demystify LLMs even more and talk more about my experience testing most of the most popular LLMs.

Demystifying LLMs - 1. Benchmarks and Rankings

Anyone who has followed my talks and videos for years is sick of hearing me talk about the book “How to Lie with Statistics”. And what I see most in the hundreds of posts about LLMs are the rankings based on benchmarks. Here is an example that went viral yesterday, at the launch of Alibaba’s new model, Qwen3:

The problem: the rankings are not wrong. What they mean is this:

“Qwen 3 beats Qwen 2.5 and also other famous ones like OpenAI o1, DeepSeek-R1, Grok 3 Beta, Gemini 2.5, etc …. IN THE BENCHMARKS THAT WERE RUN - and ONLY in the benchmarks that were run.”

That’s all. But 99% of posts publish it like this:

“Qwen 3 IS BETTER AT WRITING CODE than Qwen 2.5 and also other famous ones like OpenAI o1, DeepSeek-R1, Grok 3 Beta, Gemini 2.5, etc”*

The benchmarks are not wrong, what is wrong is whoever interpreted that to mean being better at everything. Let’s go to another analogy:

“Student So-and-So got 99% right on every college entrance mock exam”

People’s conclusion:

“Student So-and-So is 99% better than everyone at everything”

I hope that sounds obviously wrong. Being better at 1 thing makes nobody better at everything, but in AI this is how every news item about a new LLM version is published in personal posts and journalistic outlets. It is an obvious CLICKBAIT. And you fall for it.

And if you are used to hearing it this way, it makes it seem that with every new LLM version - that is “better at everything” than the previous one - we are very close, or have already reached, the point where yes, human programmers are no longer needed, nor mathematicians, nor engineers, nor doctors, since after all, the LLM is “GOOD AT EVERYTHING”.

And nothing could be further from the truth than this. These statistical ranking studies have a testing METHODOLOGY and a fixed benchmark suite. The tests are SIMPLE, think things at the level of “write a function that computes a factorial”, “write a function that sorts a list of words”, “given a list of words, find a specific one in logarithmic time”, etc. Things you see in introductory computer science courses or on Leet Code.

These tests are run MULTIPLE TIMES and the “outliers” (tests where it got way too much wrong, or tests where it got way too much right, or anything that falls out of the average) are discarded, a statistical distribution is built, and a generic overall “number” is compiled like “got 99% right” or something like that.

It got a lot wrong, but that data point is an outlier, and it was removed from the tally. It is statistically irrelevant within the methodology. But here is a fact: no LLM gets it right 100% of the time, and none ever will. I demonstrated this in my post about Modelfiles where I explain that there is a controlled random factor (temperature, top_p, top_k, min_p, key sampling). And there are also normalizations and random factors during training (softmax, relu). And there are also later optimization factors that “round” or “truncate” the probabilities like quantization (fp8, Q4, etc). In other words, there are several “micro error” factors and randomness baked into the entire process. It will never be a “correct” answer, only “possibly one of the most correct” and this “possibly” can vary A LOT.

Dissecting AI Myths - 2. Exponential Evolution

Whoever just arrived and is seeing frequent news about releases of new LLM versions like Alibaba’s Qwen3 now, Xiaomi’s new MiMo, Gemini version 2.5, ChatGPT version 4.1, etc has the impression that we are evolving by leaps and bounds.

But the truth is that yes, 2022 was a historical milestone with the original ChatGPT, mainly GPT 2. But from then until now, evolution has slowed down. Each new version is no longer visibly “twice as good” as the previous one, except in certain benchmarks, under certain specific conditions - that do not match reality. I will demonstrate this shortly.

A friend of mine reminded me about the evolution of deep learning technologies in image recognition, years earlier:

• 2012 – AlexNet: First major victory on ImageNet with 8 layers, reaching 84.7% top-5 accuracy.​

• 2014 – VGG: Networks with 16–19 layers, incremental improvements, but with a significant increase in parameters.​

• 2015 – ResNet: Introduction of residual connections, allowing networks with more than 100 layers and surpassing human performance in top-5 accuracy.​

• 2016–2017 – Inception, ResNeXt, SENet: More complex models with marginal gains.​

• Post-2018: Top-1 accuracy stabilizes around 85–88%, with marginal gains even in models like EfficientNet and NasNet.

AI has been studied since literally the beginning of modern computing in the late 1930s, by none other than Alan Turing himself or John Von Neumann. I talked about them here:

Think of a “slow beginning”: from 1930 until around 2012 when ImageNet and things like AlphaGo, GANs and such started to pick up speed. We left the bottom leg of the “S” for the middle starting in the 2010s and have been accelerating until now. I “guess” that we are either already at, or heading toward, the top of the “S”, where the curve stabilizes and slows down. That is what happened with deep learning for images:

Remember AlphaGo? I followed it live. As a hobbyist amateur in Go, I watched live the games with the South Korean masters like Lee Sedol, at the time it happened, I think 2016. You probably just watched the documentary on Netflix only now, but this has been going on for years. And now, where is AlphaGo evolving exponentially? Everyone has forgotten already, because the hot thing of the moment is LLMs, which is just one more category in the AI world.

The vast majority of optimizations have already been done or are being done. If I had to summarize just some of the most important milestones of this part of the generation, it would go roughly like this:

Every engineer and scientist knows this: when you have nothing, anything is a quantum leap. When you only have 1 real, 2 reais is already “double”. When you have 10 reais, 20 is already a lot. But when you get to 20 thousand, another 100 no longer adds as much value as when you only had 1 (there it would be 100x).

Every new drop of optimization now COSTS A LOT. Even in lossy optimization (quantization) we already went from fp32, moved to fp16, fp8, already reached 1-bit. There is nowhere further down to go after that. We are at the point where we are trading precision for performance.

Doubling parameters no longer results in doubling result quality. Need to double to get 5%? Maybe? And it is no use to keep increasing, the result starts getting worse instead of better. That is why we already jumped to things like specialist LLMs, MoE (Mixture of Experts).

Deep thinking/Chain-of-Thought/Reasoning was a big leap, but just increasing more thinking no longer delivers as much either, in fact, in many cases it makes the result worse with “over-thinking”. Thinking too much is not linear either.

Increasing context does not help improve the answers either. On the contrary, we already see that past a certain point, more context hurts the result, because the attention architecture (the great differentiator of LLMs), has limits. Yes, a Deepseek or Gemini claim to support “1 million tokens”. But I already explained in previous articles that this is Sliding Window Attention like SDPA or Flash where the attention is focused only on a PART of that large context: it cannot pay attention to everything all the time.

Every spot where you could put the obvious things, like caching, whether in training or in generation, has already been put there. We are running out of options here. And yes, new discoveries continue to happen, but as I said, none has yet managed to push past the limits we know exist.

Demystifying AI Myths - 3. Ending Programmers

What I hate most about the current hype are the false promises of “AGI”, “Vibe Coding”, “replacing employees with MCPs”. Let me state it again: it is all propaganda.

Lying propaganda and false snake oil promises (something that always existed and will always exist in history) DEVALUES the reality of the innovations we have today.

“But Anthropic’s CEO and uncle Zuck said they will replace programmers. Microsoft and Google said that 30% of their code already comes out of AI.”

As I said before about statistics. Yes: a lot of stuff IS going to be done with AI indeed. You don’t need AI to optimize work in several areas:

• a stick and a clay block are enough to replace people’s memory. Nobody remembers details, especially numerical ones, permanently. For millennia we have been evolving in helping our memory with some kind of external storage. Whether a clay block, whether paper, whether a post-it, whether a .txt file on your machine.

• the first photographic camera already removed the need to hire a painter to have a “selfie”.

• the first primitive computer already eliminated the need for an entire building of mathematicians doing and redoing calculations on paper. Even so, this is how the first rockets went to space. Have you watched the movie Hidden Figures? I recommend it.

• cars have been assembled almost entirely by robots for years now. Robotics is nothing new in industry. These days, a tablet has already replaced supermarket and McDonald’s cashiers. All of this without needing AI. IVRs and little bots have already replaced a lot of telemarketing and support.

So yes, in practice, AI will also replace an entire class of programmers: the low-value-added ones. The ones who don’t know how to do much more than copy and paste, or whose work routine is repetitive. If your job involves repetitive tasks, it is obvious that it is a matter of time until they get automated, whether by AI or mere scripts. Something we already do today.

A programmer’s job has always been to replace other people’s work. You, who work building an e-commerce system: you helped replace the work of salespeople, window dressers, store decorators, cashiers. You, who build ticketing and support systems, you already replaced human attendants. You, who build delivery systems, already replaced telephone operators. You, who build financial systems, already replaced bank clerks, the people who build bank branches, etc.

You, programmer, have always worked replacing other people’s work. It was a matter of time until programmers replaced the work of programmers. Call it poetic justice. It is just evolution. It happens. Nothing in the world is made to be static nor guaranteed.

Here is the good news: as always happens. There are still painters, even though there are photographers. There are still salespeople, even though there is e-commerce. There is still construction, even though there is not as much need for stores or even offices (with home office). There still exist and will continue to exist, doctors, lawyers, accountants, several professions. The difference is that before, an accounting firm needed a building full of people who knew how to use abacuses and write spreadsheets on paper. Today a single accountant who knows how to use Excel replaces an entire floor. In the old days, an advertising agency was an entire building, today it is one person using Canva, CapCut and Photoshop.

Programmer is the same thing. Before it was an entire building with a purple ball pit. Tomorrow it will be one, GOOD, programmer with Cursor and Aider. Who disappears in this game? Whoever did the low-value-added grunt work.

I warned this was going to happen. For 5 years, before this generation of LLMs and AI even existed. Because it is the natural course of things. The weekend online course programmer. That is the first one who is going to disappear.

Do you know calculus? Do you know Algebra? Do you know Linear Algebra? Do you know Probability Statistics? Do you know what a statistical distribution is? Do you know what vectors or tensors are? Do you know what a Hilbert space is? No? I would take precautions if I were you. If all the articles I published this month of April/2025 were very difficult, you already know what you need to study.

My Experience with LLMs

I have been using LLMs for 2 years. Every kind of research or code I do passes through some LLM in some capacity. I use it heavily, really. My ChatGPT history is gigantic.

And after doing another intensive round to make sure. Yes, o4-mini-high, Sonnet 3.7, Gemini 2.5, Qwen3, Deepseek-R1, etc are all extremely useful and none of them, absolutely none, can satisfy me.

Vibe Coding is enormous nonsense. Nobody without programming knowledge can build more than super simple software (and full of bugs) using only LLMs and prompts or MCPs. That is a fact.

“But evolution is exponential, next year it will be perfect.”

It won’t. I already argued that point above.

“But the benchmarks say they already manage to produce 99% perfect code.”

I already argued that point too, your interpretation is mistaken.

We are near or already at the beginning of the top of the “S” curve. And I see no problem at all with that. I understand how LLMs are made, I understand how they are optimized, I understand what they can do and, more importantly, I understand what they are incapable of doing.

Look at the pull requests of every attempt I made to do code refactoring and unit tests with the main LLMs on the market, open and closed. What I see:

• it needs LOTS of prompting and lots of instruction to get them to start spitting out code that works.
• they look like an intern, the famous “it works on my machine”. They come out spitting, a bunch of copy-pasted code, and don’t re-check whether it makes sense or whether it was needed. The amount of useless code they generate is scary.
• they repeat the same mistakes, even when warned not to commit them.
• even with “agents”, “MCP”, even running the code that was generated and giving the error stacktrace, they easily lose focus, lose attention and cannot fix it. Even retrying multiple times to fix the same error. Even giving hints. Even writing at length what is wrong. They quickly enter a loop. Especially if the so-called “thinking” is enabled. They think too much and don’t solve it.
• I’m tired of seeing attempts to randomly go around tweaking the code, in parts I didn’t even ask them to touch, and breaking more than fixing.
• none of them was able to generate unit tests that work on the first try. Some managed to write a few simple ones, after giving them the error and asking them to fix it. Some get stuck in a thinking loop, confused, and go around changing things without fixing. In the end they fail.
• Out of nowhere they start hallucinating. Qwen 3 itself, if I try to raise temperature just a bit, from 0.1 to 0.2, out of nowhere Chinese characters start coming out in the middle of the code, like this:

• Every now and then, more than one LLM pulled off the feat of generating a unit test that gave a recursive error. This filled the stacktrace so much that if I tried to pass it to the model (over 12 thousand tokens), it would blow the context window and from there it couldn’t pay attention to anything else:

• since they mess up a lot, I repeatedly and exhaustively give it chances to fix things. I run the code it generated, send the error stacktrace, ask it to fix. It touches another part of the code. I run again, it errors and I repeat. If you do this more than half a dozen times, the context starts filling up, sliding window makes it split attention, it “forgets” what came before, starts repeating the same error and stays there forever.

• it does not matter whether it supports 8 thousand tokens, 30 thousand tokens, 100 thousand tokens or 1 million tokens of context. That did not influence the quality of the code nor improved this routine of error repetition. It never manages to pay attention to everything.

• there is no point trying to tune key sampling. whether with temperature 0, 0.1, 0.6. It only makes it err a little later or a little earlier, but it quickly errs and quickly becomes unable to fix its own mistakes. Tools like Aider take the code it suggested and write it over the real code file. Several times, from filling the context too much, it starts to “forget” and delete chunks of code. Thank goodness GIT exists, because several times I needed to run git checkout to go back to the beginning. If you don’t check, be careful, it deletes code or overwrites it with nonsense, and this is frequent.

• deep thinking/reasoning/chain-of-thought, whatever you prefer to call it, just means it spends a lot of time thinking in excess and filling the context with filler, eating up your tokens. If it’s your commercial API, be careful: you will burn through your credits very fast and the result is not significantly better. There are isolated cases where it helps. I recommend leaving it off by default and turning it on only in a few special cases.

And look: my example project is ridiculous: it is 5 files. 4 of them have fewer than 100 lines of code, the biggest one has 400-something lines. A real, large project is MILLIONS of lines of code. It does not fit in any context window of any Gemini or Deepseek. And even if it did fit, it would only make the model more confused. The good practice in any tool is to give it the minimum number of files. And that restricts the use cases to local and isolated refactorings, never things like renaming a class or function that is used in hundreds of files. For that, keep using your IntelliJ.

No model I tested is perfect. Some models do a bit better in some cases. On the first attempt I made with Gemini 2.5, it actually managed to perform the tasks I asked. It did not produce marvelous code, but at least it didn’t break anything.

The second time, I ran git reset --hard and started over, with the same files and the same prompts. This time it was extremely disappointing. It broke the main code during the refactoring and was unable to finish a unit test that works, even though I forced it several times. I gave up out of exhaustion.

The third time, it gave a different result, improved the code a bit and managed to finish the same test. But it also required a few rounds of broken tests, giving stacktraces and asking it to fix obvious errors. And when I say “obvious” it is for it to fix a mock that it itself had placed without needing to.

And this is consistent across all the other models. If I run it only once, I get an impression. For example, that Claude is better than Qwen3. But if I run it again, the same test, now Claude disappoints me and Qwen3 jumps ahead. There is never an objectively better winner. They are all more or less at the same position and keep shuffling in the ranking depending on how many times you repeat exactly the same test, with the same code and the same prompts.

And who keeps repeating the same thing? Nobody. Everybody accepts the first answer. And the first answer can be QUITE wrong. At an obvious level of wrong. If you accept it automatically, you will insert garbage into your repo. And that is my problem with things like MCP or agents: if you leave everything on autopilot and ask things like “take all the code files in this directory and fix every bug”. It will, with full certainty, generate more bugs, delete code, vanish files and leave the final repository in a worse state than before.

Pure Vibe Coding, with zero interaction from a programmer, does not work. I tested all the main models. None was able to pass simple tests. None will be able to pass real larger tests. Not without a lot of interaction from a good programmer to reject errors and demand it try again, or manually fix what came out wrong.

And guess what: a coder who only knows how to copy and paste from stackoverflow (and now from ChatGPT), is unable to recognize many of these errors. So instead of helping, he may make things worse.

For me, who knows exactly what I want, the errors are obvious and I automatically reject them. And I reject what every LLM does more than I accept. Many times I just grab a snippet of what it suggested and discard all the rest. That is the real day-to-day. Everyone who says otherwise has not written code more complicated than a Hello World.

Why do you think every example of “wow, look at the LLM writing code on its own” is always writing a factorial function? Or a crappy web page? Because that is all it actually manages to do. No MCP example I have seen so far has impressed me. It was all smoke. And you got fooled by the propaganda.

Now you know.

How do you learn more and avoid getting fooled? Start by learning the fundamentals. 1 year ago I made several videos explaining how LLMs work. You should already have watched them:

And how to become a programmer who will not be replaced by AI? That is what I made my channel for. When everything I said becomes common knowledge for you, congratulations, you have a good chance of surviving.

People from Wisecrack always manage to put a smile on my face. They give me hope that there are still people of reason in this world. This essay is inspired by that video and the gathering of complementary thoughts.

As an engineer, I stay amazed at what we’re able to create. No one would have guessed that one of humankind’s most fabulous inventions, the internet, along with its biggest hits, could turn into a weapon of mass destruction. I mean ubiquitous mobile access and social networks that gather absurd numbers of people at the same time.

This case is far from the only one, but it works as an example. A few days ago, I was caught off guard by a seemingly small piece of news. James Gunn, the beloved director of two of the MCU’s biggest hits with his Guardians of the Galaxy, was fired over tweets he wrote ten years earlier.

I am not here to judge the merits of the tweets or if his apologies are good enough.

Actually, by just stating neutrality, I am automatically judged as being in favor. This is the problem here.

These days, we’ve seen right-wing pages and accounts deleted from Facebook. It’s part of the platform’s ongoing effort to fight “fake news,” which really is a problem of modern times. News outlets have turned into click-bait factories, exactly as Wisecrack’s video describes.

Who decides what “fake news” is? It “offends” a demographic that is loud and generates clicks. Therefore, we must ban the other side.

It reminds me of a cliche phrase from The Lord of the Rings that always resonated with me. When the fellowship is trying to go through Moria, Frodo laments to Gandalf:

‘What a pity that Bilbo did not stab that vile creature, when he had a chance!’

To which Gandalf replies:

‘Pity? It was Pity that stayed his hand. Pity, and Mercy: not to strike without need. And he has been well rewarded, Frodo. Be sure that he took so little hurt from the evil, and escaped in the end, because he began his ownership of the Ring so. With Pity.’

And then concludes:

‘Deserves it! I daresay he does. Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement.

For even the very wise cannot see all ends. I have not much hope that Gollum can be cured before he dies, but there is a chance of it. And he is bound up with the fate of the Ring. My heart tells me that he has some part to play yet, for good or ill, before the end; and when that comes, the pity of Bilbo may rule the fate of many — yours not least.’

Back to Gunn, what surprised me was not that those tweets were republished or the public outcry (and of course, no sane person supports the specific contents literally). What really surprised me was the incredible velocity with which a mega-corporation the size of Disney responded with a swift beheading, literally terminating a great career in less than a few hours.

It reminds me of equally quick public sentences without trials or due process. Again, I’m not advocating for these people, but James Damore vs. Google, Brendan Eich vs. Mozilla, and James Watson vs. Nobel.

And most of you or your friends would say, “of course they were ousted, they are bad people, we must police ourselves to remove these villains from our midst.”

Should we?

Can you give back their future if you were wrong? What makes you entitled to be a jury and judge?

Careful. When antagonized, an average, reasonable person should dialogue in private, as any civilized society learned to do. But social networks motivate people to do the worst: call out in public.

This is Mob Formation. This is plain old bullying. I suffered bullying my whole life, being a Japanese minority in a Western country, and I know exactly how much it hurts. That’s why I never bully back.

If you call out someone in public, you’re not practicing “justice.” You are a mere bully. No matter the subject at hand.

Have you ever read the image header of my Facebook and Twitter profiles? It reads:

“I Disapprove of What You Say, But I Will Defend to the Death Your Right to Say It.” - Evelyn Beatrice Hall.

And I believe that.

I shall never shame someone in public. Only cowards do that. Shaming someone in the open has the sole purpose of mobbing people, transforming the herd into a maneuvering mass to swiftly perform a public execution, and thus, make your point without having to defend it.

“But I have the right not to be offended.”

No, you don’t.

Another movie I talked about years ago, and cropped a segment to upload on my blog, is Miloš Forman’s masterpiece The People vs. Larry Flynt, produced by Oliver Stone.

It tells the story of the founder of the pornography magazine Hustler. By all means, a despicable person.

But this is precisely the point. Larry did things most of you would condemn. Not just publishing porn, but making satire out of public figures with bad-taste jokes. Jokes nonetheless. The part that really hit me was the idea that people have no right not to be offended. It’s a subjective matter, with no place in court, because we can’t legally define taste.

“Ladies and gentlemen of the jury, you have heard a lot today, and I’m not gonna go back over it, but you have to go into that room and make some decisions. But before you do, there’s something you need to know. I am not trying to suggest that you should like what Larry Flynt does. I don’t like what Larry Flynt does, but I do like that I live in a country where you and I can make that decision for ourselves. I like that I live in a country where I can pick up Hustler magazine and read it, or throw it in the garbage can if that’s where I think it belongs.”

Anyone has the right to do and say whatever he or she wants as long as it doesn’t harm the other person. This is a delicate matter because my rights should end where your rights start.

“If the First Amendment will protect a scumbag like me, it will protect all of you.” - Larry Flynt.

But because it can’t be decided in court, radical people take matters with their own hands, using the most powerful weapon ever devised: social networks. They can quickly gather a large jury and determine the public execution. It’s like handing a loaded gun to a toddler.

This is Inquisition territory. Galileo was judged and sentenced because he offended Catholic society by stating that the Earth and the planets revolve around the Sun, and not the other way around. It seems stupidly trivial today, but it was a monumental scandal back then. People would rather die than accept that offensive statement. It would be trending on the Twitter of the 1600s, and public execution would be demanded within minutes.

This “I’m offended” justification is what ultimately led to assassinations such as Luther King, JFK, Lennon, the arrest of Gandhi, and the genocide of the Jews. Intolerance.

If not being offended is the ultimate goal, intolerance is the only path, and the murder of Freedom is the worst consequence.

Every atrocity in humankind starts with mob behavior around the “I shouldn’t feel offended.”

That’s the story behind Fahrenheit 451, which Wisecrack explains well. At some point, people just started building echo chambers. Every Twitter feed and every Facebook timeline is, by definition, an echo chamber. You only get content meticulously curated by machine learning, configured to spit out posts that won’t offend you and won’t ever challenge your points of view.

You create and live in a bubble, and you immediately get outraged when your reality is challenged by any thought-provoking idea. You limit yourself to your personalized and narrow status quo.

It’s a lie when you say “I’m open-minded” but keep calling people out and whining about how offended you are. You are not open-minded. You can’t have your cake and eat it too. At least admit the truth: you’re narrow-minded and intolerant.

Contrary to what many of us believe, the internet was supposed to set us free from governments, authoritarian institutions, and big media channels that supposedly controlled the masses’ points of view.

We were supposed to have access to a broader range of knowledge, without borders, without prejudice, and that would help us advance faster into the future, into more innovation.

Innovation, by definition, is a challenge against the status quo. You can’t innovate and please everybody at the same time. That’s impossible. Otherwise, it’s just more of the same.

The invention of fire challenged nature, the invention of heliocentrism questioned God, and the design of natural selection challenged humankind’s soul.

Social networks took a free, decentralized internet and put it on a very tight leash, controlled by “Influencers.” People of pure charisma, with no righteousness and much less wisdom. Charisma is what pulls in huge numbers of followers. The network effect is vicious.

We were supposed to be all together collaborating for the betterment of humankind, regardless of race, geography, and political inclinations.

Be warned, you are all falling for the Eight stages of Genocide. Behold:

1. Classification: People are divided into “them and us”.
2. Symbolization: “When combined with hatred, symbols may be forced upon unwilling members of pariah groups…”
3. Dehumanization: “One group denies the humanity of the other group. Members of it are equated with animals, vermin, insects, or diseases.”
4. Organization: “Genocide is always organized… Special army units or militias are often trained and armed…”
5. Polarization: “Hate groups broadcast polarizing propaganda…”
6. Preparation: “Victims are identified and separated out because of their ethnic or religious identity…”
7. Extermination: “It is ’extermination’ to the killers because they do not believe their victims to be fully human”.
8. Denial: “The perpetrators… deny that they committed any crimes…”

This is the original Nazi modus operandi, and you are perpetuating those steps. I’m not a Jew, but I deeply admire and respect their history and resilience. I’ve been to the official Holocaust Institute at Yad Vashem, in Israel, and to the one in Washington D.C., because I respect the lessons they left behind. It was supposed to be our duty not to let history repeat itself.

But, such is the power of blind ideology and the leadership of charismatic celebrities.

We had charismatic leaders doing good things and bad things, charismatic nonetheless. For every Lincoln or Churchill, we had a Stalin or a Castro.

What’s more difficult is that we can only really know that something went horrendously bad in hindsight, from History. There is no such thing as a black-and-white “good” vs. “evil.” You always think that you are doing an excellent job by following charismatic people who seem to be only promoting the well-being of a minority group.

Ask yourself: are you following a selfless person, one who can treat another with more humanity than they got? Or does it sound more like selfish revenge and payback? Hate is always the stuff of evil. A righteous person does not mimic what they claim to fight against. Anyone advocating “let’s do to them what they did to us” is most probably Evil. You cite people like Gandhi. Did you learn nothing from what he taught all his life?

Every Fidel, every Mussolini, every Hitler, they all really believed that they were fighting for the well-being of their people. Every Nazi acted thinking they were doing the right thing for the future of their sons and daughters, that the sacrifices would pay off. That they were being Noble for killing people.

There has never been a better platform to mob people into irrational herds than now. There are YouTubers out there that have millions of more followers than any Hitler ever had.

And to add injury to misery, we’ve formed the online consensus that people have a magical, inherent right to “never be offended.” They shall not be offended by 200-character tweets. That’s a capital sin, and the perpetrator must die. Apologies are not enough. The thought police have reached the point where one out-of-context tweet is enough to judge and execute a person’s life, without recourse, without parole.

It’s fascinating to see how a series of technologies and innovations supposed to broaden the freedom of everybody would turn to become the most potent weapon of mass destruction ever devised. And it didn’t need a newborn Hitler.

The end of the world doesn’t have to be a catastrophic physical event like a nuclear blast. I think the destruction of the fabric of society itself is even worse. It’s not a big evil dictator that will kill Freedom, it’s the people who don’t deserve it. It’s far more nefarious and can be even more damning.

That’s the lesson: no Omar Bashir, Bashar Al-Assad, or Nicolás Maduro will, alone, be responsible for destroying society.

Every evildoer in history did what they did “in the name of the people.”

And it all starts with “I shouldn’t be offended.”

Out of curiosity, I asked over there whether anyone knew of companies or people working in this area here in Brazil, and the list I got back turned out pretty interesting. Worth sharing the recommendations with everyone.

• Auctus - alt-coin ICO
• Original My - proof-of-authenticity
• Laivon - looks like they develop mobile apps and some of them are cryptocurrency trackers
• OpenDime - another hardware stick wallet - they say there are Brazilians working there too
• HugPay - a way to send remittances to/from abroad without needing a bank account, in partnership with lottery shops (good idea)
• Blocko Ventures - I didn’t quite get whether they’re a services company or investors in blockchain solutions
• Kriptacoin - just another alt-coin (see comments)
• BlinkTrade - looks like an exchange infrastructure (I think Foxbit and others might use it, though I haven’t confirmed) and was founded by Brazilians
• Stone Pagamentos - said they’re helping companies accept payments in cryptocurrencies.

I want to hear about more Brazilian companies and professionals in the bitcoin and cryptocurrency ecosystem in general. I’m especially looking for speakers who know the subject and are doing hands-on coding, to speak (in English) at the conference I’m organizing, THE CONF. If you know of anyone, send them in the comments section.

I did think about writing about blockchain or cryptocurrencies, since I’ve been studying and investing quite a bit. But everything you need to know is already accessible in countless blogs and sites, in English and in Portuguese, and there’s no point in explaining it all again.

What interests me is knowing where people’s biggest questions are on the subject, so I can try to dig into some specific aspect. Comment about that too.

One of the most popular ones answers the question “What is the hardest thing you do as a software engineer?”. I wrote something similar in Brazilian Portuguese in the post “Estimativas são Promessas. Promessas devem ser cumpridas.”.

In a nutshell, you can never give an estimate that is “correct”. If you could, it would not be an “estimate”, it would be a “prediction”.

Let us assume we have neither precognition powers nor magic crystal balls to tell us the future.

To estimate something is to “guess” the value of something. It’s always a guess, the same thing as a valuation. And like any guess, it can never be deemed “correct”: it’s just a likely candidate among an infinite range of possible values.

There is zero connection between a guess and the outcome. Understand this simple truth: saying something can happen does not MAKE it happen.

Estimating tomorrow’s weather as rainy does not MAKE it rain. Estimating the result of the Super Bowl does not MAKE it happen. There is zero correlation between an estimate and the actual outcome.

I stated in those articles that “Estimates are Promises”. The intention was to provoke a reaction, since most people assume that estimates can never be promises, exactly because of what I just explained.

What makes a promise special is that once you promise something, you’re expected to ACT on delivering it.

No one that has no “skin in the game” should give estimates.

If you’re not an active player in the game, you shouldn’t be handing out guesses. The same way no one makes promises on someone else’s behalf.

Can you actually make credible promises and keep them? You can, but first you have to understand a few more truths about reality.

You’ve probably already seen plenty of articles explaining project management methodologies and techniques. Most of them manage to explain the Whats and the Hows, but as usual, they fail on the Whys.

Why do we need those methodologies? Why are they necessary? Why do they work? What hidden mechanisms do they set in motion?

What makes Agile techniques any different from your usual homeopathy or a budget self-help cliché?

It’s always all about Pareto

There is no such thing as a precise project scope. There is a limit to adding detail, and past it you just get diminishing returns.

The most precise level of detail a feature scope can have is the actual code of the feature. And this matters: the lines of code are NOT the outcome. What end users actually experience is the execution of that code at runtime.

The programming itself is the actual blueprint. The diagrams, the use cases, the user stories, and anything else that comes before the programming are just a draft, a mere sketch.

A naive architect or designer might think that detailed diagrams, use case documents, and fancy PowerPoint slides are worth as much as an engineering blueprint. They’re worth less: they’re the equivalent of a sketch on a napkin. Volatile and, in practice, mostly worthless.

“But isn’t the programming the same as the construction phase itself, laying bricks on top of bricks?” NO, that’s not what a programmer does. The bricklaying is the job of the language interpreter or the compiler that spits out the executable binary.

This is the metaphor that drives non-programmers crazy. In engineering, the construction itself is the most expensive and time-consuming part. In programming, the expensive part is the blueprint (writing the code), and the “construction” is trivial: just compiling, which is automatic.

In the same way, a project scope is just a set of sketches. We have to drop the notion that a “complete” scope will ever exist. There’s no way to say “100% of the scope” or “closed scope”, because a software project scope is, by definition, always incomplete.

On top of that, I’ll argue that roughly 80% of this so-called “scope”, what I prefer to call a sketch, is mostly worthless to most end-user activities: the admin section, the institutional pages nobody reads, convoluted sign-up flows, and so on.

This is why every feature list MUST be prioritized. You can usually get by with 20% of the features, which is roughly what people mean when they say “MVP” or “minimum viable product”. Release as early as you can, get user feedback, and refine the rest of the “sketch” you call a backlog.

So instead of aiming for an all-or-nothing proposition, hunting for stupidly complex equations to figure out a “precise” estimate of an incomplete sketch, assume you can actually deliver EARLY the first 20% that really matters and figure out the rest in iterations.

Oh yeah, this is what we call “Agile”, by the way.

Agile is about Risk Management

People assume Agility is about managing the project management instruments themselves: the backlog, the rituals, the metrics.

Having Agile-like instruments doesn’t make you Agile.

Being Agile is keeping Risk under control.

Instead of treating projects as an all-or-nothing endeavor, start thinking about them the way an investor thinks about a portfolio of stocks. You don’t expect the whole portfolio to turn a profit; you assume some stocks will underperform. You just don’t know which ones, so you dilute your risk.

Trying to predict the stock market is an exercise in futility.

Trying to predict the precise implementation of a project, especially the long ones, is also an exercise in futility.

So you have to deal with uncertainty the right way: by becoming Antifragile.

“Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better” - Nassim Taleb

Instead of the preposterous exercise in futility of trying to predict uncertainty and random events, you do the reasonable thing: you assume Black Swans exist and you can’t predict them. So you prepare for uncertainty the only reasonable way there is, by not trying to predict them.

Expose the small mistakes early and correct them often. Implementing everything in a black box and doing a Big Bang deployment is the easiest path to failure. Delivering often, exposing the bugs, and fixing them constantly is accepting that mistakes will happen and gaining strength along the way.

A Better Metaphor

Imagine that you, whether the non-programmer client or the programmer who has no clue how to explain the process to that client, have an iron ore furnace to manage.

The thing about those furnaces is that if you heat them too much, they can explode in your face. If you cool them down too much, the ore hardens.

Your job is to add coal to the furnace, and you decide the rate. Too fast and it gets exploding hot. Too slow and you might put out the fire and lose your furnace.

Now try to estimate a constant intake of coal to keep the furnace in good shape.

You can’t.

The easiest way out is to install a thermometer that tracks the furnace’s current temperature.

You stay safe within a certain margin of temperatures, speeding up or slowing down the coal intake by checking the thermometer all the time.

ALL THE FREAKING TIME.

This is what Agile-based “Velocity” (or any of the fancier Monte Carlo simulations) actually is: a thermometer.

If the Velocity is too high, your team is probably working extra hours or delivering lower-quality code. This will backfire: either your team burns out too fast, or the code piles up technical debt too fast and you won’t be able to pay it back. Keep that pace and Velocity drops to a halt (the furnace explodes).

If the Velocity is too low, your team is slacking off, your backlog is a useless piece of shit no one can understand even after 10-hour meetings, or you already let Velocity run too high and now you’re paying back technical debt, or your team is dead from burnout (fire extinguished).

You want to keep Velocity steady, constant. This is what being Agile is all about: keeping an eye on the thermometer and responding.

The Triforce of Projects

Welcome to the Iron Triangle of Project Management.

Repeat after me: if I want to lock down the time, the cost, and the scope, I am a moron.

Repeat again.

You should lock down time and cost. If you’ve read this far, you know you can never lock down “scope”; you can only make it fat, and not necessarily more valuable. This is why I always say the very definition of a Product Manager or Product Owner is to be the bastion of ROI (Return on Investment).

Now, why?

Because the Iron Triangle has the following corollary:

• If you want it fast and good, it can’t be cheap
• If you want it fast and cheap, it can’t be good
• If you want it good and cheap, it can’t be fast

This is a Law, you can’t fiddle with it. Pick your choice.

How do I keep Promises then?

Now, with those 3 truths in hand:

• You can’t have your lunch and eat it too (cheap, fast, and good)
• You’re managing the temperature of the furnace
• You only need 20% of the “sketch” you call “scope”

Yes, any experienced developer can give you a “ballpark” estimate. A ballpark goes like this:

• 1 month (maybe 1 month and a half, but definitely less than 2)
• 3 months (it’s more than 2 months, less than 6 months)
• 6 months (it’s more than 4 months, less than 9 months)
• it’s more than 6 months, probably less than 1 year

Don’t even try to granulate more than that. It’s useless.

Lock the time. And lock the cost (that being the number of developers times the hourly rate times the total amount of estimated hours). That’s it.

Now jot down what the client calls “scope” as user stories in a backlog and have him prioritize it.

Start the iterations. After each one, release to a staging environment. Non-programmers, beware: ALWAYS make sure whichever programmer you hire delivers testable versions of the finished stories to a publicly available URL you can actually visit and test.

If your programmer refuses to do that or gives excuses: FIRE HIM.

If your programmer or company or whatever promises you a “closed scope” price, promises to do everything, and you believe them, you’re too gullible.

Do you think it’s funny to play this stupid game of “I’ll pretend to tell you that I know the truth and you will pretend that you believe what I tell you.”

No serious professional has time for stupid games, and the only honest thing anyone can say about any software project is: “given my experience I believe the ballpark for this kind of project is within X months, given the Y and Z assumptions”.

You don’t have to believe him. You just need to start checking the thermometer. Any non-programmer can assess the quality of the delivery based on the frequent deliveries of the prioritized features.

“But what if after 2 weeks I don’t like the results?” Easy: FIRE HIM.

And sometimes “firing” isn’t even the right word. Sometimes the relationship is difficult and the best thing to do is to part ways.

You have to accept losing 2 weeks, or any short period of time, as part of Risk Management. It’s better to accept losing 2 weeks of your project budget than to blindly trust someone for 6 months and lose the entire project budget and then some.

Pareto again: Agility is about Risk Management. You accept that losing 20% of your budget is okay, and you play with that. And that’s fine, because you only really need a bit more than 20% of the sketchy scope you have.

See what I just did with the Math here?

We stop playing the pretend game and actually manage the project’s risks. You collaborate on the equivalent thermometer, which combines the prioritized backlog (the scale) and the velocity (the temperature), and you keep an eye on the partial deliveries in the staging environment.

Conclusion

So yes, Estimates should be taken as seriously as Promises. You can give reasonable Estimates as long as you can manage the Risks and the Client accepts the rules of the game: there is no “closed, complete scope”, priorities first, and testing and accepting delivered features every week.

The idea behind Promises is that you have to MANAGE in order to meet them. The best way to do that is to frequently stop, re-assess, and keep going. It feels like you’re wasting time, but you’re actually saving yourself from wasting it.

If you don’t have skin in the game, back off.

Velocity is meant to be kept steady, at a predictable rate. Use the variance as a sign of being too fast or too slow, adjust the other variable, measure again, and go. Just like a furnace thermometer.

There are several versions of “thermometers”, from Joel Spolsky’s Evidence Based Scheduling all the way to fancy Monte Carlo simulations and other stochastic processes (they are all thermometers, and NOT estimation tools).

What stops you from doing that is using the wrong metaphors and the wrong references.

Instead of hunting for equivalent metaphors in construction, factories, and other “hard”-ware assemblies, look elsewhere, where you’ll find other “soft”-ware processes.

Musicians have deadlines. Painters have deadlines. Choreographers have deadlines. Sports have deadlines. Research laboratories have deadlines. How do they meet them? By constantly checking the current state, comparing it to the goals, assessing whether what they’re doing is actually working, and changing what doesn’t.

Hollywood has deadlines. They have far worse variables to control than any software project you’ll ever run into, and they still manage to deliver. And profit.

And accept that you can’t control every variable, so stop trying. Think of it as the financial markets. One day you have Ethereum skyrocketing 4,000% and the very next day you have it falling down to ashes in a flash-crash.

Don’t aim to become resistant or resilient. Prepare to become Antifragile.

Now, you’re a small tech startup or even a small team in a big corporation. How to even start?

And the recommendation is: do the smallest thing that works first. Always. Of course, avoid “quick and dirty” as much as you can. But don’t get paranoid and over-engineer too much.

Over-engineering is as expensive as doing things “dirty”.

Add “Time” to your equation

What most people do very wrong is disregarding the variable of “Time”.

Everybody goes to tech conferences or read fancy blog posts, or watch flashy screencasts. Their wrong conclusion is: “Netflix uses it, therefore it should be good for me, because I want to become Netflix”.

The wrong assumption is that Netflix, or Google, or Facebook, or Spotify, is a static system that always functioned the way they advertise it today.

People forget that every unicorn company had a day-1. And on day-1 they did not use microservices. They did not have React.js. They did not have Go or Elixir. Some of them didn’t even have good programmers to begin with. Netflix started as a VHS renting service, remember that? Google started off in a dorm-room with off-the-shelf hardware components assembled in a Lego-based rack.

You are a fan of some celebrity. That celebrity has a Lamborghini car. So you want to be like that celebrity one day. What do you do? Do you buy the same Lamborghini he has?

If you are that stupid, the only thing you will end up with is a HUGE debt to pay.

Stop envying the rich guy’s Lamborghini.

(Technical) Debt

This is neither a new term nor a new theme. Every decision you make in programming is a compromise between what the “future-ideal” should be and what you can actually do right now. Loan to buy the equivalent Lamborghini too soon, and you will have to deal with an unpayable (Technical) Debt. You will stall, you will stop, and you will do nothing but pay that debt from now on.

You want to “code faster” therefore you skip writing automated tests, because you assume it will slow you down. And you’re right. Test-driven development doesn’t make you fast at first, and it isn’t supposed to. It protects your future self from your present self, and keeps you from piling up Technical Debt.

Again, you forget the “Time” variable.

You write and deliver fast for the 1st month. After the first version is deployed, now you will be obliged to start paying the debt. Your productivity will slow down. Regression bugs will show up. Every new feature you try to add breaks something in unexpected ways. Because you don’t have automated tests, you will keep fixing the same things many times over. Debt will catch up, and you will pay. One way or the other.

Minimal test suites are like Insurance. You don’t need it right now, on day-1. But on day-100 you will be so glad you have it.

Doing too much microservices on day-1 is debt. It feels great that you’re doing that fancy thing you read in a blog post. On day-100, with your 3 people team and a dozen microservices, from now on you will do nothing but pay the accumulated debt, with Interest. Every new microservices deployment breaks your system. And of course you didn’t add monitoring, you didn’t add integrated tests. So every time you code something, something else unexpectedly breaks.

Enjoying that early Lamborghini now?

The Mythical Man-Month

Philip Calçado writes very good posts and presentations about microservices in the right way. If you’re serious about that subject I strongly recommend that you read his posts, such as his “Prerequisites” post or his “Economics” presentation.

He correctly remembers Fred Brooks’ The Mythical Man-Month. I urge developers to read this small book. It’s uncanny how the entire industry is still repeating the very same mistakes Brooks reports in his book from projects in the 60’s!

To me, microservices is a by-product of tech companies with too many developers. Once you break through the 5-developers team a “monolithic” system with poor organization and few automated tests can become cumbersome to deal with. So the consequence is the desire to break it down. You make 2 teams and 2 microservices and coordinate. And the teams start to isolate, and play the finger-pointing game when new bugs are reported (“it’s the other team’s microservice’s fault”).

That’s Conway’s Law if you do it wrong:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Also in play is another chapter in Brooks’ book: The Second System Effect. Every developer, tech startup, has to assume that the first version of anything is not the best design. And the second system (the first big rewrite) is the most dangerous system you will write. As Brooks states, it goes like this:

An architect’s first work is apt to be spare and clean. He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used “next time.” Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a “big pile.”

Then, what happens? The CEO, the board, the investors, or whatever, start doing the wrong thing: hiring more and more people. Loan more and more. Instead of paying the debts they end up making more debt. They fell for what Brooks reported in the first chapter and what gives the name to the book: The Mythical Man-Month.

Adding manpower to a late software project makes it later.

Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.

Therefore, assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever increasing quantity of the calendar time available.

Again, it’s foregoing the sense of the “Time” variable. And confusing “debt” for “investment”.

First of all, do yourself a favor and read the goddamn book, twice.

Do Agile right! And no, it’s not Kanban!

If there is one good thing the whole Lean noise generated is the notion of “Minimum Viable Product” or MVP. People call it “prototype”. Some call it “launching Beta” or simply “version 1.0”. Doesn’t matter. It’s the realization that you don’t know much at the beginning so overengineering on the first version is a waste of time. Lean is about controlling “waste”, so we do the minimal that works, gauge results and work from there.

The cynical will say that any prototype that reaches production will never die. And they’re not wrong.

The balance is to not do the “quick and dirty” version. That’s what we have Agile techniques for. Do the minimal, organize the minimal. That’s why we have object-oriented design patterns, from GoF to DDD. You don’t need to do EVERY pattern, and that’s exactly what “overengineering” means. But you can do the minimal monolith that will allow you to evolve later.

People criticize Ruby on Rails for not being organized “enough”. Nick Sutterer, the creator of Trailblazer, has a good point.

Rails done wrong is bad. The conclusion should NOT be: “let’s do microservices” though. That jump in faith is idiotic and makes no sense for all the reasons I mentioned above.

“Let’s do proper Agile stuff and proper object-oriented stuff” should be the initial answer.

And by “Agile” forget about idiotic post-its, idiotic numerology-based estimation equations (this is a whole post in itself, because story points and velocity are useful, but adding Montecarlo and other Gaussian-based stuff are not). The only “Agile” things you should be concerned about are the Extreme Programming (XP) techniques, including Iteration-based timeboxes.

You MUST do timeboxes. Stop, re-assess, change directions, and then keep going. The model of “Pull” is only reasonable when your direction is very, very clear, written in stone and unchangeable, like in a factory production line! (Which is exactly where the concept of Pull, and Lean, was actually born!)

Iterations, like automated tests, are like Insurance. You can never avoid all waste, but you can minimize it. You can afford to throw away an Iteration-worth of work. After the iteration you measure the results, and throw it away if necessary, changing direction in the process. Throwing useless stuff away is as important as adding new stuff. If you just add, you have a hoarding disorder!

If in doubt, do XP. Yes, it feels more “difficult”, and Kanban is “simpler” to explain. Now, is that a good reason?

Forget about Raw Performance when you DON’T need it!

Another problem is choosing languages or framework because of performance.

If you’re in the web development business, this is a huge WASTE.

Understand this truth: your servers will IDLE most of the time. And if you feel like using your web app is slow, the slowness comes from the POOR programming you did, not from the language. And no good language will rescue a bad programmer. I always say that if performance was that important, we should all be doing C.

Most of what you serve in HTTP-based apps, be it user-readable content, be it API GET results, can be CACHED! If you’re not using a CDN, you’re doing it wrong.

Yeah, yeah, yeah, you think you’re building the next Spotify. You’re not, at least not 99% of you. And the 1% doing custom engineering, with custom techniques and custom stack, successfully: you’re the 1%. Actually I’d say you’re a fraction of the 1%. Do not assume that what you do is good for the rest of the population.

90% of what most small companies and solo web developers need is just a Shopify account and a vanilla Wordpress installation. And that’s it.

Are you doing infrastructure development like building custom components to Docker, Kubernetes, Terraform? Command-line tools? Daemons? Then choose GO.

Are you doing embedded libraries? Maybe the next generation OpenSSL? Drivers? Then choose RUST.

Are you doing mobile development? Then don’t have a lot of choice: do Swift for iOS, do Kotlin/Java for Android. Or do React Native for simpler apps.

Are you really doing the next Whatsapp? The next Waze? The next Snap? You have hundreds or thousands of users in need of long-lived connections over unreliable network doing broadcasts of messages? Or you’re building the next evolution of distributed NoSQL databases? Or anything that actually has the proper meaning of “Distributed” in its definition? Then choose ELIXIR.

Are you doing a CRUD based web application? Go RAILS and never look back.

Are you doing all of the above? Use all the alternatives then. And I hope you have the budget, because you need a big team.

Conclusion

The Economics only makes sense when you consider the day-1. Do not forget the “Time” variable. It makes all the difference.

You will always get Debt to pay. So be smart in which kind of debt you choose. Because you will have to pay it back eventually.

Again, read Brooks. He said it decades ago: THERE IS NO SILVER BULLET. Don’t bullshit yourself. A new language, a new framework, a new architecture. None of those will save you.

In any tech endeavor, code is not the only thing to worry about. I would go as far as to say that in a tech startup, code is only 20% of the problem. A tech startup is just a company, like any other. If you’re the founder or CEO, you have to deal with all the remaining 80%: marketing, accounting, human resources, legal, etc. It’s already difficult enough without your tech team getting you unwanted Technical Debt, the unneeded Lamborghini, that you won’t be able to pay.

You can start humble on day-1. Keep evolving, continuously. This is the core of any Agile or Lean process: KAIZEN. Choose smart debts, pay them a small bit at a time, continuously. It’s the same reasoning as getting a loan in the bank.

Netflix day-7,200 is NOT your day-1.

Facebook day-4,800 is NOT your day-1.

Google day-6,809 is NOT your day-1.

Be humble. Deliver fast. Pay your Debts. Keep evolving continuously. Stop believing in fairy tales and silver bullets.

The Blender community is so passionate and committed that they frequently produce high quality, almost Hollywood grade short movies inside Blender. The point is to stress test the tool and flush out bottlenecks and usability issues in a real world workflow.

This is primarily a post for “future me” to jump back into a single resource list. Being a 3D modeler is not my full time job, so I’ll have large gaps between Blender sessions. And I know I’ll regret it if I don’t dump my brain into a post while it’s still fresh :-)

Beginner First Steps

First things first. If you’re in this blog, you’re probably a programmer. And let me tell you that the Graphics folks see “usability” very differently from what we, programmers, usually think of. The sheer amount of customization, options, shortcuts and combinations will rival even Vim and Emacs users out there.

Oh, by the way, you’re going to need a real 3-button mouse. Touchpads are useless with Blender, and the Mac mouse is terrible. Any cheap PC mouse will do.

Out of the box, the main button is the right one, not the left one we’re used to. Change that in the user preferences to select with Left, and things start to make sense. While you’re there, enable Numpad emulation too.

By the way, it’s well worth having a keyboard with a numpad, or even a separate numpad. You can use the number row on top of your normal keyboard, but Blender was built assuming both an inverted 3-button mouse and a numpad.

If you have never studied Blender before, you will not figure things out just by randomly exploring the UI. The UI is useless until someone teaches you the ins and outs. There are hundreds of terms you just have no idea what they mean, such as Meshes, Edges, Seams, Nodes, Viewport, Subsurface, Modifiers, etc.

The main thing you MUST do before proceeding is watching this entire 9 part series from Blender Guru, called Blender Beginner Tutorial Series. Optionally you can slowly do the Intermediate Blender Tutorials later.

The Beginner Series will teach you enough that you’ll finally start feeling confident with the UI and tools. And don’t forget to print and hang this handy “cheat sheet”. You won’t believe how much easier your life becomes once you get used to the most important keyboard shortcuts.

Better Defaults

For historical reasons, some things are not how they should be. Knowledge in the 3D rendering field is evolving very fast.

The very first thing to do: change the default render engine from Blender Render to the Cycles Raytracing Engine.

Then, color grading. The default sRGB EOTF is basically wrong. You must download Sobotka’s filmic-blender configuration. If you’re on Arch Linux you can basically do:

pacaur -S filmic-blender-git

I created a script at ~/bin/filmic-blender with this:

env OCIO=/usr/share/blender/2.78/datafiles/filmic-blender/config.ocio blender

And I always start Blender from the terminal like this:

optirun ~/bin/filmic-blender

This does 2 things: first, it pre-configures OpenColorIO to use the Filmic replacement. Second, it enables the external GPU of my notebook to be available to Blender. Read my post on “Enabling Optimus NVIDIA GPU on the Dell XPS 15 with Linux, even on Battery” for more details. On Windows or Mac this is not necessary, but you’ll still need to load the filmic configuration.

Then, on the Scene tab you must reconfigure “Color Management” to be like this:

Then you need to configure Cycles. If you’re on Linux and Optimus is correctly installed as I explained before, you should have the CUDA option enabled in the User Preferences:

In the Render tab, you should have something like this:

In the Dimensions section, you’ll notice it has the Full HD (1920x1080 px) size but only 50% (so it will only render half the size). Increase it to 100%. If you want a 4K shot, increase the dimensions to 3840x2160 px. 4K makes it 4 times slower to render than 1080p, obviously.

In the Performance section you’ll see 2 input fields for “Tile size”. Blender will slice your full image into tiles, and each tile renders in parallel on an available CPU or GPU core. My notebook has 8 CPU cores, so 64 is a good size, because it will render 8 tiles of 64 pixels each in parallel.

The fewer cores you have, the larger you should make the tile sizes. For my NVIDIA GPU, I only have 2 available cores (and not a lot of video memory either!), so it’s worth bumping both fields to 512. On the GPU it only renders 2 tiles at once, and larger tiles optimize the render.

As you probably guessed, Blender Guru has a very useful “18 ways to speed up Cycles Rendering” tutorial.

These should cover the basic defaults.

You must think as a Photographer!

You will want to watch A LOT of online tutorials, because it’s really not obvious how to best use the tools. Another channel I really like is BornCG and CG Masters. Pick a few of their videos to get a more in-depth view on specific tools, modeling techniques and so on.

And really, you must practice as much as possible while studying a lot along the way. One important area is Photography. This is what you see when you select the Camera tab:

There’s a lot of customization you can do here. For example: Focal length: 35.00, which is what photographers know as a 35mm lens, a good default choice. You can also use a really wide angle such as 200mm or 300mm, and indoor shots, in small rooms, could use a 24mm or even 18mm lens. This article “Understanding Color Lenses” should give you the basics.

Then, you must understand “Depth of Field”. This can be done at this configuration before rendering, or you can simulate it after rendering (if you chose to separate the render in layers), in the Compositor.

Speaking of which, another way to control Depth of Field is reconfiguring “f-stop”, which is the measurement of exposure, or aperture. The default is “128.0”, which is “f/128”. As a reference, your iPhone 7s camera has an f/2.2 aperture. Again, let’s study more about this starting with the article “What’s the Best F-Stop?”

Taking a photo (or rendering a still, in our case) is a whole lot more than just point-and-click. You also have to worry about proper composition techniques such as the Rule of Thirds, the golden ratio, and so on. You can change that in the “Composition Guides” combo box as shown above.

You really should dive deep into the field of Photography to improve the final result of the renders. I’m an amateur and it’s really exciting to be able to apply real world techniques to 3D rendering.

Material Design and Physically-Based Render (PBR)

The golden standard in 3D modeling and rendering is certainly Disney/Pixar RenderMan. Every award winning Pixar movie was made with it.

But Blender learns fast. Every Pixar paper eventually becomes part of Blender itself. Material design, for example, has always been quite cumbersome in the tool. I did some of the tutorials myself, and creating materials with the proper real world characteristics, like proper Fresnel and the right dielectric versus metallic distinction, was a challenge.

If you subscribed to Blender Guru’s channel you should really watch the tutorials “How to Make Photorealistic PBR Materials - Part 1” and “Part 2”. And you will end up with this complicated Nodes configuration for PBR materials:

And Blender Guru just posted a new video introducing a feature for the upcoming Blender 2.79 (currently at 2.78): the implementation of the “Physically-Based Shader at Disney” paper as a proper and optimized new Blender Shader named “Principled Shader”. It’s quite literally the Ultimate Shader, because it makes creating and customizing realistic materials very easy, and compatible with Renderman and Substance.

Conclusion

I am still a beginner at Blender, there is a very long road to walk here. But it’s a very exciting environment and I am learning tons of new and useful stuff all the time. Anyone should try it!

Over time I hope I find the time to integrate the Blender workflow with other tools such as Unreal Engine or Unity3D to create interactive stuff as well.

This is by no means a complete tutorial or reference. The idea was to highlight a few things that are not immediately obvious when you start with Blender and that can give you a broader sense of what Blender can do.

If you want to go really in-depth in the customization, watch this CG Master setup video:

I’m a longtime proponent of killing gods; it’s practically a hobby. They make excellent fiction characters in bedtime stories, but obviously they don’t exist. Like the boogeyman, Santa Claus, or the Easter bunny. And no, this isn’t another anti-religion article, relax.

For the same reasons, I want to dismantle the myth of “Talent” and bring the demigods back to humanity.

Talent Is Highly Overrated

I really hate the use of the word “Talent.” It should be used as a compliment, a quality, but it’s very often used as an excuse. The Latin root of the word simply means a large amount of money. Today’s mistaken and common use devalues the real efforts of truly “talented” people.

Every time it’s used to denote something like “I’ll never be an Einstein, so I won’t even bother trying.” It’s the favorite excuse of lazy people.

Although environmental and circumstantial factors play a crucial role, there is ABSOLUTELY NOTHING in our biological material, like a gene, that would stop someone from reaching similar levels of success given the same circumstances.

Yes, some people end up, randomly, in the right place at the right time. It’s like winning the lottery. And unfortunately, it’s impossible to recreate the same network of circumstances for everyone and replicate levels of success (more on this at the end of the article).

At the same time, it doesn’t help at all to believe in the mysticism that “talent” can be defined physically, “genetically.” That’s the thinking that creates Josef Mengeles and much of racism and other forms of segregation. There is no predestination.

These days you’ve probably heard of the concept of 10,000 hours of deliberate training to become a master at something, first presented in the book “Outliers” by the prolix Malcolm Gladwell.

From Bill Gates to Oppenheimer to the Beatles, the book tries to describe how these people’s continuous, focused effort, the famous 10,000 hours (roughly 5 years full-time), helps explain their levels of success.

Geoff Colvin, in his book “Talent Is Overrated: What Really Separates World-Class Performers from Everybody Else” tries to go further than Gladwell and explains that, obviously, 10,000 hours of training alone isn’t enough if it isn’t “deliberate practice”: obsessive training focused on continuous improvement, above the mere repetition of the same routine.

In summary: do you want the chance to become a master at something? Have the obsession to train focused on improving by millimeters and milliseconds over 10,000 hours. Repeating the same routine, without focusing on improving results, doesn’t take anyone anywhere. It’s just a pastime.

This kind of deliberate training that Gladwell and Colvin detail in their books is one possible factor of success.

10% of the Brain: the Myth

This one is easy to debunk, so I’ll start here.

One of the “mystical” aspects of talent is linked to the belief in people who can activate more than 10% of the brain. The myth that we don’t use all of our “potential.”

Recent fiction films like “Lucy” by Luc Besson don’t help at all because they perpetuate this popular belief. Let’s describe it this way:

“The human brain constitutes 1/40 of the total mass of the human body, on average, but consumes 1/5 of all the calories we absorb. From an evolutionary point of view, where every organ in our body was created and naturally selected over ages for efficiency, having a brain that sucks up 20% of all our daily energy reserve for a mere 10% of efficiency simply makes no sense.”

Think about yourself right now. Are you using your muscles to sit there now? Using your hands to scroll your computer mouse (or finger on your phone screen)? Maybe eating or drinking something? Listening to some music? Breathing? Rest assured, you’re using more than 10% of your brain right now - Nature

With that factor out of the way, let’s continue.

Humanizing Einstein

In general, I don’t respect biographies. I rarely waste my time reading any. I’m not against them, but to me a biography is a story told by a writer, who took into account every technique to keep me hooked on the story he wants to tell. Every biography is limited to the writer’s interests, not the character whose name is on the book’s cover.

In fact, I consider biographies as any other kind of entertainment story. In exactly the same category as watching Captain America or Superman. Because that’s exactly how writers and directors produce “based on true facts” films.

By the way, hats off to the Coen brothers for the film “Fargo” which opens with the line “this is a true story.” And many people, even today, believe it’s real. A trolling of every film that begins with the infamous “based on a true story” while everyone thinks they’re watching facts, not entertainment.

Put in a name that existed, a situation that existed, and everyone associates the entire fiction as if it were real. I hope nobody thinks Lincoln was a vampire hunter because of the film “Abraham Lincoln: Vampire Hunter”.

But if I were to ask anyone in the world who the greatest super-genius scientist of all time was, with the theories that most revolutionized humanity, no one would hesitate to say: Albert Einstein!

But why?

Physicist Roger Schlafly, in his book “How Einstein Ruined Physics: Motion, Symmetry, and Revolution in Science” brings a ton of evidence to the contrary.

In summary, yes, Einstein really did publish many very interesting things, but the super-inflated myth created around his figure is much more harmful than beneficial for the future of physics and his successors. And it keeps fueling the myth-making market.

Einstein was a person full of flaws, like all of us. A long way from a demigod.

Mark Green, in his article “New Book Says Einstein Highly-Overrated and Ruined Physics” describes:

“What made Einstein so great? The official story goes this way: Albert Einstein, a young clerk in a Swiss patent office, single-handedly transformed physics from a static, three-dimensional science to a four-dimensional, mind-blowing, time-space universe via brilliant and solitary ’thought experiments’ involving gravity, motion, space and time. Einstein also made unprecedented inroads into understanding the nature of light and energy and was the first to comprehend the equivalence between energy and mass. Einstein’s discoveries not only transformed modern physics but the way we view the universe.”

It’s what we all know. And I strongly recommend you read Mark Green’s full article, but let’s get to the points that matter.

E=MC²: was not invented by Einstein!

The equation was published 2 years earlier by Olinto de Pretto. As Schlafly says in his book, “Einstein’s understanding of special relativity … was inferior to (Henri) Poincaré’s.” By the way, if you’ve never heard of the French physicist Poincaré, I recommend reading the book “Chaos: Making a New Science” by James Gleick.

The notion of motion and time as a 4th dimension separate from three-dimensional space.

H.G. Wells speculated about the concept in the famous fiction piece “The Time Machine” in 1894. That same year Lorentz wrote the scientific paper where he “proposes the concept of local time in a moving object.” Poincaré wrote one in 1898 and another in 1900 exploring the relationship between motion and time.

And the relationship of E=MC² to the atomic bomb?

As Schlafly describes, E=MC² isn’t even necessary for the atomic bomb. The equation gives no clue about how to split the atom, or how to create a nuclear chain reaction, or any of the other steps necessary in making the atomic bomb. Relativity isn’t even necessary to understand the energy release of a uranium or plutonium bomb, since the release can be explained by electromagnetism considerations … predictions about relativistic mass were being tested (by German physicist Walter Kaufmann) in 1901, before Einstein wrote anything about it.

And, to top it off, it was also H.G. Wells who first published about the concept of “atomic bombs”.

There were many exceptional scientists, who worked hard, before and during Einstein’s era. The French mathematician and physicist Henri Poincaré, whom British philosopher Bertrand Russell (remember Russell’s teapot?) called the greatest man France ever produced. The Dutch physicist and Nobel laureate Hendrik Lorentz. And the Scottish physicist and mathematician James Clerk Maxwell.

According to Schlafly, Maxwell was the first to coin the term “relativity” and created the first true theory of relativity of mass and energy. Electromagnetism generated the most important equations in the history of science.

Poincaré’s subsequent work on relativity provided the theorems that were “mathematically identical to Einstein’s,” and most of his work came before Einstein. Lorentz and Poincaré had all the main aspects of the theory of relativity, and published before Einstein.

Remember another detail of the “official story.” Einstein worked at a patent office. He understood the importance of “intellectual property” and had access to a lot of work before it had been patented!

And so a talent is born, irreplaceable and of inestimable value … for the mass entertainment market.

Hold onto another detail: what if Einstein hadn’t existed? Would we have been deprived of the Theory of Relativity? No, that work was practically complete before him. Others would have served the role and the media and folklore would just have a different name to call God.

Talent, is relative …

Every Genius Is Actually a Group!

An important fact is that the Theory of Relativity wasn’t the invention of one person. A lone wolf who had a “Eureka” moment. Eureka moments are very different from what you imagine.

Understand that today, the Theory of Relativity is basic material for any physics student. Nothing remarkable.

Everything we have today is the result of hundreds of individuals and groups, who throughout history have used what was known before, thrown away what no longer works, refined what works, and added new pieces for the following generations.

Nothing we do today is truly done “from scratch.” Everything we have at our disposal today makes us orders of magnitude superior, more efficient, faster, than the generation that lived 200 years ago, millennia ago.

We don’t create anything based on absolute truths written in stone millennia ago. Evolution exists because everything is volatile. Everything that has been proving itself correct given years, centuries of scrutiny, becomes the strongest tools to create new things. Engineering, Medicine, etc.

Thanks to that we went from the era of subsistence to agriculture. To the Industrial Revolution. To the Information Age. And to where we’re heading toward the Age of Artificial Intelligence, and so on.

“Talent” is a way of pointing out moments in this continuous and uninterrupted history where society as a whole has been climbing on the shoulders of giants to take longer strides into the future. But no “one” individual was necessarily pivotal. The achievements would be made by someone, but from time to time, we elect a few individuals.

It’s easier to tell the story that way. That’s all. Innovation is always a group effort.

Serendipity, Randomness, and Complex Systems

Unfortunately we, human beings, are terrible at understanding randomness. The world is highly random.

More than Einstein, the scientist who published the most significant work for humanity was Charles Darwin and his magnum opus “On the Origin of Species” where he explains how complexity emerges in a world of random events through natural selection.

I wrote in part about this in the post “Processes, Methodologies, and the Human Brain” from 2013 and in the post “We Are Mathematically Ignorant” from 2008. I’ll try not to repeat myself too much.

The very story of how we survived and evolved in this world, until reaching the humanoid form we have today, is the result of what we had to face in the natural environment, or we wouldn’t be here.

And a crucial factor in our primitive brain is finding patterns, things that repeat, and doing it fast. If, in the dead of night, in the middle of a forest, we see a small pair of shining circles moving around us and don’t immediately connect them to the eyes of a lurking wolf so we can run as soon as possible, we wouldn’t be here.

That same mechanism is what makes us see “faces in the clouds,” “images in coffee grounds,” “the face of Christ on a dirty cloth,” and so on. Identifying patterns amid randomness guaranteed our survival, but in the modern world this capability of our brain leads us to totally wrong conclusions of cause and effect.

That’s why I’ve written so much about “correlation isn’t the same as causation.”

“cum hoc ergo propter hoc”

The real world is “complex,” in the mathematical sense, which describes the exponentiality of results given a network of factors. There is no linear, step-by-step path in anyone’s biography. Not even in twins who were born and lived together, under the same set of factors, at least in theory.

“Complexity” isn’t what we’re used to imagining it is, and it’s what prevents us from predicting the weather more than the short term. It’s what leads to Lorenz’s famous butterfly, Mandelbrot’s fractals, and Chaos Theory. And more recently to Modern Network Theory (including Social Networks) published by authors like Barabási, Strogatz, or Duncan.

Anyone who knows me knows I’ve been fascinated by this subject for a decade and have already recommended all these authors’ books. It was even the topic of my first public talk in 2008, “Killing the Average”.

Beyond those 10,000 hours of obsessive deliberate training toward continuous improvement, you also need to be exposed to as many situations and people as possible to increase your chances of “serendipity” which is the combination of “being in the right place, at the right time, and with the capability to seize the opportunity.”

This is what can lead to such “success.” There’s no simple recipe, only hard work and a good dose of randomness. When all these factors align, the results can really seem “miraculous” or “superhuman.” And given enough time and the human habit of inflating stories each time they’re retold, in a few years we create new Demigods.

Killing Gods

In every mythology there are many gods. Both popular manifestations of beliefs around the “inexplicable” facts of nature (at the time) like storms, volcanoes, the seasons, the weather.

And there are also the demigods, human beings who demonstrated some kind of superiority or so-called “miraculous” feats (at the time) that no other human could ever achieve, with a good dose of creativity in telling the story.

Both cases are explainable. Unfortunately the logical explanation is much less dramatic and doesn’t make as good a story, most of the time. Curing diseases and advancing humanity isn’t as “sexy” as a so-called “miraculous” feat.

But our society’s style of mass communication (newspapers, magazines, television, films, social media) loves “sexy stories.” Negative news sells. Sexy sells. Logical facts don’t generate audiences. And, worse, they elevate false myths to the status of “truth.”

“Tell a lie enough times and it becomes truth.” - Joseph Goebbels

Just because you yourself don’t know the explanation for something, the argument that “therefore there is the possibility of something mystical” doesn’t hold. If I can’t explain that your God doesn’t exist, neither can you prove that he does. It’s a fallacious argument and has no place in a serious discussion.

And that’s being nice, because whoever tells the story is the one who carries the burden of proof. Not me, the one listening, who’s required to disprove you.

The last 200 years have been fantastic, because we’ve been killing gods at rates never before recorded in the history of humanity. It’s the reflection of how much we’ve advanced in our knowledge about nature and how it works. There aren’t many left, and we don’t need to keep creating more.

Conclusion

The circumstances of why certain individuals are elevated to the status of demigods isn’t an easy answer. Much less a linear sequence of events. Much less an entertainment film, with high doses of fiction and drama, that claims to be “based on real facts.”

We all live in a complex world, where everything is intertwined in an infinite network of possibilities. Each individual has very different circumstances.

Many have no conditions at all and even so they exceed expectations, with superior determination, with superior dedication, with superior patience, and some really reach success.

“Natural” talent?

Many have the conditions, but don’t have dedication, don’t have patience, don’t have determination. And they fail. How many stories of heirs of great fortunes destroying the legacy of their ancestors?

Lack of Talent?

Everyone has chances. But there’s no point in waiting. The best thing to do is to build the capabilities as soon as possible so that, if randomness arrives and you’re in the right place at the right time, you have the conditions to seize the opportunity and surf on it.

But there are no simple answers, no recipes, no miracles, and no talents naturally born with genius ready and, therefore, unreachable ideals.

Now, if you have the conditions and don’t get success handed to you on a plate, it isn’t the “bad luck” of having been born without the talent gene. It’s pure laziness. Simple as that.

Don’t have idols. Have references.

This is a very old tricky question used in interviews. And if you at least watched Scorsese’s magnificent “Wolf of Wall Street”, you will remember this phrase.

But how many of you actually thought it through?

Introduction

There are any number of ways you can try to sell me the pen. You can tell me about the tradition of its manufacturer brand. You can tell me about its outstanding smoothness. You can try to persuade me on the availability of different colors and sizes. You can even steer away from the pen and start bragging about how many hundreds of pens you sold already, your tour de force.

I will argue that you can do all of those, but you will probably miss the point. And you will not sell the pen most of the time.

I’ve seen this happen many times. Most tech talks I’ve seen, for example, have this format:

1. Who is the sales person speaker. Achievements. Tour de force.
2. What is being sold. The Pen.
3. How good the Pen is or how easy it is to use.
4. “Buy it.” End of story.

There is nothing wrong with those points. Sometimes the speaker goes as far as doing “flashy” and “gimmicky” things. Doing a live coding session to demonstrate how good he is (not the pen). Doing a tech demo demonstrating what the pen is. All fireworks and firecrackers. But those dissipate very quickly, and no one talks about it later. It doesn’t stick.

And you don’t sell the pen.

Sometimes, brute force alone, the strength of the brand behind you, is enough to persuade a lot of people. But not most of them. Instead of selling the pen, the speaker sells the big brand, Microsoft, Google, Facebook. It was “no one was ever fired for buying IBM” in 60’s. The famous F.U.D. (the triforce of “Fear, Uncertainty, Doubt”). Now it is “no one, usually, gets fired for choosing Facebook or Google”.

Again, you’re not selling the pen.

Elaboration

As any really good sales person will tell you, you’re missing the most important point in the sequence above, between items 3 and 4. You wasted an insurmountable amount of time describing the “What”. Most tech speakers waste a very long time explaining the “How”, with code examples, live coding, trying to convince you how easy it may be.

But they often forget to ask the question: “WHY the pen could be important for YOU”. “YOU” being the audience. You’re not connecting. You’re lacking empathy. You’re just telling them instead of persuading them. Telling and Persuading are worlds apart.

The WHY is the most important thing. And the difficult part in large audiences is that each person has a different “WHY” that needs a good answer.

Whenever I see a speaker/writer/evangelist giving too much time for immaterial stuff like “benchmarks”, “performance”, “hyper-modularized architectures”, I see them missing a large portion of the audience. They have legitimate reasons for worrying about those points, because they experienced it inside Unicorns like Netflix, Facebook or Twitter. Still, I will argue that more than 95% of the audience population will never have those problems.

Therefore, you’re trying to push a Lamborghini to people that not only can’t afford it, but even if they could, it’s not nearly at the top of their priority lists. Yes, the Lamborghini is obviously a fast and fine car. But WHY do I need it? WHY are you trying to push it to me? WHY is this pen even relevant to me?

Your priority is not my priority!

I see an interview as a talk for an audience of one. And I see a blog post as a talk for an audience I can’t see. The structure is exactly the same.

But in a one-to-one interview we all have an extra very important advantage: you get to ask direct questions! Do you realize how important that is? In a talk with an audience you have to make assumptions on what they want to hear. In an interview you get to ask directly and give straightforward answers, closing the gap of assumptions.

The irony is that most people don’t ask questions on interviews. It’s so much easier to make assumptions: “everybody wants to hear what I like to hear, because I know better”. This is the utmost lack of empathy.

Let’s say that you’re a top engineer working on performance sensitive tech in your unicorn startup. You tried everything and decided to write key real-time components near the bare bone metal, in C. And now you give talks about how important it is that everybody starts everything in C.

Now, communication is an art. Requires research, study, practice. You must understand your mother language very well, the grammar, the many subtle phrase constructions that better convey the message.

There are several “design patterns” when it comes to Argumentation Theory, many well known traps, fallacies you want to avoid. Everything to create a rock solid, simple to grasp, and difficult to refute, line of thought.

You don’t want to be easily proven wrong. So each phrase you deliver is like a chess move: you must anticipate 10 different ways it can be refuted and have responses for each.

Which is why you need to practice. Write, talk as much as possible, no matter the event. The point is the opportunity to get exposed to an audience with little risk, regardless of the size of the audience or your ego. Only tackle a large audience once you’re confident that you can defend your arguments.

Calibrate your weapons before you use them. When you start tackling the WHY, you may be provoking open wounds on the audience, so better be prepared.

But if you don’t go for the WHYs, it’s way worse: you’re FORGETTABLE. You get applause at the end, and after an hour no one remembers your name. What is the purpose of a speaker no one remembers later? Or a speaker that is funny and people remember the jokes, but can’t remember the content of the talk?

So they sympathize with the speaker, but the message is irrelevant. If you want to be an actor or comedian, that’s fine. If you want to convince people of a certain point of view though, that’s failure.

And the same goes for writing. You should’ve learned this in school. If you ever went through college and had to defend a thesis you SHOULD KNOW that the dissertation HAS to be divided in at least 3 sections: Introduction, Elaboration and Argumentation, and Conclusion. This is the WHAT, HOW, and WHY parts.

In a similar topic, if you’re into Agile techniques. Do you remember the classic User Story structure? Most people find it super annoying. Every other Kanban-like tool forgets that: they just tell you “write here what you want”. And most people just want to write the WHAT. Sometimes they write the HOW. But they feel lazy to think about the WHY.

As a X, I want Y, so that Z.

The 3rd section is elusive, but it’s the ONLY section that matters. It’s the WHY. Why do YOU want THAT particular feature? The WHY is the acceptance test. The Done Criteria. The only thing you should be looking for. We write what we THINK we want, not what actually NEEDS to be done. The User Story structure is yet another tool to bend your tiny reptile brain to use your more modern gray matter a bit more.

Conclusion

My goal is to bring attention to a point many speakers and blog writers are not doing: you’re concentrating too much on the WHAT and the HOW alone and not exploring the audience’s true concern: the WHY!

Again, whenever you see one of those cheap “my language is better than yours” theme and the argument is: “because in the benchmarks we can clearly see that it’s 50% faster” or that “we can clearly see that it uses 50% less memory” or that “we can clearly see that it can run more concurrent processes at once”. Those are ALL missing the point.

This is the HOW. It’s fine.

But 95% of your audience will rarely empathize with those points. They will agree on a conscious level, but the subconscious will tell them the truth: “you don’t have this problem.” Most of the time their servers are idling, doing nothing. How good a 50% or a 200% performance gain will help them? It will not.

It’s a major lack of empathy when a programmer, working on a big company, with many different teams colliding with big monoliths and legacy code decides that micro-services is the way to go. And now they “know” that if it’s good for them, it ought to be good for everybody, right? Therefore, anyone doing differently is a dork.

They’re not. Most of the other teams in the world may be small 3 to 5 people with projects that are yet to see the light of day. And here you have it: trying to implement your wonder over-architecture, and not getting any value back, because it delays their time to market.

Oh hey, their competition caught up, released first, they lost time to market, and all because they trusted your narrow sighted opinion, your lack of empathy with your audience. And this is the case when they listened to you. Most of them already forgot what you said, because it never touched their true concerns anyway.

And I am also to blame, I do this sometimes. In the beginning of my career I did it more, and the older I get the more careful I become on how I craft what I want to say. It’s very difficult to see beyond our small routines. It’s difficult to communicate with a larger and diverse audience. But if this is the role we chose to pursue, we must do better.

I hope this gave you some insights in how to structure your pitch in small to big talks or individual interviews or writing your blog post. It’s all the same: WHAT, HOW, and least but not last, WHY!

“But what is happiness? It’s a moment before you need more happiness.” - Don Draper

One of the great myths of modern society, perpetuated by a torturous daily repetition on social media, is the false “goal” of the “pursuit of happiness.”

On top of that comes the myth of “motivation”. TL;DR: motivation is overrated, far more than it actually deserves.

“People can have two different mindsets, she says. Those with a “fixed mindset” believe that their talents and abilities are carved in stone. Those with a “growth mindset” believe that their talents and abilities can be developed. Fixed mindsets see every encounter as a test of their worthiness. Growth mindsets see the same encounters as opportunities to improve.” - Daniel H. Pink, Drive: The Surprising Truth About What Motivates Us

Then comes the repeated mantra of “do what you love.” As I discussed back in 2014, that idea is a petty way of devaluing other people’s work.

“…, the big problem with the ’love what you do’ narrative is that it’s tied to a discourse of happiness that means ‘being on top of the rollercoaster all the time.’ As if a normal, day-to-day, routine life couldn’t be a life of satisfaction. All of that makes this scenario worrying.” - Bárbara Castro - “5 Reasons why ‘do what you love’ isn’t the solution”

In our small big world of tech, this leads many people to conclude: “I’m going to work at a startup or start my own.” The decision by itself has nothing wrong with it. The problem is reaching it driven by the previous myths, which turns into a huge source of unnecessary frustration, as I already explained in 2013.

“I won’t mince words: I am deeply skeptical of this system. I’m skeptical of this system’s slavery, self-congratulatory fetishization of “disruption,” while at the same time becoming so obviously the kind of impassive institution it wants to replace. I’m skeptical of the short-term vision of the startup community. And I’m particularly skeptical of its disregard for the lives of the people who participate in it and the lives of those who live in the world that startups seek to reshape. Let’s not even start to discuss the collusion, cartelization, and other market corruption activities that are so common in the VC world. The point being: it’s a bad game, and a fraudulent game.” - Alex Payne

Add to that the social media “consensus” that the world never stops getting worse. Everything today is supposedly worse. People, worse. Jobs, worse. The environment, destroyed. Everything offends everyone all the time, and nobody can stop judging others.

I disagree, as I’ve explained back in 2013 and repeat every year: the world is better, constantly improving, and the future will be even better. I’d like to take this chance to honor one of the men who helped change my perspective on the world, the recently deceased Dr. Hans Rosling.

The Perpetuation of the Myths

There’s no shortage of books, talks, TV shows, movies, and everything else built around the idea that everyone “must” be happy, all the time. And that if you’re not happy, you’re doing something very wrong. The relentless pursuit of “ideal happiness” has become one of the most unhealthy and cruel obsessions of the past two centuries, right next to the excessive consumption of sugar. That’s another subject, though sugar and happiness do tend to be correlated.

There are 2 concepts everyone needs to understand:

1. You probably don’t have depression. These days everyone “is depressed,” of course, because “figuring out what you love to do” takes a lot of work and brings a lot of “suffering”…

No, you’re just bored, momentarily.

Saying “I’m depressed” instead of “I’m bored” has become so common that the real clinical condition needed another name to set itself apart, “Major Depressive Disorder”. That one is a medical condition, far too serious to be treated with such carelessness.

2. Normally, even after going through events we consider very bad, or very good, we tend to return to the same level of “happiness” (or boredom) we were at before them. This is called the “Hedonic Treadmill”. It’s the main reason the “pursuit of happiness” is such a cruel journey: whoever doesn’t grasp this mechanism lives frustrated all the time.

“When enough is not enough, a Hedonist is born.” - Sukant Ratnakar

Have you ever thought “I’ll finally be happy when I get married.” Or “if I get this job, I’ll feel completely satisfied.” Or maybe you relate more to the other side of the coin: “I’ll never be happy now that I got this medical diagnosis.” Or “I can’t be happy while I have to pay these debts.” Psychological research has revealed two important findings when it comes to these beliefs: The things we think will make us happy never make us happy for as long as we imagine. At the same time, negative life events and challenges don’t have a lasting impact on our happiness either, as we believe they would. - Sonja Lyubomirsky, Ph.D - The Myths of Happiness

“We seem obsessed with motivation, rallying ourselves to something beyond the life available to us right now, and we treat this motivation as if it were a major part of the history of wisdom, which it is not.” - Jennifer Hecht - The Happiness Myth: The Historical Antidote to What Isn’t Working Today

Because of Hedonic Adaptation, any change seems to supply fresh “motivation,” the feeling that “we’ve finally locked onto the right path.” Unless it brings a new purpose, it’s just more of the same. We soon get used to the “new normal” and drift back to boredom.

Without understanding this, you stay stuck in the endless, unsatisfying cycle of “the grass is always greener on the other side.” The most twisted effect of these myths shows up when a person starts blaming others for their own problems. “I can’t because my husband…”, “I can’t because my family…”, “I can’t because my coworkers…”, “I can’t because my boss…”, “I can’t because society…”

At this point you’re lost. You want changes, but you want everything around you to change, except yourself. That’s the best definition of a coward: living on superficial justifications and excuses to avoid effort, to avoid pain, to maximize short-term pleasure. It’s the behavior of an addict, and judging everything and everyone is the drug.

Only you are destined for great things, but something or someone is holding you back. Only you are special. Only you deserve special treatment. In the old days we’d politely call this “immaturity” or “childishness.” Today I’d say most people actually fit into “Narcissistic Personality Disorder”.

“Narcissistic personality disorder is a mental disorder in which people have an inflated sense of their own importance, a deep need for admiration and a lack of empathy for others. But behind this mask of ultraconfidence lies a fragile self-esteem that’s vulnerable to the slightest criticism … (this) causes problems in many areas of life, such as relationships, work, school or financial affairs. You may be generally unhappy and disappointed when you’re not given the special favors or admiration you believe you deserve. Others may not enjoy being around you, and you may find your relationships unfulfilling.” - Mayo Clinic

In the modern world, I’d reduce this to the “Like Culture.” Sad.

Conclusion

This relentless pursuit of “ideal happiness,” this “doing only what you love,” and this certainty that “the world is going to end” make people very weak. Low self-esteem, low empathy, sky-high narcissism, and a sense of “depression” that ends up paralyzing them. In the end, the person just lashes out in every direction, for lack of “purpose” and out of constant frustration with everything and everyone.

Fortunately, I never had this problem. I’ve known people who do, and this article is dedicated to them, as a “wake up call.” That doesn’t mean I haven’t had my unhappy moments and personal crises. I’ve lost a lot, financially and personally. Businesses, friends, relationships. I’m not exaggerating. But I accept my losses and I pay for them, as part of life: No Pain, No Gain.

A “fancy” work environment was never a concern. I once worked under a tarp (!) when they were painting the small office where I was an intern, in summer, with no air conditioning, because they were going to throw a party and the work couldn’t stop. I worked inside a logistics warehouse, with a zinc roof, only a fan, and trucks coming in and out right next to me.

I slept on the office floor dozens of times. I carried furniture down the middle of the street to move offices. I pulled many unpaid all-nighters. I got chewed out for things that weren’t even my responsibility (I was an intern). I did all kinds of things unrelated to my real job, fought with managers, with “coworkers,” with vendors.

I never treated any of this as “the end of the world.” It was just the inevitable. The famous “accept it, it hurts less.”

It’s no accident that I’m an Engineer. An engineer solves problems, and our obsession is always finding a more efficient way to do the same thing. No engineer ever solved anything just by whining.

There’s also no such thing as “work that devalues me.” If I have to crop a Photoshop, I won’t treat it as useless manual labor. There’s no useless work. There’s bad will. Any ordinary, underestimated task, done with your head engaged, can lead to great accidental discoveries.

“The inventor of the Coca-Cola wasn’t a shrewd businessman, a seller of sweets, or a dreamer looking to strike it rich in the beverage business. John Pemberton just wanted to cure headaches. A pharmacist by profession, Pemberton used two main ingredients in his hopeful headache cure: coca leaves and cola nuts. When his lab assistant accidentally mixed the two with carbonated water, the world’s first Coke was the result.” - 10 Awesome Accidental Discoveries

Many of these narcissists, in their aura of self-importance, believe they need the perfect environment, that someone must give them the conditions to achieve great things (emphasis on “give” because they refuse to earn what they need on their own). That’s a load of nonsense. I’ve yet to see anyone who thinks that way achieve anything relevant to anyone.

In my experience, all the great discoveries were born in humble conditions, with people who had a real interest in what they were doing. Only that. Professionals, “craftsmen,” interested in perfecting their own knowledge, who as a consequence came out with great things that benefited more people. You don’t plan something revolutionary. It happens by accident, given the ideal conditions of temperature and pressure at that moment.

“The question isn’t who is going to let me; it’s who is going to stop me.” - by Akita.

I am not a programmer with the goal of one day surpassing Bill Gates or Linus Torvalds. You can do good work without being blindly arrogant. 30 years in, I still have fun with trivial things: a new piece of code that compiles, a configuration that optimizes my GPU, setting up a Raspberry Pi, testing a new language, tweaking my text editor, researching, learning, evolving, and so on. “Doing what you love” is doing these small things well. And “being happy” is a process of trial and error, always in motion, something you win little by little rather than reach as a final destination.

Whoever enjoys the present, what exists around them and within their reach right now, instead of wasting time on “what if in the future…”, is the one with the best chance of doing what others can’t, blinded by the journey of impossible happiness. Constraints lead to Innovation, as I’ve been repeating for years.

“carpe diem, quam minimum credula postero” - “Make the most of the (limited) time you have”.

“Whoever lives in the past is a museum. And whoever suffers over the distant future is mentally ill.” - Unknown.

Coincidentally, while I was researching for this post, the Hipsters Ponto Tech podcast came out where I made a small appearance precisely to talk about the topic of Careers in tech.

And reread my old posts mentioned above, related to these topics:

• The World Today Is Very Good! Happy 2013!
• Letter to a Young Programmer Considering a Startup
• Constraints are liberating: less is more
• Don’t Do What You (“THINK”) You Love

TL;DR: Learn how to learn, and make better use of your life.

“Creative” professionals (as if “creative” were restricted to painters and illustrators) have always been the most loyal Apple followers, for good reason. It was the cradle of essential tools like Photoshop, QuarkXPress, PostScript, PDF, and QuickTime. Apple set the standards for media creation, and anyone that was someone used those tools.

Microsoft focused on the corporate market, not on the creatives. Linux was still in its infancy, and most developers didn’t even know the difference between CMYK and RGB. They were content with a crude bitmap on the screen.

I have this theory that we took technology for granted in the late 90’s, thinking we were at the top of the world. That came from the Dotcom Bubble of the late 90’s, which burst together with 9/11. The depression made us waste the next 3 to 4 years trying to figure out what we would do next.

Apple had the luck to dodge the burst. They were already at the rock bottom since 1997. The cleaning up of their hardware lineup and the release of the iPod created their own small bubble. Steve Jobs was back and he brought good developers that made OS X a joy to use not only for creatives, but developers as well.

The Microsoft Antitrust case of 2000, the Dotcom Bubble burst in 2001, the release of the iPod in 2001, the switch from System 9 to OS X/BSD in 1999, the switch from PowerPC to Intel in 2005, the release of the ultra desirable Titanium PowerBook G4 in 2001. All of those contributed to give Apple the edge. And while everybody was down, it made them feel even larger than life.

Then in 2007/2008 they had a new push: the iPhone, the App Store, and the need to use Xcode, available only on Apple computers. Unlike being forced onto Windows because of Visual Studio, using Xcode was actually an extra reason to buy a Mac.

Linux distros were still struggling. Back then, we were stuck with the stupid X11. If a Linux-based OS was cutting edge, X11 on top of it was the worst of both worlds. Apple was smart enough not to adopt it and built Quartz from scratch, improving it with each new OS X release. It took five years to fully stabilize. Only now, in 2017, are we finally moving from X to Wayland/Weston.

Microsoft also struggled after Bill Gates handed the reins to Steve Ballmer. The road from XP to Windows 10 ran through the disasters of Vista, Windows 8, and Windows Mobile, plus the endless attempts to revive the dominant but defunct Internet Explorer, the largest Walking Dead ever in technology. The Ballmer era was a disaster.

Then the iPad got released and Steve Jobs died.

Apple is stuck in 2010.

And so are we.

Major Linux distros, Microsoft, PC hardware manufacturers, big industry turnarounds (Nokia, Blackberry, Motorola) the dawn of the GPU era, the end of Moore’s Law speed clock wars into parallel computing, the dawn of ARM. It took 10 years for all the smoke to finally settle, and it took having Apple standing still for 6 years for everybody to finally catch up.

Ballmer left the reins to Satya Nadella. Microsoft acquired Xamarin, made huge strides into open source, and even Ubuntu now runs natively on top of Windows 10.

And the Asians. Samsung, LG, Huawei, the South Koreans and the Chinese all forced the North Americans to push harder.

One last legacy of the Steve Jobs era was both killing Adobe Flash (finally!) and pushing HTML 5 technologies forward, an acceleration of 10 years in 5. It was because of the iPhone that we have the Web as it is.

Google jumped in, took over the ball that Internet Explorer left behind. WebKit became the quintessential web browser reference. Javascript became the new application platform, pushed by the many evolving Social Networks.

For better or worse, the social networks forced the new dawn of complex and interactive Web Applications. We got the example of Gmail and Web 2.0 and with the new mobile environment, everything converged into making cross-platform, ubiquitous apps.

It’s now easier than ever to switch between desktop OSes because we made it easy to jump around between the desktop and mobile devices already.

Why is it easy now to move between macOS or Windows or Linux distros? Or between macOS and iOS, or between Linux and Android? Because most of the software is in “the cloud”. Linux dominates the Cloud world that Amazon debuted in 2006 with S3 and EC2, now closely followed by Google Cloud and Microsoft Azure and other smaller competitors.

Because there is at least a good Chrome browser in every platform.

Because the apps we use are mostly web enabled: Gmail, Spotify, Slack, Hangout, Twitter, Facebook, YouTube, Netflix, Amazon. The other half are all available natively under iOS or Android: Whatsapp, Waze, Swarm, Snapchat, Instagram.

10 years ago, with the release of the iPhone, the technology industry finally started to put their shit together.

It was a cat and mouse chase until at least 5 years ago, then everybody started to settle.

After Jobs died we still had expectations that Apple would keep pushing forward, albeit at a slower pace without Jobs’ whip.

It didn’t happen. They made bad decision after bad decision and we keep feeling that we are back in the early 90’s, under Scully, Spindler or Amelio.

But now, there are fallbacks readily available: Windows 10 Anniversary Edition is finally a competent Windows, bringing back the glory days of the mid-90’s. And major Linux distros are cohesive, requiring little to no nerdy tweaking into obscure config files, pushed by Canonical, for better or worse.

And most of the apps we use in our routines are available. Heck, you can find a good web-based cross platform text editor in the form of Atom nowadays.

Apple also left the legacy of ubiquitous cross platform compilation readily available in the form of LLVM (in Portuguese). It served their own needs to have Objective-C available on PowerPC, Intel, ARM and Apple Ax processors. But LLVM is now the best backbone to enable languages such as Rust, RubyMotion, Crystal to exist and easily create fast binaries on multiple platforms.

“Apple’s current board of directors need to go”. “Tim Cook needs to step down”. I am sure many are crying out loud like this, but there is no Steve Jobs waiting to return. Apple is so big that the inertia alone will keep them going a few more years, but they are in danger of falling into irrelevance.

Other industries such as energy, health, genetics, are evolving in their own ways, but computer technology is in a dangerous standstill.

Computer Languages stopped evolving in the mid-90’s. All “new” languages are amalgams of language features that were already there since the 70’s and 80’s. CPU processors are stuck into just making transistors smaller and more energy efficient. And we are already there: $9 computers are good enough for trivial tasks such as web browsing. So much that we are putting them everywhere: even a bluetooth toothbrush that keeps track of your brushing sessions.

Did you see CES 2017 products? Pillows and beds that track your sleep and sync data to an app. Washing machines. Vacuum cleaners. Fitness devices. Health devices. Personal assistants such as Alexa. Everything takes data from you and syncs it into “the cloud”.

“The cloud” has also peaked. It’s ubiquitous, accessible, and downright cheap. Technology in general is dirt cheap nowadays.

Wearables and VR are good gimmicks, but even if they become ubiquitous, they stay just an extension of the use cases that the iPhone revolution bootstrapped.

Mobile, wearables, and social networks only made people more anxious. Giving everyone a “voice” online didn’t improve things, it just raised the overall anxiety. Opinions are in such large supply that they are worth less and less.

Every person online is now a source of terabytes of useless information to generate pseudo-statistics that are useless for the most part. Every person is now defined by a bunch of data in the cloud.

I have no idea where we go from here. As a witness of history, I have to say I miss the excitement of exploring new frontiers. We had it from the mid-90’s onward. We took a small break after the Dotcom burst, then got it back full blown in 2004. We lost it after 2010.

2010 has been the longest year I’ve ever seen. Maybe settling down is a good thing. Who knows?

I can probably pinpoint why a certain argument is wrong. But I am very incompetent the other way around: given a proper data collection, how to do proper exploratory data analysis? What are the correct methodologies for any given scenario? And of course, all the math involved.

I just posted 2 articles to shed some light on exactly that. Most developers’ “common sense” on dealing with data is primitive aggregations such as sums and averages. Start talking about “standard deviation” and you lost half of the developer population. Start talking about binomial or Poisson distributions and you lost the remaining half. Now get into linear regression and bayesian statistics, and almost everybody left the room already.

We live in the 21st century. Every 60 seconds, Facebook receives an extra 3.3 million new posts, YouTube receives 400 hours of videos, Instagram receives 55,555 uploaded photos, and WhatsApp exchanges 44.4 million messages. Even e-mail: more than 206 million of them are fired off. By the time you finish reading this post, you can multiply that amount by 5 to 10.

“We are drowning in information,

but we are starved for knowledge”

– Various authors, original probably John Naisbitt

I will spend a few weeks diving into R. Yes, many people will talk about Julia, but we can’t deny the amazing body of knowledge, the experience, and the robust and extensive set of packages available for R, including learning material. There’s a great tool called RStudio, which just saw its 1.0 release.

And within the many materials I gathered, one stood out just for its introduction, and I still have to review the book as a whole. It’s called “Learning Statistics with R”, by Daniel Navarro from the University of Adelaide, Australia. I find it interesting because it’s a psychology professor teaching proper statistics through the basics of R, which is exactly what I wanted. You can purchase a hardcopy or download the free PDF.

I like the introduction so much that I wanted to share a few paragraphs to motivate you to join me in learning better statistics. So let’s dive right into it:

The cautionary tale of Simpson’s paradox

The following is a true story. In 1973, the University of California, Berkeley got into some trouble over its admissions of students into postgraduate courses. Specifically, the thing that caused the problem was that the gender breakdown of their admissions looked like this …

         Number of applicants     Percent admitted
Males           8442                    44%
Females         4321                    35%

… and they got sued. Given that there were nearly 13,000 applicants, a difference of 9% in admission rates between males and females is just way too big to be a coincidence. Pretty compelling data, right? And if I were to say to you that these data actually reflect a weak bias in favor of females, you’d probably think that I was either crazy or sexist.

Oddly, it’s actually sort of true … after Berkeley got sued, people started looking very carefully at the admissions data (Bickel, Hammel, & O’Connell, 1975). And remarkably, when they looked at it on a department by department basis, it turned out that most of the departments actually had a slightly higher success rate for female applicants than for male applicants. The table below shows the admission figures for the six largest departments (with the names of the departments removed for privacy reasons):

                      Males                          Females
Department   Applicants   Percent admitted   Applicants   Percent admitted
A                825             62%            108              82%
B                560             63%             25              68%
C                325             37%            593              34%
D                417             33%            375              35%
E                191             28%            393              24%
F                272              6%            341               7%

Remarkably, most departments had a higher rate of admissions for females than for males! Yet the overall rate of admission across the university for females was lower than for males. How can this be? How can both of these statements be true at the same time?

Here’s what’s going on. Firstly, notice that the departments are not equal to one another in terms of their admission percentages: some departments (e.g., engineering, chemistry) tended to admit a high percentage of the qualified applicants, whereas others (e.g., English) tended to reject most of the candidates, even if they were high quality.

So, among the six departments shown above, notice that department A is the most generous, followed by B, C, D, E and F in that order. Next, notice that males and females tended to apply to different departments. If we rank the departments in terms of the total number of male applicants, we get A > B > D > C > F > E (the “easy” departments are in bold).

On the whole, males tended to apply to the departments that had high admission rates. Now compare this to how the female applicants distributed themselves. Ranking the departments in terms of the total number of female applicants produces a quite different ordering C > E > D > F > A > B.

In other words, what these data seem to be suggesting is that the female applicants tended to apply to “harder” departments.

And in fact, if we look at all Figure 1.1 we see that this trend is systematic, and quite striking. This effect is known as Simpson’s paradox. It’s not common, but it does happen in real life, and most people are very surprised by it when they first encounter it, and many people refuse to even believe that it’s real. It is very real. And while there are lots of very subtle statistical lessons buried in there, I want to use it to make a much more important point . . . doing research is hard, and there are lots of subtle, counterintuitive traps lying in wait for the unwary. That’s reason #2 why scientists love statistics, and why we teach research methods. Because science is hard, and the truth is sometimes cunningly hidden in the nooks and crannies of complicated data.

Before leaving this topic entirely, I want to point out something else really critical that is often overlooked in a research methods class. Statistics only solves part of the problem. Remember that we started all this with the concern that Berkeley’s admissions processes might be unfairly biased against female applicants. When we looked at the “aggregated” data, it did seem like the university was discriminating against women, but when we “disaggregate” and looked at the individual behavior of all the departments, it turned out that the actual departments were, if anything, slightly biased in favor of women.

The gender bias in total admissions was caused by the fact that women tended to self-select for harder departments. From a purely legal perspective, that puts the university in the clear. Postgraduate admissions are determined at the level of the individual department (and there are very good reasons to do that), and at the level of individual departments, the decisions are more or less unbiased (the weak bias in favor of females at that level is small, and not consistent across departments). Since the university can’t dictate which departments people choose to apply to, and the decision making takes place at the level of the department it can hardly be held accountable for any biases that those choices produce.

That was the basis for my somewhat glib remarks earlier, but that’s not exactly the whole story, is it? After all, if we’re interested in this from a more sociological and psychological perspective, we might want to ask why there are such strong gender differences in applications. Why do males tend to apply to engineering more often than females, and why is this reversed for the English department? And why is it the case that the departments that tend to have a female-application bias tend to have lower overall admission rates than those departments that have a male-application bias? Might this not still reflect a gender bias, even though every single department is itself unbiased? It might.

Suppose, hypothetically, that males preferred to apply to “hard sciences” and females prefer “humanities”. And suppose further that the reason why the humanities departments have low admission rates is because the government doesn’t want to fund the humanities (Ph.D. places, for instance, are often tied to government funded research projects). Does that constitute a gender bias? Or just an unenlightened view of the value of the humanities? What if someone at a high level in the government cut the humanities funds because they felt that the humanities are “useless chick stuff”. That seems pretty blatantly gender biased. None of this falls within the purview of statistics, but it matters to the research project.

If you’re interested in the overall structural effects of subtle gender biases, then you probably want to look at both the aggregated and disaggregated data. If you’re interested in the decision making process at Berkeley itself then you’re probably only interested in the disaggregated data.

In short there are a lot of critical questions that you can’t answer with statistics, but the answers to those questions will have a huge impact on how you analyze and interpret data. And this is the reason why you should always think of statistics as a tool to help you learn about your data, no more and no less. It’s a powerful tool to that end, but there’s no substitute for careful thought.

Download the Book

Did you get intrigued? So download the book and let’s study some statistics beyond the mere basics. I am not saying this is the best book, just one that seems interesting, and if you happen to know a good book teaching statistics for novices through the use of R without any prior knowledge, let me know in the comments section below.