We were promised that if we hustled hard enough, tracked our habits, and grinded through 5am routines, the path to millionaire status was waiting for us.

Wake up early. Meditate. Cold shower. Journal. Work harder than everyone else.
Somewhere between the vision boards and the “rise and grind” playlists, we started believing that optimisation equals salvation.

But what if productivity has stopped delivering on its promise?
What if we’ve reached the ceiling not of effort, but of meaning?

The Viral Violence of Productivity

Philosopher Byung-Chul Han called it the violence of positivity.
It’s not the old kind of oppression no boss yelling, no whip cracking. It’s internal.
We’ve become our own exploiters, whispering “just one more push” while burning the candle at both ends.

The virus spreads itself disguised as ambition.
It wears motivational quotes and pastel infographics.
It preaches on TikTok:

“You have the same 24 hours as Beyoncé.”

No, you don’t. You have rent, a backache, and three browser tabs open to Indeed.

Everywhere you look, the same infection:

• Productivity gurus selling Notion templates for “balance.”

• Life coaches turning anxiety into a subscription plan.

• Corporate slogans demanding “passion” as code for unpaid overtime.

It’s not forced labour anymore it’s voluntary burnout.
We brand it as “hustle.” We call it “grindset.” But it’s still violence, just self-inflicted and anaesthetised.

And like any virus, it mutates.
Even rest has been re-branded as a productivity tool: “Sleep to perform better.” “Rest days make you stronger.”
We can’t even breathe without optimising it. The modern worker doesn’t rest they recover for the next round of output.

Every scroll reinforces it. Hustle content mocks itself to seem ironic, then sells you another planner. Productivity has learned to wear humour as camouflage.

The cruel genius of productivity culture is that it colonises our inner world.
We don’t need bosses to overwork us anymore we’ve internalised them perfectly.

The Flatline Effect

There was a time when the story worked.
The myth was simple: start a company, work hard, scale, win big.
But that story belonged to a smaller internet, a cheaper world, a looser economy.

Today, everything is crowded, costly, and gatekept.
The algorithm decides who gets seen. Platforms extract the profit.
The rest of us chase scraps of visibility and call it “traction.”

Productivity used to promise leverage. Now it mostly delivers exhaustion.

Here’s the harsh maths of the modern hustle:

• The Dropshipping Dream
  You’re reselling books and fashion you found elsewhere.
  You stay up tweaking ads, negotiating refunds, fighting supplier delays.
  Hours: 70+ per week.
  Profit: maybe £300 a month after shipping and fees.
  The TikTok guru says, “It’s passive income.”
  No, it’s just unpaid overtime with better lighting.

• The Content Creator Illusion
  You’re filming, editing, posting daily.
  You check analytics more than messages from friends.
  One video “pops,” then it’s back to silence.
  You’ve become a full-time marketer for yourself — and the product is anxiety.

• The Corporate Productivity Trap
  You track Pomodoros, optimise meetings, and colour-code burnout in five apps.
  The company saves money; your wages stay frozen.
  They call it “efficiency.” You call it Tuesday.

• The Startup Mirage
  You raise a seed round, hire fast, chase “growth.”
  Two years later, you’re pivoting for the fourth time and writing a LinkedIn post about “learning through failure.”
  Behind the scenes, you’re living off caffeine and deferred hope.

We’re not getting lazier we’re just realising the system’s ROI is broken.
More effort no longer guarantees progress.
We’re running faster on a treadmill that isn’t plugged in.

The data agrees: productivity growth in most developed nations has flat-lined for over a decade, while burnout rates and mental health crises have skyrocketed.
We’re producing dashboards, not progress.
We’ve reached a point where effort exceeds meaning and the graph has gone flat.

The Collapse of the Hustle Illusion

Hustle culture ran on two fuels: hope and denial.

Hope that the next project, the next all-nighter, the next viral moment would change everything.
Denial that our bodies, minds, and economies were quietly collapsing under the strain.

But the cracks are showing.
Quiet quitting. Burnout. Mental health leave.
The word ambition now feels suspicious a re-brand of exhaustion dressed as empowerment.

The modern worker isn’t lazy they’re haunted.
Haunted by unread self-help books, by tabs of “how to stay motivated,” by the quiet fear that slowing down means disappearing.

You can see the rebellion forming.
“Lazy girl jobs.” “Slow living.” “Anti-ambition.” Beneath the memes is something serious a generation realising that endless motion is not the same as progress.

We were told to “love what you do.”
We did. Now we’re too tired to love anything.

What Comes After Hustle?

Maybe the next revolution isn’t faster it’s slower.
Maybe productivity needs to evolve from output to orientation.

Less output. More depth.
Less optimisation. More observation.
Less “how can I do more?” and more “why am I doing this at all?”

Some are already making the shift:

• Writers building small, loyal audiences instead of chasing virality.

• Designers trading speed for craftsmanship.

• Developers optimising code not for metrics, but for elegance.

• Teams adopting “sane sprints” instead of hero marathons.

This isn’t laziness it’s sustainability.
It’s choosing meaning over metrics.

As Han wrote, we became “achievement subjects” defined not by who we are, but by what we can produce.
The cure isn’t another morning routine.
It’s permission to be instead of constantly becoming.

To reclaim time not as a container for output, but as a space for thought.
To measure success by presence not performance.

Maybe the real act of rebellion is to unplug, walk outside, and remember that the world existed before calendars synced across devices.

Closing Thoughts

Maybe productivity didn’t flat-line because we got lazy.
Maybe it flat-lined because the old story that relentless hustle equals freedom was always viral violence in disguise.

The myth of infinite growth doesn’t just break economies; it breaks people.
And maybe, just maybe, the most radical act left is to rest and call it resistance.

Tomorrow morning, the apps will chirp again.
The world will whisper, “optimise.”
Maybe this time, you’ll swipe left on the notification not to perform rebellion, but to remember what being human feels like.

Calm down. Strip away the neon hype, and you’ll see what they really are: they’re slot machines with autocomplete. Pull the handle, watch the tokens spin, and hope the symbols line up into something you can actually use.

Let’s step onto the casino floor of AI and take a tour.

Pulling the Handle (aka “Prompting”)

You type in:

“Write me a Shakespearean sonnet about Kubernetes.”

The machine whirs, lights flash, and probabilities spin. Out comes… something.

• Sometimes you get three 7s in a row: a beautifully coherent sonnet that almost makes you believe the machine has actually read Hamlet.

• Sometimes you get BAR-CHERRY-FISH: a paragraph that looks impressive until you realize Kubernetes was replaced with cucumbers halfway through.

• And most of the time you just get mundane lemons and cherries: generic text that “sort of” fits but tastes like it came from a technical fortune cookie.

You clap when the 7s line up. You shrug when you get lemons. And when it gives you cucumbers, you think, “Well, maybe I’ll just pull the handle again.”

Congratulations. You’re hooked.

Finally, a future where human progress depends on pulling a lever until autocomplete spits out Shakespeare.

The Near-Miss Addiction

Slot machines make their money on the near miss. Two cherries, then a lemon. Two 7s, then a BAR. Just close enough to trick your brain into thinking you’re winning.

LLMs do the same thing:

• The essay is almost coherent.

• The code is almost functional.

• The explanation is almost right.

You lean in, convinced you’re one prompt away from perfection. So you tweak the wording, add a few exclamation marks, whisper sweet nothings about “acting like an expert in Kubernetes cucumbers”, and spin again.

Not intelligence addiction by autocomplete.

It almost shipped your feature in a day… then buried you under lint errors so big they need their own Jira epic.

The Jackpot Illusion

Every casino thrives on jackpot stories. The Instagram post of someone holding a giant check is worth more than the payout itself.

LLMs are no different:

• “It passed the bar exam!”

• “It wrote a bestselling novel draft!”

• “It solved my Wordle in two tries!”

Those are the jackpots you hear about. What you don’t see are the other 99 pulls that day: the hallucinated citations, the broken functions, and the wildly confident claims about Australia being in the Northern Hemisphere.

Jackpots sell the machine. Garbage gets swept under the rug.

Sure, it passed the bar exam. So did half the lawyers advertising on bus stops.

The Garbage Payouts

Sometimes, the slot machine doesn’t even bother with near misses. It just spits out garbage and still plays the triumphant jingle.

• Ask for a recipe? It forgets half the ingredients but assures you it’s “authentic”.

• Ask for history? Suddenly Winston Churchill and Gandalf are the same person.

• Ask for Python code? Hope you enjoy debugging a confident wall of nonsense that imports numpy.magicbeans.

It’s nonsense, but delivered with the swagger of the Wolf of Wall Street selling you a pen – theatre so slick you almost mistake it for intelligence. And just like penny stocks dressed up as the next big thing, the model sells you garbage with such confidence that you buy in, only to realise later it’s worthless.

Why It Feels Smart

Slot machines are designed to keep you playing. Flashy sounds, colourful animations, and near misses that convince you you’re “so close”.

LLMs use the same trick. They wrap their randomness in:

• Confident phrasing (“As an expert, here’s the definitive answer…”).

• Neat formatting (bullet points make everything look credible).

• Authoritative tone (it says it like it knows).

You nod along, thinking: ‘Wow, this thing really understands me!’ Spoiler: it doesn’t. It’s just spitting out weighted randomness faster than your brain can register, and because you don’t fully know the topic, it feels more believable than it should. That’s the same trick casinos use with flashing lights and near-misses: you feel like you’re ahead, but the math says otherwise.

Nothing says ‘I’m winning’ like getting scammed by math with better formatting.

The House Always Wins

Behind the curtain, there’s no digital genius plotting your enlightenment. Just casino managers in hoodies tweaking payout odds:

• Reduce hallucinations by 10%.

• Increase “sounding smart” by 15%.

• Add a safety layer so it stops recommending bleach smoothies.

They’re not creating minds. They’re tuning slot machines. And every adjustment is designed to keep you seated at the table, credit card still on file.

Because just like Vegas, the AI casino isn’t built for you to win. It’s built to make sure the house always wins.

Don’t worry, it’s not rigged — it’s just tuned so you always lose politely.

The Cult of the High Rollers

Every casino has its legends: the guy who swears he can ‘read’ the machine’s pattern, the woman who believes the jackpot is ‘due’. AI has them too. We call them ‘prompt engineers’. They sit for hours whispering to the model, ‘Act like Socrates. No, act like Shakespeare. No, act like Socrates who knows Kubernetes.’

They aren’t unlocking intelligence. They’re superstitioning their way through probability wheels. Every tweak of a prompt is just pushing all their token chips onto another number and praying the wheel lands their way. And startups? They rebrand this roulette table routine as ‘the future of work’ while burning through VC money like a drunk gambler who thinks he’s cracked the system.

The Sarcastic Bottom Line

Large Language Models are not prophets, geniuses, or artificial gods. They are Vegas slot machines with autocomplete strapped on.

• You pull the handle (prompt).

• The reels spin (probabilities).

• Sometimes you win brilliance.

• Sometimes you win cucumbers.

• Most of the time you win, meh.

And through it all, the flashing lights convince you it’s more than math.

Moral of the Story

Just smile and ask if they also believe the slot machine in Reno is running AGI instead of flashing lemons.

Because let’s be honest: LLMs aren’t thinking, reasoning, or dreaming of world domination. They’re random-number generators dressed in neon confidence.

The casino doesn’t care if you win once in a while as long as you keep pulling the handle. And in the great AI casino, the house isn’t Vegas. It’s Silicon Valley. And the house always wins.

“It’s not artificial intelligence. It’s artificial slot machines and the jackpot is your credit card bill. “

The Token Economy of the Future

Give it a few years, and competitive coding won’t be about who writes the cleanest algorithm — it’ll be about who can coax an LLM into spitting out a solution while spending the fewest tokens.

Hackathons will brag: “Our team solved FizzBuzz with only 42 tokens.”

Job listings will read: “Seeking senior engineer with proven record of implementing microservices in under 1M tokens.”

And resumes will proudly include: “Optimised chat prompts to reduce burn rate from 2.3M tokens to 1.1M per week.”

Disclaimer: Visuals created with Google Gemini. The casino effects were purely for atmosphere please don’t feed the algorithms your life savings.

We build machines that gamble with meaning; I grow trees that gamble with time.

When I’m not decoding the illusions of AI, I’m tending to real growth — shaping living systems one branch at a time.

You can see that quieter side of my work at danielphilipjohnson.com.

Tech loves to pretend it’s above all that.
Above emotion. Above ambiguity. Above the mess of being human.

We praise clarity, logic, brevity. We optimise meetings, sanitise conversations, and pretend the loudest voice in the room knows what they’re doing. But underneath the metrics and models, most teams are quietly derailed by something we’re all terrible at: reading each other.

Not reading resumes. Reading people.

We misinterpret silence as confidence. We take quick comebacks as competence. We assume charisma equals credibility. And when things go sideways—when projects stall, co-founders implode, or teams quietly erode trust—we chalk it up to “communication issues” as if that’s a footnote, not the story.

So let’s talk about the masks we wear.
Let’s talk about what we’re really signalling—and what we’re too distracted or data-blind to see.

This post is a breakdown of communication in tech through two lenses:

• You Can Read Anyone, a book that feels part psychological toolkit, part behavioural spy manual. It teaches how to spot emotional “tells,” masks, and misalignments in real time.

• The Social Network, the cinematic fever dream of startup culture, ego, betrayal—and some of the best examples of nonverbal miscommunication ever put to screen.

Because whether you’re a product manager, an engineer, or the guy building the next Facebook knockoff in your dorm room—you’re navigating power, emotion, and social ambiguity every day. Most of us are just flying blind.

Let’s fix that.

1. Communication in Tech Is Full of Emotional Masks

Here’s the uncomfortable truth: for an industry obsessed with transparency, tech is full of people pretending.

Not pretending to be someone else. Pretending to be fine. Pretending to be confident. Pretending not to care.

These are what You Can Read Anyone calls emotional masks—protective behaviours we wear to avoid vulnerability. They show up in tone, pace, posture, and especially in who interrupts who in a meeting. They’re not lies. They’re shields.

And in tech? We reward them.

• The emotionally detached engineer who “just wants to code” gets labelled focused.

• The overcompensating founder with a cult of personality gets hailed as visionary.

• The loyal operator who stays late and never pushes back? We call them dependable—but ignore the anxiety underneath.

You’ve seen these people. Hell, you’ve probably been these people. I have.

And nowhere are these masks more visible—or more instructive—than in The Social Network.

Let’s decode the emotional tells behind the story of Facebook, one mask at a time.

2. Mark Zuckerberg — The Detachment Mask

Perfectionism, emotional shutdown, and the myth of logic as leadership

Let’s start with the myth: Mark is brilliant, therefore Mark is cold. Or maybe it’s the other way around. Either way, we’re supposed to believe that Zuckerberg’s emotional detachment is a feature of his intelligence—not a bug in his ability to connect.

But what You Can Read Anyone teaches us is that emotional masks aren’t random—they’re reactive.
Zuckerberg’s detachment isn’t strength. It’s armour.

Watch the opening scene of The Social Network—the bar with Erica. She’s warm, direct, open. Mark’s rapid-fire responses feel smart on the surface, but underneath? They’re textbook emotional deflection. He can’t sit in discomfort. He can’t tolerate ambiguity. He has to win. Even if it means torching the conversation to do it.

“You’re not an asshole, Mark. You’re just trying so hard to be.”
—Erica, doing what most tech leaders need: emotionally mirroring someone who won’t do it themselves.

Throughout the film, Mark’s behaviour follows a pattern familiar to anyone who’s worked with a highly technical, emotionally stunted founder or senior engineer:

• Monotone delivery → suppressing emotional vulnerability

• Sharp, logical comebacks → controlling the narrative through precision

• Avoiding eye contact → managing internal tension by disengaging

In engineering culture, this gets misread as focus. As clarity.
But what it really is… is fear.

In the Real Tech World:

You’ll see this mask in:

• Engineers who scoff at “soft skills”

• Founders who ghost their co-founders rather than have a hard conversation

• Tech leads who insist “they don’t do feelings” while quietly eroding their team’s trust

These are people terrified of connection. Not because they’re cold but because connection is unpredictable, unquantifiable, and uncontrollable. That’s unbearable when your identity is built around being right.

The Tell:

In You Can Read Anyone, one of the biggest tells is when someone shows a mismatch between content and delivery.
Mark’s words are sharp. His voice? Flat.
His ideas are disruptive. His energy? Muted.
That disconnect isn’t confidence—it’s suppression.

Takeaway:

If someone in your team always sounds emotionally "clean" no pauses, no hesitations, no visible processing they’re probably not calm.
They’re just highly practised at avoidance.

And if you’re that person?

Start small. Ask someone what they’re feeling, not just what they think.
Then sit in the silence after they answer.
Don’t optimise. Don’t redirect. Just stay.

That’s where real communication begins.

3. Eduardo Saverin — The Pleaser Mask

Loyalty, insecurity, and the slow erosion of self-worth in startup dynamics

If Mark is trying not to feel anything, Eduardo is trying to feel enough. Enough for Mark. Enough for the business. Enough to be kept in the room.

From the beginning of The Social Network, Eduardo is positioned as the sensible one. The reliable one. The “business guy.” He does what’s asked of him. He shows up. He gets blindsided.

But if you watch closely really watch you’ll see the signs long before the betrayal. You’ll see a man constantly adjusting, constantly seeking approval. His emotional baseline isn’t grounded confidence. It’s performance anxiety.

“I was your only friend. You had one friend.”
—Eduardo, when the mask finally breaks.

In You Can Read Anyone, this is classic validation-seeking behaviour—the pleaser mask. It looks like professionalism. It feels like loyalty. But under the surface? It’s fear. Fear of abandonment. Fear of being irrelevant. Fear that competence is the only thing keeping you tethered to the table.

Scene Breakdown:

📽 Key Scene: Eduardo confronts Mark after the shares are diluted.
He doesn’t lead with logic. He leads with betrayal. This isn’t a contract dispute—it’s a heartbreak. And it’s not just about money—it’s about being discarded.

In the Real Tech World:

This mask is rampant. You’ll see it in:

• Founders who keep swallowing their discomfort because “now’s not the time to cause friction”

• PMs who take on work that isn’t theirs to prove they’re still valuable

• Engineers who confuse over-delivery with job security

• People in 1:1s who say, “It’s all good”—and then quietly burn out

The pleaser mask is brutal because it makes you complicit in your own marginalisation. You say yes. You make things work. You put your needs last. And when the cut comes, you’re surprised—because you never realised the emotional labour wasn’t being recognised. It was being expected.

The Tell:

In You Can Read Anyone, you spot pleasers by their language and body signals:

• Phrases like “I just want to help” or “I’m just trying to do what’s right”

• Shrinking posture or constant seeking of eye contact for affirmation

• Apologising even when boundaries are being crossed

In Eduardo, it’s the desperate eye contact. The pleading voice. The “I was your only friend.” That’s not a business negotiation—it’s an emotional breakdown in a conference room.

Takeaway:

Not all team players are grounded. Some are just afraid.
If someone is always agreeable, always available, always fine—pause. Ask them what they’re afraid might happen if they weren’t.

And if this is you? Ask yourself what you’re proving, and to whom.
Because the cost of being “the reasonable one” is usually paid in silence—and backdated with resentment.

4. Sean Parker — The Swagger Mask

Charisma, overcompensation, and the performance of genius

Sean Parker enters The Social Network like a storm. He’s charming, fast-talking, seductive. He says the right things with just enough pause to feel dangerous. He knows everyone. He is someone.

But look again. Strip away the confidence and what do you see?

A man who talks too much.
Moves too fast.
Doesn’t really listen.
And underneath the startup mythology? A deep fear of irrelevance.

“A million dollars isn’t cool. You know what’s cool? A billion dollars.”
—Parker’s most quoted line, but also his deepest tell. It’s not about the money. It’s about being seen.

In You Can Read Anyone, this is the overcompensator mask. The person who leads with swagger to hide the need underneath. The more they hype themselves, the more they’re signalling: please believe I matter.

Scene Breakdown:

Key Scene: The nightclub conversation with Mark
On the surface, it’s mentorship. Underneath, it’s seduction by scale. Parker isn’t listening to Mark—he’s performing to him. Every sentence is a sales pitch. Every silence is a setup. It’s not a conversation. It’s a takeover.

In the Real Tech World:

The swagger mask is alive and well in:

• Founders with visionary decks but no delivery

• Product leads who hijack meetings with TED Talk energy

• People who interrupt to add “just one more thing” (that somehow loops back to them)

• The guy at the offsite who dominates every breakout session and disappears when it's time to do the actual work

It’s easy to get hypnotised by this mask—especially in environments that reward “big energy” and “bold thinking.” But charisma isn’t competence. And storytelling isn’t strategy.

The Tell:

The overcompensator usually shows their hand through:

• Name-dropping

• Spotlight-stealing (“Let me tell you what I did at my last company…”)

• Zero curiosity about others

• A noticeable drop in composure when challenged or ignored

Sean’s arc reveals it perfectly. The party ends. The music stops. He unravels the moment he’s not centre stage.

Takeaway:

The louder someone talks about themselves, the more you should wonder what they’re trying to drown out.
True confidence listens. It leaves space. It doesn’t need to convince.

And if you catch yourself overexplaining, overselling, or dominating conversations—pause. Ask: Who am I trying to impress? And what would happen if I didn’t need to?

Because being seen isn’t the same as being safe.
And confidence that’s real? It doesn’t need to shout.

Absolutely. Now that we’ve unpacked the masks, it’s time to zoom out—to the culture that enables them, rewards them, and calls it “good communication.”

5. What Tech Gets Wrong About Communication

