DEV Community: Paulo Henrique

Generative AI is a gacha game with no pity system

Paulo Henrique — Tue, 21 Jul 2026 19:35:32 +0000

Last week, I posted about a personal situation where I struggled with Generative AI and how I was able to fix the problem by asking if a real person could help me. I believe that some people got the point of the story, but some comments started piling up, and I thought that a full post following up on that discussion would be better than a long discussion thread.

Generative AI Is Basically a Gacha Game

The strongest counterargument deserves to be stated properly: Inference is cheap. A hundred image generations cost less than one hour of a senior designer, and there's no dispute on that.

The problem starts when you notice that the winning result might show up at attempt 2 or only at attempt 1,000, or never show at all. In a way, content generation is like a gacha game. Every prompt is another pull. Better prompts don't necessarily guarantee the rare drop, they simply improve the odds that you'll get it before your token budget runs out. Even if you structure the first prompt like a real design brief instead of drip-feeding small corrections, a good model will often still require several tries.

And you could argue "ok, but it's still cheaper than a designer", and again, sometimes that math is correct. I use GenAI myself for blog illustrations and placeholder art, where honestly even an uncommon pull in the gacha machine is a good result.

But, hypothetically, what if you really need that SSR pull? That extremely rare card/item?

Retries are only cheap on the invoice

Every attempt on GenAI needs a human on the other side to open the output, compare it against the mental picture they're aiming for, figure out what went wrong, and translate that judgment into new prompt language. The single generation costs cents. But the judgment can cost hours, and that part can't be parallelized.

Run 40 attempts, and you spent much more than 40 generations: you spent an afternoon doing quality control for a machine that doesn't understand or even remember why attempt 12 failed. So not only did you spend time reviewing the art, but you also piled up frustration and stress.

All these problems matter more than the price per pull. And here's one aspect where I feel that GenAI can be worse than a gacha game: Most gachas have some sort of "pity system", where you have a better chance to get a high-tier item after XX interactions. But GenAI is a gacha with no pity system.

The model carries no optical judgment between attempts. Each generation samples from the same distribution, nudged by whatever words changed since the last round. When the target is "clean sans-serif wordmark", that distribution is dense with acceptable answers, and you win fast. When the target is "this exact typeface, with one letter working as two symbols at once", you're fishing in a region the training data barely covers. Attempt 400 draws from the same pool as attempt 4, and a perfectly structured brief hits the same wall, because the brief competes with the prior instead of overriding it.

So, it's a gacha. But the chances won't improve as you keep playing.

A PNG is a picture of a logo

But OK, let's suppose that the model finally nailed it after attempt 400. Congratulations, now what you have is a raster image: pixels, at one size, on one background.

A real working logo is a vector system. Editable anchor points, light and dark variants, a monogram for tight spaces, letterforms that survive both a 16-pixel favicon and a four-meter banner.

Moving from the perfect PNG to that system means manual vectorization and redrawing, which lands you right back in Figma or Inkscape, doing the design work the generation was supposed to replace.

"But OK, I could just ask the model to output the vector directly, right?" Right. That was my Claude experiment in the original post, and there's actual research explaining why it failed.

Why the models fail where even a junior designer wouldn't

Pixel generators learn statistical visual patterns from billions of image-text pairs and reproduce what text usually looks like in them. Typography demands stroke-level precision, and the gap between those two things is so well documented that it spawned a research subfield: TextDiffuser, GlyphControl-style conditioning, Glyph-ByT5, and character-aware text encoders all exist specifically because base models garble letters. A letterform that must read as an h and as a / simultaneously is a constraint-satisfaction problem wearing an image-generation costume. Nothing in pixel prediction enforces "hold both meanings", so the model produces something plausible. Plausible is precisely the wrong target when the brief demands intended.

Now, the vector route fails differently. An LLM writing SVG reads <path d="M 10 10 L 40 60"> as a flat stream of tokens. Research on vector generation (SVGFusion) spells out the consequences: the model has no built-in sense that those two 10s form a coordinate pair inside a moveto command, and it can't see how a new shape lands on the canvas while writing it. Small geometric errors accumulate with no way back. SVGenius, a benchmark that ran more than 20 mainstream models through SVG understanding and generation tasks, found systematic performance degradation as complexity increases, in both proprietary and open models.

Meanwhile, a junior designer with a year of Illustrator experience solves the same problem by... looking at it.

Draw, look, adjust, look again.

The feedback loop the models lack is the baseline of the craft, and every "paste the screenshot back and ask for fixes" workaround is a lossy imitation of it, filtered through a vision encoder built to answer semantic questions rather than optical ones.

So when does each one win

Short answer: constraint density.

Generation wins when constraints are loose, and outputs are disposable. Hero images, textures, placeholder illustrations, twenty rough layout directions to react to. Any good result is acceptable, verification takes two seconds per attempt, and nobody will ever need to edit the curves. You just need to pull something from the gacha machine, and anything is acceptable.

A person wins when the artifact carries identity, when the constraints are dense and non-negotiable, and when the deliverable must stay editable by other humans later. A logo checks every box. So does a brand system, and so does any piece where "close enough" means "wrong".

There's a third factor that goes underdiscussed: a designer looks at a reference and knows which constraints can flex and which can't, usually even before the client finishes explaining. That judgment is the actual service.

Now, an argument made in the comments that I feel needs to be addressed: Would the story change if the designer had charged full market rate? Honestly, it depends. It depends on the price being fair and matching the quality and speed I need. On how much they could improve my original idea. Maybe they notice that there's a better font or suggest a better color pairing. Maybe another designer friend of mine could have messaged me a few hours later, saying, "hey, do you remember that time you convinced everyone in the office that the building was haunted, and that the only way to ward off the spirits was to draw a circle of salt around the office, and they did it? This gave me an idea, maybe we could make a logo where phalkmin is read as phAIlkmin, with the AI kinda transparent, like a ghost?" and I would probably say "cool, let's try".

No AI can do that. No AI will say "hey, cool prompt, bro, but remember that time that you asked at 2 am if tomato could be added to a fruit salad?" and then proceed to suggest a new logo idea. There's a price on human creativity.

A human designer with a fair rate buys convergence: a professional who gets closer with every round, remembers exactly why the last round missed, asks the questions you forgot to answer, and hands over source files at the end.

Tokens buy attempts. Designers sell convergence. Those are different products, and you will always be limited by the number of tokens you can use and the time you have to finally pull the perfect drop.

The models will improve, and I believe that some opinions in this post will age badly. The final verification bill, though, stays on the human side of the table for as long as the human is the one who knows what "right" looks like.

Where do you draw that line on your own projects?

I burned through thousands of AI tokens. Then a friend did it for free

Paulo Henrique — Thu, 16 Jul 2026 22:52:32 +0000

(yep, kinda clickbait, just for the funsies 😊)

At the beginning of the year, I relaunched my portfolio site using Codex and Gemini CLI as my main development tools. It wasn't entirely vibe-coded: I spent several days updating content and researching best practices, plus a good pile of tokens on brainstorming sessions.

For personal projects, I'm trying to keep a philosophy of "done is better than perfect". So even knowing the layout wasn't what I wanted, I uploaded the site and let it sit for a few months, gathering data with the basics (Search Console and Hotjar, plus the usual analytics stack) to understand what organic visitors wanted to see and how they were finding me. When you have time, data is the best asset you can collect.

A few days ago, I started using Google Stitch to rethink the site presentation and, honestly, my whole "brand". Basically: who I am, and what more than 20 years of building things online should look like graphically. Somewhere in the middle of the color and font brainstorm, a logo idea appeared. Something I could use instead of just my name at the top, which is the usual for vibe-coded sites.

The brainstorm went well. The execution was a total mess.

The path to failure

Building things on the internet, I have 20 years of experience. But I started earlier, learning how to install Linux from floppy disks and how to configure my modem by hand, until I finally landed on shell scripts. Bash was always my main tool, and I wanted the logo to carry that. Something modern that could still hold my history. The idea was simple: my handle, phalkmin, with the h drawn as a slash to suggest a Linux path. A blinking cursor at the end. Simple.

So I wrote a prompt and asked Gemini to create it, with a reference sketch attached and every detail spelled out. It failed badly. Then I tried ChatGPT, and guess what? It failed too. Even when I pointed out the exact problems and asked for specific fixes, every round came back as a fresh hallucination. OK, Claude can't generate images, but it can write SVG. SVG is basically code, right? It should work.

It failed.

Below are some of the results, and these aren't even the worst ones. Almost a week of tokens on the best models I could reach, and the output was comical.

Every single model I can access failed. Every? Not exactly. I have an OpenRouter account and OpenDesign installed, with access to GLM through my own keys. So I added $10 in credits and started working inside an app built specifically for design work.

If you're paying attention to the title, you already know how this ends: almost $6 spent, and the results weren't even marginally better.

I was frustrated and tired, and I seriously considered learning Inkscape or Figma just to build this damn logo as a vector myself.

Then it finally occurred to me: I have friends.

Over the years, I worked with some of the best designers I know. Some as colleagues, some as people who reported directly to me. A few of them owed me favors. So, without spending a single token, I reached out to one of them and explained what I needed. And I kid you not, in less than a day, I had the logo in light and dark mode, blinking cursor included, plus a bonus monogram. All for the price of a coffee to be redeemed in the near future.

It's beautiful, and it's already on my site.

Why every model failed

Is this a post to conclude that "humans are better"? If you're reading this, you already know that creatively, yes, we are. The interesting part is why, because all the models failed in a very similar way, and I don't believe the problem was graphic quality or raw model capability.