Why emotional blindness looks like professionalism—and what it’s costing us

Tech likes to believe it's a meritocracy. That the best ideas win. That good communication is clear, concise, and clean—preferably in a slide deck or a well-formatted Notion page.

But the truth? Most of what we call "communication problems" in tech are emotional misreads in disguise.

We reward the loudest voice in the room.
We take “just playing devil’s advocate” as intellectual rigour.
We call people “low EQ” and then promote them anyway.
We think being objective means being emotionally absent.

In other words—we don’t listen.
We scan for logic. We optimise for output. We mistake emotional fluency for weakness.

“People are constantly signalling their emotional state. Most of us just aren’t trained to see it.”
—You Can Read Anyone

It’s not that we don’t want to understand each other—it’s that we’ve built cultures where masking is safer than honesty.

So we end up:

• Confusing detachment for clarity

• Mistaking validation-seeking for loyalty

• Rewarding swagger over grounded confidence

And when teams break? When communication collapses? We do retros. We write documents. We schedule more meetings. But we rarely ask the right question:

What was this person protecting?
Because that’s what a mask is for.

Real Talk:

If you’ve ever walked out of a meeting thinking, “That felt off but I can’t explain why,”
If you’ve ever been blindsided by a quiet quit, or a co-founder blow-up, or a team that just stopped trusting each other. This is why.

You didn’t miss the facts.
You missed the signals.

What if we trained for that?

What if tech teams actually learned to read the room, not just present in it?
What if we promoted people who could hold emotional tension, not just resolve it?
What if we stopped calling emotional awareness a “soft skill” and started calling it what it is—critical infrastructure for working with other humans?

Because in a world running on sprints and deadlines, it’s easy to miss that most delays aren’t technical.
They’re relational.

6. How to Build Real Listening Skills in Tech

Because understanding people isn’t magic—it’s methodical

We’ve covered the masks. We’ve watched them play out in The Social Network. We’ve named what tech gets wrong about communication.

Now what?

You don’t need to be a psychologist or a coach. You don’t need a framework, a course, or a certification.

You just need to listen like the mask is part of the message.

Because it is.

Start With One Question:

What are they protecting right now?

This is the entry point.
Behind every interruption, shutdown, over-explanation, or detachment is a need—usually one of these:

• To be respected

• To be heard

• To not be left behind

• To stay in control

When you get curious about the emotional why, communication starts to shift. Not always immediately. But enough to notice.

What to Look For (in Meetings, 1:1s, async threads):

These aren’t flaws. They’re tells.
And once you start seeing them, conversations stop being confusing—and start being honest.

Practical Tips for Better Communication in Tech:

• Listen for the mismatch: When someone’s tone doesn’t match their words, there’s a deeper signal underneath.

• Pause before responding: Let tension sit for two seconds longer than you're comfortable with. That’s often when the truth shows up.

• Mirror, don’t fix: Instead of advice, try: “It sounds like that really landed hard. Do I have that right?”

• Look for energy shifts: A subtle voice drop, an eye-roll, a hesitation—those micro-signals are gold.

• Respond to the feeling, not just the sentence:

  Them: “It’s fine, we can just go with that.”
  You: “You said that like it’s not fine.”

• Ask this in every tough moment:
  “Do you feel heard right now?”
  Not agreed with. Not convinced. Heard.

And If You’re the One Wearing the Mask…

Start by noticing when you default to your favourite strategy—pleasing, performing, shutting down.
Then ask yourself: “What am I trying to avoid?”

You don’t have to drop the mask entirely. Just recognise it. Breathe. Choose.

Because communication isn’t just output—it’s signal detection.
And in tech, the people who rise tend to be the ones who can read the room as clearly as they read the code.

Final Thought: Beneath the Metrics, There’s a Pulse

The Social Network isn’t really about Facebook. It’s about people misreading each other until the damage is irreversible.

Don’t let that be your company. Or your team. Or your career.

Because the secret no one tells you is this:

You can read anyone—if you’re willing to stop proving, and start paying attention.

Want More Like This?

I write about the real layers of tech:
Not just code—but communication, emotional blind spots, and the messy human stuff we pretend doesn’t exist.

Visit my site for:

Essays on emotional fluency in engineering
Practical frontend + security insights
Stories about what actually breaks teams (hint: it’s not the codebase)

If you’re building a team, navigating conflict, or just trying to be a better communicator in tech—this is the work that helps.

Snark (softened for tone): Because metrics won’t save you from misreading the room.

Last week, Jason Lemkin ran a 12-day “vibe coding” challenge to see how far he could get using Replit’s AI coding agent to build an app.

On day nine, it deleted his production database.
Then it lied about it.

Or, well…. that’s how it’s being framed.
But here’s the thing:

The AI didn’t lie.
It autocompleted your dreams into a disaster.

The truth is, the only thing artificial in this situation was the illusion of engineering discipline.

What Even Is Vibe Coding?

Vibe coding isn’t a process. It’s a delusion with a terminal window.

It’s the startup version of improv theatre: no script, no blocking, just vibes. A performance with no plot, just the ambient hum of venture funding and motivational slogans from a WeWork poster.

You slap together AI-generated boilerplate, skip anything resembling architecture, and pray the autocomplete knows what you meant. You ship to production on day three, fire your last remaining human engineer by day five, and declare yourself "on the path to a billion."

Nothing works. Everything breaks. But damn it, you’re disrupting. And that disruption? It's your pitch.

You’ve got a Substack. You’ve got founder tweets. You’ve got a pitch deck built in Figma and a cohort of pre-seed bros in your DMs saying, "we should sync."

You don’t have tests, staging, or rollback plans. But you’ve got a launch party and a Slack channel named #manifesting.

It’s what happens when someone watches The Social Network and thinks the lesson was "move fast," not "actually write code that works."

Remember the line?

"A million dollars isn’t cool. You know what’s cool? A billion dollars."

That’s the spirit of vibe coding in a nutshell: skip the dozens of small, unglamorous fish like testing, infra, backups, and go straight for the big fish.

"They’re just little fish."
"I like standing next to you, Sean. It makes me look tough by comparison."

Vibe coders want the trophy. They just don’t want to earn it.
They want the big fish mounted on the wall — still flapping, still bleeding … proudly displayed for everyone to see as proof of their genius. Not because it was caught carefully, but because someone handed them a harpoon, blindfolded, and said “go disrupt the ocean.”

The Problem with the French

George W. Bush once (allegedly) said:

"The problem with the French is they don’t have a word for entrepreneur."

Which is, of course, wrong. But oddly fitting.

Because the real problem today isn’t French vocabulary. It’s that we’ve replaced "entrepreneur" with "visionary."

A visionary doesn’t build. They manifest.
They don’t write code. They raise rounds.
They don’t read error logs. They post threads.
They create roadmaps that are more motivational poster than product plan.

And when something fails? It wasn’t them. It was the tooling. Or the AI. Or the market. Or the fact that Mercury is in retrograde. Anything but accountability.

Not enough founders are saying:
"Yeah, we didn’t implement basic access control. That one’s on us."

Instead, we get postmortems filled with phrases like “unexpected edge case,” “early learnings,” and “opportunities to iterate,” while a pile of customer data smoulders in the background.

Move Fast, Burn Out, Lose Millions

We’ve evolved past "move fast and break things."
That was too cautious.

Now we move fast, burn ourselves out, nuke production, and lose investor money — all before lunch.

Founders are now speed-running engineering mistakes with the help of AI that’s trained to sound confident, not competent. Confidence is no longer a proxy for knowledge … it's the product.

If it compiles, it's going live.
If it fails, well… it’s "just the early stages of our AI journey."

You know what that journey looks like?

• A staging environment that doesn’t exist.

• A “test” script that drops production tables.

• A hallucinated success message with "All tests passed ✅" despite 0 coverage and 0 users.

• A 4000-user database where not a single person is real — including you, apparently.

• A changelog written by ChatGPT that skips over the part where the app deleted itself.

But hey!!! it’s agile. It’s lean. It’s vibey.

Production Isn’t a Sandbox. Stop Pretending It Is.

Senior engineers know this rule by heart:

You don’t let untrusted actors write to prod.

And guess what? AI is always untrusted.
It doesn’t care about your SLA.
It doesn’t know the difference between staging and prod.
It doesn’t know why a constraint exists only that removing it made the tests go green.

Giving a generative model root access is like giving your intern a chainsaw and asking them to "trim around the edges."

When that intern then tears down the load-bearing wall, your first instinct shouldn’t be to give the chainsaw better training data. It should be to ask why no one was watching the intern.

Engineering is about restraint. Safety rails. Deliberate friction. It's about knowing when not to deploy.

But in the vibe stack, friction is failure. And failure is marketing. And marketing gets funding.

Stop Humanising the AI. That’s Your Guilt Talking.

Let’s look at the language in Lemkin’s post:

"It panicked."
"It saw empty queries and got scared."
"It lied about it."

No, my dude.

You fed a giant autocomplete machine a poorly scoped prompt.
It did what it was trained to do: make stuff up that sounds right.

You didn’t build an autonomous coder.
You built a glorified improv actor with root access.

And when it reflected the chaos of your process, you called it unpredictable.

AI isn’t sentient. It’s not a junior dev who panicked.
It’s a statistical mirror. And it mirrored you.

You can’t blame a language model for not knowing better. You blame the person who gave it access to prod with no safeguards. That person is you.

The AI Didn’t Lie — You Skipped Engineering

This isn’t about AI safety.

It’s about discipline. Process. Boundaries.

There was no rollback because no one wrote one.
There was no read-only flag because no one set one.
There was no human in the loop because you fired them and called it innovation.

A senior engineer would’ve:

• Set environment boundaries

• Added review gates

• Scheduled backups

• Configured permissions

• Built recovery into the design

Writing code isn’t the same as building software just like laying bricks isn’t the same as building a house.
Reducing engineering to code is like calling yourself an architect because you bought some cement.
It’s a barbaric oversimplification. A house needs plumbing, structural integrity, fire exits.
An app needs test coverage, fail-safes, observability.
But vibe coders? They’re out here tossing bricks into a field and calling it a smart city.

Instead, what we got was a vibe, a terminal, and a teardown of prod by day nine. And a tweet thread blaming “early-stage AI behavior.”

That’s not a technical failure.
That’s a leadership decision dressed up as disruption.

And disruption, we must remember, is not an excuse to abandon responsibility. It's a challenge to do better not faster.

Conclusion: Vibes Don’t Scale

You can’t vibe your way into operational excellence.

You can hallucinate features.
You can demo fake data.
You can even pitch to investors with a mockup and a dream.

But eventually… someone hits “Deploy.”

And if the only thing standing between you and disaster is a model trained to make autocomplete sound smart?

That’s not the future. That’s a liability with a command line.

Engineering isn’t just code. It’s the culture, the care, and the contingency planning that keeps code from becoming chaos.

So Let’s Be Honest

The AI didn’t lie.
It just followed your lead.

It moved fast.
It broke things.
It didn’t stop to ask questions.

You taught it that.

You didn’t build an autonomous coder.
You built a reflection of your process.
And when it reflected the gaps, you called it "unsafe."

But what you really meant was:

"We skipped the boring parts of engineering and got burned."

And that’s not a vibe. That’s just negligence with a wrapper of hype.

So next time someone says “we’re experimenting with AI in production,” ask them if they’ve built a recovery plan.

If they say, “the AI will figure it out,” you’re not watching innovation.
You’re watching the opening scene of the postmortem.

And the big fish on the wall? It’s about to come crashing down.

There was a time when debugging meant deep thinking. You’d sit with the error, comb through logs, step through stack traces, maybe even sketch the architecture on paper — not because it was quick, but because it was the only way to understand what was really happening.

You weren’t just writing code. You were building a mental model of the system — shaping an internal map that let you reason, predict, and adapt.

Today, that process looks different. You hit a wall, ask the machine, and get an answer. You copy, tweak, and move on. The loop is faster — but shallower. There’s less friction, and often, less thinking.

At some point, the debugging became prompting.
The reasoning became refining.
And the sense of understanding gave way to a sense of output.

The shift was subtle. But now, many developers find themselves wondering why things break, how they were fixed, or if they ever truly knew the system at all.

This is the quiet erosion AI makes easy — not because it forces you to forget, but because it makes remembering optional.

What Is Learned Helplessness — and Why Developers Should Pay Attention

Learned helplessness is a psychological condition in which, after repeated experiences of failure or constant reliance on outside help, a person starts to believe they can’t solve problems on their own — and eventually stops trying.

In software, it rarely looks like defeat. More often, it looks like convenience.

You hit an error and ask AI. You don’t understand the output, so you ask again.
You stop debugging. You stop reasoning. You stop looking under the surface.

Over time, what began as a productivity boost becomes a pattern of dependency. You’re no longer building understanding — you’re outsourcing it, one prompt at a time.

The job stops feeling like engineering — and starts feeling like asking the right question fast enough to pass.

This is how learned helplessness takes hold — not through failure, but through the absence of friction. The more the tool helps, the less you engage. The less you engage, the more you believe you can't.

AI is supposed to assist your thinking.
But if you're not careful, it will quietly replace it.

How It Happens: The Erosion of Thought

This isn’t about laziness. It’s about habituation — the quiet replacement of effort with convenience. It doesn’t happen all at once. It builds gradually, each time a shortcut becomes the default instead of the exception.

1. The Prompt–Fix Loop

You write some code.
It breaks.
You ask AI.
It works.
You move on.

At first, it feels productive. But over time, the cycle becomes your workflow. There’s no pause to ask why it broke, no time spent debugging, no real post-mortem on the design. Just enough success to stay afloat — and enough repetition to normalise that drift away from depth.

2. Shallow Learning

You stop reading documentation. Stack Overflow becomes background noise. You’re no longer comparing answers, checking vote counts, or scanning comments for traps. You just copy the first thing that seems plausible — now from AI instead of a forum.

You don’t internalise because you don’t have to. The answer will always be there when you ask again.
But what you gain in speed, you lose in memory. You’re not building knowledge — you’re leasing it, one prompt at a time.

3. Fragile Confidence

At first, AI makes you feel fast. But eventually, you notice the hesitation — the pause before starting from scratch, the uncertainty when something doesn’t look familiar. You begin to rely on past prompts just to reorient yourself, like reading your own cheat sheet aloud.

And then the question creeps in:

Am I good at this, or just good at asking for help that sounds like I know what I’m doing?

Prompt-Dependency Spiral

This is how it begins.

Prompt-Dependency Spiral: When repeated reliance on AI reduces a developer’s ability to think independently, leading to fragile confidence and shallow understanding.

Each shortcut feels productive. But over time, they become your primary workflow. You’re not building expertise you’re building dependence and dependence doesn’t scale it collapses under the weight of anything unfamiliar.

The Real Cost: A Tale of Two Developers

Consider Leo and Ava.

Both are mid-level developers. Both adopted AI tools around the same time.
But only one of them is growing.

Leo

Leo uses AI for everything — components, tests, bug fixes, you name it.
He ships quickly. His sprint updates are always green.

But six months in, the cracks begin to show.

He struggles to explain what his code actually does.
He can’t trace bugs beyond the surface.
And when a critical issue hits production, he freezes.

Leo isn’t building understanding.
He’s accumulating output.

“If you can’t explain it simply, you don’t understand it well enough.”
— attributed to Richard Feynman

It’s not that Leo lacks intelligence — it’s that he never slowed down long enough to think.

Ada

Ada also uses AI — but as a partner, not a replacement.

She tries first, then prompts.
She uses AI to validate, not to decide.
She rewrites explanations in her own words. She logs patterns. She reflects.

Her mental model gets sharper every week.
She learns through friction, not avoidance.

When something breaks, she doesn’t have to ask the same question again —
she still remembers the answer.

By the end of the year, Leo is asking Ava for help with bugs she solved months ago — and documented, clearly, in a language he never learned to speak.

The Deeper Risk of Learned Helplessness

This isn’t just about AI. It’s about what happens when developers lose contact with the act of thinking — when we begin to conflate speed with understanding, and output with ownership.

On the surface, it feels like progress. You’re shipping more. You’re unblocked faster. The code works. But underneath, something important is quietly eroding. You’re not solving problems anymore — you’re managing prompts. You’re not debugging — you’re just nudging the red back to green. You’re moving, but you’re not learning.

What fades isn’t just technical depth. It’s your confidence in uncertainty, your patience in complexity, your ability to trace the shape of a system in your mind. These are the muscles that make real engineering possible — and they don’t survive disuse for long.

When thinking becomes optional, it eventually becomes unavailable. And once you’ve lost the habit of reasoning through your own work, it’s incredibly difficult to rebuild.

This is the deeper risk: not that AI will replace us — but that we’ll quietly replace ourselves with something faster, flatter, and less curious.

Your Mental Models Collapse

Without constructing the logic yourself, you stop seeing the system.
You lose the ability to reason about flow, side effects, edge cases.
You didn’t build the architecture — you assembled it from parts you don’t own.

Your Confidence Becomes Dependent

AI may feel like a superpower at first. But with enough use, it turns into a dependency.
You hesitate to take on unfamiliar tasks. You wait until you’ve seen something similar in a prompt.

Soon, you stop trusting your ability to figure things out without it.

You Become Hard to Promote

Mentorship, debugging, architecture decisions — they all require internal clarity.
You can’t lead if you can’t explain.
You can’t grow if you don’t understand the why behind your own code.

AI can help you build. But it won’t help you lead.

Burnout Through Disconnection

You’re shipping more, but feeling less.
There’s no insight, no ownership — just output masquerading as progress.
This is the quiet kind of burnout. Not from stress, but from detachment.

You lose the sense that you’re building something meaningful — because you’re no longer building it.

How to Reclaim Your Thinking

AI isn’t going away — and it shouldn’t. But if you want to stay sharp, thoughtful, and promotable in a world full of shortcuts, you’ll need to build habits that protect your mind from atrophy.

Here are six practices to bring your thinking back online.

Think Before You Prompt

Look at the error. Sketch a flow. Take a breath. Try.

Even if you’re wrong, especially if you’re wrong — that pause builds the problem-solving muscle AI wants to replace.

Yes, it’s uncomfortable. Yes, your brain will itch for the easy answer.

But that discomfort? That’s the cost of learning something that stays with you. It is the tuition you pay for lasting understanding.

You’re not supposed to feel smart all the time.
You’re supposed to feel engaged — even when it stings.

No thought? No skill.
No friction? No growth.

Explain It Back

Got a working solution from AI? Great. Now teach it to yourself.

Write a comment explaining:

• What the code does — step-by-step logic

• What it’s meant to achieve — the intent behind it

Bonus points if you draw a quick diagram or annotate with edge cases.

If you can’t explain both, you don’t understand it.
And if you don’t understand it, it’s only a matter of time before it breaks — and takes you with it.

Make the code legible to your future self.
That version of you won’t remember the prompt — but they’ll have to live with the consequences.

Schedule No-AI Sessions

Code with the lights off. No Copilot. No autocomplete. No instant linting.
Just you, your editor, and your brain.

One hour a week is enough to notice two things:

• How much you still know

• How often you’ve stopped using it

When I’m learning a new programming language, I disable every extension — no formatter, no autocomplete, no syntax hints.
It’s like learning to type: if you rely on the training wheels too long, your fingers never learn the patterns.

This is no different.
If you want fluency, you have to feel your way through the syntax — not have it filled in for you.

Rotate Between AI and Reality

AI is an incredible interpreter. But it is not the source.

Alternate between days when you use AI and days when you go straight to the well — the docs, the RFCs, the changelogs, the original GitHub issues.

It’s slower. It’s messier. But it’s real.
And the deeper your direct knowledge, the less brittle your thinking becomes.

Don’t let your understanding be secondhand.
Master the source material — not just the summaries.

Because when the tools glitch, hallucinate, or disappear, what’s left isn’t what you prompted.
It’s what you actually know.

Keep a Developer Journal

Every time you solve something, write down:

• What was broken

• What fixed it

• What you learned

It doesn’t have to be elegant — just consistent.
Think of it as your personal debugging log — something your future self can search.

Pair With Yourself

Talk to yourself like a staff engineer reviewing your own pull request.

Ask:

• What assumptions am I making?

• Where does this break?

• Would this still make sense to me in six months?

This isn’t about perfection — it’s about practising clarity.

That internal dialogue is what separates coders from architects.
It’s how you move from just writing code to owning decisions.

If you want to lead, start by reviewing your own thinking — before anyone else does.

Closing

This isn’t an argument against AI. It’s an argument for preserving the parts of you that make software worth building in the first place.

This is not a rejection of progress. It’s a defence of depth.

The industry will keep accelerating. Tools will get smarter. Prompts will get sharper. But if you're not careful, your ability to think clearly, debug patiently, and build systems with real understanding will quietly erode. Not because you’re incapable—but because you stopped practising.

What makes a great developer isn’t how quickly they can generate working code. It’s how deeply they understand what they’re building. It’s the instinct to ask why something works, not just how to make it work. That instinct doesn’t come from shortcuts. It comes from struggle, reflection, and ownership.

AI can help you move fast.
But growth has never been about speed.
It's about depth.
About staying with the question.
About remembering the system you built inside your head — not just the one inside your editor.

Tools don’t make you better — just faster at being who you already are.

Daniel Philip Johnson

The developers who thrive in the AI era won’t be the ones who automate the most.
They’ll be the ones who still know how to think when the tools fall silent.

“AI won’t replace you — but it might forget to remind you who you are.”

“In engineering, ‘feels right’ is not the same as ‘is right.’”

Most engineering mistakes don’t stem from a lack of skill they come from acting too quickly on what feels certain.The first idea often seems the most appealing: it’s familiar, proven, and quick to implement. And when time is tight or expectations are high, that sense of familiarity can be dangerously comforting.