Image generators produce pixels from statistical patterns learned across billions of images. They're great at "a cozy cabin at sunset" because that's a texture and composition problem, the kind of thing the training data covers millions of times. A wordmark where one letter has to work as two symbols at once is a different thing: the h must stay legible as an h while also reading as a /. That's a symbolic constraint, and there's nothing in the pixel-prediction process that enforces "hold both meanings simultaneously". The model renders something h-ish, something slash-ish, and hopes for the best, because it can't just say "I can't do it". Every model is instructed to return something, even if it's conceptually wrong.

The SVG route fails for a different reason. An LLM writing SVG is writing coordinates blind. It predicts tokens, but never "sees" the render. A designer draws a curve, looks at it, feels that the weight is off, nudges an anchor point, looks again. That perception and action loop is the entire craft. The model gets one forward pass and ships whatever geometry the math produced.

"But you can paste the render back and ask for fixes!" I did, many times. It helps less than you'd expect. Vision encoders compress an image into a representation built to answer semantic questions ("is there a dog?", "what does this sign say?"), and optical judgment barely survives that compression. The model can confirm the logo says phalkmin. It can't "feel" that the slash terminal is a few pixels too heavy, and the whole balance collapses because of it.

My hypothesis: creating a symbol demands intention and identity refined through iteration, where each round depends on genuinely seeing the previous one. My friend looked at my reference once and knew what was wrong before I finished explaining. Something that thousands of tokens and hours of back-and-forth work weren't able to do.

The coffee, by the way, will cost me less than the OpenRouter credits did.

AI Bots Are Driving Up Your Hosting Bill. I have a WordPress fix

Paulo Henrique — Tue, 09 Jun 2026 14:36:58 +0000

A client called me last month, half panicked, after getting an email from his hosting provider. The subject line wasn’t a good one: “Your site is consuming excessive resources." The options were either to upgrade the plan or migrate to a better server.

His traffic graphs in GA4 were flat. Same visitors as the previous month. So I went into the access logs to understand what was happening.

It wasn't a DDoS. Well, it was kinda a DDoS. Made by AI bots.

The crawler invasion

Pull up the raw access log of any moderately popular site right now, and you'll see them: GPTBot. ClaudeBot. PerplexityBot. Bytespider. Google-Extended. Meta-ExternalAgent. OAI-SearchBot. CCBot. Applebot-Extended. Each one of them crawling page after page, product after product, post after post, on a schedule none of us were consulted about.

The math starts getting ugly fast. Every one of those requests fires a full WordPress bootstrap: theme, widgets, page builders, plugins, everything that makes your WordPress site run. Database queries fire. CSS and JavaScript get assembled. And then, after the server has done all that work, the response goes out: 80, 100, sometimes 200 kilobytes of HTML per page.

In the end, the bot reads about 5% of it.

So, you paid for the CPU time, the memory, the database connection, and the bandwidth, just to ship hundreds, maybe thousands of kilobytes of theme markup to a crawler that didn't want it.

"Just block them” sometimes won’t work

The first instinct of every dev who notices this is to reach for robots.txt, .htaccess, or Cloudflare bot rules, and block everything related to AI bots.

Problem solved, right?

Nope. Now you've also disappeared from the answers ChatGPT, Claude, and Perplexity give to people searching for what you sell. AI Overviews on Google? Gone. Citations in answer engines? Gone.

For most sites that depend on organic discovery, that's a worse outcome than the hosting bill. Now that Google is killing the default search engine, just blocking AI Bots is the same as killing your site to organic visitors.

AEO (Answer Engine Optimization) is the new front line of search. The companies winning at it right now are the ones whose content actually gets ingested by the major LLMs.

Also, if the marketing team is working on AEO, you might kill weeks or months of strategic work with a single setup. There has to be a better answer.

Let the bots in. Serve them just the main course

That's what ParseLess does. I built it after the call with that client, and released it on the WordPress directory a few weeks ago for public usage.

The idea is straightforward to the point of being almost embarrassing: when an AI bot hits your WordPress site, the plugin detects it by User-Agent and serves the content as clean Markdown instead of full-theme HTML. Same content. Same URL. Human visitors and Googlebot get the normal site. They don't even know the plugin exists. Only the AI crawlers get the lightweight version. To the AI Bot, this is gold.

The numbers come from measuring the same WordPress page in two ways. First, as a browser sees it: the HTML document plus every CSS file, JavaScript bundle, and image the browser has to fetch to render the page. Then, as a bot would see it through ParseLess: a single Markdown response.

Metric	Full HTML page	Markdown response	Difference
TTFB	459 ms	155 ms	~3x faster
HTTP requests	16 (1 doc + 15 assets)	1	94% fewer
Total weight	~484 KB (doc + CSS + JS + images)	~6 KB	~80x smaller
Database queries	full bootstrap	cache read	60–80% fewer

The first row is the one most people focus on, but it's the third row that does the actual budget damage. When an AI crawler hits a normal HTML page, it doesn't just download the HTML. The crawler pulls the stylesheets, the JavaScript bundles, and increasingly the images too.

ParseLess collapses that to one request. No follow-up asset fetches. Images become plain Markdown links that the bot can choose to fetch or ignore, instead of being downloaded automatically with the page.

Multiply by the bot traffic you're actually receiving in a month, and the bandwidth math stops being a curiosity.

What this looks like in practice

Say you have a WordPress site with 500 posts and/or products. Say the major AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Bytespider, Google-Extended, etc.) each hit most of those pages over the course of a month. Let’s consider conservative numbers.

Before ParseLess: roughly 500 pages × 10 bots × ~484 KB = around 2.4 GB of bandwidth, and 5,000 full WordPress renders with all their cascading asset requests.

After ParseLess, with the cache warm: 6 KB per response on average, single transient reads instead of full bootstraps. Around 30 MB total bandwidth for the same set of crawls. PHP-FPM workers freed up around 3x faster per request, which means the same server handles more concurrent crawler traffic before saturating.

It's the same content being delivered through a much shorter pipe, and without making the hosting bill skyrocket.

The client whose hosting alert triggered all this saved his server upgrade. He didn't lose AEO. He kept being crawled by every model that mattered. And the crawlers stopped costing him real money.

How it works

ParseLess hooks into template_redirect and runs the request through a User-Agent check before WordPress even decides which template to load. If the bot matches a known AI crawler, the request gets routed to the Markdown converter instead of the theme.

The converter runs the_content filter, so anything Elementor, Divi, ACF, or Gutenberg blocks render into the post content is captured correctly. Then it strips the wrapping markup and converts what's left to Markdown. Tables, nested lists, code blocks with language preserved, images with alt text, links, everything is preserved. The output gets stored in a transient with a configurable TTL.

Subsequent bot hits on the same post don't run the conversion. They get a single cache read and a response in milliseconds.

The plugin respects everything you'd expect it to respect. Posts marked noindex in Yoast, Rank Math, or Genesis are excluded. Private, draft, password-protected, and trashed posts never get served. All public post types are included by default, but you can restrict them in settings.

There's also a /llms.txt endpoint at your site root. Optional, off by default if you don't want it.

Since version 0.5.0, ParseLess also publishes a /botfood-sitemap.xml, an AI-specific sitemap listing the Markdown URL of every public post. It gets advertised in robots.txt automatically so crawlers actually find it, and it can be toggled off if you'd rather not expose it.

Knowing it's actually working

The first question anyone sensible asks after installing a plugin like this is: how do I know the bots are actually hitting the Markdown version and not still pulling full HTML?

So I added an Analytics tab to the settings page. Optional logging records each Markdown request with the bot User-Agent, post URL, timestamp, bytes served, and whether the response came from cache. The IP gets stored as a salted SHA-256 hash, never as the raw address. That keeps the data useful for "how often did this bot hit me" without dragging the site into avoidable GDPR or LGPD territory.

The Analytics tab gives you a 30-day chart of bot activity, a breakdown by crawler, the top URLs being fetched, and a list of unknown User-Agents that look bot-shaped but aren't on the detection list. If something in that "unknown" list is clearly an AI crawler — happens regularly, the space moves fast — there's a one-click button to add it to the detection list.

A dashboard widget in wp-admin shows the same data in summary form, so you see it the moment you log in.

If you don't want any of this, leave logging off. The Markdown serving works fine without it. But if you're trying to justify the install to a client, or you want to know whether the new crawler that just appeared in your access logs is actually an LLM bot or something else, the data is there.

Where you will see the benefits

A short list of who actually benefits from this:

E-commerce sites running WooCommerce, especially with a lot of product pages. AI bots love to crawl product catalogs, and product pages tend to be HTML-heavy.

News sites and high-volume blogs where the content updates faster than the crawl can keep up, and the bots come back often.

Sites built on page builders. Elementor and Divi sites are the highest-impact use cases because their HTML payloads are the heaviest in the WordPress ecosystem.

Anyone on shared hosting or a tight VPS who's started getting resource warnings without being able to explain the spike in traffic.

If you're on dedicated infrastructure with headroom, the savings will still be real, but you'll feel them more in your CDN bill than in your server bill.

What it costs

Nothing. ParseLess is GPL, free, and in the official WordPress directory. Install, activate, and AI bots immediately start receiving the lightweight version. No configuration required for the default behavior to work.

Settings live under Tools → ParseLess if you want to adjust the bot list, the cache TTL, the post types, or the frontmatter options.

I'd love to hear from anyone who installs it and measures their own numbers — especially if the savings are different from what I'm seeing. Server setups vary, and the more data I have on real-world impact, the better the next version gets.

Either way, stop paying to render your theme for robots.

Age verification is coming. Free Software can build it right.

Paulo Henrique — Mon, 08 Jun 2026 14:27:34 +0000