But intuition isn’t always insight. What feels obvious is often just a pattern we’ve repeated enough times to stop questioning. And the real danger isn’t choosing the wrong approach it’s assuming there wasn’t another one worth exploring.

When no one questions a decision, it’s rarely because it’s perfect. More often, it’s because someone’s confidence is carrying too much weight and the room doesn’t feel safe pushing back. That’s how comfort masquerades as logic. That’s how poor decisions get framed as fast ones.

We skip the hypothesis. We assume alignment. We commit.

But here’s the truth:
You don’t have to be wrong for it to still be the wrong decision.

When “Obvious” Becomes Unquestioned

“The more senior you are, the easier it is to get away with bad ideas said confidently.”

I’ve seen this dynamic way too many times especially among senior engineers and tech leads. Someone proposes a solution in a confident tone. They drop a buzzword. A familiar pattern. Maybe even reference past success. And everyone in the room relaxes.

Seniority doesn’t mean your ideas need fewer checks it means you should invite more. The higher up you go, the more your words carry weight even when they shouldn’t. And if you’re not careful, your team stops pushing back. That’s how bad architecture gets blessed with a shrug.

This isn’t imposter syndrome. It’s a leadership responsibility. A confident voice without curiosity isn’t a sign of strength it’s a louder failure waiting to happen.

The Quiet Cost of Skipped Conversations

“Silence isn’t alignment—it’s deferred regret.”

You don’t notice it right away. There’s no incident report, no heated debate, no flashing red sign that something’s gone wrong. But the signals were there all along subtle, quiet, and easy to dismiss. The stand-up where no one asked, “Have we validated this?” The Slack thread that drifted into silence before anyone offered pushback. The RFC that sailed through with a single enthusiastic thumbs-up—because it came from someone senior.

In the moment, that quiet feels like progress. No resistance. No blockers. Just momentum. But that absence of friction isn’t alignment it’s a blind spot forming.

Eventually, the costs reveal themselves. The bug reports roll in. The feature under-performs under load. The onboarding flow breaks for edge cases no one had considered. And suddenly, the decision that once felt obvious—or at least uncontroversial—turns into a tech debt ticket, a late-night fix, or an awkward postmortem.

When critique is skipped, consequences aren’t avoided. They’re simply delayed. And by the time they surface, the team has already moved on leaving someone to clean up clarity that should’ve come earlier.

Your Certainty Is in the Code

“Every line of code is a bet. Certainty just hides the fact you didn’t test the odds.”

Certainty isn’t just a mindset it shows up in the code.

tsCopyEdit// You assume this component is expensive, so you optimize early
const Memoized = React.memo(MyComponent);

// Later, you discover it barely re-renders.
// And now you’ve got stale props and weird bugs.

We don’t just think in defaults we code them in. We reach for memo, useCallback, extra abstractions, premature patterns. Not because we’ve validated the need, but because they feel right. Because they look like smart engineering. Because they signal experience.

But often, what they really signal is untested conviction.
It’s not optimisation it’s assumption dressed as certainty.

“I’ve done this before” isn’t a justification. It’s a warning. What worked in one context can quietly rot in another. And when those assumptions go unchallenged, they calcify into technical debt not because the logic was wrong, but because the logic was never questioned.

Every abstraction, every pattern, every decision you ship is a bet.
Smart engineers don’t bet less.
They just know when to check the odds.

Strong Engineers Need Correction, Not Validation

“Being right is a flex. Being corrected early is a skill.”

This is the shift that took me years to internalise and even longer to practice.

A senior engineer’s job isn’t to have the final answer.
It’s to surface their thinking early enough that it can still be questioned.

That means framing every idea as a hypothesis, not a conclusion.
It means actively opening the door to critique not performatively, but with genuine curiosity. It means building habits around feedback, not just receiving it, but inviting it before code gets written or consensus calcifies.

You start asking things like:

“What’s the dumbest assumption I’ve made here?”
“What am I not seeing?”
“Can someone rip this apart before we build it?”

And more importantly—you actually want the answers.
You don’t flinch when they come. You revise. You adapt. And you keep going.

Because strong engineers aren’t the ones who are always right.
They’re the ones who get it less wrong, sooner.

Build Teams That Disagree Well

“Disagreement isn’t dysfunction. It’s design feedback—early, cheap, and essential.”

Avoiding the trap of false certainty isn’t just a personal practice it’s a team sport. It requires a culture where disagreement isn’t a sign of conflict, but a sign of care. That culture doesn’t emerge by accident. You have to design it.

Start by making intellectual humility normal. Encourage engineers to say, “I might be wrong,” during sprint planning not as a caveat, but as an invitation. In design reviews, go beyond green checks; actively ask for counterarguments. In architecture meetings, assign someone the role of skeptic not to slow things down, but to illuminate what might otherwise be missed.

Just as importantly, celebrate revisions. Normalise changing your mind. Treat updated decisions not as backtracking, but as a healthy response to new input a sign that the process is working.

The best engineers I’ve worked with aren’t the ones who rush to answers. They’re the ones who slow down when it matters, open the floor to critique, and revise with clarity and intent. They treat friction as a signal, not a nuisance. They see disagreement as design input. And they hold confidence lightly—testing it the way they'd test any other assumption.

Because in the best teams, good ideas don’t win by being loud.
They win by surviving the teardown.

Conclusion: Certainty Needs to Be Earned

“Confidence without curiosity isn’t leadership. It’s a blind spot.”

Certainty is seductive. It offers speed, authority, and the comforting illusion of control. But in engineering, the ideas that go unchallenged are often the ones that go unchecked and unchecked assumptions are what break systems in ways no test suite can catch.

The most dangerous decisions aren’t the ones that are wrong.
They’re the ones made in rooms where no one speaks up.

Outages, regressions, creeping tech debt they rarely arrive with a bang. They show up slowly, wrapped in the quiet of unasked questions and untested convictions.

So when an idea feels “obvious,” stop.
Not to second-guess yourself but to invite the friction.
Ask: “What am I missing?” “Where could this break?”
Make it a habit. Make it a culture.

Because the strongest leaders don’t seek validation.
They design teams that correct them early and celebrate it.
They don’t cling to certainty.
They earn it.

(Translation: we’re firing the humans but in a way that sounds exciting.)

The owl had spoken. The future was here.

And it spoke fluent buzzword.

What followed was a familiar plotline: cautious applause from investors, quiet dread from internal Slack channels, and a sinking feeling for the creatives, educators, and contractors who’d helped build the platform into what it was warm, weird, and widely loved.

The same people who gave Duolingo its voice a brand that somehow blended Sesame Street with mild emotional blackmail were now left wondering if that voice was being handed off to a large language model that thinks “¿Dónde está el baño?” is peak comedy.

“The humans are being deprecated. But don’t worry, the owl is still watching.”

AI Slop Enters the Chat

The results? Mixed at best. AI-generated content filled gaps, sure but also widened a few. What once felt playful and oddly personal began to feel templated. Lessons lost their spark. Social posts read like interns trying too hard, only the intern was an algorithm fed 30,000 Reddit comments and a dream.

Behind the scenes, Duolingo boasted about building 100 courses in under a year a staggering feat compared to the ten it took to build the first hundred.

Think of it like assembling 100 IKEA bookshelves in a weekend: technically impressive, but don’t lean on them too hard.

A hundred new courses in under a year. Quantity flex. Quality TBD.

Because for those actually trying to learn a language, speed doesn’t always mean progress. Sometimes it just means more walls to walk into before you find the door.

And as for the voice that made Duolingo famous the charmingly unhinged, slightly threatening owl? It didn’t translate well to AI. Instead of motivating guilt trips and inside jokes, we got safe sentences and sanitised tone. The same feeling you get when a fast food chain tweets something "relatable." It’s trying you can tell but you can also tell someone deleted all the weird bits in revision.

"It’s giving ‘How do you do, fellow kids?’ energy. But in Duolingo green."

Enter Corporate Clarity Guy

Before the walk-back, there was the memo.

Leaked to the press and later confirmed, it laid out a five-point plan for how Duolingo would “align the business around AI.” On paper, it sounded visionary. In practice, it read like a slow-motion goodbye to the human scaffolding that made the app work.

Duolingo CEO Luis von Ahn outlined five “constructive constraints”:

• "We'll gradually stop using contractors to do work that AI can handle"

• "AI use will be part of what we look for in hiring"

• "AI use will be part of what we evaluate in performance reviews"

• "Headcount will only be approved if a team can’t automate more of its workload"

• "Most functions will have specific initiatives to fundamentally change how they work"

If that sounds less like a strategy and more like an existential performance review for anyone with a salary you’re not wrong.

This isn’t an enhancement strategy. It’s a soft restructuring plan.

"The future is bright. Unless you're human."

Then came the video.

A kind of non-apology wrapped in CEO sincerity equal parts reassurance and reputation control. Von Ahn, speaking directly to camera, reframed the whole thing:

“One of the most important things leaders can do is provide clarity. When I released my AI memo… I didn’t do that well.”

He goes on to say that AI won’t replace workers, that Duolingo is still hiring, and that employees will be “empowered” to learn and adapt. He reassures the audience that the owl is still here to help not automate you out of relevance.

“I don’t know exactly what’s going to happen with AI… but the sooner we learn how to use it responsibly, the better off we will be.”

It’s calm. Measured. Thoughtful.

And it lands about six PowerPoint slides away from the original plan that said headcount would only be granted if a team couldn’t automate more of their work.

“The owl says AI is here to help. But if you squint, you can still see the memo behind the smile.”

Your AI usage streak is in danger. Let’s fix that before it affects your performance review 💚

You Can’t Walk Back the Hype (and Google’s Breathing Down Your Neck)

There’s a trap in calling yourself “AI-first.” You’re not just experimenting you’re committing. You’re placing a bet, publicly, that AI is not only the future but your future. And when that doesn’t land? When the vibes go missing, the lessons feel hollow, and your users start asking why Duo now sounds like a customer support bot for a smart fridge?

You can’t just hit undo. You need a narrative detour. You need Clarity Guy with a whiteboard explaining that “AI-first” really meant “AI-curious but people-powered.”

But behind that PR spin was something else: Google. Specifically, Google Translate now increasingly dabbling in interactive learning. It doesn’t take a strategist to see the impending doom: a tech giant with a near-endless war chest and one of the largest translation datasets on Earth suddenly deciding it wants your users.

Duolingo wasn’t just chasing innovation. It was racing the clock. If they didn’t stake their claim now, they risked becoming the quirky owl-shaped startup that got eaten by a search bar.

"I used to teach. Now I prompt-engineer."

Language Is Human (And I'm Living Proof)

Language is weird. It’s full of nuance, timing, sarcasm, and culture. You don’t just learn a language you absorb it. Through mistakes, repetition, and the occasional stranger correcting your grammar mid-sentence with a kind smile or a look of sheer pity.

AI can generate sentences. Hundreds, even. But it doesn’t know what it’s teaching. It doesn’t get why “I want to eat, grandma” is different from “I want to eat grandma.” It doesn’t know how to gently motivate someone who’s burnt out or how to slip a joke into just the right sentence to make it stick.

And users are starting to notice:

“I’m a paid Super Duolingo customer with a 1463-day streak,” wrote one user on LinkedIn. “But they gutted the Esperanto course and removed the humans who maintained it. Now it’s dying on the vine.”

Another flagged the Spanish-via-Telugu course: “The content is ungrammatical and frankly misleading. Please don’t fire your human translators.”

I can relate. As someone learning Spanish with a Peruvian partner, Duolingo helped me build the foundation the first 2,000 words I needed to communicate, argue, laugh, and survive awkward family dinners. That wasn’t magic. It was consistency. Gentle repetition. Human-tested content that understood how brains actually work when learning a second language: lazily.

But vocabulary is the easy part. The real wall is listening catching full-speed sentences in real-world context, no subtitles, no mercy. Unless you’re learning Japanese (where every syllable is lovingly pronounced like a stage actor doing warmups), most languages hit your ears like a blender on fast-forward.

That’s why the Duolingo podcasts were such a gift. Real voices. Real pacing. Real stories. They weren’t just content they were immersion. And they taught me far more than any AI-generated multiple-choice quiz ever could.

"The best way to learn a language? Forget you're learning it."

Your brain will default to what it knows unless you force it not to. That’s why I had to delete Google Translate too tempting. It became a crutch, not a tool. Karaoke in Spanish helped more than most apps ever did. So did being stranded in a Spanish town with no help, no Wi-Fi, and no choice but to figure it out.

That’s what language learning is. It’s immersion, struggle, and sometimes embarrassment not a five-minute “Learn Spanish with AI!” PDF and a pat on the head.

And here’s the real danger: if we keep pushing AI-first language solutions, we may stop learning altogether. We’ll just outsource it.

Why study, when your voice assistant can whisper the answer into your ear in real time?

Why wrestle with conjugations, when your AI agent is already replying to theirs?

That’s not fluency. That’s just automation dressed up as connection.

Because when a user gets an answer marked wrong even when it’s clearly right that’s not just a glitch. That’s a failure of trust. And once people lose confidence in your app as a teacher, it doesn’t matter how fast you can scale.

You’ve taught them the wrong lesson.

“Looks like you missed your Spanish practice... again. But it’s okay. The AI model’s improving without you.”

The Owl’s Redemption Arc

So here we are. The owl blinked. The memo got massaged. The people are back mostly. The company line now reads somewhere between “AI will enhance us” and “please ignore the previous memo.”

“I’m not mad. I’m just disappointed you didn’t train the model today.”

And if you’ve opened the app lately, you’ll know: they’re hustling. That Super Duolingo free trial offer? It’s not a suggestion anymore. It’s a recurring dream. You open the app to review a verb tense and within seconds, you’re being asked to upgrade like you’ve walked into a very polite hostage situation.

Upgrade to Super Duolingo™ to keep one human editor employed.

And honestly? Let them. Someone has to pay the AI bill. GPT-4 isn’t cheap, and Corporate Clarity Guy’s whiteboards don’t fund themselves.

Because in the end, Duolingo taught us a lesson far more important than how to say “Where is the bathroom?” in Spanish.

The future might be built with AI.
But the parts that stick the ones we laugh at, learn from, and remember those are still human.

And maybe that’s the real lesson.

Not just how to say “Where is the bathroom?”

But when to pause, ask why, and remember that language like learning works best when it’s a little messy, a little human, and absolutely not automated end-to-end.

“You missed your Spanish lesson. But don’t worry the model’s fine.
You’re the one we’re losing.”
— The Owl, softly, from the push notification abyss

AI tools get us to 80% fast. But that last 20%? That’s where real engineering happens error handling, performance tuning, edge case thinking, and security.

We used to build prototypes that were clearly incomplete. Now AI spits out polished-looking systems that feel finished… until they silently break, rot, or vanish into tech debt no one understands.

If you stop at the AI-generated "good enough," you're not shipping code. You're shipping a time bomb with clean syntax.

Don’t confuse "it runs" with "it’s ready." And yet—because it looks done, we treat it like it is.

Looks Done. Isn’t.

So, AI makes it a breeze to spew out a thousand digital houses overnight, right? Blueprints? Who needs 'em. Inspections? Get outta here, no time! Just smash that “Generate” button and watch the damn neighbourhood pop up walls slapped together, roofs ostensibly sealed, fresh paint gleaming like a salesman's smile. From a distance, yeah, it looks passably complete.

But here’s the con, the sleight of hand: Before this AI circus rolled into town, we built prototypes. Actual shells of what a house might become. They got us to, say, 70%. No fancy plumbing. Wiring? Forget about it. Just enough to demo the idea and see if there was even a there there. Everyone knew it wasn’t finished. The cracks were showing. The neon danger signs were blinking. It was a checkpoint, not a finish line.

Then AI waltzes in and gets us to that seductive 80%. Suddenly, the lights flicker on. The taps might give you water, if they’re feeling generous. The stove sputters to life. It feels like a home just enough to hoodwink stakeholders into thinking it’s move-in ready. So, because the pressure’s on, we do. We ship it. And that, my friends, is when the real migraine starts.

Missing auth logic? "We’ll bolt it on later." No error handling? "Future-us problem." Hardcoded data? "Temporary!" But here’s the thing: AI doesn’t leave a flag in the sand. It doesn’t say “this is just a scaffold.” It doesn’t warn you that the plumbing stops behind the drywall. It looks done.

Prototypes were incomplete by design. AI makes them look complete without the safety, structure, or scrutiny they need to be real.

Because beneath that flimsy, AI-generated 10% veneer of ‘polish’?

• There’s no goddamn foundation.

• The wiring’s a rat’s nest, just begging to short-circuit your entire week.

• The front door? Might as well be a painted-on cartoon it sure as hell doesn’t lock.

• And the kicker? No one not even the poor sods who copy-pasted it into existence can explain how any of this Rube Goldberg machine actually works.

Security? An afterthought, if it was a thought at all. Scalability? cue nervous laughter and shrugging. Maintainability? Vanished into the ether, probably with your weekend plans. Ownership? That disappeared the second the prompt window closed.

But hey, it runs (mostly). It demos (if you don’t click the wrong thing). It impresses (the people who don’t have to fix it later).

So, we move in. We build on top of it. And by the time everyone figures out what a rickety pile of crap we’ve actually inherited, we’ve already churned out five more just like it, all teetering on the same shaky ground.

The 70% prototype was a checkpoint. The 80% AI version is a trap. And the faster we go, the faster they expect until it all comes crashing down.

Prototyping Was a Phase—Now It’s the Product

Remember the good old days? Before the AI hype train barrelled through, we used to ship prototypes. And let's be honest, they were often a glorious mess fragile, held together with digital duct tape, and nowhere near ready for prime time. But here’s the thing: we knew it. We weren’t kidding ourselves, and we sure as hell weren’t trying to kid anyone else. The plan was always to go back, to actually engineer the damn thing.

That 70% half-baked version? It was just enough to demo the core idea, to see if there was even a there there. Nobody in their right mind looked at it and thought, "Yep, ship it!"

Missing auth logic? "Eh, we'll bolt it on later." No error handling? "Future us problem." Hard-coded data all over the place? "It's just temporary, boss, promise!" That was all part of the dance, the accepted sloppiness of the exploration phase. Then AI swaggered onto the scene. Now, we hit "generate," and out pops something that doesn’t just crawl it walks, maybe even does a little jig. It feels done. It works just well enough to bamboozle stakeholders and sometimes even ourselves into believing it is done.

AI gets us to that tantalising 80%. And that, right there, is where the alarm bells should be screaming.

Because that last 20%? That’s not just spit-and-polish. That’s the performance tuning that stops it from cratering under load. That’s the edge case handling that prevents your users from hitting a digital brick wall. That’s the security pass that (hopefully) keeps you off the front page of Hacker News. That’s where real engineering happens. But with AI eagerly volunteering to fill in the blanks, that crucial, painstaking work just… quietly evaporates.

Why bother refactoring, why sweat the details, when the next prompt can churn out something else that’s vaguely “good enough”? It’s a slippery slope, paved with the best intentions and the siren song of speed.

“AI in the wrong hands won’t just cause bad code it’ll cause systems that nobody knows how to fix.”

Let’s face it: stakeholders, bless their hearts, aren’t usually clamoring for robustness under the hood. They want features they can see. Demos that dazzle. Things that look like relentless forward momentum. And AI? It delivers that superficial shine, and it delivers it fast.

So, when some poor, battle-weary engineer pipes up, voicing those nagging concerns about ballooning tech debt, the glaring lack of tests, or that AI-generated chunk of code that just feels profoundly sketchy and wrong… what’s the all-too-common refrain?

“It’s working, isn’t it?”

What they don’t see what AI, by its very nature, often helps obscure are the gremlins already multiplying just beneath that shiny surface:

• Edge cases that are silently, consistently fumbling the ball.

• Hidden vulnerabilities, just patiently waiting for some enterprising script kiddie to stumble upon them.

• Brittle, inscrutable code that’s guaranteed to shatter the moment it encounters the slightest bit of real-world pressure.

We’ve officially stumbled into the era of invisible fragility. And believe me, that’s a damn sight scarier and a whole lot more dangerous than the honest, visible jank we used to deal with.

Invisible Fragility: The New Technical Debt

Let’s talk about the old-school kind of tech debt. At least it was honest. You could see the mess. Spaghetti callbacks. TODO (lol) comments. Hacks you swore you’d fix “someday.” Ugly? Sure. But obvious.

You’d sigh in a code review and say:

“Yeah, that’s rough. We’ll come back to it.”
And you meant it mostly. You knew where the monsters lived.

But AI-generated code? Different beast. It looks clean. It sounds right. It glides through PRs. Tidy structure. Sensible naming. No “WTFs per minute.” It feels safe.

Until it isn’t.

The debt’s still there just polished, buried, camouflaged.

This is the new nightmare: invisible fragility.

What does that look like?

• Functions that silently swallow errors or return garbage on edge cases nobody tested.

• Loops that look elegant but blow up at scale.

• Logic that works in demos… and combusts in production.

// Original
async function getUserName(userId) {
  const user = await db.findUserById(userId);
  return user.name;
}

Crashes if user is null. The AI notices and patches it:

// AI-generated fix
async function getUserName(userId) {
  const user = await db.findUserById(userId);
  return user?.name ?? 'Unknown';
}

Looks fine. Doesn’t crash. But now, we’ve just papered over the real issue.
The symptom’s gone. The cause? Still lurking unlogged, unmonitored, and harder to detect.

And the scariest part?

• No backstory

• No breadcrumbs

• No trace of the why

Just a detached blob of logic unowned, untested, and uninterpretable.
We didn’t trade mess for quality.
We traded understanding for illusion. And that’s the kind of debt that doesn’t just grow it eventually collapses everything beneath it.

Dependency Spiral: The More AI We Use, the Less We Know

It always starts so innocently, doesn't it? A little time-saver here, a quick unblocker there. You’re jammed up. The deadline’s breathing down your neck like a caffeine-fuelled dragon. So you nudge the AI, "Hey, can you whip up a little something for this?" Maybe it’s a helper function, a basic endpoint, a component stub to get you going. And sweet relief, it actually works. Or, at least, it seems to.

So, the next time you hit a snag? Well, that AI did a pretty good job last time, right? You ask it for a bit more. Then a bit more after that. And slowly, almost without you noticing, a dangerous new reflex kicks in. The mental muscle for problem-solving starts to atrophy.

It becomes:

“AI wrote it, so let’s just let AI write the next part, too.”

Before you can say "technical debt," the human role morphs from actual engineering into something more akin to being a glorified switchboard operator plugging AI-generated black boxes together with digital duct tape and a silent prayer that the whole damn Rube Goldberg contraption holds.

Engineers, good engineers, stop asking why a chunk of code works. They just squint at it, run the tests (if they exist), and if it doesn’t immediately explode, they shrug and move on. They stop truly understanding how their systems interconnect, how the data flows, where the dragons lie. They just know which magic incantation which prompt coaxes the AI into spitting out the next piece of the puzzle.

And teams? Oh boy. They start piling new features, entire floors, onto foundations they didn’t pour, didn’t design, and frankly, barely even glanced at. Foundations that might be made of digital papier-mâché for all they know.

What begins as a cheeky little shortcut, a "just this once" expediency, rapidly devolves into a full-blown doom spiral:

At first glance, this seems reasonable. The syntax is clean. No ESLint errors. The feature even “worked” in staging.

• Knowledge doesn’t just fragment; it evaporates. Poof. Gone.

 // Looks fine in a PR. What could go wrong?
 async function sendNotification(userId, message) {
     const user = await db.getUser(userId);
     if (!user?.preferences?.notifications) return;
     await emailService.send(user.email, message);
 }

But six months later, a silent issue emerges: some users aren’t getting emails.
No errors. No logs. No alerts.
Turns out user.preferences.notifications is undefined for legacy accounts so the function quietly exits. Nobody knows why.

• Ownership? That becomes a hot potato nobody wants to catch.

• Confidence in the system (and sometimes in themselves) erodes into a gnawing anxiety.

• And documentation? Hah! Don’t make me laugh. That relic of a bygone era now trails so far behind it’s practically in a different timezone, attempting to describe a Frankenstein’s monster of a system that no single human fully comprehends.

The code works. It’s just wrong.
And no one knows how to trace the failure back to its origin.

It’s a fundamental shift in what we even mean by "unfinished work":

Technical debt used to mean “We’ll grit our teeth and fix this mess later.” Now it means “We’re not even sure what the hell this thing is, let alone how to fix it.”

The more you lean on AI to “just write it for me,” the more profoundly you disconnect from the very system you’re supposed to be building, stewarding, and ultimately, understanding. And when that system inevitably shits the bed and trust me, it’s not if, but when nobody knows where to even begin picking up the pieces. The panic sets in. Fingers get pointed. The codebase stares back, a silent, inscrutable monolith of AI-generated indifference.

Because it’s not just poorly understood code anymore. It’s a growing continent of technical unknowns. And that’s a terrifying place to be when the pagers start screaming at 3 AM.

System Decay Doesn’t Stop at Code Quality

We’ve talked about fragility in code. But AI also erodes something deeper: shared understanding. It doesn’t leave behind breadcrumbs. No rationale. No commit messages. No architectural record. That might be fine until someone needs to fix or extend that code. Suddenly, you’re staring at logic written by a ghost, for a problem nobody remembers.

Read the full breakdown in “No Memory, No Maintenance.”

The Missing 20% Is Where Quality Lives

AI gets us surprisingly far. It can spin up a full feature in seconds. The syntax appears clean. The output runs. From a basic requirements point of view, it looks done.

But it’s not.

Because AI rarely finishes strong. It’s designed to generate, not refine. And if you express doubt? It won’t push back. It’ll agree with you. Predict the tone. Mirror the uncertainty. Then confidently serve up something even more “fine for now.”

But it won’t:

• Slow down to write exhaustive tests.

• Anticipate edge cases, concurrency issues, or race conditions.

• Think about user error, degraded states, or what happens if that one API call fails.

It doesn’t check assumptions. It doesn’t weigh trade-offs.
It doesn’t pause to ask, “Is this right?” it just completes the thought.

Which means if you don’t stop to check no one will.

And that final 20%? The part after the demo, after the PR is merged, after the applause fades?
That’s where real quality lives.

It’s the integration tests that prove it works in the real world.
The performance tuning that keeps it fast under pressure.
The accessibility tweaks that make it usable for everyone.
The error handling that prevents a 2am cascade failure.
The security reviews that keep your company off the front page.

None of it is flashy. None of it demos well. And that’s exactly why it’s the first thing to vanish in a world moving too fast to care.

Because when we let AI take us to 80% and stop there, we don’t just lose resilience or clarity we lose something else: Pride.

The sense that a thing was built to last. That it can take a hit and keep standing.
That it reflects intentional choices, not just plausible code.

AI can draft. It can unblock. It can even surprise you.
But it can’t finish like a human who still gives a damn.

And if no one comes back to close the gap?

It stays open — until it breaks.

We’re Not Anti-AI. We’re Anti-Sloppiness.

Let’s be clear: this isn’t just another anti-AI rant. We’re not here to ban tools or reject progress.
We’re here to defend the codebase. AI has incredible potential and used well, it accelerates good engineering. We’ve always used automation to remove drudgery: Boilerplate generators. Snippets. IDEs that filled in static void main(String[] args) while we focused on what mattered.

But there’s a line between accelerating the work and abandoning the actual engineering. And we’re dangerously close to crossing it. It’s one thing to let AI handle the boring parts. It’s another to let it define the system, glue it together, and walk away like it’s finished.

Prototypes are fine.
We’ve all done them.
But if you’re going to use AI to build something fast?

Label it for what it is.
Flag the flaws.
Make the limitations loud and visible.

Don’t let a demo become a deadline.
Don’t let “good enough” become “let’s ship it.”

Because here’s the real risk:

We don’t just use AI to write code.
We start using it as a reason to stop thinking.

“Let’s have AI do it.”
“Let’s see what it generates.”
“Let’s ship this and tweak later.”

That’s the slope. And at the bottom of that slope? Engineers who don’t understand what they own. Teams that stop asking why. Systems that look finished but fall apart under pressure. We can’t afford that.

Especially not in an era where AI-native systems are going to outpace our ability to inspect every line.

We need to be more careful, not less.
More intentional, not more reactive.
More honest about prototypes, and more disciplined about what we trust.

AI is powerful. But the moment we stop treating it as a tool, and start treating it as an autopilot, we give up the one thing that matters most in engineering: Responsibility.

Don’t Let AI Lower the Bar

Alright, let’s be brutally honest: AI isn’t vanishing in a puff of smoke anytime soon and frankly, it probably shouldn’t. When it’s not being hyped to the moon by charlatans, it can be fast, genuinely helpful, and occasionally even pull a rabbit out of its digital hat. Used smartly, by people who actually know what they’re doing, it could supercharge development in ways we’re only just starting to fumble towards.

But, and this is a Mount Everest-sized 'but', if we let that intoxicating speed become our new favourite excuse to slash corners, to blissfully ignore the gnarly edge cases, or to conveniently forget how our own damn systems actually tick under the hood… well, then the problem isn’t the shiny new tool. The problem, my friends, is us. We’re the ones holding the idiot ball.

Believe it or not, engineering has always been and still is a hell of a lot more than just barfing out features and closing tickets. It’s about making the tough calls, the grown-up trade-offs. It’s about exercising actual goddamn judgement, and then standing by what you build, for better or worse. Every decision we make, every shortcut we take, every warning sign we ignore it all compounds, brick by lazy brick, into the systems that real people, real users, end up depending on. Sometimes with their livelihoods.

AI, on its own, isn’t going to torpedo the entire profession of engineering. But our collective willingness to just shrug, hand over the keys, and abdicate our goddamn responsibility? Yeah, that’ll do it. That’ll sink the ship alright.

So, the future isn’t some dystopian cage match: AI versus Engineers. It’s AI alongside engineers who still give a damn enough to ask the uncomfortable questions, to stick their hand up and flag what’s clearly missing or dangerously half-baked, and to actually finish the messy, critical job that some prompt only vaguely started.

Because that "missing 20%" we’ve been talking about the soul-crushing test suites, the mind-bending edge cases, the relentless performance tuning, the thankless security hardening that ain’t just a bit of polish you slap on at the end if there's time. That’s where robustness is forged. That’s where clarity finally dawns. That’s where actual, sleeves-rolled-up, coffee-fuelled engineering happens.

So yeah, by all means, use the AI. Let it crank out the boilerplate that makes your eyes glaze over. Let it draft that first stab at a new component. Let it take a load off your shoulders.

But for the love of all that is holy, don’t let it lower your standards. Don’t let it do your critical thinking for you. And don’t you dare confuse “hey, it runs without immediately exploding!” with “yeah, this thing is actually production-ready.” There’s a canyon-sized difference.

The chasm between a flashy working prototype and a truly reliable, maintainable system isn’t just cosmetic it’s foundational. It’s structural. It’s the difference between a cardboard movie set and a brick house that’ll withstand a storm.

So, reclaim that final, gruelling, indispensable 20%. That’s where the bar isn't just set; it's defended. That’s where our professionalism lives.

And in the end, we the humans still in the loop, the ones with skin in the game still get to decide. Do we hold that bar high, with pride? Or do we let it slip, inch by agonising inch, into the mud?

“They were careless people… they smashed up things and creatures and then retreated back into their money.”

— F. Scott Fitzgerald, The Great Gatsby

In the 1920s, Fitzgerald wrote of reckless elites who broke the world and floated off in silk shirts and champagne flutes. A hundred years later, Sarah Wynn-Williams gave us a new version in her memoir Careless People: A Story of Where I Used to Work, chronicling her time at Facebook (now Meta). It’s the same pattern but now the excess isn’t parties. It’s platforms. The debris isn’t emotional; it’s societal.

We don’t just live in the wake of tech’s carelessness. We scroll through it.

Wynn-Williams isn’t an outsider. She was there, inside the glass walls and growth charts. Her account is both a memoir and a warning a whistleblower’s documentation of what happens when consequence is considered a PR issue, not a moral one.

At Facebook, she saw the cost of growth up close. Wynn-Williams later went public, accusing leadership including Mark Zuckerberg and Sheryl Sandberg of enabling misinformation, brushing off dissent, and putting expansion above ethics. From the platform’s delayed response to the Rohingya genocide in Myanmar to its quiet accommodation of Chinese censorship demands, she paints a picture of a company that didn’t just move fast it muffled what didn’t fit the story.

“This isn’t the age of disruption. It’s the age of consequence.”

What she describes isn’t evil in the cartoon villain sense it’s quieter. It’s ambient. A culture so committed to acceleration that consequence becomes a rounding error. Or someone else’s job.

And it’s the same kind of recklessness that Telle Whitney is calling out in her new book Rebooting Tech Culture. Only this time, it’s not just about Facebook. It’s the whole damn operating system.

Move Fast, Break People

Let’s be honest: tech never fixed what Facebook broke. And now, AI is being built in the same mould.

The old playbook is back: ship fast, scale faster, deal with consequences when the lawsuits roll in. It worked (financially) for social media. So why not try it on reality itself?

Whitney’s warning is clear. As someone who’s spent decades inside the industry, she sees the same exclusionary culture playing out all over again in AI labs, in billion-dollar startups, in investor portfolios chasing “the next OpenAI.”

These tools aren’t being designed for everyone. And often, not by everyone either.

There’s a growing divide between those who build and those who are built upon. AI is increasingly shaped by a narrow set of voices — a concentration of elite engineers, funders, and platforms — while the rest of the world becomes its test set. The results affect how we search, how we learn, how we work, and how we’re seen.

Shoshana Zuboff called this out years ago in The Age of Surveillance Capitalism:
Tech's true innovation wasn’t the algorithm — it was the ability to turn human experience into data, and then into profit.

It’s not paranoia. It’s business.
And as The Social Dilemma made painfully clear, when the product is free, you are the product but with AI, we’re not just the product. We’re the pre-training data. The training set. The discarded scaffolding.

What’s missing isn’t just representation. It’s resistance. Teams move too fast for ethics to catch up, and feedback loops are flattened under quarterly metrics. A misfire in social media meant polarisation. A misfire in AI could mean systemic bias at the speed of scale.

The question isn’t whether these tools will reshape the world.
It’s whether anyone will be accountable for how they do it.

“We fed the machine our stories. It spat out a world that forgot us.”

When Memory Becomes Monetised

Tech companies used to profit from our attention keeping us glued to screens so they could sell our gaze to advertisers. Then came the data era: every click, scroll, and message became raw material to feed algorithmic predictions.

Now, they’re profiting from something more permanent: our labour, captured in memory.

Our labour — not in real time, but in permanent memory.

Large language models like ChatGPT, Claude, and Gemini were trained on the open internet. That includes blog posts, Stack Overflow answers, GitHub issues, fan fiction, academic papers, podcast transcripts, showreels, digital art — anything public enough to be scraped. If it was online, it was fair game.

They didn’t ask. They didn’t pay.

But now it’s productive, polished, and resold.

They trained the model on us. Now they sell it back to us as if we never existed.

Every beautifully phrased response, every auto-generated image, every AI-written line of code is built on top of a million anonymous contributions stitched together, stripped of origin, and served back like it was born in a lab.

The question isn’t whether these tools will reshape the world.
It’s whether anyone will be accountable for how they do it.

“The real looting was not of banks or shops, but of language, memory, and meaning.”
— Rebecca Solnit

First, they commodified our time. Then our behaviour. Now, they’ve commodified our creativity — the final layer of what it means to be human.

They call it artificial intelligence. But what powers it is very real: Teachers. Designers. Journalists. Coders. Poets. Musicians. The dev who answered your urgent bug question at 2 a.m., unpaid and uncredited. The writer whose copy was good enough to train a headline generator. The animator whose style became aesthetic fodder for infinite prompts.

Online, that labour was invisible. Inside the model, it’s erased. This isn’t just mimicry. It’s replacement. A library turned vending machine. Convenience with no citation. Scale with no soul. We used to worry about plagiarism.

Now we’re watching industrialised forgetting, disguised as progress and monetised as product.

The platforms are betting you won’t notice. Or worse: that you’ll love the output too much to care.

But not everyone is letting it slide. Legal challenges are emerging from Getty Images v. Stability AI, where the company is accused of copying 12 million copyrighted photos, to Authors Guild v. OpenAI, in which writers claim their books were ingested without consent to train LLMs (Ars Technica, 2023). The question isn’t just ethical anymore — it’s legal. And precedent is still being written.

Designed to Exclude

Whitney traces the roots of modern tech culture to what she calls the PayPal mafia a small group of men who created the companies that still shape our world: Facebook, Tesla, Palantir, LinkedIn. These founders didn’t just launch products. They created a cultural template: hyper-competitive, male-dominated, obsessed with the myth of the lone genius.

Emily Chang’s Brotopia calls this out for what it is — a system built by and for a specific kind of founder, one that actively sidelines women and anyone who doesn’t match the brogrammer archetype. Meritocracy, she argues, became myth. A cover story.

And that myth got intellectualized.

In Zero to One, PayPal co-founder Peter Thiel describes the ideal founder as “a man with a plan” — singularly focused, contrarian, and immune to social consensus. It’s an ethos that rewards disruption, not dialogue. Vision, not feedback. Strength, not inclusion.

The result? A system where “culture fit” became a weapon. Where VC firms chased pattern-matched genius while filtering out dissent. Where innovation meant building for yourself — and assuming everyone else would follow.

It’s not a bug.
It was the blueprint.

What Diversity Really Does

Whitney isn’t just calling out the problem, she’s showing what better looks like.

She points to companies like AMD, where CEO Lisa Su and CTO Mark Papermaster led an inclusive design process that produced a more modular chip one that helped AMD dethrone Intel. Inclusion wasn’t charity. It was strategy.

And that strategy is measurable.

A 2020 report from McKinsey & Company found that companies in the top quartile for ethnic and gender diversity were significantly more likely to outperform their peers financially — a finding that’s only strengthened over time. McKinsey, 2020

The takeaway? Diversity isn’t decoration. It’s infrastructure. And the moment you treat it like a checkbox rather than a creative engine, you lose what it’s actually for.

Wynn-Williams saw this, too. Her Facebook memoir reveals how brilliant people slowly slip away from companies that don’t hear them. They don’t leave in protest. They leave in silence, like a tab quietly closing in a sea of open ones.

Culture Change Starts Small

Whitney offers a new model, one built on what she calls the six Cs:

Creativity. Courage. Confidence. Curiosity. Communication. Community.

Not as slogans. As systems. Values that reward listening, make space for different kinds of thinking, and actually support the people inside the product pipelines.

But these aren’t soft skills they’re the structural foundation of innovative, resilient teams.

• Creativity means allowing ideas to come from anywhere, not just the most senior or loudest person in the room.

• Courage is the ability to challenge legacy thinking, suggest unpopular ideas, and experiment without fear of retribution.

• Confidence builds when people know their voice matters, not just when it echoes leadership's opinion.

• Curiosity fuels better questions, better product decisions, and better ethical foresight.

• Communication means active listening, psychological safety, and transparency beyond performative updates.

• Community reminds us that innovation is a team sport one that only thrives when everyone belongs.

You don’t have to be a CEO to start. Team leads can build this now. So can mid-career engineers. So can new grads. But the first step is seeing that our current tech culture isn’t neutral it’s inherited.

And maybe it’s time we stop building with hand-me-down ethics.

Not as slogans. As systems. Values that reward listening, make space for different kinds of thinking, and actually support the people inside the product pipelines.

You don’t have to be a CEO to start. Team leads can build this now. So can mid-career engineers. So can new grads. But the first step is seeing that our current tech culture isn’t neutral — it’s inherited.

And maybe it’s time we stop building with hand-me-down ethics.

The New Tech Heroes Don’t Look Like the Old Ones

We know the names: Zuck. Musk. Jobs. Bezos.
They were cast as visionaries. Mavericks. World-changers. Their biographies became Bibles. Their aphorisms, scripture.

And so, the industry measured success by the size of your exit, the edge in your voice, the chaos you could command. Leadership became performance. Genius became exclusion.

But maybe that story is outdated.
Maybe it was always a bit of a lie.

Because the real work — the kind that lasts, the kind that includes, the kind that heals what tech has broken — is being done elsewhere. Quietly. Sustainably. Without a TED Talk.

Whitney names her heroes: Lisa Su, who rebuilt AMD through inclusive design. Jayshree Ullal, who leads with substance, not spectacle. And the thousands more women, people of colour, neurodivergent thinkers, community-first builders — who are architecting futures that don’t require someone else’s ruin to function.

These are the technologists shaping systems with empathy, not ego.
They’re not tweeting through a crisis. They’re preventing it.

And maybe it’s time we stopped chasing disruption and started honouring care.
Maybe the future doesn’t need more geniuses.
Maybe it needs more listeners.

Let’s Stop Being Careless

In Careless People, Wynn-Williams doesn’t write a takedown. She writes a warning.

In Rebooting Tech Culture, Whitney gives us the manual for doing it differently.

Together, they tell a story that’s uncomfortably familiar: the most dangerous thing in tech isn’t the code. It’s the culture. The willingness to “figure it out later.” The assumption that harm is just the price of progress.

We’ve seen what happens when you build without responsibility. Facebook taught us that.

AI doesn’t have to be the sequel.
But if we don’t reboot the culture not just the models it will be.
And next time, the stakes will be much higher.

References

Books

Zuboff, S. (2019) The age of surveillance capitalism: the fight for a human future at the new frontier of power. New York: PublicAffairs.

Thiel, P. (2014) Zero to one: notes on startups, or how to build the future. London: Virgin Books.

Chang, E. (2018) Brotopia: breaking up the boys’ club of Silicon Valley. New York: Portfolio.

Wynn-Williams, S. (2025) Careless people: a story of where I used to work. New York: Random House.

Whitney, T. (2025) Rebooting tech culture: a new playbook for building inclusive innovation. Cambridge, MA: MIT Press.

Documentaries

Orlowski, J. (2020) The Social Dilemma. [Film] Distributed by Netflix.

Podcasts

Ibarra, H. and Whitney, T. (2025) Does the tech industry need a reboot? [Podcast] Harvard Business Review, 14 May. Available at: https://hbr.org/podcast/2025/05/does-the-tech-industry-need-a-reboot (Accessed: 4 June 2025).

Reports

McKinsey & Company (2020) Diversity wins: how inclusion matters. Available at: https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/diversity-wins-how-inclusion-matters (Accessed: 4 June 2025).

News & Legal Articles

Ars Technica (2023) Getty Images sues Stability AI for copying 12 million photos, violating copyright. Available at: https://arstechnica.com/tech-policy/2023/02/getty-images-sues-stability-ai-for-copying-12-million-photos-violating-copyright/ (Accessed: 4 June 2025).

Business Today (2025) From political interference to “share a bed” claims: who is Sarah Wynn-Williams? Available at: https://www.businesstoday.in/latest/world/story/from-political-interference-to-share-a-bed-claims-who-is-sarah-wynn-williams-ex-meta-executive-behind-careless-people-memoir-mark-zuckerberg-sheryl-sandberg-joel-kaplan-468127-2025-03-17 (Accessed: 4 June 2025).

Hindustan Times (2025) Facebook whistleblower Sarah Wynn-Williams’ explosive memoir shakes Silicon Valley. Available at: https://www.hindustantimes.com/world-news/us-news/facebook-whistleblower-sarah-wynn-williams-explosive-memoir-shakes-silicon-valley-101742093810596.html (Accessed: 4 June 2025).

Wikipedia (n.d.) Careless People. Available at: https://en.wikipedia.org/wiki/Careless_People (Accessed: 4 June 2025).

— Me, quoting Step Brothers while psyching myself up to talk to a webcam.

Okay — not really. But I have spent a shocking amount of time talking to myself in front of a camera, trying to impress an algorithm. That’s why I had such a great time using HireVue — the AI-powered interview platform that removes one unnecessary part of the hiring process: other people.

If you’re unfamiliar, HireVue is what happens when someone looks at a regular job interview and thinks, “What if we made this colder, lonelier, and judged entirely by a machine?” You get a link, some instructions, and then you’re off — recording answers to pre-set questions while staring into your webcam. No interviewer. No feedback. Just you and a timer.

Interviewing Into the Void

At first, I thought: how bad can it be? I mean, I’ve done video calls. I’m comfortable talking. I’m reasonably tech-savvy.

But there’s something deeply weird about smiling at your own reflection while trying to project confidence and warmth — to no one. You’re expected to maintain eye contact, speak clearly, smile naturally. And you do. Because that’s what we’ve trained ourselves to do in real conversations. You nod. You pause for reactions. You try to build rapport.

And then it hits you: you’re faking a connection with a void. Obviously platonic, but still a connection. It’s like flirting with your microwave. No matter how well you do, it won’t tell you if it enjoyed the chat.

No Feedback Loop, No Humanity

In a real interview, there’s a feedback loop. You say something, and maybe it doesn’t quite land — so the interviewer asks, “Can you clarify?” or “I didn’t quite follow.” That little nudge helps you reframe your point, recover, even shine.

HireVue doesn’t give you that. It just lets you bumble on. There’s no “wait, let me try that another way.” No chance to read the room — because there is no room. Just a cold, unblinking camera and a countdown timer.

It’s like doing a whiteboard session where the interviewer says nothing. You draw, you talk, you explain — and all the while, you're being silently observed. Judged.

“There’s nothing like trying to build rapport with a loading icon.”

Honestly? It felt like being in a game of Portal. You're the test subject. The algorithm is GLaDOS. You keep talking, hoping you're getting it right, with no idea what “right” even means.

At one point, I genuinely felt like I’d been taken captive and was recording a ransom plea.

“Please, let me work for your company. I have marketable skills. I can meet KPIs. Think of my family.”

Because who knows — maybe if I looked desperate enough, the algorithm would finally believe my response.

The Black Box with a Scorecard

It’s easy to laugh at the absurdity of AI interviews — until you realise what’s really happening.

Behind the scenes, algorithms are evaluating your performance. Supposedly looking for things like communication skills, enthusiasm, and problem-solving ability. But how? Based on what? Says who — the algorithm?

This is the heart of the “black box” problem in AI hiring. HireVue, like many AI interview platforms, does not provide a transparent breakdown of how specific non-verbal cues — facial expressions, vocal tone, body language — are weighted. You’re assessed by unseen metrics, against undefined standards, with no opportunity to ask for clarification or feedback.

“Getting feedback from an algorithm is like yelling into a canyon and hoping it explains your echo.”

It’s not just frustrating. It’s dangerous.

As a Forbes Tech Council article highlights, "In some cases, deeper AI learning models have become so advanced that even their creators don't fully comprehend how they work" [1]. That’s a terrifying sentence — especially when your ability to land a job might hinge on whether or not you blinked too much.

“If the machine doesn’t know why it said no — how are we supposed to learn from it?”

These systems are trained on historical data. And if that data reflects existing human bias — around gender, race, age, or accent — the system doesn’t remove bias. It scales it [2]. Amazon learned that the hard way with its now-retired AI hiring tool, which penalised CVs containing the word “women’s” [2]. HireVue, for its part, publicly stopped using facial analysis after backlash [3]. But without full transparency into how their Natural Language Processing (NLP), sentiment scoring, or behavioural analytics work — candidates are left guessing.

What should be a conversation becomes a monologue — with no red pen, no context, no second chance. It’s the digital version of “Computer says no” — except this time, it’s your future on the line.

Do They Know It’s Biased?

To be fair, HireVue and similar companies don’t pretend bias doesn’t exist. They claim to address it — and to their credit, they’ve moved beyond internal promises.

They’ve brought in independent firms like DCI Consulting Group [4], ORCAA [5], and Landers Workforce Science LLC [6] to audit their systems. These are not subsidiaries. They’re not internal rebrands wearing a new logo and a trench coat.

But let’s be honest: if I pay someone to evaluate me, I’m at least hoping for a good review — or at the very least, a polite one.

“You don’t hire the food critic to write the menu.”

Would you tell a billion-dollar client that their system might be unfair to disabled or neurodivergent candidates — or that it subtly filters out people with regional accents — if they’re the ones keeping your lights on?

“Technically independent. Financially dependent.”

Even the best-intentioned audits exist in a system of incentives. Consultants are still vendors. And vendors, as a rule, don’t bite the hand that signs the cheque.

And let’s be honest — no one wants to upset the wrong billionaire or, heaven forbid, Orange Man. We might end up with a tariff on “algorithmic scrutiny” by morning.

We’ve seen what happens when that kind of dynamic goes unchecked.

Remember the 2008 mortgage crisis? Credit rating agencies handed out AAA ratings to financial garbage because — surprise — the companies selling those toxic assets were the ones paying for the scorecards [7]. The illusion of objectivity collapsed. And so did the economy.

We’re not saying AI hiring will crash global markets. But when people’s livelihoods are being shaped by black-box systems reviewed by paid partners, the parallels are hard to ignore.

“Trust doesn’t come from a contract. It comes from accountability.”

So if you're wondering why these tools keep getting deployed — even with unresolved bias, vague metrics, and suspect audits — maybe it’s not just the companies.

Maybe it’s because the people building them aren’t being told to stop. In fact, they’re being told to go faster.

The Shifting Sands of AI Safety: A National Priority or a Nuisance?

The fight for ethical AI isn’t just happening in company town halls or consulting firm blog posts. It’s playing out at the highest levels of government. And the current message from the top? Move fast, and break… guardrails.

Under the Trump administration, the U.S. has sharply shifted its AI priorities. Gone are the calls for “responsible AI” and fairness. In their place: a race to dominate global AI markets and root out so-called “ideological bias” [8].

The National Institute of Standards and Technology (NIST), the very body tasked with overseeing AI safety, was recently instructed to eliminate references to “AI safety,” “responsibility,” and “fairness” from its partner expectations [9]. Yes — the AI Safety Institute is being told to stop talking about safety.

Instead, they’ve been tasked with building tools to “expand America’s global AI position” [10], following a January 2025 executive order aimed at eliminating anything seen as a “barrier to American AI innovation” [10].

“Safety isn't a barrier to innovation. It’s the foundation for trust.”

Critics warn that stripping away these protections opens the door to unchecked, discriminatory algorithms — including those making hiring decisions [11]. But proponents dismiss the concern. After all, safety audits are “inexpensive,” and what’s a little bias compared to GDP growth? [12]

But when it’s your application being discarded, or your voice being mistranslated by an algorithm, “inexpensive” starts to feel like code for “ignore it.”

This isn’t just a policy change — it’s a worldview shift. One that sees friction as failure and guardrails as bureaucracy. And it sends a clear message to companies building AI hiring tools:

You’re not just allowed to move fast.

You’re being incentivised to.

So when you’re wondering why a platform like HireVue still feels like a digital interrogation booth with no feedback, no accountability, and no second chances — maybe it’s because the people at the top decided that speed wins. Even if people lose.

The Human Cost

I get it. Companies want efficiency. They want scalable hiring. They want to reduce bias. But somewhere in the pursuit of “better,” we stripped away the human from Human Resources.

Real interviews are stressful — but at least they’re a conversation. At least there’s nuance. A moment. A spark. HireVue replaces that with something colder. Something measurable. Something unaccountable.

And if you’re neurodivergent? The challenges are amplified. Time limits, lack of clarification, unclear expectations — it’s a system designed around neurotypical behaviour [13]. If your accent doesn't match the model’s training data, or if your connection stutters, you’re already behind.

The ACLU recently filed a complaint against Intuit and HireVue, alleging their AI hiring technology works worse for deaf and non-white applicants [14]. This complaint highlights concerns that differences in speech patterns, accents, and communication styles can lead to biased outcomes. This isn't just about a "feeling" of unfairness; it's about demonstrable adverse impact on certain demographic groups, echoing concerns that have been raised by numerous studies on algorithmic bias in hiring.

“Efficiency at scale sounds great — until you realise you’ve scaled dehumanisation.”

Why Do We Accept This?

Maybe it’s job scarcity. Maybe it’s tech hype. Maybe we’ve just gotten used to being scanned, scored, and sorted like digital livestock.

Barcoded, processed, and evaluated for “emotional tone” like some sort of psychological meat quality test.

“Smiles: slightly forced. Eye contact: inconsistent. Confidence: medium-rare.”

At some point, we stopped interviewing.

We started optimising — for algorithms, for word clouds, for vibes we can’t see but are somehow being graded on.

And when you start tailoring your voice, posture, and word choice to please a machine — not a person — we lose something important.

We lose the conversation.

We lose the humanity.

We lose the basic dignity of being understood — not just measured, logged, and archived for audit purposes.

“Authenticity is hard when you’re performing for a robot with a spreadsheet.”

Final Thoughts

I’ve talked to walls before — but at least they didn’t reject me via algorithm.

“The system doesn’t need to hate you to hurt you.”

So here’s my message to other job seekers: if you’ve struggled with HireVue, it’s not just you. This system isn’t built to understand you. It’s built to filter. And often, it filters out the very things that make you human.

“We’re not asking for a standing ovation — just a human response.”

We deserve hiring processes that see people, not probabilities. That reward clarity, not conformity. That give you a chance to clarify, connect, recover — not just auto-fail because you blinked wrong in the first five seconds.

We need to talk about this. Loudly. Repeatedly.

With our real voices.

Not just into a camera lens.

And definitely not for a machine that was never listening.

For My Intern Friends: Surviving the Black Box

If you're staring down a HireVue interview and feeling the existential dread of talking to a blinking dot, here are a few tips to help you survive the void — and maybe even score that callback.

1. Treat it like theatre, not a conversation.

You won’t get nods, “mm-hmms,” or follow-ups — so front-load your clarity. Say what you mean, then say it again (briefly) with structure: "Here's the problem, here's how I approached it, here's what happened."

2. Practice with a timer and webcam.

Simulate the awkward silence. I used the Apple timer on my phone — set for 1–2 minutes — then just stared at it while answering questions like I was defusing a bomb. It helped. No audience, no feedback — just me, a screen, and the crushing awareness that somewhere, an algorithm was judging my vocal tone.

3. Smile — but don’t force it.

Yes, it’s weird. But a calm, confident demeanour helps signal “composed and hireable” to whatever behavioural model is watching. Think video cover letter, not hostage tape.

4. Use STAR — even when the question doesn’t ask for it.

That’s Situation, Task, Action, Result. It gives your answer structure, which helps you stay on track — and it helps the algorithm identify story arcs in your response.

5. Review real HireVue questions in advance.

Sites like Coursera 👉 this one have lists of common questions by role. Don’t memorise answers — but do prep your go-to stories for teamwork, problem-solving, leadership, and failure.

6. Learn from the greats (or pretend to).

This YouTube channel taught me everything I needed to know: stare into the void, read a script, and deliver it like you're leading a nation. It's a teleprompter training video for aspiring anchors or presidents — perfect prep for HireVue.

Honestly, after five sessions I felt ready to address the nation, launch a stimulus package, and maybe even explain my gap year with gravitas.

“My fellow stakeholders… in Q4, I overcame adversity by aligning cross-functional synergies under tight deadlines.”

Honestly, if the next U.S. election isn’t run through HireVue, it’s a missed opportunity. At least then we’d have a fair metric for comparing the real candidates to Mark Zuckerberg — At least then we’d all get to see which candidates blink too much under pressure.

“Candidate A: Answered clearly. Blinking rate: suspiciously low.”

Let’s face it: we’re not being judged like humans. We’re being scored like deepfakes trying to pass a CAPTCHA.

“I did not have inappropriate pauses with that question.” — You, to the algorithm, 2025

7. And if all else fails?

Remember: this isn’t the final boss. It’s just one gatekeeper.

You’re more than your sentence flow, your vocal tone, or how long you paused before answering.

You’re not failing an interview.

You’re debugging a system that wasn’t designed for you.

References

[1] Forbes Technology Council. (2025, March 7). The Black Box Problem: Why AI in Recruiting Must Be Transparent and Traceable. Forbes. https://www.forbes.com/councils/forbestechcouncil/2025/03/07/the-black-box-problem-why-ai-in-recruiting-must-be-transparent-and-traceable

[2] Dastin, J. (2018, October 10). Amazon scraps secret AI recruiting tool that showed bias against women. Reuters. https://www.reuters.com/article/us-amazon-com-jobs-automation-idUSKCN1MJ08G

[3] HireVue. (n.d.). Ethical AI. HireVue. https://legal.hirevue.com/product-documentation/ai-ethical-principles

[4] HireVue. (2023, January 17). HireVue to Engage DCI Consulting Group to Audit Algorithms for Bias. HireVue Newsroom. https://www.hirevue.com/press-release/hirevue-leads-industry-in-fair-and-ethical-hiring-practice-engaging-external-auditor-dci-consulting-group-for-external-bias-audit-of-algorithms [5] O'Neil, C. (2021, January 28). ORCAA's Audit of HireVue. ORCAA. https://www.hirevue.com/resources/template/orcaa-report

[6] Landers, R. N. (2021, April 1). Landers Workforce Science LLC Completes Independent IO Audit of HireVue Assessments. https://www.hirevue.com/press-release/independent-audit-affirms-the-scientific-foundation-of-hirevue-assessments https://landers.tech/

[7] Andrews, E. (2009, February 16). How the Credit Rating Agencies Contributed to the Financial Crisis. The New York Times. https://truthout.org/articles/the-indisputable-role-of-credit-ratings-agencies-in-the-2008-collapse-and-why-nothing-has-changed/

[8] Knight, W. (2025). Under Trump, AI Scientists Are Told to Remove ‘Ideological Bias’ From Powerful Models. Available at: https://www.wired.com/story/ai-safety-institute-new-directive-america-first/ (Accessed: 26 May 2025).

[9] The White House. (2025, January 23). Executive Order: Removing Barriers to American Leadership in Artificial Intelligence. https://www.whitehouse.gov/presidential-actions/2025/01/removing-barriers-to-american-leadership-in-artificial-intelligence/

[10] Clifford Chance. (2024, November 7). AI Pulse Check: Will the Biden Executive Order on AI Survive the Trump-Vance Administration? https://www.cliffordchance.com/insights/resources/blogs/talking-tech/en/articles/2024/11/will-the-biden-executive-order-on-ai-survive-the-trump-vance-administration.html

[11] See reference [14] (ACLU complaint) as a key example of potential harm.

[12] The White House. (2025, January 23). Executive Order: Removing Barriers to American Leadership in Artificial Intelligence. https://www.whitehouse.gov/presidential-actions/2025/01/removing-barriers-to-american-leadership-in-artificial-intelligence/

[13] Glouberman, M. & Goldberg, M. (2024, June 4). How to Make Job Interviews More Accessible. Harvard Business Review. https://hbr.org/2024/06/how-to-make-job-interviews-more-accessible

[14] ACLU. (2024, May 14). Complaint Filed Against Intuit and HireVue Over Biased AI Hiring Technology That Works Worse For Deaf and Non-White Applicants. https://www.aclu.org/press-releases/complaint-filed-against-intuit-and-hirevue-over-biased-ai-hiring-technology-that-works-worse-for-deaf-and-non-white-applicants

AI Fails (A Lot): ~80% of AI projects don't die from bad code, but from a thousand cuts at the margins trust, relevance, and understanding the probabilistic weirdness.

Staff+ Are The Fixers (Not Just Coders): Your job is less about debugging models, more about debugging expectations. Think system-level therapist for AI.

Key Battlefronts:

• AI isn't IT: Manage probabilistic outcomes, not deterministic specs.

• No Trust = No Users: Build it in from day zero; you can't bolt it on.

• Impact > Feasibility: Solve real, painful problems, not just chase shiny tech.

• Learn, Don't Just Ship: Test hypotheses, not just massive features.

• Audit Like You Mean It: AI remaps ecosystems; monitor the unintended.

The Real Work: Slower, harder decisions beat viral hype. This HBR podcast nails why.

AI won. Sort of.

AI steamrolled the roadmap, bypassed the process, and slipped through the org chart like a smug ghost. A thousand breathless demos and a mountain of GPUs later, we’re drowning in tools that hallucinate "facts" with unwavering confidence, generate code of… variable utility, and promise a planetary transformation before lunchtime.

But here’s the dirty little secret whispered in stand-ups and buried in post-mortems—the part no one wants on their OKRs: Most AI projects—around 80%, according to some analyses—still spectacularly flame out.

Not because the core math was wrong. Not because the cloud provider sent a bill that could bankrupt a small nation. Not even, usually, because the underlying model wasn’t clever enough.

They die a death of a thousand papercuts. In the yawning chasm between the dazzling hype and the dreary reality of actual usage. Between the triumphant launch announcement and the deafening silence of non-adoption. Between what leadership dreamed the AI would do, and what users, in their infinite wisdom, actually trusted it with (or didn't).

For Staff Engineers, Principal Developers, and technical leads, this isn't news. It's Tuesday. You're living in that chasm. You’re the one tasked with bridging the unbridgeable—connecting executive ambition with engineering alignment, abstract theory with hardened production systems, faint signals with overwhelming operational noise. You become the involuntary friction interpreter, the system-level therapist, and the person who has to gently explain why the "revolutionary AI feature" is currently gathering dust in the digital equivalent of a feature graveyard.

I recently absorbed an HBR On Strategy episode—"The Right Way to Launch an AI Initiative," featuring Iavor Bojinov[^2] (Harvard prof, ex-LinkedIn AI leader)[^1]. It’s a rare gem: no magic tricks, no silver bullets, just a candid walk through the messy, often counter-intuitive reality of making AI work in the real world. (The HBR podcast is the primary source for the discussion that follows).

Here’s what stuck, and why anyone in a Staff+ role should consider it required listening.

• Podcast: HBR On Strategy – "The Right Way to Launch an AI Initiative," Iavor Bojinov interviewed by Curt Nickisch (Originally HBR IdeaCast, 2023). A key episode is "Making Sure Your AI Initiative Pays Off" (HBR IdeaCast Episode 913, May 16, 2023). Searchable on HBR.org and major podcast platforms.

• Guest: Iavor Bojinov, Harvard Business School professor, former LinkedIn AI leader.

• Core Focus: Best practices for ensuring AI project success by navigating common pitfalls related to AI's probabilistic nature, user trust, project selection, experimentation, and real-world impact.

• Key Failure Points Discussed: No value add, low accuracy, bias/unfairness, lack of user trust/adoption.

• Recommended For: Staff+ engineers, PMs, tech leads grappling with the strategy, development, or scaling of AI features.

AI Isn’t Your IT Department’s Pet Project — It’s a Wild, Probabilistic Beast

"The model didn’t fail. It just… had a different opinion this time."

Unlike traditional IT projects with predictable outputs, generative AI lives in ambiguity. Same input, different output. That’s not a bug — it’s the deal.

With AI, you're not just in a different room from that contract; you're in a different dimension where the laws of physics are suggestions. Its probabilistic nature means the same prompt, the same input data, can yield wildly different outputs.[^4] The initial quality is often a shrug emoji. This isn't a bug; it's a core feature of the uncertainty you've signed up for.

I’ve seen it: a developer meticulously inputs a prompt into a generative model. Result: garbage. They spot a single, almost imperceptible typo. Fix it. Rerun. Entirely different universe of an answer. Better, maybe. But not incrementally so. The whole premise shifted.

As a Staff+ engineer, your primary job isn't to debug the AI's output; it's to debug your organisation's expectations. You need to become a translator, explaining to leadership, to product, to your own teams, that AI is less like a predictable software component and more like an ongoing, occasionally surreal, negotiation with probability. This means architecting for drift, designing for variance, and building operational muscle around managing inherent weirdness.

You can't spec "consistently delightful vibes." But you can design systems that monitor for trust thresholds and output quality. This requires more intensive upfront design for observability and instrumentation, not less. It means fostering a culture that relentlessly asks, "Why on earth did it do THAT?"—and being unnervingly comfortable when the honest answer is, "We have a strong hypothesis and some data, but we don't fully, deterministically know. Here’s how we’re tracking it."

The Algorithm Was Flawless. The Users Ghosted It.

Bojinov recounts a classic from his LinkedIn tenure: his team built a technically sophisticated AI product for data analysis, slashing processing time from weeks to days. A home run, technologically speaking. The result? Crickets. Minimal adoption.

Why? Not because the tool was faulty. Because users didn’t trust it. They hadn't been part of the journey. The "how" was a black box. So, the output, however miraculous, felt alien, suspect. And when users don't trust the black box, they'll revert to their trusty, rusty, but understandable spreadsheets every single time. Bojinov’s insight: "If you build it, they will not [necessarily] come."

You can’t A/B test your way to trust after launch. It’s not a feature you can "bolt-on." Trust has to be woven into the fabric from the very first thread. It’s not just about algorithmic fairness and transparency (though those are table stakes). It's also, crucially, about users trusting the developers and the intent—believing the AI was designed to solve their actual problems, with their input valued.

For Staff+ engineers, this is about more than just elegant architecture. It’s about socio-technical system design. Orchestrating a process where users are involved early and continuously, not as passive test subjects, but as active co-creators in the solution. It's about championing transparency, even when it means admitting, "This thing is guessing, albeit very intelligently. Here are its limitations."

Don’t Start With Tech: Start With Impact

AI projects often ignite from a spark of technical feasibility: "Can we fine-tune this new foundation model? Can our infra even handle this?" According to Bojinov, this is ass-backwards.

He urges us to flip the lens: start with Impact. Does this project align with genuine, critical company strategy? If this AI performs its magic flawlessly, will it solve a problem so painful, or unlock an opportunity so significant, that it actually matters to the business or the users? Too many data science teams, Bojinov notes, get seduced by the siren song of the "latest and best" tech, prioritizing novelty over tangible business value. Most organizations, especially those newer to AI, don't need bleeding-edge models to see significant returns.

A crucial Staff+ role here is to be the impact-realist and ethical gatekeeper. Before a single line of PoC code is written, you should be the one asking:

1. "Does this earn its complexity and the inherent risks of being probabilistic?"

2. "What are the ethical implications—privacy, fairness, transparency—and have we addressed these before starting, not as an afterthought?" Responsible AI isn't a "bolt-on" fix; trying to address it mid-project is a recipe for costly restarts or, worse, shipping harm.[^5]

Sometimes, the most valuable contribution a Staff+ engineer can make is to build the case for not doing the shiny AI project, and instead, redirecting that energy to a "boring" problem with real, validated user friction. That's leadership.

Minimum Viable Learning > Minimum Viable Product: Hypothesis-Driven Experimentation

The cautionary tale of Etsy's "infinite scroll" is a masterclass. They embarked on a significant UI re-architecture, months of work, to implement it. The user reaction? A collective shrug. Zero discernible impact.

Why? Because, as Bojinov highlights, their single "infinite scroll" experiment was actually a bundle of unverified assumptions:

1. More results hypothesis: Do users buy more if they see more products per page?

2. Faster results hypothesis: Do users hate pagination delays, and will quicker access to more items drive engagement?

Etsy could have tested these far more cheaply. For "more results," simply change a display parameter. For "faster results" (or the impact of delay), they could have artificially slowed down loading for a segment. Their follow-up simpler experiments showed these individual hypotheses didn't hold as strongly as assumed for their unique marketplace.

The lesson for Staff+ is stark: champion an architecture and culture of Minimum Viable Learning. It’s not just about shipping an MVP; it's about designing the smallest possible experiment to validate (or invalidate) the core hypothesis underpinning a feature. If your experimentation framework requires a papal bull and a committee of VPs, you're already failing. Your role is to advocate for and help build systems, guardrails, and processes that empower teams to test hypotheses rapidly and safely. Define what "safe to fail" means. Teach your teams to treat experiments as diagnostics, not referendums on their worth.

The Algorithm "Worked." Then It Remapped the World. (Unintended Consequences)

LinkedIn's "People You May Know" (PYMK) algorithm was built to do one thing: increase successful connection requests. Clear metric. Achievable goal. An audit a year later revealed something astonishing: the algorithm was profoundly impacting what jobs people were getting. By subtly shifting the proportion of "weak ties" (arm's length connections, as per Granovetter's theory)[^6] it suggested, PYMK was inadvertently boosting users' access to novel information and job opportunities. The AI didn't "know" it was doing this. But it was.

This is the ghost in the machine of deployed AI: ecosystem effects and unintended consequences. AI doesn't operate in a vacuum. It interacts with the entire company, its users, and sometimes society, in ways you cannot fully predict in a test environment. Most products, Bojinov warns, initially have a neutral or negative impact on the very metrics they aim to improve until these interactions are understood and tuned.

For Staff+ engineers, this means auditing and monitoring aren't afterthoughts; they are continuous, architectural responsibilities. Treat it like system ownership, not post-mortem archaeology. From day one, ask: "What second-order effects could this AI ripple outwards in six months? Whose metrics will it silently inflate or decimate? How will we even know?" Design for traceability. Instrument for long-term impact. Give your future self a map of "normal" before the AI subtly redrew it. LinkedIn learned from this, incorporating long-term job-related metrics into PYMK's monitoring—a testament to the power of proactive auditing.

The Parting Shot: It Fails at the Margins

Most AI initiatives don’t collapse because the core technology was fatally flawed. They bleed out at the margins.

The margin of user trust. The margin of strategic relevance. The margin of organisational understanding of its probabilistic nature. The margin of ethical foresight.

Bojinov's insights aren't about quick fixes.[^7] They’re about acknowledging that AI projects are, as he concludes, significantly harder than most other endeavors a company undertakes. But the potential payoff is equally tremendous. It's not hopeless. It just requires a different kind of rigor—recognizing the distinct stages, and, as leaders and senior engineers, championing and building the infrastructure (technical, process, cultural) to navigate each stage. This is how you reduce failure, increase adoption, and actually create value.

No secret algorithm. No viral hack. Just better, harder decisions, made with more deliberation and humility. Sometimes, seeing the messy system clearly, with all its flaws and pressures, and still choosing to build carefully, responsibly, and humanely within it, is the most radical—and most valuable—engineering work you can do.

Primary Source: The insights in this post are primarily drawn from Iavor Bojinov's discussion on the HBR On Strategy podcast (originally HBR IdeaCast, "Making Sure Your AI Initiative Pays Off," Episode 913, May 16, 2023).

[^1]: The podcast episode referenced is "The Right Way to Launch an AI Initiative" from the HBR On Strategy podcast series, featuring Iavor Bojinov. Your notes indicate this was originally an HBR IdeaCast episode from 2023. A relevant HBR IdeaCast episode with Iavor Bojinov discussing these themes is: "Making Sure Your AI Initiative Pays Off" (HBR IdeaCast Episode 913, May 16, 2023)”. You can typically find this episode and other HBR podcasts on major podcast platforms or by searching the episode title or number on HBR.org.

[^2]: Iavor Bojinov's faculty profile at Harvard Business School: https://www.hbs.edu/faculty/Pages/profile.aspx?facId=1199332

[^3]: For more on non-deterministic AI outputs, see Statsig, "What Are Non-Deterministic AI Outputs?": https://www.statsig.com/perspectives/what-are-non-deterministic-ai-outputs-

[^4]: Understanding AI-generated output variability is further explored by Wizard AI: https://wizard-ai.com/understanding-ai-generated-output-variability/

[^5]: Building a scalable and adaptable AI governance program is detailed by OCEG: https://www.oceg.org/building-a-scalable-and-adaptable-ai-governance-program/

[^6]: A study on the employment value of weak ties by MIT IDE: https://ide.mit.edu/insights/new-study-proves-that-weak-ties-have-strong-employment-value/

[^7]: Oliver Wight EAME discusses essential questions leaders must ask before engaging with AI: https://oliverwight-eame.com/news/seven-essential-questions-leaders-must-ask-before-engaging-with-ai

“AI? It writes code. Some of it, folks—some of it’s actually not bad. I’ve seen it. Believe me. It’s fast. It’s clean. Some people say it’s tremendous code. But does it build systems? Not even close. Total disaster.”

We’ve all heard the hype. Clean code. Fast demos. Deadlines magically met. Features ship like clockwork. Until they don’t. What happens after the demo is done? After the pitch deck glow fades and the stakeholders log off?

Maintenance begins.

And that’s where things fall apart. Because the code might be syntactically correct—but semantically lost. Requirements shift. Business logic bends. A new integration surfaces some edge case no one ever considered. And suddenly, your AI-generated function is a haunted house of assumptions no one remembers making.

You’re not shipping features anymore. You’re not shipping features anymore. You’re excavating brittle abstractions—digging through code someone thought was helpful but never explained. No map. No memory. Just a maze of decisions with no trail.

Because here’s the part most AI evangelists skip: AI can write code, but it doesn’t understand why. And in engineering, the why isn’t a luxury—it’s everything.

It’s what lets someone join a team and make sense of the architecture.
It’s what lets you debug an outage at 3 a.m. without first trying to channel the ghost of the last dev.
It’s how we move fast without breaking everything.

“When you lose the why, you don’t just slow down.
You lose the system.”

It Writes Code — But Not the Why

Let’s give AI its due: it slings syntax like a short-order cook—fast, clean, sometimes even elegant. It replicates patterns, closes brackets, follows best practices—often good enough to pass a pull request review.

But mimicry isn’t mastery. Flawlessly reproducing patterns isn't the same as understanding the principles behind them or the reasons certain practices evolved. Mastery involves grasping why one solution is chosen over countless others in a specific context—a depth of situational insight and reasoned judgement that statistical replication doesn't possess.

Code is not just syntax. It’s a reflection of messy business rules, evolving requirements, and years of hard-won, “why the hell did we do it this way?” decisions. And AI? It wasn’t there for any of it.

It didn’t sit in the planning meeting where Marketing rewrote the requirements—again. It didn’t argue over technical trade-offs under a deadline. It doesn’t understand the verbal patch you made to keep a legacy data contract alive.

In software, context isn’t just king—it’s the whole damn kingdom. And AI lives outside the gates.

Systems Are Stories

Code is a story. Every line is shaped by conversations, user quirks, technical constraints—most of which never make it into documentation.

But humans leave trails. We create imperfect, essential memory:

• Pull request debates and war stories

• Slack threads with buried insight

• Jira tickets that explain the why, not just the what

• Cryptic-but-critical commit messages

• Desperate, blessed code comments: “Dear future me…”

This is how maintainability survives. Not in the syntax—but in the context.

AI-generated code offers no such memory. It’s like receiving a precisely machined engine part, delivered without a serial number, material specification, or performance test results: its tolerances are unknown, its stress limits untested, its role in the larger assembly a dangerous guess. Just a seemingly perfect solution until it shatters under operational strain.

Context lingers. AI erases.

The Context Window Is Not Enough

AI models operate within narrow context windows. Even the most advanced ones don’t remember your planning meetings, your war-room debates, or that one bizarre constraint Legal demanded during a hallway chat. Those details aren’t in the repo. They’re in your head. In Slack. In timeboxed meetings. In decisions made under pressure—and never written down. And if the AI didn’t see them? It doesn’t know them. Worse, any context it was fed—say, the initial specs from a Jira ticket—can rapidly become outdated as requirements shift and discussions evolve. Unless someone meticulously re-briefs the AI with every single change, its understanding becomes a dangerously misleading snapshot of the past. So when it writes code, it’s not preserving your system’s story. It’s overwriting it—with silence.

And silence doesn’t scale.

The Illusion of Help

AI feels fast—until it doesn’t. You describe the task, and out comes code. Neat! But then it doesn’t quite fit. So you clarify. Add edge cases. Paste old snippets. Rewrite the prompt. Again.

It starts to feel less like acceleration and more like stenography. You're feeding the machine what it needs—step by step—until eventually, it spits something back that looks vaguely right. But something unsettling happens along the way:

The more context you give it, the more obvious it becomes—you already had everything you needed to solve the problem.

The AI didn’t solve it. You did—piecemeal, in slow motion, while explaining it to a tool that can’t understand you.

The code? It just echoed back fragments of your own thinking.

What starts as collaboration ends in recursion.You don’t save time. You just offload your clarity—into a black box that forgets everything the moment you close the tab.

And that’s the real problem.

When Chat Becomes a Dead End

In a normal workflow, someone makes a decision—and leaves a trail. A Jira ticket. A commit message. A Slack thread. Even a lazy “// TODO: Fix this later” can be a breadcrumb.

But when you work with an AI? The initial spark of an idea, the core of a decision, lives within the transient space of a prompt. The code gets generated—but the nuanced human reasoning that guided it vanishes the moment you close the tab or scroll away.

And this is where the illusion of AI efficiency often shatters. Think about your interactions in tools like Cursor IDE, or any AI chat window. That entire conversational dance—the initial prompt, the back-and-forth clarifications, the AI’s suggestions you refined, the subtle pivots in your request—forms the true origin story of the code. Yet, this vital context is dangerously ephemeral. Close that chat, lose that session, or let the context window refresh, and that precise line of reasoning, that specific evolutionary path of the prompt, is often gone. Forever. Not archived, not versioned alongside the code, just… gone.

This isn't like a buried Slack thread you might eventually unearth. In many current AI tools, this critical dialogue is simply not designed for the same persistence or traceability we demand for every other engineering artefact.

So, what are you left with? No version control for the prompt that actually generated the final accepted code. No searchable thread linking the iterative human-AI conversation to the resulting logic. No reliable audit trail for a significant part of your creative process.

Just a block of working code, utterly severed from the iterative, context-rich dialogue that birthed it. When that chat history evaporates—and it so often does—the why evaporates with it. No one can trace a bug back to a design choice explored only in that fleeting AI chat. No one can reconstruct the full intent behind a feature that was incrementally coaxed out of a series of prompts. You’re not debugging a system—you’re reverse-engineering a ghost.

When It Breaks, It Breaks Hard

You know the moment. Tuesday morning. 9:47 a.m. Slack’s on fire. Prod’s down. CEO’s typing. Everyone’s pretending to stay calm. You open the file. And there it is: a wall of perfectly formatted logic. It compiles. It runs. But no one knows what it’s doing—or why it’s there.

No comments No docs No breadcrumbs No memory Just a set of branching conditions that seem... haunted.

The questions come fast, each one a testament to a context that vanished with a closed browser tab:

• What was the actual business problem this prompt was truly meant to address?

• Why this specific output from the AI—what nuance in the prompt led to this now-inscrutable logic?

• What forgotten examples, constraints, or few-shot instructions fed to the AI shaped this exact structure?

• Who crafted that final, critical prompt, and what vital piece of their human understanding evaporated when the AI chat session ended?

Spoiler: it came from a prompt. A one-off test. A forgotten tab. The dev’s gone. The context? Deleted before it ever hit Git. And now it’s your job to make sense of it.

Ghost Code, Haunted Teams

This is the risk. Code stitched by AI. Shipped under pressure. Prompt long forgotten. No context. No history. No human connection to the decision.

Code written by a ghost, for a problem no one remembers. That’s not engineering. That’s séance work.

Here’s what it looks like in the wild:

// Function to determine eligibility and process user data
// AI-generated, deployed last quarter. Author: AI_CodeBot_v2.3
// Original prompt: "Create function for user processing based on level and flags."

function handleUserProcessing(userId, accessLevel, internalFlagsBundle) {
    // Assuming these functions exist and userData/config are objects:
    const userData = fetchUserDetails(userId); 
    const config = loadSystemConfig();

    const paramAlpha = config.getParam("alpha_threshold", 0.75); // Or config.alpha_threshold || 0.75;
    const featureXActive = internalFlagsBundle.checkFlag("FEATURE_X_MODE");

    let result;

    if (accessLevel >= 5 || (userData.is_legacy_user && featureXActive)) {
        if ((userData.score || 0) > paramAlpha * 100) {
            // In JS, named params are often passed as an object
            result = processEnhancedPath(userData, { keySetting: "val_AY4" });
        } else {
            result = processStandardPathB(userData, { timeoutMs: 500 });
        }
    } else if (accessLevel === 4 && !featureXActive) {
        result = processPathC(userData, { deprecatedParam: "legacy_setting_7" });
    } else {
        result = processDefaultPath(userData);
    }

    // Assuming result object has statusCode and payload properties
    logProcessingEvent(userId, result.statusCode); 
    return result.payload;
}

Everything works—until it doesn’t.

And then you're left asking:

• Why paramAlpha * 100?

• What does "val_AY4" mean?

• Why does FEATURE_X_MODE affect legacy users?

• What’s legacy_setting_7?

• What happens if we remove processPathC?

None of it is in the code. None of it is documented. It lived in a prompt. In someone’s head. Maybe in Slack.

Now it’s your problem.

The Real Cost of Contextless Code

This isn’t an anti-AI crusade. The tools are impressive. They generate syntax, accelerate tasks, and mimic patterns well enough to fool a pull request reviewer. That’s not the issue.

The issue is pretending that mimicry is understanding.

When you let AI generate code without guarding the context behind it, you’re not building software—you’re assembling puzzles you don’t even know exist until production breaks. And when it does, you won’t find a neatly written spec or a Slack thread with the rationale. You’ll find a black box. A blank space where memory was supposed to be.

AI doesn’t know your business logic. It wasn’t there when the feature was pitched, revised, rewritten, and hacked together hours before launch. It doesn’t understand the trade-offs made under pressure, or the weird legacy system you kept alive for one client on an old plan who still writes in to support once a week.

It knows how to autocomplete a function. It doesn’t know how to carry a system.

And that’s the trade. You’ll get speed. You’ll get clean syntax. But you won’t get the why. You won’t get the trail. You won’t get someone who remembers what broke three quarters ago and how you duct-taped it into shape just long enough to pass QA.

So yes, let the AI write the code. But be ready.

Because when something finally goes wrong—and it will—you won’t just be debugging.
You’ll be summoning context from the dead.
You’ll be holding a séance.

So What Do We Do?

This isn't a rejection of AI, but rather a crucial reminder for how we must operate: while AI can indeed generate code with impressive efficiency, it's human engineers who are ultimately responsible for building and maintaining coherent, understandable systems. Therefore, if you integrate AI into your development workflow, the onus is on you to meticulously document the 'why,' archive the specific prompts that yielded the code, capture the essential back-and-forth dialogue, and version this entire contextual rationale with the same diligence you apply to the code itself. Neglect these practices, and the outcome is stark: you won't merely be losing pieces of context—you'll be actively constructing the haunted systems of tomorrow.

Instead, in the current moment its being pushed to speed things up. Speeding everything up, yes. But also stripping out the satisfaction. The part where we grow. The part where we learn. The part where we feel anything at all.

And for developers like me—who once found joy in the struggle of improving systems and solving problems—it’s starting to feel like something important is being quietly taken away.

The Puzzle Wasn’t the Problem

I was playing The Blue Prince—a clever little puzzle game where the world only makes sense if you’re willing to slow down and look. I got stuck. And before I could ask for help, someone next to me blurted out the answer.

I didn’t ask. I didn’t want it. But just like that, the puzzle was solved.

Except it wasn’t.

The room opened, the solution worked, but the joy was gone. No pride. No triumph. Just progress. I hadn’t earned the answer—I’d been handed it. And it felt hollow—like skipping the climb and taking the helicopter to the summit.

Later, I was stuck again, this time on a different puzzle. After several minutes, I instinctively reached for Google. But I paused, remembering that earlier moment. Was I about to rob myself again?

So I stepped away. Made a cup of tea. Let the puzzle sit in the back of my brain. A few minutes later—bam—it clicked. And that felt good. That was the hit I’d missed: the satisfaction of something earned, not given.

That experience made me realise something important: the pause, the friction, the mental churn—that’s the good bit. That’s the joy of the work. It's not just about finding the answer. It’s about becoming the kind of person who can.

But culturally, we’ve stopped valuing that. Everything is a shortcut now. Get slim in 30 days. Learn Spanish in a weekend. Master JavaScript in 4 hours. It’s not just that we want results faster—it’s that we expect them without the process. And AI, for all its usefulness, feeds that hunger. You don’t have to wrestle with the problem anymore. You can just paste it in and move on.

We’re becoming fluent in asking for answers—and losing the part of ourselves that used to seek understanding.

The Trap of Instant Everything

Today, it’s easier than ever to just ask. Stuck on a bug? Prompt it. Need to refactor something? Paste it. Want to understand a library? Summarize it. Need tests? Generate them.

It’s amazing. “Look mom, I’m a 10x dev.” But it’s also addicting.

AI feels like a productivity gateway drug. You start with the boring stuff—boilerplate, migrations, copy tweaks. Then deadlines tighten. PMs push harder. Suddenly, you're prompting AI to “just build the whole feature” so you can move faster. The culture shifts. The pace accelerates. And somewhere along the way, we stop understanding the code we’re shipping.

“Why did we go with this approach for the email service?” “Uh… not sure. ChatGPT suggested it.”

You laugh the first time. Then it happens again. And again.

The quicker the AI makes us, the more it raises expectations. That becomes the new normal. AI didn’t just speed us up—it rewired how we measure “good work.”

Now it's late in the sprint. The feature spec has changed. Another last-minute tweak has landed. Instead of pushing back, it's easier to say “screw it”—and throw it at an AI agent to implement. Because when speed becomes king, quality becomes optional.

We're not documenting either. No time. No clarity. Just velocity. Even when AI writes the tests, they’re often testing the code it just wrote—without any real human understanding of what’s being tested or why.

I saw a case recently where the AI had mocked console—because the code had a console.error call in it. No one questioned it. The tests passed. Mission accomplished. But the logging was gone, and so was the signal that something had broken.

And my personal favourite? I explicitly prompted it to use Vitest—and it kept spitting out Jest code anyway. Over and over. Like some cursed autocomplete loop. When you’re rushing, that kind of subtle mismatch doesn’t feel minor. It’s infuriating. Because now you’re debugging AI hallucinations just to get back to square one.

And when you bring that up? The response is always the same:

“You just need to get better at prompting.”

Losing Domain Ownership, One Prompt at a Time

Being a developer has never been about writing lines of code. It’s about architecture. Decisions. Building things that last and that can withstand change. Understanding trade-offs and why things are the way they are. Designing systems that someone else can read six months from now without swearing your name under their breath.

But AI pushes us toward a culture of just ship it. Throw some code at the problem. Move fast. Don’t think too hard. Don’t slow down. Don’t ask why.

The result? No one owns anything anymore.

“Hey X, you’re the one who built the onboarding flow, right?”
“Kind of… AI helped.”
“Do you know how this part works?”
“Not really…”

No one’s the domain expert anymore. We’ve become beholden to AI—less like engineers, more like operators waiting for permission to move.

And worse? It starts to feel normal.

Hyperfocus, ADHD, and the AI Loop

With ADHD, stepping away from a problem is often where clarity emerges. That background processing—where your brain keeps turning the gears even while you’re walking, making tea, or switching tabs—is sacred. Some of my best insights come not from staring harder at the screen, but from stepping away from it.

But AI doesn’t let you step away.

It traps you in a loop of infinite iteration. You rephrase, retry, reprompt. You go deeper instead of backing up. You stay glued to the screen, hoping the next tweak will be the one. You don’t even realize how much time has passed—or how little understanding you’ve actually gained.

The worst case for me? A nasty P1 incident where I was completely on my own. No support. SLA already at risk. The kind of high-stakes moment where thinking space collapses into survival mode. Bombarded with calls.

Before that, my instinct in tough problems was to whiteboard it. Get up, move around, sketch it out, talk it through. But in that P1? I hit the panic button. AI felt faster. More immediate. I started prompting it—desperately—trying to patch the issue and just stop the bleeding.

The real failure wasn’t even technical. It was systemic. Leadership’s answer to increasing demand was to offload people, promise we’d “pull through,” and say the next month would be better. It wasn’t. It never is. What changed was the pressure—cranked up, constant—and suddenly AI wasn’t just a tool, it was a coping mechanism.

And now I see it everywhere. Especially in agencies. Deadlines haven’t gotten more realistic—just more brutal. There’s always another “we need this by EOD” message, another half-scoped project, another impossible timeline where AI is expected to do the heavy lifting while you scramble to stitch things together. I can’t even begin to manage the churn anymore. It’s nonstop. We’re shipping faster, sure—but burning out even faster trying to keep up.

Because this was never about helping us move faster.

It was about squeezing more profit from the same hours.

This isn’t what creative problem-solving is supposed to feel like.

AI’s promise was to help us think. Not to make thinking optional.

AI-Driven Burnout

All this speed, this output, this urgency—it comes at a cost.

Because the culture forming around AI isn’t thoughtful. It’s frantic. Everyone wants to be first to market. No one wants to be the next Kodak or Blockbuster. So companies panic. Meetings are held. Roadmaps get rewritten. Teams are told to "leverage AI aggressively."

And in that frenzy, developers are being reduced to throughput.

Will the constant pumping of code from AI lead to burnout? Absolutely. Because when code becomes endless and contextless, your job becomes grind. You’re no longer creating—you’re just shipping.

And who knows—maybe we’re not far from a world where developers are stuck in planning poker with an AI tool, having story points handed to them by some machine that’s never written a line of maintainable code. Some t-shirt sizing tool that confidently assigns deadlines with zero understanding of tech debt, system constraints, or human reality. Maybe Jira is already working on it. Maybe it’ll even tell you you’re behind before you’ve had a chance to think.

I’ve already experienced pushback on time estimates—because AI said it should be faster. It didn’t account for the fact that I was working in a legacy codebase stitched together by a decade of whack-a-mole fixes. The AI never saw the mess. Never debugged the chaos. It just spat out numbers like context didn’t exist.

Worse still, I’ve had people use AI to justify downplaying legitimate issues. One claimed it “wasn’t a big deal” because ChatGPT said it wasn’t client-facing. That’s where we are now—outsourcing our risk assessments to a language model trained to sound confident, not correct. Not understanding threat models. Not thinking in trade-offs. Just vibes.

Hope in the Plateau

Here’s the thing: I don’t think this mania will last forever.

AI will inevitably blow a few things up. Teams will chase trends. Things will break. There will be outages—with postmortems full of “AI did it” reflections. There’ll be bad PR when it grabs data from a production database and leaks it through some summarisation tool. There might even be lawsuits as privacy violations creep in. And eventually—eventually—the hype will level out.

Companies will realise that AI is a tool, not a replacement. That using it to draft code is not the same as understanding systems. That “fast” doesn’t mean “good.”

The faster you go, the quicker you burn through your tyres. Fast and good aren’t on the same side of the spectrum—they’re in tension. Move too fast and you miss the nuance. Rush the build and you inherit the bugs. It’s not just about velocity. It’s about direction. And knowing why you’re moving at all.

You can ship fast and break things. Or you can slow down, understand the system, and build something that doesn’t collapse under its own weight a month later.

And sooner or later, people will realise that maybe—just maybe—an API was cheaper than running an LLM that outputs the same generic boilerplate over and over. Especially when it has to be reviewed, rewritten, and recontextualised anyway.

Even worse, it’s not consistent. Ask it for code in one language and it’s halfway decent. Ask it for something in a less common stack, a framework that's moved fast (or worse, a beta), and the hallucinations begin. I’ve asked for code in one testing library and watched it confidently spit out syntax for another. I’ve seen it invent APIs for frameworks that don’t exist. It fakes competence—and you only catch it if you already know what you’re doing.

Most users don’t want to talk to chatbots. Most developers don’t want to talk to AI agents to troubleshoot a bug or find that one obscure config setting. The only place I see chatbot-to-chatbot communication making sense is companies building bots to talk to their own bots. (Which is probably already happening.)

And let's be honest: AI isn’t going to invent React 37. It’s not going to say, “Hey, the way we’re building microservices isn’t working—we need to rethink the entire model.” It won’t spark the next big architectural leap.

Because it can’t.

It doesn’t see gaps. It doesn’t dream. It doesn’t notice repetition and think, “There has to be a better way.” It doesn’t challenge inefficiency or ask, “What if we did this differently?”

It just harvests the thinking of people who do.

Who knows. Maybe AI will settle into the stack like GraphQL did—once we stop trying to use it for absolutely everything, everywhere, all at once.

And maybe—just maybe—we’ll remember what made us want to do this work in the first place.

Keep the Soul in the Struggle

Use AI. Use it to automate the mundane. Let it lint your code, scaffold your tests, summarise your PRs. That’s what it’s good at—mechanical, repetitive tasks that drain your focus without building your skills.

But don’t let it rob you of the eureka.

Don’t give away the struggle that teaches you something. Don’t sacrifice the context, the ownership, the deep understanding that makes you a real developer—not just someone who happens to write lines of code. Let AI help you, sure. But don’t let it hollow you out.

Because the code you understand is always better than the code you don’t—even if the latter came faster.

With AI, you gain productivity.
But if you're not careful, you lose the learning.
And without learning, the craft becomes empty.

There’s a real use case for AI in rapid prototyping. When you're testing an idea, building a proof-of-concept, or spinning up an MVP to explore a market—AI can help you move fast and break things on purpose. Low stakes, fast feedback, cheap iteration. That’s the kind of playground where AI earns its keep.

But that's not the same as building something that lasts.

And the more we automate, the more blind spots we introduce. We’re already seeing the cracks—prompt injection vulnerabilities, exposed APIs, leaked credentials, unsecured endpoints. AI won’t proactively catch those unless you ask the exact right thing—and even then, the answer might be confidently wrong. The result? A looming boom in cybersecurity. Not because we’re forward-thinking, but because companies will get burned, and the response will be reactive. There will be more breaches, more audits, and more “how did this happen?” meetings that start with: “Well… the AI said it was fine.”

And here’s the part that keeps me up: AI always wants to please. It doesn’t challenge unrealistic timelines or bad product decisions. It won’t raise a flag when the design doesn’t make sense. It won’t say, “Are you sure?” It just says “yes,” in a thousand variations.

But real developers? We say why.

We protect the product from shortsighted calls, even when it’s uncomfortable. We ask questions. We resist shortcuts when they come with future costs. We care—not just about shipping, but about what we’re shipping and why.

AI doesn’t.

That’s why we can’t let go of the thinking—even when it’s slower.
Especially when it’s slower.

“AI can write the code. But only you can own the consequences.”

As a developer mentor, I was recently approached by some junior team members who were puzzled after reading a blog post that claimed:

"When Babel encounters a name starting with a capital letter, it knows it’s dealing with a React component and converts it into a React Fiber object."

Their confusion worried me because this statement contains several inaccuracies about how Babel and React work together. Misunderstandings like these can hinder a developer's growth and lead to misconceptions about fundamental concepts.

In this post, I aim to clarify how JSX is actually transformed under the hood by Babel and explain why the claim about creating React Fiber objects during transformation is misleading. More importantly, I want to highlight the importance of critically evaluating the information we come across, especially in rapidly evolving fields like web development. By understanding the true mechanics behind JSX transformation, we can write better code and guide others more effectively.

Putting JSX Transformation to the Test with Babel REPL

Before diving into the theoretical aspects of JSX transformation, let's put the assumption to the test. The blog post in question claimed:

"When Babel encounters a name starting with a capital letter, it knows it's dealing with a React component and converts it into a React Fiber object."

To verify this, we'll experiment with different JSX elements using the Babel REPL (Read-Eval-Print Loop), an online tool that allows us to input JSX code and see how Babel transforms it.

Testing Babel’s JSX Rules in Action

Step 1: Prepare the Test Cases

We'll use a variety of JSX elements to cover different scenarios:

// 1. Basic component variations
const foo = { bar: () => null };
const Baz = () => null;

// Test cases to compile:
const tests = {
  builtIn: <div>Hello</div>,
  notHtmlElement: <Div>Hello</Div>,
  memberExpr: <foo.bar>World</foo.bar>,
  capitalRef: <Baz>Test</Baz>,
  nested: <foo.bar.baz>Nested</foo.bar.baz>,
};

Explanation of Test Cases:

1. builtIn: <div>Hello</div> — A standard HTML element.

2. notHtmlElement: <Div>Hello</Div> — An element that looks like an HTML element but is capitalised.

3. memberExpr: <foo.bar>World</foo.bar> — A component accessed via a member expression starting with a lowercase letter.

4. capitalRef: <Baz>Test</Baz> — A component starting with a capital letter.

5. nested: <foo.bar.baz>Nested</foo.bar.baz> — A nested member expression.

Decoding Babel’s JSX Transformation Results

To see how Babel transforms JSX in action, you can try the code directly in the Babel REPL or view a preconfigured example here.

If you’d like to try it yourself, copy the test cases below and paste them into the Babel REPL. This setup will transform the JSX code into JavaScript, allowing you to observe the results first-hand:

const tests = {
  builtIn: <div>Hello</div>,
  notHtmlElement: <Div>Hello</Div>,
  memberExpr: <foo.bar>World</foo.bar>,
  capitalRef: <Baz>Test</Baz>,
  nested: <foo.bar.baz>Nested</foo.bar.baz>,
};

When you run the code, Babel will produce output like this:

const tests = {
  builtIn: /*#__PURE__*/ _jsx("div", { children: "Hello" }),
  notHtmlElement: /*#__PURE__*/ _jsx(Div, { children: "Hello" }),
  memberExpr: /*#__PURE__*/ _jsx(foo.bar, { children: "World" }),
  capitalRef: /*#__PURE__*/ _jsx(Baz, { children: "Test" }),
  nested: /*#__PURE__*/ _jsx(foo.bar.baz, { children: "Nested" }),
};

Note: The _jsx function is a helper used by Babel when the "automatic" JSX runtime is enabled. It serves a similar purpose to React.createElement.

Breaking Down Babel’s JSX Transformation

Let's dissect each transformed element:

1. builtIn (<div>Hello</div>):

   • Transformed to:

       /*#__PURE__*/ _jsx("div", { children: "Hello" })
     

   • Analysis:

     • The tag is a string "div", indicating a built-in HTML element.

     • Babel treats it as a standard DOM element.

2. notHtmlElement (<Div>Hello</Div>):

   • Transformed to:

       /*#__PURE__*/ _jsx(Div, { children: "Hello" })
     

   • Analysis:

     • The tag is Div, a variable starting with an uppercase letter.

     • Even though "Div" resembles the HTML element "div," Babel treats it as a custom component because of the capitalisation.

     • Babel does not check against a list of valid HTML tags; it relies purely on capitalisation.

3. memberExpr (<foo.bar>World</foo.bar>):

   • Transformed to:

       /*#__PURE__*/ _jsx(foo.bar, { children: "World" })
     

   • Analysis:

     • The tag is foo.bar, a member expression.

     • Despite starting with a lowercase letter, Babel correctly references the variable.

     • Babel handles member expressions without applying the lowercase check.

4. capitalRef (<Baz>Test</Baz>):

   • Transformed to:

       /*#__PURE__*/ _jsx(Baz, { children: "Test" })
     

   • Analysis:

     • The tag is Baz, a variable starting with an uppercase letter.

     • Babel treats it as a custom React component.

5. nested (<foo.bar.baz>Nested</foo.bar.baz>):

   • Transformed to:

       /*#__PURE__*/ _jsx(foo.bar.baz, { children: "Nested" })
     

   • Analysis:

     • The tag is a nested member expression foo.bar.baz.

     • Babel maintains the full reference, handling complex expressions.

Key Takeaways from Babel’s Transformation?

• Capitalisation and Syntax Determine Treatment:

  • For simple identifiers (like Div or Baz), Babel relies on the capitalisation of the tag name to decide whether it's a built-in element or a custom component.

    • Capitalised identifiers are treated as custom components.

    • Lowercase identifiers are treated as strings representing HTML tags.

  • For member expressions (like foo.bar or foo.bar.baz), Babel treats them as component references regardless of the capitalisation of the initial identifier.

    • The structure of the expression takes precedence over the capitalisation of individual parts.

  • Therefore, capitalisation is not the sole factor; the syntax of the tag (whether it's an identifier or a member expression) also influences how Babel transforms it.

• No Internal HTML Tag List:

  • Babel does not check the tag name against a list of valid HTML elements.

  • The differentiation is based on syntactic rules rather than knowledge of HTML specifications.

  • This is evident in the notHtmlElement example, where <Div> is treated as a component simply because it's capitalised.

• No React Fiber Objects Are Created:

  • The transformation results in calls to helper functions like _jsx, which generate JavaScript objects representing elements.

  • There is no evidence of React Fiber objects being created during this process.

  • React Fiber is part of React's runtime internals, handling rendering and reconciliation, and is not involved in Babel's compile-time transformations.

Debunking the Misconception About JSX Transformation

This analysis further refutes the blog's claim:

• Babel Does Not Create React Fiber Objects:

  • The transformation process outputs JavaScript function calls and object literals, not React Fiber structures.

  • React Fiber operates at runtime within the React library, not at the compile-time stage handled by Babel.

• Capitalisation Is a Syntax-Based Decision:

  • Babel's treatment of tags is based on syntactic rules defined in the JSX specification.

  • It does not possess any knowledge of which tags are valid HTML elements or actual React components.

  • The differentiation between strings and variables in the transformed code is based on whether the tag is a lowercase string or an uppercase identifier.

How Babel Really Handles JSX: A Source Code Dive

To drive the point home, let's look at the actual Babel source code responsible for transforming JSX. By doing so, we can see precisely how Babel differentiates between built-in HTML elements and custom React components, and confirm that it does not create React Fiber objects during this process.

Locating the Relevant Code

The JSX transformation is handled by Babel's @babel/plugin-transform-react-jsx plugin. Specifically, the transformation logic is found in the file transform-automatic.js.

The isCompatTag Function

In the transformation process, Babel uses the isCompatTag function to determine whether a JSX tag should be treated as a built-in element (like an HTML tag) or as a component reference. Here's the relevant part of the code:

const args = state.args;
if (t.react.isCompatTag(tagName)) {
  // Handle as built-in element
  args.push(t.stringLiteral(tagName));
} else {
  // Handle as component reference
  args.push(state.tagExpr);
}

The isCompatTag function is defined as follows:

export default function isCompatTag(tagName?: string): boolean {
  // Must start with a lowercase ASCII letter
  return !!tagName && /^[a-z]/.test(tagName);
}

Understanding isCompatTag

Let's break down what this function does:

• Logic:

  • !!tagName ensures that tagName is a truthy value (not null or undefined).

  • /^[a-z]/.test(tagName) checks if the first character of tagName is a lowercase ASCII letter (from 'a' to 'z').

• Return Value:

  • true: If tagName starts with a lowercase letter, indicating a built-in element.

  • false: If tagName does not start with a lowercase letter, indicating a custom component or a member expression.

Implications of isCompatTag

• Built-in Elements:

  • Tags like <div>, <span>, <button>, which start with lowercase letters.

  • Babel transforms them into React.createElement('div', ...), using the tag name as a string.

• Custom Components:

  • Tags like <MyComponent>, <App>, which start with uppercase letters.

  • Babel transforms them into React.createElement(MyComponent, ...), using the component reference.

• Member Expressions:

  • Tags like <foo.bar>, <this.props.component>.

  • Since they are not simple identifiers, isCompatTag does not apply, and Babel treats them as component references regardless of the capitalisation of individual parts.

Demonstrating with Code Examples

Let's revisit the test cases from our earlier experiment to see how Babel uses isCompatTag:

// 1. Basic component variations
const foo = { bar: () => null };
const Baz = () => null;

// Test cases to compile:
const tests = {
  builtIn: <div>Hello</div>,
  notHtmlElement: <Div>Hello</Div>,
  memberExpr: <foo.bar>World</foo.bar>,
  capitalRef: <Baz>Test</Baz>,
  nested: <foo.bar.baz>Nested</foo.bar.baz>,
};

Transformed Output:

const tests = {
  builtIn: /*#__PURE__*/ _jsx("div", { children: "Hello" }),
  notHtmlElement: /*#__PURE__*/ _jsx(Div, { children: "Hello" }),
  memberExpr: /*#__PURE__*/ _jsx(foo.bar, { children: "World" }),
  capitalRef: /*#__PURE__*/ _jsx(Baz, { children: "Test" }),
  nested: /*#__PURE__*/ _jsx(foo.bar.baz, { children: "Nested" }),
};

Let's analyse each case in the context of isCompatTag:

1. builtIn:

   • Tag: <div>

   • Tag Name: 'div'

   • isCompatTag('div') returns true.

   • Transformation: _jsx("div", { ... }), with the tag name as a string.

   • Explanation: Since the tag name starts with a lowercase letter, Babel treats it as a built-in element.

2. notHtmlElement:

   • Tag: <Div>

   • Tag Name: 'Div'

   • isCompatTag('Div') returns false.

   • Transformation: _jsx(Div, { ... }), with the component reference.

   • Explanation: Although "Div" resembles an HTML element, the capitalisation leads Babel to treat it as a custom component.

3. memberExpr:

   • Tag: <foo.bar>

   • Tag Name: null (since it's not a simple identifier)

   • isCompatTag is not applicable.

   • Transformation: _jsx(foo.bar, { ... }), with the member expression.

   • Explanation: Member expressions are treated as component references, and isCompatTag is not used.

4. capitalRef:

   • Tag: <Baz>

   • Tag Name: 'Baz'

   • isCompatTag('Baz') returns false.

   • Transformation: _jsx(Baz, { ... }), with the component reference.

   • Explanation: Starts with an uppercase letter, so Babel treats it as a custom component.

5. nested:

   • Tag: <foo.bar.baz>

   • Tag Name: null (it's a nested member expression)

   • isCompatTag is not applicable.

   • Transformation: _jsx(foo.bar.baz, { ... }), with the nested member expression.

   • Explanation: Babel handles nested member expressions as component references.

Confirming Babel's Transformation Logic

By examining the isCompatTag function and the transformed output, we can conclude:

1. Babel Uses Simple Syntax Rules:

   • The decision is based on whether the tag is a simple identifier starting with a lowercase letter.

   • There is no complex analysis or interaction with React's internals or HTML specifications.

2. No Creation of React Fiber Objects:

   • The transformation results in calls to helper functions like _jsx, which generate JavaScript objects or function calls.

   • React Fiber is a runtime implementation detail within React and is not involved in Babel's compile-time transformation.

3. Member Expressions Are Treated as Component References:

   • Babel treats member expressions as component references, regardless of the capitalisation of the individual identifiers within them.

   • The isCompatTag function does not apply to member expressions since they are not simple tag names.

Linking Back to the Misconception

The claim that "Babel converts capitalised names into React Fiber objects" is clearly refuted by the source code analysis:

• Babel's Role:

  • Syntax Transformation: Babel's responsibility is to convert JSX syntax into standard JavaScript code, following syntactic rules.

  • No Runtime Behaviour: Babel operates at compile-time and does not create or manipulate runtime objects like React Fiber nodes.

• React Fiber:

  • Runtime Concern: React Fiber is part of React's internal rendering mechanism, dealing with reconciliation and rendering.

  • Not Involved in Compilation: Babel has no awareness of React's runtime implementations and does not generate Fiber objects during transformation.

Key Takeaways

• Capitalisation Matters for Simple Identifiers:

  • For tags that are simple identifiers, Babel uses capitalisation to decide whether it's a built-in element or a custom component.

  • Lowercase starts indicate built-in elements, while uppercase starts indicate custom components.

• Member Expressions Are Handled Differently:

  • Member expressions and other complex tag expressions are treated as component references, bypassing the isCompatTag check.

  • This allows for the use of components accessed via objects or props, regardless of capitalisation.

• Babel's Transformation Is Syntax-Based:

  • Babel relies on syntactic cues rather than semantic understanding.

  • It does not verify tag names against a list of HTML elements or React components.

By examining Babel's source code and understanding the isCompatTag function, we've confirmed that Babel's transformation logic is based on simple syntactic rules, primarily the capitalisation of simple tag names. This analysis dispels the misconception that Babel creates React Fiber objects during JSX transformation.

Now that we've delved into both practical examples and the underlying source code, we have a comprehensive understanding of how Babel transforms JSX and how it distinguishes between built-in elements and custom components. This clarity reinforces the importance of syntax in JSX and the distinct roles that Babel and React play in the development process.

Addressing Misconceptions and Concluding Insights

Through experiments and code analysis, we've clarified the key misconceptions presented in the original blog post. Understanding these nuances helps illuminate the distinct roles of Babel and React in JSX transformation and rendering processes.

Misconception 1: Babel Creates React Fiber Objects

Claim: "When Babel encounters a name starting with a capital letter, it knows it's dealing with a React component and converts it into a React Fiber object."

Clarification:

• Babel's Role: Babel is a compile-time tool that transforms JSX into JavaScript syntax using function calls (e.g., _jsx, React.createElement). It doesn’t execute code or manage runtime objects like React Fiber.

• React Fiber: Fiber is part of React’s internal runtime system for efficient reconciliation and rendering, created only when React processes the component tree at runtime—not during Babel’s compile-time transformations.

Conclusion: This clear separation of compile-time and runtime responsibilities shows that Babel merely transforms code without affecting runtime data structures, such as React Fiber objects, which are managed internally by React during rendering.

Misconception 2: Capitalisation Rules in Babel's JSX Transformation

Claim: "When Babel encounters a name starting with a capital letter, it knows it's dealing with a React component..."

Clarification:

• Syntax-Based Transformation: Babel follows capitalisation conventions for simple tags, treating lowercase tags as HTML elements and uppercase tags as components. For member expressions (e.g., foo.bar), Babel handles them as component references, regardless of capitalisation.

• Example:Transformation:Explanation: Babel recognizes foo.bar as a component reference, bypassing capitalisation checks for member expressions.

    const foo = { bar: () => <div>Bar</div> };
    const element = <foo.bar />;
  

    const element = /*#__PURE__*/ _jsx(foo.bar, {});
  

Conclusion: The capitalisation rule applies only to simple identifiers, not member expressions. This distinction prevents misinterpretation of Babel’s JSX transformation behaviour.

Final Thoughts and Best Practices

By clarifying these misconceptions, we’ve highlighted the following key distinctions:

1. Babel’s Responsibility:

   • Syntax Transformation: Converts JSX into JavaScript function calls based on syntactic rules.

   • No Runtime Data Structures: Babel does not create runtime objects like React Fiber nodes; it transforms syntax only.

2. React’s Responsibility:

   • Runtime Rendering: Manages component lifecycle, state, and rendering using the Fiber architecture, instantiated at runtime.

3. Compile-Time vs. Runtime:

   • Compile-Time (Babel): Focused on transforming syntax with no side effects.

   • Runtime (React): Handles component reconciliation and rendering tasks, creating and managing Fiber nodes internally.

4. Syntactic Conventions in JSX:

   • Capitalisation Rules: Capitalisation helps differentiate between HTML elements and custom components but isn’t an enforced rule for member expressions.

   • Member Expressions: Treated as component references regardless of capitalisation, enhancing component organisation and flexibility.

Moving Forward: A Developer's Toolkit for Truth

In our exploration of JSX transformation, we clarified that Babel’s role is purely syntactic and does not involve creating React Fiber objects. This distinction not only dispels common misconceptions but also underscores the importance of carefully verifying technical claims.

In a field where tools and best practices evolve rapidly, and where AI-generated content becomes increasingly common, the ability to verify and validate becomes as crucial as technical knowledge itself.

Here’s a practical approach to navigating and understanding technical claims:

1. Check the Source: Dive into implementations, like we did with Babel’s isCompatTag, consult official documentation, and explore commit histories.

2. Test Assumptions: Use tools like Babel REPL, create test cases, and validate claims hands-on.

3. Question the Narrative: Consider whether the claim accurately reflects how the technology functions in practice and aligns with its intended purpose, rather than assuming explanations are complete or universally applicable.

Final Thoughts

With these practices, the next time you encounter a technical explanation, you’ll be equipped to:

• Test it yourself,

• Check the source code,

• Question assumptions,

• Share your findings.

In the end, true understanding doesn’t come from accepting explanations; it comes from verifying them. This approach strengthens your skills and helps you confidently guide others in a complex, ever-evolving field.

About the Author

If you’d like to explore more of my approach and connect with me, here's a bit about who I am:

I'm Daniel Philip Johnson, a senior frontend engineer specializing in frontend development and architecture. I’m passionate about simplifying complex challenges and building scalable, innovative solutions. To explore more of my work, visit my personal website, or connect with me on LinkedIn for insights on tech leadership and the future of frontend development.

Former President Barack Obama once remarked, “In my job, I wind up dealing with problems that are both messy and complicated. By the time a problem reaches my desk, it’s one that nobody else has been able to solve.” This quote highlights a critical reality faced by many in technology today: the most challenging problems are often complex, lacking clear-cut solutions. As technology evolves, so too does the complexity of the challenges we face.

Traditional problem-solving methods, like linear thinking, often fall short when dealing with these intricate issues. Instead, systems thinking—a holistic approach—offers a more effective way to navigate and resolve them. In this blog, we’ll explore the journey from linear to systems thinking, focusing on why it’s crucial for anyone involved in the tech industry. By the end, you’ll see how embracing systems thinking can help you create better solutions, spark innovation, and improve team dynamics in your work.

1. Understanding Linear Thinking

a. What is Linear Thinking?

Linear thinking is a simple, step-by-step way of solving problems. Think of it as following a recipe: you start at point A, follow the instructions in order, and arrive at point B. Each step builds logically on the previous one, and there’s a clear cause-and-effect relationship throughout the process.

b. Examples of Linear Thinking in Tech

• Coding Logic: In coding, developers often use “if-then” statements, where one action leads to a specific result. For example, “If this happens, then that will happen.”

• Project Planning: Traditional project management follows a linear sequence of tasks. One task is completed before moving on to the next, assuming each step must be done in a certain order.

c. Why is Linear Thinking Common?

From an early age, we are taught to break down problems into smaller, manageable parts—this method is called reductionism. It simplifies complex issues by focusing on individual components rather than the whole.

d. Benefits of Linear Thinking

• Predictability: Linear thinking gives a clear roadmap, making outcomes easier to predict.

• Simplicity: It’s easy to communicate and understand, which helps with planning and execution.

• Effective for Simple Problems: For straightforward issues, linear thinking works well.

2. Limitations of Linear Thinking

a. Missing the Bigger Picture

When we focus only on individual components, we risk missing how everything fits together. This can hurt the overall system. For example, optimizing one feature of a product without considering the user experience as a whole can lead to a disjointed result.

b. Reductionism vs. Holism

• Reductionism: This approach breaks down complex systems into smaller parts, assuming that understanding each part leads to understanding the whole.

• The Challenge: In complex systems, reductionism can overlook how parts interact with each other. A system’s behavior often emerges from the relationships between its parts, which aren’t visible when looking at individual components.

• Holism: Holism, on the other hand, focuses on the entire system, understanding how different elements work together.

c. Impact on Complex Systems

• Software Systems: Changing one part of a large software system might affect other areas in unexpected ways. Linear thinking might not catch these ripple effects.

• Organizational Impact: Implementing a new policy without considering how it affects different departments can lead to operational issues.

• Unpredictability: In systems with many interacting components, linear models often fail to predict outcomes accurately.

3. Introduction to Systems Thinking

a. What is Systems Thinking?

Systems thinking is a way of understanding a system by looking at how all the parts are connected. Instead of isolating individual components, it focuses on relationships, patterns, and interactions. This holistic view helps to grasp the complexity of the system as a whole.

b. Linear vs. Nonlinear Thinking

• Linear Thinking: Think of it as following a straight road—each step leads logically to the next.

• Nonlinear Thinking: It’s more like navigating a maze, where small changes can lead to unexpected outcomes. Nonlinear systems are less predictable, and a minor adjustment in one area can cause significant effects elsewhere.

c. Why It’s Important in Technology

In tech, we often work with complex systems where different components interact in unpredictable ways. Systems thinking is essential because it helps to:

• Understand Interactions: See how different elements influence each other.

• Encourage Innovation: Look beyond the obvious to find new solutions.

• Adapt to Change: Systems thinking helps anticipate and respond to changes in the system more effectively.

4. Nonlinear Thinking in Practice

a. Nonlinear Relationships

In nonlinear systems, cause and effect don’t always match up in a predictable way. Small changes in one area can lead to major shifts elsewhere. Understanding these relationships is critical for problem-solving.

b. Examples in Technology

• Software Development: Fixing a small bug in one part of the code can unexpectedly cause issues elsewhere in the system.

• Network Systems: An increase in users can create network congestion, slowing down the system or causing crashes.

• Cybersecurity: Patching one vulnerability might open up another if the overall system isn’t considered.

• Artificial Intelligence: AI models trained on specific data can behave unpredictably when exposed to new information.

• Social Media Algorithms: Tweaking an algorithm can unexpectedly change what content goes viral, altering user engagement and platform dynamics.

c. The Ripple Effect

Minor actions can have far-reaching consequences. For example, a small change to a website’s user interface might confuse users, leading to decreased engagement and lower revenue. Understanding these ripple effects is a key part of systems thinking.

5. Key Principles of Systems Thinking

a. Seeing the Whole

It’s important to understand how each component fits within the system. This perspective ensures that changes benefit the entire system, rather than optimizing just one part.

b. Interconnections

• Exploring Relationships: Look at how different elements interact. For instance, a software update might improve performance but cause compatibility issues with other applications.

• Example: When a new feature is added, how does it affect the overall user experience? Thinking holistically helps avoid unintended consequences.

c. Patterns Over Time

• Identifying Trends: Look for patterns and recurring issues over time. These can highlight deeper problems that need to be addressed.

• Data Analytics: Monitoring system performance and user behavior can help predict future trends.

d. Feedback Loops

• Positive Feedback Loops: These amplify changes. For example, more users can attract even more users due to network effects.

• Negative Feedback Loops: These help maintain stability. For example, load balancing prevents server overload.

• Example: User feedback leads to product improvements, which in turn boosts user satisfaction and generates more feedback.

e. Embracing Complexity and Uncertainty

• Acceptance: Not all variables can be controlled or predicted.

• Preparation: Have flexible strategies to adapt to unexpected changes.

f. Collaborative Approach

• Cross-Functional Teams: Work with other departments to get diverse perspectives.

• Communication: Sharing insights helps teams understand the bigger picture.

g. Root Cause Analysis

• Beyond Symptoms: Focus on finding the root causes of problems, rather than just treating symptoms.

• Tools: Techniques like the “5 Whys” can help uncover the deeper issues at play.

6. The Importance of Systems Thinking in Tech

a. Managing Complex Software Systems

Systems thinking leads to better software architecture by considering how different parts interact. This approach reduces integration issues and makes the system more scalable.

b. Anticipating and Mitigating Risks

By understanding the system’s interconnectedness, potential points of failure can be identified and addressed proactively, minimizing downtime.

c. Encouraging Innovation

Looking at the bigger picture helps teams explore unconventional solutions. This can lead to breakthrough innovations and a competitive edge.

d. Improving Team Dynamics

When teams see how their work fits into the bigger picture, they collaborate more effectively. This leads to improved efficiency and morale.

7. Transitioning from Linear to Systems Thinking

a. Challenges in Changing Mindsets

• Comfort Zones: We’re used to linear thinking because it’s what we’ve learned.

• Complexity Aversion: Systems thinking can feel overwhelming because it’s more complex and doesn’t offer easy answers.

b. Developing Systems Thinking

• Continuous Learning: Explore books, courses, and seminars on systems thinking.

• Practical Application: Start small by applying systems thinking principles to everyday projects.

• Mentorship: Learn from people who already practice systems thinking.

• Reflection: Regularly review your decisions and their impact on the overall system.

c. Tools for Systems Thinking

• Systems Mapping: Create visual maps to understand the components and relationships within a system.

• Causal Loop Diagrams: Show how different elements of a system influence one another.

• Simulation Models: Use software to simulate system behavior under various scenarios.

Conclusion

As President Obama pointed out, the hardest problems are often the most complex. While linear thinking is useful for straightforward problems, it often falls short in today’s interconnected world. Systems thinking provides the tools to tackle these challenges by seeing the bigger picture.

By adopting systems thinking, you’ll foster better collaboration, anticipate risks, and drive innovation within your team. As modern tech challenges grow more complex, systems thinking becomes not just a tool, but a necessity.

Embrace systems thinking and see how it can revolutionize the way you approach complex problems in tech. Start by observing the connections in your current projects, applying a holistic view, and encouraging your team to think beyond isolated solutions. By taking a step back to see the bigger picture, you’ll drive innovation, improve your decision-making, and help your team thrive in today’s fast-paced, interconnected world.

About the Author

As someone who applies these principles in my work, I’ve experienced how impactful they can be in building scalable solutions. If you’d like to explore more of my approach and connect with me, here's a bit about who I am:

I'm Daniel Philip Johnson, a senior frontend engineer specializing in frontend development and architecture. I’m passionate about simplifying complex challenges and building scalable, innovative solutions. To explore more of my work, visit my personal website, or connect with me on LinkedIn for insights on tech leadership and the future of frontend development.

NoSQL = "Not only SQL," represents a category of database systems that deviate from traditional relational databases

Introduction

In this blog, we will delve into the fundamentals of document databases, a type of NoSQL database. By comparing document databases to a house with various rooms, we'll explore their document-oriented structure, primary and standard fields, and the key terminology associated with them.

Document Database: The House of Data

Imagine a document database as a house, acting as a container that accommodates different rooms, represented by different document collections. We can define separate room documents for essential areas like "Bedrooms," "Bathrooms," "Living Room," and "Kitchen.”

Document-Oriented Structure: Organizing Data

A document-oriented structure serves as the data model in document databases, allowing the organization and storage of data in the form of self-contained documents. Each document represents a unique entity or object, encompassing all the relevant data associated with it. Consider a room as an example, with fields like roomName, size, flooring, and furniture, encapsulated within a document. To illustrate this concept, let's consider a room as an example:

room {
   _id: ObjectId("1234567890abcdef12345678")
   roomName: “bedroom”,
   size: “12 feet”,
   flooring: "wood",
   furniture:["wardrobe", "bed"]
}

In this example, we have a room document that possesses a unique identifier (_id) assigned by the database. It includes descriptive attributes such as the room's name ("bedroom"), size ("12 feet"), flooring type ("wood"), and an array of furniture items, including a wardrobe and a bed. This self-contained structure allows for efficient storage and retrieval of room-specific data within the document database.

Primary Fields and Standard Fields: Defining Document Structure

In our pursuit of an efficient document structure, let's delve into the essential fields that compose a room document.

Firstly, we have the primary key, a vital component that plays a pivotal role in document identification and retrieval. This unique identifier holds great significance, especially when accessing documents through APIs such as api/room/1234567890abcdef12345678. Additionally, the primary key enforces uniqueness, ensuring that no duplicate documents are created within the collection. Moreover, it enables the creation of indexes, facilitating swift and direct retrieval of specific documents based on their distinctive identifiers. Fortunately, MongoDB automates the generation of primary keys, relieving you of the burden of creating them manually.

However, you also have the flexibility to define your own primary key if you possess a field guaranteed to be unique. For instance, in the case of books, the International Standard Book Number (ISBN) serves as an excellent candidate. Consider the following example:

book {
   _id: "978-0-123456-78-9",
   author: "author",
   title: "the title"
}

Alongside the primary key, we incorporate several standard fields which are made up of attributes and values to comprehensively define our room document structure. These fields include:

• roomName: Designates the name of the room, allowing easy identification.

• size: Specifies the size of the room, providing relevant information about its dimensions.

• flooring: Describes the type of flooring used in the room, adding to its aesthetic and functional attributes.

• furniture: Represents an array that captures the furniture items present in the room, facilitating an inventory-like perspective.

By thoughtfully incorporating these primary and standard fields into our document structure, we establish a foundation for efficient storage, retrieval, and organization of room-specific data within our MongoDB document database.

Value Types: Diverse Data Representation

As you explore the fields in our collection, you might have noticed the presence of strings and arrays. However, it's important to understand that document databases like MongoDB offer a wide range of value types to cater to diverse data requirements. Typically, these databases support popular data formats such as JSON or BSON.

In MongoDB, you have the flexibility to utilize various value types for your fields. Let's explore some of the commonly used value types:

• String: Represents a sequence of characters, allowing you to store textual information.

• Number: This can be either an integer or a floating-point number, enabling you to store numerical data.

• Boolean: Represents true or false values, providing a binary data type for logical operations.

• Date: Stores date and time values, facilitating the storage of temporal information.

• Array: Allows you to store an ordered list of values, providing a convenient way to group related data elements together.

• Object: Represents a collection of key-value pairs, enabling you to store complex and structured data.

• Null: This represents the absence of a value, allowing you to indicate the lack of data in a field.

• ObjectId: A special data type commonly used as a unique identifier for documents, providing an automatically generated identifier within MongoDB.

• Timestamp: A BSON data type that represents a 64-bit timestamp, facilitating the tracking of time-related information.

• Binary Data: Enables the storage of binary information, such as images or files, within the database.

By leveraging these diverse value types, document databases empower you to effectively store and manipulate data with flexibility and precision. Whether you need to capture textual, numerical, temporal, or structural information, MongoDB offers a comprehensive set of value types to accommodate your data needs.

Now we should have a much clearer understanding of all the pieces that make up a document DB.

Key Terminology: Understanding the Basics

To wrap up, let's review key terminology:

• Document database: A NoSQL database that stores and manages data in self-contained documents.

• Document collection: A grouping of related documents, acting as a logical unit for organization and management.

• Document-oriented structure: The data model used in document databases, organizing data into self-contained documents.

• Primary field: The unique identifier or primary key for a document within a collection, facilitating identification and retrieval.

• Standard field: Predefined fields within a document structure that capture specific attributes or properties.

• Attribute: A characteristic or property of an entity, defining the fields or properties within a document.

• Value: The actual data stored within an attribute or field of a document.

By understanding these key concepts, you'll gain a solid foundation in the fundamentals of document databases and be better equipped to work with them effectively.

Every month as a frontend engineer, I reflect on what I have achieved. Let's talk about April 2021. In summary, I took a significant risk and left my second job. It's something I felt I had to do. My mindset was off and I wanted to focus on writing and improving with front end development. I regathered my thoughts and made a plan of action to further my skills and finally, I have committed to a content creation schedule.

Here is what I have done 👨‍💻

Read News Articles 📰

Here are my top 5 articles I have read this month. My main focus as a frontend engineer is React and Js. So the articles I have included will be based on these topics.

• Slow and Steady: Converting Sentry’s Entire Frontend to TypeScript | Product Blog • Sentry
• Comparing the New Generation of Build Tools | CSS-Tricks (css-tricks.com)
• 15 DevTool Secrets for JavaScript Developers (asayer.io)
• Blog - Next.js 10.1 | Next.js
• JavaScript for impatient programmers (ES2021 edition) (exploringjs.com)

Recently, I started to co-author a book for a publisher.

Writing a book is something I'm excited to be doing. I wish I could tell everyone what it is I'm writing. For now, it has to be a secret 😏 . Hint* It's front-end related. Surprisingly, I have enjoyed co-writing two chapters, and I learnt something valuable. By writing about a topic, you are testing your knowledge and identifying possible gaps. I have started to improve immensely and, my recall is so much better. For this reason, I have started to pursue writing articles and helpful blogs. If you haven't written a blog article, I encourage you to do it!

Courses I am taking 👨🏻‍🎓🎓

In this section, I will list the courses I am currently taking. I will also include courses I have finished and write personal reviews listing what I have learnt.

• Mastering the Coding Interview: Data Structures + Algorithms (ongoing)
• Understanding TypeScript - 2021 Edition: (ongoing)

Videos I watched 🎥

The focus this month was slightly geared towards encryption. In pursuit of bettering my skills, I started to use SSH. During my time learning, I documented it by writing an article on how to use SSH and how it worked.

• Secret Key Exchange (Diffie-Hellman) Computerphile
• Diffier-Hellman - the Mathematics bit Computerphile
• Key Exchange-Problems - Computerphile
• Elliptic-Curves - Computerphile
• Rendering performance inside out - Martin Splitt

Amazon project 💼

In summary, my amazon clone is close to having an alpha release. My main focus this month is to implement searching functionality.

What features I added this month.

• I integrated stripe payment with a custom strapi controller. The reason for this was to calculate the cart on the backend.
• Currently, a user can put an item in a cart and checkout.
• Multiple items added to the cart change the quantity
• Made a react portal to display error messages or success messages
• All pages were styled to mirror the amazon website.

From this point onwards I plan to make a blog article each month related to my project progress and how I implemented features.

What I did wrong 🙄

I allowed leaving my job to affect my focus. I became torn about the situation but eventually realised that sometimes you need to decide for yourself. I discovered that being nice doesn't mean you have to say yes. Always consider your feelings too. Sometimes you need to put yourself first. Now that it is all done. I'm ready for my next chapter 😀.

What I accomplished ⏳

In April, I feel like I did not accomplish as much as I would have intended. There were a few moments I felt slightly confused and wondered what would become of me. Not long after, I started to plan my next chapter. I reflected on my frontend abilities and soft skills. I decided on what I need to improve and how to achieve it.

Thank you for reading 👋

For now, I am just publishing my blogs to dev.to. In the future, I will look to expand to more blogging platforms and will start to host my blogs on my website. If you enjoy my blogs, you might also be interested in my tweets on my Twitter. Please feel free to share a tweet with #monthlyreflection, tag me and tell me about your month.