In December 2025, Australia became the first country to ban under-16s from social media. Ten platforms, Instagram, TikTok, YouTube, Reddit, X, and the rest, had to block minors or face fines of around 32 million USD. People lost their accounts overnight.
The UK is debating its own version right now. The House of Lords already voted in favor of an Australia-style ban. France, Spain, Greece, Norway, Denmark, Turkey, Indonesia, Brazil: the list keeps growing every month. If you build anything that touches users on the internet, age verification is going to be a new task on your Jira/Asana/whatever dashboard. It isn't an "if" situation; it's a matter of "when".

A few weeks ago, Brazil's internet steering committee invited me to a closed session with government bodies, the national data protection authority, and representatives from operating system vendors, to work through what our age verification law actually means for OSes in practice. A few weeks ago, I wrote about a new child protection law passed in Brazil and how some people were creating FUD around it. (the translated version here on DEV). I went in to argue one narrow technical point and left convinced that the technical fight is the whole fight. Below are the arguments I made there, stripped of the local legal weeds, because I feel that this is a global problem, not just something happening in Brazil.

TL;DR: almost every age verification law is being implemented the wrong way. And the wrong way is the default unless engineers and Free Software activists start pushing back.

The wrong way is winning by default

What happens when a platform gets an age verification mandate and a legal deadline? The lawyers ask one question: what's the cheapest thing we can do that a regulator won't punish us for? And the cheapest, safest answer is almost always: ask for an ID.

Upload your passport. Scan your face. Type your government number. Give us a credit card. The platform gets a yes-or-no answer to a legal question, and as a bonus, it now holds a verified identity document tied to a real human. That document is an asset. It will be stored, analyzed, eventually breached, and in the worst cases, sold.

The EFF has been saying this for two years, and they are right: these laws keep pushing the debate toward identity, which is the wrong way. You just want to prove you are old enough to read a +18 fanfic, and you end up handing your data to a 3rd party company that had a data breach last spring.

Proving your age shouldn't also require proving your identity. Those are two completely different problems. Age is a boolean. Identity is not.

When a service needs to know if you are old enough, it needs exactly one bit of information. Over 18: yes or no. That's it. It does not need your name, your birth date, your document, or your face. It needs a true/false statement.

We already have the cryptography and the technology to deliver exactly that. Verifiable credentials and zero-knowledge proofs let you prove a single attribute, "this person is over 18", without revealing anything else about who that person is. It works today, and standards bodies have been shipping it for years.

The design is almost boring once you see it. The operating system, or some trusted issuer, already knows your age. It hands the app a signed signal: over 18, true. The app reads the signal, makes its decision, and never sees a document. Responsibility for acting on the signal stays with the app. Your privacy stays with you, because nothing about your identity ever leaves your device.

Think of it like an SSH key. You generate it once. It proves one specific thing. You reuse it across machines without ever exposing the secret behind it. An age key could work the same way: a single credential that says "over 18" and nothing more, reusable on your phone and your laptop, readable by any app, traceable to no one.
We win, big tech companies lose.

Open source is in a weird spot here

I say this as someone who has been in the Linux and free software world since the late 90s and saw all "Linux is evil" campaign during the early 00s: A few governments have started carving out exemptions for open-source operating systems. On paper, that sounds like a win. In practice, it is a trap, and some people in the community have already spotted it.

Being exempt from implementing verification does not give you the right to access anything. If the law excuses the OS but still forces every app to verify age under threat of a fine, the app can just block the open platform entirely in that region to avoid the risk. We have seen this movie before. Streaming DRM that delivers half resolution or even nothing on Linux. The exemption that looks like a gift can quietly become a blocker for the common user.

And there's a second-order problem. If open systems are exempt, the easy move is to wave every check through, to "yes-man" the verification. That gives the proprietary side an excuse to harden their mechanisms until open implementations can't pass, even when they want to. Android's Play Integrity is the cautionary tale. Exemption is not a solution. It just moves the bill to a later date, and the bill always comes due.

The free software community is excellent at one thing: pointing out what governments got wrong. Write the thread, give the talk, share the article. I have done all three. What we are bad at is showing up first with what actually works.

Someone is going to set the standard

Here's what changed my mind about the whole debate.
In 2025, the European Union published an open-source age verification blueprint. Privacy-preserving, interoperable, and designed to prove you're over 18 without revealing anything else. The EU's age verification app is fully open source, works on any device, and each member state can adapt it to its own rules.

Let that sink in. The blueprint for privacy-respecting age checks, the kind of free software that has been demanded, got shipped by a government bureaucracy while the community was busy filing objections.

This is the part where I get a little hopeful, which, honestly, isn't my natural mode.

The reference design exists. It is open. It is forkable. Any country willing to invest in it could adapt it, improve it, and ship a national age-assurance layer that proves an attribute without harvesting an identity. Whoever does that well first sets the global default, the same way the EU's cookie law ended up shaping consent banners on every site on earth, for better or worse.

I keep thinking that my own country could be that one. Brazil already ships open-source software across the public sector, runs one of the largest digital-identity stacks in the world, and is writing its own age-verification rules right now, with the regulator on record saying age checks should not become identity checks. Sitting in that session, hearing the data protection authority say out loud that age is not identity, I caught myself thinking the alignment is actually there: the political will, the public infrastructure, and a clean reference design from the EU waiting to be forked. The pieces are on the table, but we need to start using them to build something.

That is not a Brazil-specific argument. Swap in whatever country has open public infrastructure and a regulatory organ that hasn't fully sold out to "just collect the ID" companies. The point is that the good version of this is buildable today, and right now the bad version is winning purely because it's the path of least resistance.

So, what now?

Age verification is not going away. The bans are spreading faster than the standards, and every month, a new parliament copies the last one's worst implementation. If the community continues to just sit and wait, the default outcome is a planet where you have to hand over a government document to access any site, to write any comment. And we have no way to know how this data will be used, and by whom.

The better outcome is technically ready. Boolean signal, zero-knowledge proof, open protocol, widely accepted by any OS/device, just proving your age, and nothing else. We have everything for it to become a reality. What's missing is engineers deciding this is worth building.

So here's my question for you, wherever you build from: when age verification reaches your stack, are you going to ship the lazy version that asks for an ID, or the one that asks for a single bit of truth?

Because both are a choice. Only one of them respects the person on the other side of the screen, and we already talked about respecting the other side of the screen.

So, what am I doing after 22 years in tech?

Paulo Henrique — Thu, 23 Apr 2026 13:28:40 +0000

A follow-up to What to do in tech after 20 years?*

Two years ago, I was between a rock and a hard place, thinking about what I should do with my career and my life. Screw with 20 years of my life and do something completely new? Continue working hard to ensure my bosses get a new yacht?

Then Google Now recommended a post on DEVto. Some nice ideas there, and the community was engaging. And then I wrote my first post here. I won't lie, it was a rant. I was lost, kind of tired, and wanted to know if anyone else out there had figured out what to do with themselves after 20+ years of IT work when the passion that brought them in was, for all practical purposes, gone.

26 comments came in. A lot of them were generous. A few were wise. One of them (mine, to be fair) ended with "my now public mid-life crisis :)".

I don't know exactly why, but I remembered that post last week and noticed that two years have passed. In internet terms, basically two centuries. It's weird reading that back. I don't disagree with past-me, but I barely recognize him either.

So here's what I've figured out in between.

The creativity wasn't gone, it was burnt out

Back in the old days, before my burnout process, coworkers used to say I was the "ideas guy". I had too many, actually. Some were good. Most were weird. A lot involved weird references to 80's movies and series. A few turned into things that actually got built.

After the burnout, that part of my brain just… switched off. Not in a dramatic way. Just... silence. I could still code. I could still ship. I could still lead projects. But the part that came up with the weird ideas stopped answering when I called. "Why should I care?" — "It doesn't matter" — "They don't respect my ideas" — my mind was filled with noise, and not the good type of noise.

What I didn't realize at the time was that burnout had stacked on top of something else I didn't yet have a name for: a brain that had been running on pure masking fuel for 35+ years. The creativity hadn't left. I had just run out of spoons to reach for it.

Getting a neurodivergence diagnosis in your 40s rewrites your whole professional and personal life in retrospect. Every "why can't I just…" and every "why am I the only one who sees this?" and every burnout cycle I thought was about the job. A lot of it turned out to be about how my brain works.

And if you read until this part, that's not a sad realization. It's actually the opposite.

Proof the lights came back on

A month after that first rant, DEV.to ran the Coze AI Bot Challenge. I was mid-diagnosis, reading a lot, talking to my therapist, trying to make sense of a life I'd been living on hard mode without knowing. And during this process, I built Auty. A friendly bot meant to help people on the spectrum: not as a professional, just as a cool friend. The name came naturally: gender-neutral, catchy, related to autism, and fulfilling my life's need to name every AI project with a pun. AutI.

And my idea won in the creativity category.

Considering where I was, no surprise to say that I was not expecting this prize.

Then, this March, I entered the Built with Google Gemini: Writing Challenge with a post about using the Gemini CLI to resurrect pet projects that had been sitting on a server, slowly dying, while I was busy being an adult. Two old MVPs that worked, won their little battles, and then aged in place because I didn't have the energy or time to revisit them.

That won too.

Somewhere in between, without me really noticing, this profile picked up 18,000+ followers. From 19 posts. I still don't fully understand how the math is "mathing" here. I'm not the guy who posts every week, I'm the guy who shows up when he feels that something needs to be said, even when it might not reach those who need to hear it. But knowing that many people felt I was worth a notification of a new post published is… good. I'm genuinely glad to be seen.

Two prizes and 18k people paying attention. For someone who wrote a rant about feeling creatively and emotionally dead, that's the universe being a little on the nose.

AI didn't bring it back. But it's part of what's keeping it going.

Here's where I'm going to contradict my old post a bit. Back then, I looked at AI and went meh. Considering the results I was getting, I thought it was just hype. The new NFTs (well, deep down I still think most of the AI talk is just smoke and mirrors, but that's not the point).

Two years of building with it later, I'm still not a believer in the religion. I've written at length on LinkedIn and Medium about AI slop, about AI regulations, about AI psychosis, and how AI is changing how people perceive reality. Every time someone tells me ChatGPT is their therapist or even their best friend, I want to scream.

But AI as a tool? Totally different story.

The reason it matters here is simple: when the creativity started flickering back on, I suddenly didn't need to 100% plan, execute, test, and market my personal projects alone. I've got a small team of junior devs (be it Claude, Gemini, Codex, or even a small local model on my home server) that I run like a very patient senior would.

Sometimes they're rubber ducks, and I work through a problem just by explaining it out loud to them. Sometimes they're planners, drafting execution files I can work through a step at a time on nights when my brain is tired but not done. Sometimes they actually write code, and I review it like I'd review any other junior's PR: carefully, with the assumption that something in there is wrong. Each one has a different personality, a different set of bad habits, and a different style of being overconfident. Managing and understanding them is more like managing people than I expected.

And every single one of them runs with a human in the loop — that's me, signing the final result. My rule for every automation I build for clients is the same rule I have for my own projects: when it screws up (and it will), some person made of flesh and blood has to be the one explaining it to another person made of flesh and blood.

I don't feel replaced. I feel like I got a new tool.

The creativity doesn't only go into code anymore

Before the burnout, I'd started learning how to cook. Not the "here's my instant ramen, I put some crumbles on top" kind, but actual dishes I wanted to experiment with. I lost that love during the burnout period, and the recovery process quietly rekindled it. If I can understand patterns as few people can, maybe I can also mix spices for a new sauce.

Now it's a thing. I've got my knives, my stocks, my opinions about which pepper to use and when. I've ruined enough plates to know what I'm doing. It scratches a part of my brain that writing and coding barely touch, and in a good way. I'm still creating things and hoping someone appreciates them. And I know I'm doing it right in the same way I know everything else is working: when my wife says she'd rather I cook than we eat out.

There's also a home server humming away in the corner of my office. Nothing fancy: it started as a Raspberry Pi trying its best, and now it's 20TB+ of data sitting in a cool case. What started as a "why am I paying for things I could host myself" project slowly became where I keep the parts of my digital life I don't want a big tech landlord evicting me from someday. Having a machine in my house that does exactly what I tell it to, nothing more, is still one of the quiet pleasures of this job.

And I still write. Here, on Medium, on LinkedIn, on my own site. But I do it differently now. Not because I need to pay my bills (well, I still need to pay my bills, sadly), but because I love what I'm doing, the way I'm doing it. Writing about the imposter syndrome of meeting clients in English and seeing how people resonate with that feeling gives me a reason to keep going — even if sometimes "keep going" means writing 20+ pages of documentation for a project I know the client won't read and then ask me about it.

That's what I couldn't see two years ago.

So, to answer the question in the title

Two years ago, I asked thousands of people what to do in tech after 20 years. I didn't get one answer: I got dozens. I met lots of new people. Somehow, DEVto embraced me. In an internet full of hate and hot takes, this place turned out to be a community where I could talk with people, get new ideas, and be challenged in good ways.

Things are a lot better now. And DEVto has a part in it.

Turns out the question was wrong. "What now?" assumes there's a single next thing, a new direction, a pivot. Reality is a lot messier. I mean, even DEVto has changed a lot since then.

There was no grand plan. No career reinvention arc. No big refactor or a new layout that would change how people perceive me. Just slightly less masking, slightly more writing, and a lot more asking what I'm doing that actually gives me pleasure.

The passion didn't come back the way it used to be. And that's OK, I'm not young anymore. "What a shame to be 45 years old and not completely covered in scars." Go watch Shrinking.

Something else took the place of that passion. I'm still figuring out what to call this version of it.

What's yours doing?

Linux Solved the "AI Code" Problem in One Page

Paulo Henrique — Tue, 14 Apr 2026 14:33:13 +0000

Around the year 2016, which in terms of internet is millennia ago, and AI was still mostly about self-driving cars and badly configured chatbots, I used to ask co-workers a simple question: if this thing screws up, who takes the blame? Or, even worse, if we start using it in the wrong ways, who's responsible? Who do we question, exactly?

Nobody had a good answer, and that's something that still raises a lot of questions. Almost ten years later, Linux has started a movement that answered how we deal with code made by AI.

One page, just ONE page

Last week, the Linux kernel published its official policy on AI-generated code. The document is less than a page long. It was approved by Linus Torvalds himself, the person who has been the final word on everything Linux decides for over thirty years. Part of the tech press covered it as either a surrender to the AI hype or just a bureaucratic crackdown on AI-assisted tools. The problem is that both readings miss the point entirely.

What the Linux team did was answer a question that has been paralyzing open source communities for the past two years, making GitHub unmanageable for most of the bigger projects.

What the document says, in short terms:

Licensing: any contribution made with AI assistance follows the same rules that always applied to the kernel. Nothing changes.

Attribution: if you used an AI tool, you tag it. Model name, version, done. It's a single line that makes it clear what you have used:

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Signature: AI agents must not add Signed-off-by tags. Period. Only a human can certify the Developer Certificate of Origin. Only a human can say "this code is mine, I have the right to submit it, and I'm responsible for it."

And that's the part where things start to get interesting.

What the Kernel team refused to do

The Linux maintainers could have gone the route some open source projects took: ban AI-generated contributions outright, treating any code touched by a model as legally contaminated. Some projects did exactly that. The fear of copyright liability was real, after all, and the easiest and quickest response was to shut the door.

They could also have gone the other way: accept anything that compiles and passes tests, no questions asked. Plenty of companies operate this way already. If the CI pipeline is green, ship it.

Linux found a third way. What they refused, above all, was the fantasy that you can police what developers do on their own machines. You can't 100% assure that someone didn't use Copilot to autocomplete a function. You can't know if they asked Claude to refactor a module. You can't know if they typed every character themselves or dictated it to a parrot that happens to know C. I mean, my cat sometimes steps on the keyboard and likes to play with my mouse, so it's safe to assume he might as well create part of my code after a few attempts.

The most important thing is: it doesn't matter how it was done, or how stressed the developer was by his cat messing with the code, or even while writing a DevTO post (Sebastian says "Hi").

What matters is: in the moment someone submits a code piece, they must put their name on it. That's the only point where control is both possible and necessary.

The word developers use for this is accountability. It means two things that can't be separated: whoever produces something must be identifiable, and whoever is identified must answer for what they produced. Remove either half, and you have a big bag of shit with a capital S.

The accountability gap that must be discussed

I've been building things with AI for a while now. I mean, it's not like I'm not being verbal about this fact. I even won some prizes by creating things with AI.

My WordPress plugin, WP-AutoInsight, connects to multiple AI APIs and generates content. But everything it produces lands in draft mode. The same thing applies to n8n automations and other tools I've been building for some clients: A human has to review it, approve it, and hit publish. A real person must be accountable.

Not every client actually reviews the drafts. But the option has to exist.

Because when AI gets it wrong, and believe me, it does get it wrong, a person made of flesh and bone will have to explain the problem to another person made of flesh and bone. That's the part that hasn't changed and won't change for a long time, regardless of how good the models get.

The Linux policy understands this. It doesn't try to evaluate the quality of AI output. It doesn't try to detect whether a human or a machine wrote that code. It simply says: whoever hits submit, that's the person who answers for it. The tool is irrelevant; what really matters is the signature.

Here's where it stops being a software story.

If you follow me and read my posts, you might know that this isn't just about coding.

The same question Linux answered in one page is the same question that courts, hospitals, newsrooms, and law firms have been struggling with for years. Who is responsible when a legal brief cites a case that doesn't exist? Who answers for a medical report generated by a model that hallucinated a diagnosis? Who owns the mistake when an AI-written news article gets the facts wrong? Who must answer for CSAM generated using AI?

Every industry that produces content with consequences is hitting the same wall. And most of them are arriving at the same answer: attach a face and a name to the content generated. Make someone sign for it. Make that signature mean something, legally.

The Linux kernel just "got lucky" and reached a good answer, in fewer words than most companies will be able to deliver.

In the same way that Linux is "getting lucky" by creating new standards before anyone else, over the last few decades.

Where the AI debate fails

The lazy reading of the Linux policy is that Torvalds opened the door for vibe-coding. The precise reading is different: Linux didn't regulate AI but regulated authorship instead.

And that distinction matters because the entire public debate about AI in development is stuck in the wrong frame. One side wants to ban AI tools because they're dangerous. The other side wants to remove all friction because AI makes everything faster. Both sides are arguing about the tool.

The Linux kernel doesn't care about the tool. It cares about who signs. And who signs, answers.

Now let's go back to the long-lasting question I've mentioned at the start of the text: "Who is responsible when this goes wrong?" applies to every piece of software, every automated decision, every AI-generated output that reaches production. That's what Linux decided.

The fact that the Linux kernel answered it in fewer words than most README files should tell us something about how we discuss things today. The answer was never complicated, we just made it seem too complex to answer.

OK, and what does this mean for us?

If you're writing code with AI assistance right now, and, let's be honest, statistically, you are, here's what you need to know about the Linux policy, in practice:

Use whatever tools you want. Nobody is coming to audit your IDE.

But when you submit that code, when you open that pull request, when you push to production: that's your code now. You reviewed it. You understood it. You certified that it does what it's supposed to do. If it breaks something, your name is on it.

"But what if I haven't reviewed it?" - you might ask. Well, it's your name there. Take the blame. That's part of the job. It always was.

The only thing the Linux policy made explicit is something that should have been obvious from the start: AI can write code, AI can write content, AI can make media. But AI can't be responsible for it. That part is still on us.

And if your workflow doesn't have a point where a human reviews, understands, and approves what the AI produced before it goes live, you don't have a workflow.

You have a liability.

When Your UX Only Fits Two Sizes

Paulo Henrique — Thu, 09 Apr 2026 13:04:01 +0000

A few years ago, right before the pandemic hit, I was trying to buy clothes online. Nothing fancy, just basic stuff, trying to get rid of my old "nerdy" t-shirts and work on different styles. "Queer Eye" got me with all those tips, you know the drill.

And while I looked at the outfits, I started to notice a pattern across multiple stores: the navigation had "Men's Clothing" with dozens of subcategories, "Women's Clothing" with even more subcategories, and then, sitting there on the menu, separate from everything... "Plus Size."

Just "Plus Size". No gender. No subcategories. As if being above a certain weight, or having a body out of the norm, erased everything else about me. According to these stores, I could be a man, a woman, or just... fat.

Someone designed that. Someone coded that. Someone approved that. And probably nobody in the room thought twice about it.

The interface is the message

@jess recently wrote something that stuck with me:

as developers, we're responsible for the interfaces the world lives in, and we have the power to build systems that refuse to force people into categories that don't fit.

And.. she's right, I love it when someone finds the exact words for an idea I've been circling around but couldn't articulate. But I think the problem goes deeper than that: Most of the time, we're not actively forcing people into bad categories. We're just not thinking about them at all.

I wrote about this last year, where I talked about my own experience as a left-handed, neurodivergent person working in tech. How being outside the norm gave me a different lens on design and problem-solving. But that was about perspective. In this context, we are talking about something more concrete: the actual decisions we make every day when we build things.

Every dropdown menu can be a decision about who we believe has the right to exist and who is being seen by us. Every form field is a statement about what matters. Every category in a navigation bar is a tiny act of world-building, whether we actively thought about it or not.

The "default human" problem

More than a decade ago, while working as a Tech Lead at an agency, a client reported issues with their site. It worked for us, so I did the basic investigation, and he used Internet Explore on Windows. When reporting it to the team, they complained about having to fix the issue, saying, "Who still uses Windows these days?"

It was 2012. Windows and IE still dominated the browser landscape. In an agency loaded with MacBooks, they couldn't understand anything out of their reality.

I like to tell this story whenever a discussion about development and design decisions arises. Most developers don't think about it because they've never had to: when you design a system, you're designing for a default human. And that default human is usually someone who looks, thinks, and lives a lot like you.

If your team is mostly young, able-bodied, right-handed, neurotypical people from similar backgrounds, your "default human" is going to reflect that. Not exactly out of malice, but by blindness.

Color-blind users get crushed by red-green status indicators because someone on the team thought "red means bad, green means good" was universal.

Screen readers choke on websites because someone decided that a div with an onClick handler was "basically the same" as a button.

Neurodivergent users get overwhelmed by interfaces full of elements, or where the elements don't have clear precedence, and it isn't clear what to do next.

None of these are edge cases. Color vision deficiency alone affects roughly 8% of men worldwide. That's not a niche demographic. That's a significant chunk of your users that you're ignoring because you never tested with them.

It's not about good intentions

I've been building things for the web for over twenty years. Obviously, I've shipped code that was exclusionary without knowing it. We all have at some point in our lives. And the point of this text isn't to make you feel guilty about it.

The point is to stop treating inclusion as a feature request.

Accessibility isn't a sprint item you add after launch. Inclusive language in your UI isn't a "nice to have." These are architecture decisions. They belong at the start, in the planning phase, when you're sketching out user flows and database schemas. Not bolted on six months later when someone files a complaint.

My first job had more women than men, so I could better understand the differences in treatment. Smart women being judged by their looks when they could run whole departments if they had the chance. Me hearing "but will she be able to lift a printer if needed?" when I decided to hire a girl as an intern.

Also, I had a color-blind boss on my second job. Great developer, great guy. He couldn't tell red from green when they were next to each other. You know what happened? I started thinking about color as information design instead of decoration.

Those experiences, along with others, changed how I build interfaces and how I communicate with everyone.

But not everyone should need a personal connection to figure that out. And that's the part we need to start fixing.

Small decisions, real consequences

Let me go back to the clothing store for a second. That "Plus Size" category without gender isn't just lazy UX. It tells plus-size customers that they don't deserve the same browsing experience as everyone else. It tells them they're an exception, not a person.

And it compounds. A form that only offers "Male" or "Female." A name field that rejects special characters (sorry, anyone with an accent, a hyphen, or an apostrophe in their name). An age dropdown that starts at 18 and ends at 65, because apparently, people over 65 don't use the internet. Each one of these is a small nuisance. But each one of these tells "this wasn't built for you" to someone that isn't you.

I've seen Brazilian names rejected by international platforms because of the "ã" or "ç" in them. And sorry, this isn't a technical limitation in 2026. That's a choice someone made, or more likely, a choice someone never thought to question.

So what do we actually do?

This isn't an AI Slop article, so I'm not going to give you a five-step listicle with generic tips, sorry. But here's what I know from experience.

First: put different people in the room when you're making decisions. Not as a diversity exercise, but because they'll catch things you literally cannot see. My color-blind boss didn't need a diversity initiative to improve our interfaces. He just needed to be there. That's why I advocate for women in tech. That's why I advocate for teaching programming in public schools.

Second: test with real humans who aren't like you. Not your coworkers. Not your friends. Actual users who interact with your product from a completely different context than the one you imagined. Believe me, the results will humble you.

Third: question your defaults. Not just as an IT professional, but as a human being. Every time you create a dropdown, a category, a label, ask yourself: who am I leaving out? And if the answer is "I don't know," you might have a problem.

We build the systems the world runs on. Not metaphorically. People apply for jobs, access healthcare, manage their money, connect with others, all through interfaces we designed. When those interfaces exclude, they are not just creating an inconvenience, they are erasing people.

That clothing store didn't mean to dehumanize anyone. But in the end, the result is the same.

Move over, Vibe-Coding: I built an AI editor for STRESS-CODING

Paulo Henrique — Mon, 06 Apr 2026 13:07:11 +0000

This is a submission for the DEV April Fools Challenge

Quantum Collapse is a React editor that monitors your face via webcam and sabotages your code when you blink. Sadly, it works.

What I Built

If you are working remote in 2026, you know how some companies like to ensure that you are "being productive". Keep your camera on, keep a "productivity tracker" installed and running while you try to work.

"We trust you," they say, from behind six layers of monitoring software.

And, at the same time, "vibe-coding" is the new hype. Everyone is talking about how we should stop caring about code quality and hard work, and let AI do the job for us.

So I built an IDE that merges those two realities.

What Quantum Collapse actually does

The premise is straightforward. If you're watching the screen, your code stays intact. The moment you blink, or look away, or even commit the biological crime of hydrating your eyeballs, the editor "collapses the wavefunction" and starts quietly sabotaging your work.

Your variable names become emojis.

Your semicolons silently turn into Greek question marks.

Your functions rename themselves after Tokusatsu Monsters (I'm a nerd, sue me).

There's a Stability Meter that drops every time you blink, and when it bottoms out, you can't save your work. And the best part? The editor doesn't tell you what it changed.

You look back at your screen, and MAYBE something is different, but you're not sure what. Was that variable always called 🌮? Did that function always return undefined? Maybe you're just tired. Maybe you made a mistake. The code was fine a second ago. Wasn't it?

That's the whole joke. You are not vibe-coding anymore. You are STRESS-CODING.

It's also, in a very direct way, the experience of working under a time tracker that logs your keystrokes and then surfaces a passive-aggressive "productivity score" for your manager to review. You know you worked. The data says something else. You start questioning yourself and how you work.

The only difference is that Quantum Collapse is honest about what it's doing.

Demo

You can try Stress-Coding your new project here

Warning: extended use may cause dry eyes, Greek punctuation in production, and a sudden appreciation for jobs that don't need to see your face to trust you.

Code

phalkmin / DevTo-April-Fool-s-Challenge

React + TypeScript + Vite

This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.

Currently, two official plugins are available:

@vitejs/plugin-react uses Oxc
@vitejs/plugin-react-swc uses SWC

React Compiler

The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see this documentation.

Expanding the ESLint configuration

If you are developing a production application, we recommend updating the configuration to enable type-aware lint rules:

export default defineConfig([
  globalIgnores(['dist']),
  {
    files: ['**/*.{ts,tsx}'],
    extends: [
      // Other configs...
      // Remove tseslint.configs.recommended and replace with this
      tseslint.configs.recommendedTypeChecked,
      // Alternatively, use this for stricter rules
      tseslint.configs.strictTypeChecked,
      // Optionally, add this for stylistic rules
      tseslint.configs.stylisticTypeChecked,

      // Other configs...

…

View on GitHub

How I Built It

This whole project was made using AI as a tool. I used Gemini Web (that has a bunch of my latest posts and memories) to brainstorm some ideas, and as I'm a notorious advocate of remote work and clear productivity goals when working, one of the ideas was to play with this concept.

Then, I used Gemini CLI's Plan Mode to map out the mutation engine, or, more specifically, brainstorming the most creative ways to mess with code without making it obviously broken.

For development, I first used Gemini CLI, but for the final steps of front-end development, I used Codex, as Gemini kept messing up some parts of the code.

For deployment, the Gemini CLI handled containerization and pushed the whole thing to Google Cloud Run. The fact that a gag application about corporate surveillance is running on enterprise-grade infrastructure with automatic scaling is, genuinely, the ironic part of the project.

What I used

Google MediaPipe (Face Landmarker) handles the blink detection: real-time computer vision, running entirely in the browser, zero latency. If you blink for 200ms, the AI knows. The AI always knows. Which is, again, exactly the energy of the companies that sell "employee monitoring solutions" to people who manage remote teams.

React 19 + TypeScript because even a deliberately broken tool should be type-safe before it breaks itself. There's something deeply funny about writing rigorous TypeScript for a chaos engine.
Framer Motion powers the glitch aesthetic ( scanlines, neon flicker, haunted CRT vibes ).

Vite 8 for the build. PrismJS for syntax highlighting, because the code deserves to look beautiful right before it gets destroyed.

No, Brazil's "Felca Law" doesn't ban Linux

Paulo Henrique — Sun, 15 Mar 2026 14:22:54 +0000

(This is a translated version of my original text on Medium, where I discuss a huge fake news being spread about brazilian laws and how parental control work on Linux)

The misinformation about Brazil's Law 15.211/2025 and Linux is a textbook case of how a legitimate concern becomes panic when nobody reads the source material.

On March 8, 2026, MidnightBSD (a niche BSD system most people have never heard of ) proactively blocked Brazilian users. The message was blunt: "Residents of Brazil are not authorized to use MidnightBSD."

Right on cue, a week later, my timeline was flooded with alarmist posts about how Brazil's "Felca Law" was going to ban Linux. Videos with all-caps titles, apocalyptic threads, people who never installed a distro in their lives sharing that "the Brazilian government is banning Linux." The full misinformation cycle, start to finish, in less than ten days, fueled by artificial panic and clickbait content.

Look, I've been using Linux since the late '90s. I've contributed to open source projects, spoken at conferences about it, and even interviewed Linus Torvalds. Using Linux is second nature to me. A good chunk of my day, even for personal projects like my home server, is spent in a terminal running native Linux commands. So it's pretty obvious that when the flood of "Linux is banned" posts started showing up, I went to look for myself.

Meaning, I read the law.

What Law 15.211/2025 actually says

Law 15.211, signed in September 2025 and effective as of March 17, 2026, is officially Brazil's Digital Statute for Children and Adolescents. The nickname "Felca Law" comes from a YouTuber by the same handle, whose video about child exploitation on social media accelerated the bill's passage in Congress. The video has over 50 million views today.

Article 1 defines the scope: it applies to "all information technology products or services directed at children and adolescents in Brazil or likely to be accessed by them." Article 2, item I, lists examples: internet applications, computer programs, software, operating systems for terminals, app stores, and electronic games.

Yes, operating systems are mentioned. And this is where most people stop reading and start panicking.

But here's the thing: at least in Brazil, laws don't exist in isolation. They depend on, limit, and build upon other laws. If a law mentions "family," there needs to be a legal definition of family, or it references an existing one, to avoid ambiguity. Everything depends on context, not on isolated words in a single article.

With that in mind, Article 12 is where the confusion was born. It says that providers of app stores and operating systems must take proportional, auditable, and technically secure measures to verify user age, allow parents to configure parental supervision, and enable age signaling via a secure API.

The keyword there is "proportional."

It shows up again in Article 39, which reinforces that obligations must be applied according to the "characteristics, functionalities, size, and degree of interference of the provider." And Article 12, §3 explicitly states that an Executive branch regulation will define minimum requirements.

In other words, the regulation isn't even finished yet. And even when it is, it still relies on other existing laws. People in Brazil are debating the worst-case scenario of a law whose practical application hasn't been defined and that doesn't exist in a vacuum.

It gets worse (for the panic narrative)

When the "Linux ban" discussion started gaining traction on the few networks I follow, I noticed that virtually nobody was mentioning three provisions from the same law that dismantle the whole narrative:

Article 2, §2 excludes from scope "essential functionalities for the operation of the internet, such as open and common technical protocols and standards." The Linux kernel runs on over 96% of the world's web servers. It is the essential functionality for the operation of the internet. I don't know how to make this clearer.

Article 14, sole paragraph, states that "regardless of the measures adopted by operating systems and app stores, providers [of applications] must implement their own mechanisms to prevent improper access." The primary responsibility lies with the applications, not the operating system. If Instagram needs to verify age, that's Instagram's job. The operating system plays a complementary role, not a central one. Pretty obvious, if you think about it for a second.

And Article 37, sole paragraph, prohibits the regulation from resulting in "massive, generic, or indiscriminate surveillance mechanisms" and explicitly protects freedom of expression and privacy. Blocking access to an entire operating system fits squarely into "generic and indiscriminate."

Three articles. Same law. That most people who shared the "Linux is banned" story either didn't read or cherry-picked to promote panic. And this is getting traction, even internationally.

How clickbait became panic

So here we go.

Between August and September 2025, when Brazil's president signed the bill, the first analyses emerged. A political columnist posted on Twitter that a "possible ramification" of the law would be "banning Linux." A tech columnist from TecMundo (a major Brazilian tech outlet) started threads analyzing Article 12 and asking what the chances were that Linux distros would implement age verification. On TabNews (a Brazilian dev community), the topic was discussed under the headline "END OF LINUX IN BRAZIL⁉️"

In December 2025, Brazil's National Data Protection Authority (ANPD) published its list of companies subject to oversight, which included Canonical (Ubuntu).

Now, being on an oversight list is radically different from being banned. I'm on the income tax registry. That doesn't mean paying taxes is illegal, or that I'm automatically going to jail. It means the tax authority knows I'm a minimally (emphasis on minimally) functional adult and I need to comply with my obligations. Once those obligations are met, nothing happens.

Finally, in March 2026, everything blew up. MidnightBSD blocked Brazilians preemptively (the project's own decision, not a legal mandate), TecMundo published an article presenting the most pessimistic scenario as plausible, and the whole thing went viral.

The misinformation spread along two axes. On the political side, right-wing sectors framed the law as "censorship" and "state control," using Linux as an example of regulatory overreach. Standard playbook: when there's nothing real to present, create panic. Content like that goes viral fast, and not always organically.

On the technical side, members of the tech community turned "could affect" into "will ban." Well, I could walk to the bakery and get hit by a Boeing 737 that lost control and crashed specifically on my head. Something having a chance of happening doesn't mean it will.

And since sharing an alarmist headline is easier than reading 37 articles of a law, here we are.

What the law can't do (and why)

No fluff, let's get to the legal arguments:

Proportionality is the central principle. Banning an entire operating system because it doesn't have native age verification would be like shutting down a highway because one of the cars on it doesn't have a seatbelt. Article 5, §3 requires the ANPD to consider "regulatory asymmetries" and "technological evolution" when issuing guidelines. Volunteer-maintained Linux distributions don't have the same implementation capacity as Microsoft or Apple. The law acknowledges this.

Applications bear the primary responsibility. I already cited Article 14, but it's worth reinforcing: the law distributes responsibility across the entire digital chain. The operating system is just one layer, not the bottleneck.

Brazil's Internet Bill of Rights protects open technologies. Remember what I said about laws not existing in isolation? Article 24, V of Law 12.965/2014 (Brazil's "Marco Civil da Internet," essentially our Internet Bill of Rights) establishes as a guideline the "preferential adoption of open and free technologies, standards, and formats." Any interpretation of Law 15.211 that results in banning free software directly conflicts with this guideline.

The "Felca Law" itself references the concepts from the "Marco Civil" law. One doesn't exist without the other, and neither exists separately from the rest of the legal framework, including the original Child and Adolescent Statute (ECA).

The Constitution protects free enterprise. Article 170 of the 1988 Constitution enshrines free enterprise. Banning Linux distribution, used by thousands of Brazilian companies and by the federal government itself, would violate this principle.

Suspension and prohibition require a court order. Article 35, §5 specifies that warnings and fines are applied by the ANPD, but suspension and prohibition of activities can only be imposed by the Judiciary. There is no scenario where the ANPD simply "bans" Linux by administrative decree. A court order would be required, with full due process.

The law itself prohibits mass surveillance. I already mentioned Article 37, but it deserves emphasis: the law prohibits the regulation from compromising "the fundamental rights to freedom of expression" and privacy. Blocking an operating system falls under that prohibition.

Technological neutrality is a principle of Brazilian regulatory law. The law doesn't differentiate between proprietary and free software. Interpreting it so that only Windows and macOS can operate would create an unconstitutional market monopoly that makes no sense whatsoever. You can have a Linux-based OS that's almost 100% nationally developed. You can't say the same for Windows or macOS.

Law firms that have formally analyzed the law treat it as imposing compliance obligations, not technology bans. No formal legal opinion supports the thesis that Linux would be banned.

I'll say it again, in bold this time: None.

"But Linux doesn't have parental controls"

For the love of sweet baby Tux, have you ever actually used Linux? This is the part that annoys me the most, because it shows that whoever pushes this argument doesn't use Linux. Or, if they do, they never looked beyond the basics.

GNOME has integrated Malcontent since version 3.38, back in 2020. It's a native parental control system that lets you restrict apps per user account, block web browsers, prevent software installation, and filter apps by age rating using the OARS (Open Age Ratings Service) standard. It's part of the desktop environment that millions of people use.

Flathub, the largest Linux app repository, mandates OARS classification for all published apps. Classification by violence, drugs, sex, language, social interaction, mapped to age ranges. The same kind of thing you find on the App Store and Play Store.

For screen time control, Timekpr-nExT offers daily, weekly, and monthly limits, time windows, per-app control, and automatic logout. Works with GNOME, KDE Plasma, XFCE, Cinnamon, Budgie, and Deepin, on both X11 and Wayland. It's been in Ubuntu's official repositories since version 20.10 — that's the year of our Lord 2020.

And there's more: CTparental, a French open source solution, combines web filtering by category, forced SafeSearch, time controls, download blocking by file extension, and a web admin interface.

At the system level, Linux offers controls that simply don't exist on Windows or macOS: PAM can restrict login by time of day directly at the kernel level; iptables/nftables can block internet access per user ID; AppArmor and SELinux implement mandatory access control. Every Unix-like system, no exception, has the foundations to meet these requirements by design.

I'd go as far as saying that if the "Felca Law" actually forced operating systems to implement age controls, Linux would probably be more suitable than Windows and macOS. If someone wants to argue that Linux can't comply with this law, they'll need better arguments. Because the facts disagree.

The debate that actually matters

Look, I'm not saying the law is perfect. No law is, by definition. Society changes, technology advances, and laws rarely keep up.

In the case of the "Felca Law", the wording is broad, as is typical of Brazilian legislation. And unfortunately, there are legitimate ambiguities that need to be resolved during the ANPD's regulatory process.

The real question is: how do we make sure that regulation recognizes the specifics of free software? Decentralized governance models, community-driven development, the impossibility of having a single "provider" responsible in the traditional sense. There are viable technical solutions, like system-level age signaling APIs, that can be implemented without compromising the open nature of the code. Ideally, APIs that aren't tied to big tech companies or other services that could misuse this information.

I'm in favor of regulation that protects children and teenagers online. I've written on LinkedIn about how platforms profit from child exploitation while treating reports as a joke. I've reported 18+ content in supposedly child-friendly videos on Instagram, and the response was always "no violations found." The Felca Law tries to solve a real problem that big tech seems to treat as a "necessary evil" for their bottom line.

The path forward is participating in the public regulatory consultation with constructive contributions. Not sharing that "Linux will be banned" without having read a single article of the law or knowing how Linux works.

Installing Linux in Brazil was legal in the '90s. It's legal today. And it will be legal tomorrow.

Staying informed is important. The panic, as usual, is optional.

With Gemini CLI, I'm able to keep my pet projects alive and kicking

Paulo Henrique — Tue, 03 Mar 2026 21:54:39 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

It's 2023, and I'm trying to figure out how LLM APIs actually work. I don't like the idea of creating a "ChatGPT clone" that just talks to the OpenAI API. There are thousands out there. So I built a rough Next.js site to merge AI and SEO in a simple way. Out with the long prompts; the site would just do the work for you with minimal inputs.

It's 2024, and I'm loving being part of the DEV.to community, writing for fun, coding for fun. During a Hackathon, I decided to build a text-based RPG for a DEV.to challenge using AI, so every adventure and interaction would be different. I had a dream of using AI to create infinite ideas like the old "Choose Your Own Adventure" books and games from the 80s and 90s. I love a good pun, so "Choose Your Own AIdventure" was born. Unfortunately, given some time constraints, the site was rough, and I didn't win the challenge.

Both projects worked as MVPs. Both won their respective little battles. And, like most pet projects, they sat on a server and aged.

Code gets outdated. APIs change. You receive some alerts from GitHub or Vercel about outdated libraries or build variables. But you still need to work, or deal with adult things. And your cool idea just sits there, unchanged, cursed to never be what you know it could be.

Enter the Gemini CLI. I was already using it professionally, but one day I just thought: "What if I asked Gemini to evaluate my code and minimally update it to 2026 standards?"

Done.

Simple as that. I just had to approve some commands, and minutes later Choose your Own AIdventure was alive and kicking again.

This is where I decided to take those two legacy projects and use the Gemini CLI to not only do a minor update, but to refactor them exactly as I envisioned them the first time. Here is exactly how that went.

What I Built

I'm by nature a terminal person. This is where I spend most of my day. I access remote servers, I build automations, I execute shell scripts, and I test things locally before they ever see a browser. So, using the Gemini CLI to execute code was natural for me. I keep it running on the second monitor and provide inputs when needed. On my main monitor, I focus on other things.

The first project I refactored was Choose Your Own AIdventure. As I mentioned, originally it was supposed to be like the old solo RPG books, where you read part of a text and choose what to do based on limited options. Good choices led you to victory. Bad choices led to a bad ending.

The biggest upgrade here was fixing the layout. I still wanted it to look like an old videogame, so I asked Gemini to analyze the codebase and create a mockup of a new front-end. After a few rounds of manual changes and conversations with the tool, I asked the CLI to apply the final version. Then, I started a brainstorming session with Gemini to discuss ideas and how to implement them by priority and complexity.

After that, I asked it to create a markdown file with all the ideas and an execution plan. In my spare time, I could just boot the CLI and ask it to execute the plan from item X to item Y. Gemini was able to understand everything, ask questions, and even test the build to ensure that everything was in place.

For the SEO Toolbox, the Gemini CLI basically refactored the whole codebase, making it smaller, faster, and packed with new features. Originally, I only had two features: create some blog post ideas, and write a text about X. Now, it feels like a true toolbox, with half a dozen options, like Competitor Analysis, Meta Tag Generation, and more.

What I Learned

Years ago, I studied to be a teacher. Going through the Brazilian Magistério program and studying Paulo Freire, you learn very quickly that you don't teach by just handing over the final answer or by assuming that everyone is on the same page as you. You need to know how to let the student learn on their own terms, and guide the interaction with the subject.

Prompting an AI that has almost infinite access to your files feels exactly like that.

I had to unlearn the way I prompted before. This meant giving clear instructions on when to act and when to just review everything, and also reviewing Gemini's decisions before approval. Giving a bad prompt meant that Gemini would overthink the solution or act on its own, modifying things I didn't ask for. Because I had limited time for these personal projects, I had to create almost perfect prompts and ensure my GEMINI.md rules were on point.

My skills evolved, too, as I learned that talking to the web version of a model is entirely different from talking to the agentic version.

Also, I usually have thousands of ideas in my head, so even minor things can get lost if I'm not paying attention. One night, after forgetting to ask Gemini to save the changes we had made in the Changelog.txt and update the PLAN.md file, I started a new session to ask if I could create a "macro" where just one phrase would make it execute a series of steps. It automatically added the "That's all, folks!" command to the GEMINI.md file.

Now, I just need to type that, and it does everything for me.

Google Gemini Feedback

Building on top of a language model requires trial and error. And sometimes an error can be fatal.

The Gemini CLI is fast. Testing prompts and streaming responses without a frontend is a massive productivity boost. You can type your prompt and let the AI take care of it while you work on other things, or try to give some attention to your cats.

But Gemini has a distinct reasoning style. It tends to be overly helpful and act without authorization if it feels like it. So, you need to set strict boundaries.

Also, as the session gets longer and the codebase grows, Gemini can hallucinate. Nothing critical, but it might add code that isn't needed or enter a loop if for some reason the build won't finish.

I like to think of the Gemini CLI as a Junior Dev. He can make your life a lot easier. But he can also make your life a nightmare. That depends entirely on how you manage him.

Looking Forward

Having pet projects can be a problem when you still need to work, deal with adult life, and feed two cats. This can be even more problematic for neurodivergent brains like mine, where that cool idea never leaves your mind.

Revisiting these projects in the terminal proved to me that legacy code can be salvaged if you have the right tools to pry it open. Ideas can leave your mind and turn into real applications, even when you don't have enough time or energy.

Right now, I am designing even more features for those two projects, and also using the CLI to work on my new portfolio page. I can think high-level while the CLI does the heavy lifting.

Which means that, someday, my pet projects can actually be turned into real products.

What about yours?

From Frustration to Feature: The Open Source Magic

Paulo Henrique — Tue, 15 Apr 2025 18:01:32 +0000

When was the last time you felt that "How is this not a thing yet?" sensation?

You know, the one where you're looking for a simple solution to a simple problem, but somehow it doesn't exist. This feeling of frustration has been the genesis of countless open source projects, and recently, it reminded me why I fell in love with the open source community in the first place.

It all started with an Install CD (and pain)

./configure
make
make install 
# *stares at cryptic error messages*
# *read the manual*
# *tries again*
# *lots of crying*

My relationship with open source software began back in 1998 with a Conectiva Linux CD and more than a few headaches. Configuring anything in Linux back then was often a nightmare, and even trying to make the monitor and video card work correctly could take hours if you didn't own a more well-known brand. But despite the frustration, I was captivated by the core concept: collaborative creation of software that was open, evolving, and free from corporate control.

This philosophy changed how I viewed software development. It wasn't just about the end product or making BILLIONS of revenue; it was about the collective effort of people solving problems together and ensuring that everyone could enjoy it.

My early contributions were modest. I worked with the KDE team for a while, helping with translations and bug reports. I created layouts and modules for PHP-Nuke. All these experiences helped me in my career, which to this day revolves around WordPress and Linux-based technologies.

But this story isn't about my career path. It's about a recent experience that reminded me why I'm still passionate about free and open source software.

When my personal needs met the community

Earlier this year, I revisited my self-hosted services setup and, along with the usual backups and automations, I wanted to add services that would make my daily life easier. That's when I discovered Actual Budget, a financial manager with a philosophy closely aligned with what I consider ideal for personal finance software.

There was just one tiny problem: the app lacked automation for Brazilian banks. Every month, I had to manually export statements from my bank, then import them into Actual, a manual process like my ancestors did 200 internet-years ago.

"Hold on," I thought, "Brazil has implemented Open Banking standards. How is there automatic integration for U.S. and European Union banks, but nothing for Brazil? Is it because we're poor?"

If this had been proprietary software, my inquiry about integration with Brazilian accounts would likely have been met with a polite "We'll consider it carefully" (which can be translated as "LOL").

But Actual Budget is open source. So I did what open source communities make possible: I went to GitHub, opened an issue, and explained the situation.

The initial response wasn't promising, as there are some limitations to the Open Banking format if you are not a bank or a company. But then something magical happened: other developers and users joined the conversation. They discussed possibilities, explored solutions, and worked toward implementing Brazilian bank support.

And now? The newest version of Actual Budget supports Brazilian banking transactions!

The most remarkable part? To make this happen, I wrote exactly zero lines of code. I paid exactly zero dollars. All I did was raise my hand, participate in testing, and contribute to implementation discussions.

The true Open Source are the friends we make along the way

This is, to me, a perfect example of what makes open source special:

You don't need special credentials to identify problems worth solving.
One person's need often reflects many others' needs, and the community validates what's worth implementing.
People contribute with what they can, whether that's coding, testing, documenting, or simply articulating the problem clearly.
You don't need to be a developer, designer, or "expert" to make meaningful contributions. You just need to be willing to be part of a community.

How to Contribute to Open Source (even when you don't code)

If this story inspires you to get involved with open source, remember: you don't need to be a coding wizard. Here are ways anyone can contribute:

Report bugs clearly and constructively
Suggest features based on real needs you've encountered
Improve documentation to make software more accessible
Participate in testing to ensure quality releases
Engage in discussions on issues and pull requests
Share your use case to help developers understand real-world applications
Translate interfaces or documentation to make software more global
Spread the word about projects you find valuable

Even a small contribution can be important

What I find most profound about the open source model is the impact small contributions can have. My simple feature request didn't just solve my problem: it potentially helped thousands of other Brazilian users who might have otherwise abandoned the software.

This ripple effect is what sustains my belief in the power of open source. Every contribution, no matter how small, has the potential to improve someone's life or work, somewhere in the world.

And the most meaningful shift that comes from participating in open source isn't technical. It's psychological.

You begin to see yourself not just as a consumer of technology, but as a potential creator and contributor.

This shift is powerful. It transforms frustration ("Why doesn't this exist?") into agency ("I can help make this exist"). And ultimately, it makes technology more human, more responsive to real needs, and more accessible to everyone.

So the next time you find yourself thinking "How is this not a thing yet?", remember that in the open source world, you can be the missing key that turns that frustration into a feature that benefits people around the globe.

And you might not even need to write a single line of code to do it.

From Left-Handed to Left Behind

Paulo Henrique — Sun, 06 Apr 2025 15:22:05 +0000

This is a submission for the WeCoded Challenge: Echoes of Experience

I have a confession to make: I'm left-handed.

Not exactly a shocking revelation in 2025, right? But if I had been born just a few decades earlier, my left-handedness would have been treated as something to "fix." Teachers would have tied my left hand down to force me to write with my right. In my country, I would be BEATEN until passing out for just using my left hand. I would have been labeled as deviant, stubborn, or worse.

For those who might not know, being left-handed was once considered an omen, a bad thing. This is shown even in our language: The term “canhoto” in Portuguese probably comes from the vulgar Latin cannus, which meant “twisted” or “crooked”. The idea is that a "canhoto" is someone “crooked”, or outside the norm. In English, "Left" comes from lyft ("weak" or "of no value"). In some places, even a few decades ago, using the left hand for something meant that you were using the "devil's hand".

I'm also neurodivergent, though unfortunately, I didn't learn this until later in life. For decades, I just thought I was "bad" at specific things that seemed to come quickly to others. I developed coping mechanisms and workarounds to function in a world designed for neurotypical people. My late diagnosis explained so much about my life experiences, but it also meant I spent decades masking and adapting rather than being understood and accepted.

I'm the son of a poor blue-collar family. My first computer was a donated MSX. It's where I developed the love for "programming", as in "solving cool problems". But I didn't have the time or money to have official IT education, as I had to come from school and help my father. I learned by trial and error, in my room, at night and on weekends. For years, even after I finished my graduation, I still heard how my "lack of official education" made me worse than others, more privileged people, even when I was able to deliver more than they were.

When I first started working only as a developer instead of a "jack of all trades" in IT, my boss was color blind. It wasn't so bad, he had some problems when red and green were placed next to each other. He was a great guy, and even as I'm more focused on backend, I still remember all the tips I got from him when I'm working on a professional layout today.

The interesting twist in all these histories? These differences and these struggles, the same ones society once tried to "fix" or "belittle", have given me unique perspectives and problem-solving approaches that have defined my career in tech.

As a left-hander, I've always had to figure out how to use tools and systems designed for the right-handed majority. This made me understand how even simple things can be complicated if you are not part of the norm.

As someone with a neurodivergent mind, I process information differently. Patterns that others miss jump out at me. Connections between seemingly unrelated systems become obvious. What some might see as overthinking, I see as thorough analysis. That helped me see opportunities and weaknesses in places no one was able to see.

As a self-learner, I was able to understand technology my way, instead of having to memorize concepts. This made me more aware of the possibilities in IT, as "thinking outside the box" was a natural thing.

When you're forced to adapt to a world not designed for you, you develop a superpower. You learn to see workarounds and alternative solutions that might not be obvious to someone who's never had to adapt.

These aren't weaknesses—they're strengths. They're exactly the kind of diverse thinking that leads to innovation. It's crazy when you think that most of the solutions we have today are based on a white-male-rich-cis-straight-and-neurotypical vision of the world, when so much can be done by looking at the problems with another mindset.

The Paper-Thin Protection

OK, but now let's get all these personal experiences and extrapolate a little:

It wasn't until the 1970s that schools widely stopped forcing left-handed children to write with their right hands. Most workplace accommodations for neurodivergent individuals are still in their infancy, and many companies still view them as optional courtesies rather than necessary accommodations. At least in Brazil, I know lots and lots of companies that do nothing to accommodate people with special needs. Or they comply and work inside the workplace standard, or they are kept unemployed.

One day, in high school, a girl asked me "Why did I choose to be left-handed". I always told this story as a joke, because WTF I WAS BORN THIS WAY, but now I see how it's stupid to ask the same question for an LGBT+ person. They didn't choose, as well as I didn't choose to be "different". I just got lucky that my differences are "passable" today for most of society.

But here's where things get sketchy: the rights that protect me today are as thin as a piece of paper. One politician can just bring back the need for everyone to be right-handed. Or can pass a new law where neurodivergent people can't do some types of jobs. Or society as a whole can decide that you are only able to work in IT if you have a very specific and expensive education.

Diversity of all kinds, whether it's neurological, handedness, race, gender, sexual orientation, or any other form of human variation, is at risk when we see ourselves as "better" than other people. The laws that protect diversity exist because enough people decided they should, and they can disappear just as easily if we stop advocating for them.

Why This Matters for Tech

Cool, but what does all this have to do with technology?

Well, everything.

Our industry has complex problems to solve. We need people who think differently, who see different patterns, who bring different experiences to the table. We need the person who asks, "But what if we approached it this way instead?" We need the team member who says, "This design won't work for people like me, and here's why.", or "the way we are advertising our product can be offensive for some people and we will lose this market."

When we push for diversity in tech, we're building stronger teams that create better solutions for more people. It's not about just checking a box saying "OK, I have a person of color, a trans and an ethnic hire, my company is diverse now."

I really want you to pause a little and think: how many times have you encountered a product or service that clearly wasn't designed with certain users in mind? The facial recognition that doesn't work for darker skin tones. The voice recognition that stumbles over accents. The websites that are impossible to navigate for people with visual impairments. The lousy sound that annoys neuroatypical people.

These aren't just minor oversights, they're failures of imagination and inclusion.

The Business Case (If You Ever Need One)

If the moral argument doesn't convince you, consider the practical one: diverse teams make better products and generate more revenue. That is a fact.

According to McKinsey, companies in the top quartile for racial and ethnic diversity are 35% more likely to have financial returns above their respective national industry medians. Companies with more gender diversity are 15% more likely to outperform their peers.

This isn't charity, political correctness, or "wokeness": it's good business sense. When your team reflects the diversity of your user base, you build products that work better for more people. You identify potential problems earlier. You discover opportunities others might miss.

As a personal comment, with only one exception, I only hired minorities my whole life when I needed someone to help me: people of color, women, LGBT, and a white guy. Ironically, the only one who ended up being a challenge wasn’t from a marginalized group.

It's Personal, But It's Also Universal

It's important to stress a fact: I'm not comparing my struggles in life with the struggles of persecuted minorities. I'm sharing my personal problems and experiences because it's one small window into a universal truth: human diversity is natural and valuable.

My left-handedness and neurodivergence are just two dimensions of human diversity. There are countless others, each bringing their own perspectives and strengths to the table.

When I see pushback against diversity initiatives in tech, I can't help but wonder if the people resisting understand what they're really saying. Do they understand that they can also be part of a struggling community? Do they understand they're arguing against including perspectives that could solve problems they can't even see? Do they realize they're limiting their team's potential by restricting the range of experiences and viewpoints available?

I understand that I, as a "passable" white person and as a cis-straight human, have privileges that most people today can't even dream of. But I also understand that it's easy to lose some of my privileges. So it makes more sense to me to defend everyone's privilege instead of attacking people who want the minimum things I have.

Moving Forward Together

So what can we do, as individuals and as an industry?

Recognize that diversity is a strength, not a checkbox: See different perspectives as valuable assets, not obligations or compliance requirements.
Create truly inclusive environments: It's not enough to hire diverse teams if those team members don't feel safe sharing their unique perspectives.
Listen to learn, not to respond: When someone offers a different perspective, listen with the goal of understanding, not defending the status quo.
Advocate for stronger protections: Remember that the rights protecting diversity are recent and fragile. They need active defenders.
Share your own story: Your experiences matter. They shape how you see the world and solve problems. Don't hide what makes you different—celebrate it.

As for me, I'll keep seeing the world in my slightly different way. I'll keep offering solutions that might not be obvious to others. I'll keep reminding people that what was once considered a deficit—my left-handedness, my neurodivergent mind—has actually been one of my greatest professional assets.

And I'll keep pushing for a tech environment that doesn't just tolerate diversity but actively seeks it out, nurtures it, and recognizes its immense value.

Because, in the end, it doesn't make sense to me that we are just a cog in the capitalist machine. We're on the road to building a better world. One where no one has to hide or "fix" what makes them unique.

What's your story? How has your unique perspective shaped your work in tech? I'd love to hear about it in the comments.