You Write For Humans

When you send someone a text, do you want them to read it? I mean, yes, right? You wrote it for them. They’re the intended recipient. Of course you want them to read it.

There’s some message, some meaning, some knowledge, some emotion that you mean to convey in your writing. This is obvious. You know this. I know this. We all know this.

But what happens when someone sends you something they didn’t write? That wasn’t even written by a human? At least ghostwriters, who’ve been a thing forever, used to be human. These days with AI, who knows?

After seeing how some people are using AI to write personal messages, from texts and emails to messages on TikTok, Instagram, Snapchat, Facebook, WhatsApp, Teams, Slack, Tinder, Bumble, Hinge, Discord, and who knows what else, I’m starting to wonder whether we’re all on the same page about what I thought was common sense.

When you write, you want people to read it.

You write for humans.

So, if you didn’t write it, why should I read it? Why would I bother to read something you couldn’t be bothered to write?

Your Words Matter

We’ve crossed the Rubicon. People are sending other people AI generated messages, and on the receiving end, it’s not always being noticed, because LLMs have gotten better.

This 💩 is bananas, B-A-N-A-N-A-S.

It’s not a good thing. I don’t like it, and I’m not alone.

There’s a great article going viral right now in the tech community that calls out how not very cash money it is to pass off AI generated text as your own.

Niklas Gruhn - Don’t Be a Meat Proxy

It’s a great short read. Here’s another good one on a similar theme.

Sophie Koonin - This Website Is For Humans

Their point and my point are largely the same. You write because you want people to read it. If you didn’t write it, why should I read it? If it wasn’t important enough for you to write, why should it be important enough for me to read?

Bring Back Pen Pals

I find myself longing for the days when people wrote letters to one another. Bring back pen pals. I’m partial to a good rom-com, particularly from the 90s and early 2000s (less raunchy, more wholesome), and You’ve Got Mail is one of my favorites.

While Meg Ryan and Tom Hanks weren’t writing physical letters, they were digital pen pals, with each of their unique voices shining through their emails. Which eventually led them to romance, despite their differences.

Can you imagine a version of that film where each side used ChatGPT to compose their emails? It wouldn’t work! The love, the romance, the connection, it was found in the nuances of their literary voices. Buried in words they wrote themselves.

Now, to be fair, both characters asked people around them for feedback on their emails. Which today is like showing a text to a friend to make sure you don’t sound too desperate or clingy, and then maybe accepting a suggestion or two. But does that make the text any less you? No! Having an editor is fine. Outsourcing the writing altogether, then putting your name on it, is not.

An Aside: If you haven’t seen You’ve Got Mail, go watch it. You’ll be happy by the end. You just smile the whole time and wish real life worked like that. Then go watch Sleepless in Seattle for another Meg Ryan + Tom Hanks pairing. You’ll also be happy by the end, as long as you can suspend your disbelief a bit during the final act.

For Whom Do We Toil?

What is the point of writing? Of communication? What sense does it make to send someone something you didn’t write as though it came from you?

It’s one thing in a formal setting like work or public speeches or even books from published authors with teams of editors, but for us everyday people…

My brother in Christ, why are you sending me AI generated messages? Did YOU even read it? And even if you did, why did you generate it to begin with? You can’t just text me yourself?

:nigeria: Are you okay? Are you mad? You dey craze? :nigeria:

The nerve, the audacity, the unmitigated gall, it takes for someone to outsource the hard work of writing, then expect someone else to do the cognitive work of reading, it’s blasphemous!

An Aside: The only maybe defensible excuse for doing this in direct messages is writing in a non-native language. In that case, yeah. I totally would just to make sure I didn’t sound silly. But if you’re speaking your native tongue, what are you doing?

This all leads me to some more great articles.

Tom Bedor - If You Are Asking For Human Attention, Demonstrate Human Effort

Bedor makes several great points with a specific focus on our shared profession of software engineering.

But for a more general take, there’s this:

Bret Stephens - I’m Begging You: Never Write With A.I.

That one is so very well written. Bret Stephens is firmly in the anti AI camp, which I’m not, but I mostly agree with him about AI’s role in writing. He says it should have no role at all. I think its role, if it’s to have one at all (you don’t need it!), should be minimal, similar to tools like spellcheck or Grammarly.

AI Transparency

Thankfully, some platforms are doing stuff to help address this problem. Substack now lets readers check whether an article was AI generated, and LinkedIn lets users report AI slop posts.

If you’re on LinkedIn, please use that button expeditiously. Do your part to make the Internet a better place. A place for humans.

And with all this in mind, as inspired by Armin Ronacher’s AI Transparency Statement, I’ve written my own.

Check out my AI Transparency Statement.

It now has a dedicated place on this website’s footer and among the buttons at the end of every post. Trust matters. If you’re a writer or content creator, be clear with your audience about how you use AI. Don’t wait until you get caught peddling slop to decide honesty is worth having a policy for.

Note: I’m a Christian, but for most of this article, I’m setting aside that bias. I’m also aware that, technically speaking, Christ is a religious title. Jesus of Nazareth would be the more neutral title, but Jesus Christ is what nearly everyone calls him, including people who aren’t Christians. Wikipedia agrees. The name is so common that people even use it as a swear word. So, that’s what I’ll call him throughout.

True For You and Me

Something’s been on my mind since this past Easter, and I’m only just now getting around to writing about it (still doing better than George R. R. Martin though, we love you GRRM, but finish the books!).

Jesus Christ was a real person.

If you’re reading this right now, that statement is true for me, you, and everyone everywhere. It’s not a religious statement. It’s not a statement of faith.

If I say Julius Caesar was a real person, nobody gets defensive, nobody bats an eye. Which is good, because he totally was. There’s no doubt about it. Saying that Jesus Christ was a real person is the same level of factual. That’s not just like, uhhhh, my opinion, man, and I’m a bit shocked that a good number of people, particularly in the Western world, aren’t aware of that.

The debate surrounding Jesus is about whether the New Testament account of him is true. Did he really perform all those miracles? Was he actually the Son of God? Did he die for our sins? And most importantly, did he rise from the dead?

But there’s no credible scholarly dispute over whether Jesus Christ existed, a consensus shared by atheist and agnostic scholars alike. There are plenty of historical records for Jesus that aren’t the Bible.

His existence is a historical fact.

Not So Common Knowledge

If, in response to this article so far, you’ve been going “duh, everyone knows Jesus was a real person”, I doth protest. Everyone does not know that.

I could offer my own anecdotes as evidence, but we have research. In a nationally representative 2022 survey, 24% of American adults either denied Jesus’s historical existence or were unsure about it.

That’s nearly 1 in 4 Americans. Those who said no, in effect, relegate Jesus to the same category as Zeus, a figure from mythology rather than a person who actually lived.

In response to those numbers, I have only this:

An Aside: This is a deep cut meme. Click here to learn its origins. If you recognized it without help, I’m proud of you. You’re my kind of person. We can be friends.

That level of uncertainty is striking given the broad historical consensus that Jesus was real.

McKenna Grace, Paul Rudd, and Finn Wolfhard

Seeing this clip recently drove home my belief that it is in fact not common knowledge that Jesus Christ was a real person.

While promoting Ghostbusters: Frozen Empire, McKenna Grace, Paul Rudd, and Finn Wolfhard were asked which person from history they’d go back in time to spend a day with. Rudd answered, “Jesus Christ”, which immediately provoked a sort of “yeah right lol” laughter from McKenna and Finn.

Rudd responded, “Laugh all you want”, then stated, “He existed. We know”. He continued, “So wouldn’t you want to spend some time with him and go, ‘Hey Jesus, what’s the deal?’” After he explained himself, McKenna and Finn conceded that his response was actually a great answer. Rudd wasn’t making a religious statement. He’s Jewish but doesn’t practice Judaism and has publicly said he isn’t “particularly religious”. Instead, he grounded his answer in the fact that Jesus was a real person and therefore suitably germane (been looking for an excuse to use that fancy phrase) to the question.

Now to be fair, I can’t know why McKenna and Finn laughed, and the clip doesn’t prove that either thought Jesus was fictional. Still, their laughter came across as mocking, and Rudd immediately felt the need to clarify that Jesus existed. That made me wonder whether part of this confusion is generational.

Across Generations

Rudd, born in 1969, is Gen X. McKenna, born in 2006, and Finn, born in 2002, are Gen Z. Technically, so am I, although I can barely claim it, having been born in what is commonly considered the generation’s first year. I’m more of a Zillennial than anything.

My suspicion that younger people are less likely to know Jesus was a real person isn’t based on this clip alone. A 2021 Australian national survey found that only 4 in 10 adults ages 18 to 35 regarded Jesus as a real historical person, with that number rising among older age groups.

How younger people get their information may also matter. The Pew Research Center found that 37% of adults under 30 regularly get news from social media influencers, and 77% of the influencers studied had no affiliation or background with a news organization.

None of this proves that social media causes this generational difference or explains why McKenna and Finn laughed. Still, it makes me wonder what happens to basic historical literacy when we increasingly get our knowledge from algorithmically curated feeds full of influencers.

We can’t have meaningful conversations about important topics without first agreeing on the basic facts. Historical truth exists outside any one of us. It simply is what it is. It’s stuff that’s already happened.

And as much as I like audio and video, when it comes to knowledge, there’s no replacement for reading. For most of human history, literacy was out of reach for huge numbers of ordinary people. Plebeians, like you and me. Now that most of us can read (excluding Floyd Mayweather Jr.), we’re struggling to get people to do it.

There’s never been a better time to leave your social media platform of choice, use Google properly, and read primary sources for yourself. Charles J. Chaput said it best.

If we don’t read, we condemn ourselves to chronic stupidity and a conditioning by mass media that have no sympathy for the things we believe. […] If we fill our heads with poison and junk, we make ourselves angry and dumb.

Charles J. Chaput

States of Confusion

Part of the confusion here no doubt comes from the common phrase “I believe in Jesus”.

Spelled out in its entirety, it would more accurately be something like, “I believe that Jesus Christ is the Son of God as evidenced by the New Testament account of his life, death, and resurrection”. But…

So instead, people say, “I believe in Jesus”. Somewhere along the way, that shorthand picked up a meaning it was never meant to carry. To say “I believe in Jesus” is not to say “I believe Jesus existed”, because you don’t get a say in that. None of us do.

I don’t get to choose whether Marcus Aurelius, Margaret Thatcher, Mansa Musa, or Mary Slessor (🙌🏾 ❤️) existed. They did. It just is what it is, we don’t get to choose. Likewise, the existence of Jesus Christ isn’t a matter of personal belief.

What we each get to decide is whether we believe the claims Jesus made about himself. Plenty of people who lived during his time didn’t believe what he said, leading ultimately to his crucifixion, which itself was an actual historical event, not merely a matter of Christian belief.

In Conclusion

This is one of those topics where what I have to say doesn’t really matter. Some things just are what they are. The sun is hot, France is a country in Europe, Olusegun Obasanjo (what a great name 😏) was the 12th president of Nigeria, the mitochondria is the powerhouse of the cell, and Jesus Christ, or Jesus of Nazareth if you prefer, was a real person.

Accepting that simple historical fact opens the door to much bigger questions about who he was. His teachings left such a mark on the world that he’s routinely considered one of the most influential people to have ever lived.

As for whether I believe the claims Jesus made about himself, I do. I am proudly, unambiguously, and devoutly a Christian.

But Christian is an identity nearly 2,000 years old. The term had a clear meaning when it emerged during the Roman Empire, long before the United States existed, and it still has a clear meaning for billions of people across hundreds of countries worldwide. Reducing that ancient, global identity to one American politician or political movement is breathtakingly arrogant. Christianity has never belonged to one country, race, politician, or political party.

Its meaning comes from Christ himself, a real person whose family fled a murderous ruler and took refuge in Egypt (hey Siri, what’s a refugee?), who experienced homelessness, and who told his followers to love their enemies, welcome strangers, and show their love for him through their actions, being rather blunt about that last part, even with his own family.

All that said, wherever you land on these bigger questions, I’m always happy to talk about Jesus. It’s my favorite topic, above even anime, cinnamon rolls, science fiction, fantasy novels, third places, and herbal teas. You can reach me on LinkedIn or through my contact page.

Warning: This article contains major spoilers for the 1995 film While You Were Sleeping. If you haven’t seen it, go watch it first. I mean it came out literally before I was born, so I feel like a spoiler warning isn’t really needed, but the ridiculousness of the film is better experienced than explained. Also, it’s a rom-com, so spoilers don’t really matter. The plot is always predictable. You’re watching for the vibes.

This Shouldn’t Work

The entire premise of While You Were Sleeping is built on what, in multiple instances, would constitute some form of identity fraud. It’s stupid, or perhaps a kinder descriptor would be silly, and yet I loved every second of it.

Set in 1990s Chicago, the film follows Lucy Moderatz (Sandra Bullock), a lonely Chicago Transit Authority fare collector who’s developed a massive crush on Peter Callaghan (Peter Gallagher), a handsome lawyer who passes through her booth every morning.

She knows his schedule. She knows what he wears. She knows where he prefers to sit. She knows he gives up his seat to older passengers. She watches him intently, collecting tiny details and using them to imagine an entire life with him.

Yet, they’ve never actually spoken.

In Gen Z lingo, which I can only barely claim, having been born in literally the first year of the generation, it’s giving Every Breath You Take by the Police.

An Aside: If you’re like me, floating culturally between the generational boundary of Gen Z and Millennial, there’s a digital place for you. Join us over at r/OlderGenZ.

I only learned while writing this post that there’s a word for what Lucy experiences. Limerence. It’s an intense romantic fixation on someone marked by intrusive thoughts, idealization, and a longing for the other person to feel the same way. In Lucy’s case, it’s fueled less by who Peter actually is than by the version of him she’s built in her head. Like Joseph Gordon Levitt’s character in 500 Days of Summer.

That limerence might’ve remained nothing more than a crush if Peter hadn’t been pushed onto the train tracks. Lucy saves him, and a chain of hospital misunderstandings that one honest sentence from her could’ve cleared up leaves his family believing she’s his fiancee while he’s in a coma. It’s the aptly named Poor Communication Kills trope in action.

His family is surprised he’s never mentioned her, but they haven’t seen much of Peter lately. He’s a very busy, very successful, very wealthy Chicago lawyer, so a secret engagement isn’t entirely unbelievable. They embrace Lucy almost immediately. Lucy, who has no living family and no close friends, lets them. Somewhere inside the lie, she falls in love with the Callaghans and eventually with Peter’s brother, Jack (Bill Pullman).

So yeah. The mechanics are ridiculous, but the emotional beats aren’t.

My Girl Was Lonely

While You Were Sleeping predates social media, but make this same film today and Lucy would absolutely be a doomscroller.

She’d work her dead end job, go home to her cat, and lie alone in her empty apartment, scrolling for hours through other people’s ostensibly perfect lives. She’d watch family Christmas reels, engagement announcements, vacation videos, and couples wearing matching pajamas while having nothing even close to that in her own life. Nobody to even share her jealousy with. Misery without company.

Lucy isn’t just lonely. She’s stalled. She carries a passport with no stamps in it, just in case she “suddenly needs to leave the country”, and dreams of going to Florence, Italy. But she never follows through. She plans vacations she doesn’t take and always finds some reason why now isn’t the right time.

Which, upon viewing, left me feeling like:

Because I’m guilty of the same. My passport is equally as pathetic. And like Lucy, I can always produce a perfectly reasonable explanation for why I still haven’t visited that one place I’ve always wanted to see. There’s always something. At a certain point though, a collection of reasonable explanations starts to look a lot like a life on pause.

The only friends we see in Lucy’s life are people she works with in some capacity. Outside of work, she has her creepy neighbor Joe Fusco Jr. (Michael Rispoli), her landlord, and her cat.

The film never hides Lucy’s loneliness, but Sandra Bullock’s charm throughout makes it easy to overlook. Lucy is funny, warm, and endearing, so her isolation can register as cute rom-com quirkiness rather than something genuinely painful.

Her mother died when she was young. Her father died about a year before the movie begins. As far as the film shows us, she has no siblings, no living family, and no close friends. Her boss asks her to work on Christmas specifically because she’s the only employee without family plans (been there myself, it sucks).

How seriously that loneliness lands may depend on how much experience you’ve had with it yourself. I’ve spent holidays alone on account of being too broke to travel, and it can be deeply isolating. Calls help. FaceTime helps. But when you’re alone during a holiday, a screen isn’t the same as having another person in the room. There’s no replacement for being physically present with people.

My girl was lonely. She’s just like me fr.

Falling In Love With Family

When Lucy walks into the Callaghan home on Christmas and finds a loud but loving family eating together, exchanging gifts, telling stories, and making room for her, I understand why she can’t bring herself to tell the truth and leave it all behind.

She goes from having nobody to having an entire family overnight. Literally. She spends the night. It was crazy. It was wrong. But I get where she was coming from.

The real love story in While You Were Sleeping isn’t only between Lucy and Jack Callaghan. It’s between Lucy and the entire Callaghan family.

The Callaghans fully embrace Lucy, and before long, she feels like family. Peter’s godfather discovers that Lucy and Peter were never engaged. But he keeps her secret anyway because the lie gives the Callaghans hope that Peter has something worth waking up for. Meanwhile, Lucy fits so naturally into their lives that she already feels less like a stranger and more like a daughter. They need her, and she needs them.

Peter might be the reason she enters their lives, but the family is the reason she stays.

An Aside: The family dynamic here reminds me of the Crawleys from Downton Abbey. As a proud Anglophile, I’ve seen every episode and all the movies. I love Downton Abbey, and Peaky Blinders, and The Crown, and just about any British culture centric show or movie out there. Except Bridgerton, I could never get into it.

The Commute Crush

Public transportation is at the heart of this story. It takes place in Chicago, one of the great American cities and a personal favorite of mine. Great food, great public transportation, and good old Midwestern kindness.

An Aside: National coverage too often reduces Chicago to gang violence in particular neighborhoods. The city most residents and visitors experience is far removed from Chiraq. Like, you won’t accidentally end up on O’Block. I promise.

Public transportation is woven into Lucy’s life. The train station is more than her workplace. It’s her ecosystem, her town square, and the center of her stifled social life. It’s where she first sees Peter, where she saves him, and where the film eventually brings everything full circle.

What Lucy is doing is certainly creepy. Building an entire romantic fantasy around a normal every day person you don’t know is strange behavior. Or…is it? Is it really? Social media has made us all weird. And I mean, if you’ve spent years commuting by bus or train, as I have, having a commute crush isn’t weird at all.

In cities like Chicago and New York, everybody takes public transportation. The high and mighty, the working class, everybody. When your daily commute makes you a passenger rather than the driver, your mind has time to wander. You have time to get bored. You notice the same people every day and start building stories around them based on observations.

Sometimes, you even develop a crush.

The problem with a commute crush is that if you shoot your shot and get rejected, you still have to see that person every day. Neither of you can avoid it. You both have jobs to get to, and now you’re back on the same train the next morning thinking, man, I wish I hadn’t done that.

But if you never say anything, you’ll never know if they feel the same. Shooters shoot.

An Aside: I miss the years when I commuted by bus or train instead of driving everywhere. Charlotte, North Carolina, is a great city, but like much of the South, it’s lagging behind the coasts when it comes to public transportation. I tried living here for a year without a car, but I couldn’t make it work without basically limiting my life to neighborhoods along the Rail Trail.

Seen through the rhythms of a daily commute, Lucy’s crush on Peter doesn’t feel all that strange to me. He’s a recurring character in the quiet story that is her daily life.

The creepy part is everything that happens after Peter falls onto the tracks. Lucy never takes her shot. The accident takes it for her, pulling her into his life before she’s ready. She doesn’t scheme her way in so much as go along with each misunderstanding, staying passive when the situation desperately calls for honesty and assertiveness. She falls into Peter’s life both literally and figuratively.

As the film goes on though, the real romantic story reveals itself, and it isn’t with the man on the tracks. Lucy slowly falls for Peter’s brother, Jack (Bill Pullman), who actually spends time with her and gets to know her. So, a love triangle. Standard rom-com stuff.

My Girl Was Starving

A ridiculous part of this film is what happens when the lie is finally exposed.

Lucy confesses that she was never engaged to Peter, had never spoken to him before the accident, and had spent the previous several weeks deceiving the entire family. She also tells them she’s in love with Jack (Peter’s younger brother).

But she goes beyond just admitting the lie. She opens up about how alone she was and how, for a little while, the misunderstanding allowed her to feel like a fiancee, a daughter, a granddaughter, a sister, and a friend. She essentially tells them, “I’m a lonely loser and I let this continue because it finally gave me a family.”

The Callaghans are stunned. They ask why she never told them, but before anyone can fully process what she’s saying, the wedding descends into even more chaos and Lucy slips away. Their forgiveness becomes clear later when the entire family helps Jack propose to her.

In reality, any reasonable family would be livid. Some of them would probably be considering legal action. Peter is a wealthy, well connected lawyer with court side Bulls tickets, lofty investments, and an apartment in Paris. Jack even jokes that if Peter were really engaged, he would’ve announced it in the Chicago Tribune. Yet here is Lucy, a complete stranger who let everyone believe she was his fiancee while the man was in a coma.

In response to this revelation, instead of outrage, the movie has the family basically go, “Well, we like you, so don’t worry about it. Let’s get you married to our other son!”

It’s absurd, but it works because of how honest Lucy was about her motivations. She never intended to hurt anyone. She just wanted to feel loved.

The way the family reacted reminds me of a Bible verse.

People do not despise a thief if he steals to satisfy his hunger when he is starving.

Proverbs 6:30

And boy, was Lucy STARVING.

She was starving for connection, relationship, companionship, family, and love. The Callaghans can see that what she did was wrong without believing she did it maliciously. Lucy might have saved Peter’s life on the tracks, but the Callaghans saved hers by giving her somewhere to belong.

That doesn’t erase the lie, but saving their son’s life buys her some grace. They can only be so mad at her. Legally, their forgiveness makes little sense. Humanly though, I get it. A little bit of mercy goes a long way!

Some Movies Aren’t Meant For Deep Introspection

There’s a great song by Hannah Jadagu called Think Too Much that could be the theme song to my life. I think entirely too much, too often, and constantly pray for the grace to sometimes just let it go and let God handle it.

Silly movies help me get into that mindset, and While You Were Sleeping is exactly the kind of film where you can turn your brain off, smile, and enjoy yourself. Which I did, even if I immediately ran to write this overthought blog post afterwards.

I’ve grown to appreciate that kind of escape. I spend all day doing cognitively demanding work. Logic, systems, rules, reason, edge cases, use cases, blah blah blah. I love that stuff. God made me that way. I think too much, and I’m fortunate to have a career in software engineering where what is often a weakness is viewed as a strength.

But when I’m unwinding after work, I don’t want entertainment that demands too much processing. Make it simple. Make it silly.

For example, I enjoy the Transformers movies because I want to see robots fight and things blow up. The plot makes no sense, and I don’t care. Just fight.

Same with Dragon Ball Z. Nobody watches it for nuanced storytelling. We watch to see Goku get stronger, overcome his limits, and beat the bad guy in epic fashion. Nothing fancy. Just going Super Saiyan and throwing hands.

And as much as I love science fiction and fantasy with deep lore, there’s a time for everything. Sometimes it’s time to just chill. While You Were Sleeping isn’t one of the greatest movies ever made. It’s probably not even in Sandra Bullock’s top ten. But I smiled like an idiot the whole way through.

I’m not handing out Oscars over here. Movies are about enjoyment. Sometimes that’s enough.

An Aside: For whatever reason, Sandra Bullock is beloved by the Nigerian auntie community. She’s routinely listed among their favorite actresses, with comments like, “She’s an honorable woman, a real queen, not like these other ashawos gallivanting about Hollywood.” It probably helps that she adopted two Black children in the least white savior way possible. She’s genuinely an amazing mother to them. I can’t prove this is a Nigerian cultural phenomenon, but I know what I’ve seen. Sandra Bullock has the Nigerian auntie seal of approval. I would love to see a PhD level research paper on this. It probably goes beyond Nigerian aunties. Why is Sandra Bullock so beloved by middle aged West African women? Lol.

Quite Alright Indeed

Apparently, I’m not the only person who was surprised by how much I enjoyed this movie.

Roger Ebert was one of the most influential film critics in American history. In his 1995 review of While You Were Sleeping, he describes almost the exact experience I had. Ebert calls out the movie’s obvious flaws, but by the end admits he was “still a little astonished how much I was enjoying it.”

Same, Roger. Same.

If you’re reading this and want to smile and maybe shake your head at something ridiculous, check out While You Were Sleeping.

It’s quite alright.

Quite alright indeed.

The Headlines Are Doing A Lot

If your feed looks anything like mine, you’ve probably seen headlines like these:

• ‘Supergirl’ Review: Milly Alcock Takes Charge in a Dystopian Superhero Movie So Flat It’s Super-Horrendous
• Behind the ‘Supergirl’ Bomb: Competing Cuts, Creative Differences
• How Supergirl’s Box Office Failure Could Reshape The Future Of James Gunn’s DC Studios
• Where Does DC Go After ‘Supergirl’ Box Office Crash?
• ‘Supergirl’ Braces for $100 Million Loss: What DC Studios Should Learn From Its Box Office Bomb
• Supergirl Will Lose Warner Bros. Over $125 Million
• ‘Supergirl’: DC Studios Boss “Confident” in Strategy Despite Film Opening Below Expectations

I get why you might be thinking, man, is it really that bad of a movie?

It isn’t. Some of those headlines are sensational, the internet is overreacting, and plenty of fans are overcorrecting in the other direction. Spend five minutes on r/boxoffice, r/DC_Cinematic, or r/DCU_, and you’ll see people defending the movie from slights both real and perceived.

Reality, as it often is, is far more boring. The truth is, Supergirl isn’t that bad. It just isn’t that good. Let me explain why the best way I know how. With examples.

Movies That Were Actually That Bad

Black Adam was that bad. It was every bit as bad as its 39% score on Rotten Tomatoes would indicate. In fact, I’d say it was worse. Loud, weirdly hollow, and convinced that being big was the same thing as being interesting (which is par for the course with The Rock).

Madame Web was that bad. There’s not much to appreciate there. Not in a fun way. Not in a “well, at least they tried something weird” way. Just bad.

Morbius was that bad. Although it did give us some great memes (stay morbin friends), one can’t deny that it was a disaster class of a film. There’s nothing there. Nothing redeemable, nothing to give you hope, just Jared Leto and all the strangeness that comes with him.

An Aside: As strange as Jared Leto is, I’ve got something of a soft spot for the man because of his glory days as lead singer of Thirty Seconds to Mars.

The Kill, From Yesterday, This Is War, Alibi, and Attack are all songs I love. If I ever made an anime, those songs would be in the OST. They’re built for either anime opening sprinting toward destiny, or anime closing gazing off into the distance. I’m a fan of both.

Or to illustrate, my range of emotions when listening to Thirty Seconds to Mars fluctuates from this to that:

Anyways, I could keep going…and I will.

Suicide Squad, the first one, which funny enough also featured Jared Leto doing a terrible job, was that bad. Batman v Superman: Dawn of Justice was that bad. Ant-Man and the Wasp: Quantumania was that bad, so bad I ranted about it. Thor: Love and Thunder was that bad, so much so that it had me questioning how the MCU even works.

Those are the kinds of movies where the online discourse of “ayo this 💩 is trash” makes sense. You can hardly even defend those films. They’re train wrecks.

Supergirl is not in that category. It isn’t that bad.

MCU Comparisons

Forgive me, but it’s no secret that any conversation about the DCU somehow, someway, turns into a comparison to the MCU. It can be annoying, but it is what it is. The MCU is the standard of excellence for superhero franchises on the big screen.

And if you think back, what the MCU did was remarkable. The run from Iron Man in 2008 to Avengers: Endgame in 2019 was generational. We’re still sleeping on it. Life moves on, we keep scrolling, our attention spans get cooked, and before long we’re barely reflecting on things that happened a few minutes ago, let alone recent history. But that stretch up until Endgame was insane. It was a cultural moment. It was, to use the precise academic term, peak.

So, let’s remember how the MCU kicked off. Iron Man was great. The Incredible Hulk was not. As the second entry in the MCU, it was a shaky follow up. It wasn’t franchise killing bad, but it also wasn’t proof that Marvel was about to become the biggest thing in cinema.

Now, in similar fashion, we have Supergirl, the second film in the still nascent DCU, flopping at the box office. And similar to the MCU, it’s following a very strong first entry in the franchise, namely Superman. But that’s where the similarities end, because Supergirl is better than The Incredible Hulk. Not by much, but it’s better.

If the MCU’s leadership weathered the storm that was The Incredible Hulk’s failure, how much more should the DCU do the same with Supergirl when it’s not even that bad. Any calls for the firing of James Gunn and Peter Safran, the leads of the DCU, are premature.

Can you imagine if Kevin Feige got fired after The Incredible Hulk? We would’ve missed out the greatest franchise in cinema history.

My point is, early stumbles don’t have to define an entire universe. If the MCU could survive The Incredible Hulk being bad, the DCU can survive Supergirl being mid.

What’s Wrong With Supergirl

I’ve never been accused of being a poet, but here’s my attempt at summing up the problem with Supergirl.

It isn’t that bad. It just isn’t that good.

Does that make sense? I doubt it, so let me expand a bit.

Coming after Superman, which was genuinely great, Supergirl feels like a side hug from your crush. It’s not that bad. Things might still develop. It just isn’t that good.

Without spoiling anything, Milly Alcock is fantastic in the role. She’s the right person to play Supergirl. The problem is the movie around her.

The story kind of wanders from scene to scene without giving you much to hold onto beyond a middling interest in seeing Supergirl in action. I mean, watching superpowered people fly around and punch things is always fun, at least to me. But the story itself feels predictable from the jump, which would be fine if the journey were stronger.

We all know the good guys are going to win. It’s a superhero movie. The destination is not the problem. The problem is that the journey doesn’t give us enough emotional investment in the characters, a world beautiful enough to get lost in, or dialogue engaging enough to make things feel fresh. It’s all pretty meh.

The villain doesn’t help. He’s milquetoast, and the only strong thought I had about him was logistical in nature. Specifically, how is this guy eating punches from a Vitamin D doused Supergirl? If he can go toe to toe with a full powered Kryptonian, why is he this bland? Like flesh him out a bit, someone so strong deserves more back story.

But more than that, the color palette of the film might be my biggest gripe. Superman was bright, colorful, and full of life. Supergirl, stylistically, is drab. That choice is especially strange because the graphic novel the movie is based on, Supergirl: Woman of Tomorrow, is extremely colorful and full of vibrant scenery.

Taking that source material and making the film look so dull was certainly one of the decisions of all time. The universe feels lived in, sure, but it’s missing the comic book pop that made Superman feel so refreshing, especially for those of us who are sick and tired of grimdark superhero movies. Life already sucks, let the movies be bright, colorful, and hopeful PLEASE!

Still Worth Seeing

It’s not all bad though, there’s still plenty in the film that works. The scenes with Superman are great. Krypto the Superdog is fun whenever he shows up. Jason Momoa is fun as Lobo. The aliens look great, in that original Star Wars cantina kind of way. And most importantly, Milly Alcock as Supergirl is not a problem. She feels right for the role. It’s the movie around her that’s a letdown.

If you were thinking about seeing the film, I hope this article hasn’t discouraged you. It really isn’t a bad movie. If you paid to see any of the other films I mentioned in this post, you should absolutely go see Supergirl. You wasted your money on those. You won’t be wasting your money here. Not entirely at least.

In fact, I think most fans who don’t overanalyze things and aren’t very online will find the movie entertaining enough to be worth their time. If you watch it without immediately running to read everyone else’s opinions, I think you’ll walk out like, “that was alright”, and then probably forget about it in a week because it doesn’t give you a ton to meditate on afterward.

Which is fine. Not every movie needs to rearrange your soul. Sometimes “good enough” is good enough.

Let Them Cook

All that said, I stand by the very simple premise of this article.

Supergirl isn’t that bad.

To bring it back to the MCU comparison from earlier, imagine if Kevin Feige had been fired after The Incredible Hulk came out and stumbled. We would’ve missed out on a generational run because people panicked too early.

Firing James Gunn and Peter Safran over Supergirl would be an overreaction. The movie is mid. That’s not the same thing as catastrophic.

Calm down. Let them cook.

The Surface Area Debate

There are questions I keep hearing, from colleagues, from friends, on Reddit, on Hacker News, in group chats. They all come in different flavors, but they boil down to the same thing. “Which AI coding tool should I be using to get the best results?”

The responses to that question are endless. Conflicting, contradictory, everyone-has-a-different-answer-and-they’re-all-absolutely-sure-they’re-right. As a software engineer expected to be on top of the latest with AI, it can cause a real sense of FOMO. Sometimes even impostor syndrome. But that feeling fades every time I dive deep to get to the truth behind the noise.

When it comes to GitHub Copilot specifically, and its many surface areas (ways of interacting with a tool), here’s the kind of stuff I see people asking.

• Which surface area should I use if I want the best results out of coding with AI?
• Why is everyone talking incessantly about the CLI these days?
• Is the CLI doing something that wasn’t happening before using GitHub Copilot in Agent Mode in VS Code?
• Is GitHub Copilot in VS Code fundamentally a different thing than GitHub Copilot on the web and in the CLI?
• In what cases does it make sense to use the CLI vs using the VS Code Chat?
• If I use the CLI, should I even be reviewing the code? How do I review changes across many files in the CLI? If the answer is “use an IDE” then why did I leave the IDE in the first place?
• Isn’t there literally a terminal inside VS Code? So why are we acting like this is CLI vs VS Code when you can do both at the same time?
• Why are we using a terminal as a chat interface when we already had a chat interface?
• Which one of these do I need to use to keep my “AI adoption” metrics high, and me off layoffs.fyi?

If you’re confused, you’re not alone.

Nothing good comes from confusion, and in this age of AI, it feels like everybody’s talking, contradicting one another, and making things sound more complicated than they really need to be. Let’s get some answers.

Why GitHub Copilot

I’m a software engineer at a company you’ve probably heard of, and I use GitHub Copilot daily across its many surface areas. CLI, VS Code, GitHub.com, you name it.

This article focuses on GitHub Copilot specifically, but the core lessons apply to every AI coding tool out there. Claude Code, OpenAI Codex, Gemini CLI, Antigravity, Cursor. They’re all great.

But Microsoft is so invested in GitHub Copilot, and so good at enterprise licensing, that if you have a corporate job there’s a very real chance you’ll be using it whether you chose it or not. But unlike a similarly named Microsoft product, GitHub Copilot doesn’t suck. The GitHub Copilot CLI has caught up with Claude Code to where the differences between the two are negligible. VS Code is the world’s best IDE, and GitHub Copilot Chat works beautifully within it. So if you’re a corporate wage slave employee, you’re best served learning how to use it well.

That said, the learnings here, specifically around Context Engineering, apply to all AI coding tools.

Where This Confusion Comes From

This whole debate is a direct result of Claude Code being so popular. It popularized terminal-based AI coding, vibe coders latched onto it, and Microsoft caught up by pushing the GitHub Copilot CLI. Now there are CLIs, web interfaces, and IDE extensions everywhere. The options multiplied, but nobody stopped to explain that the underlying AI is the same.

Part of the problem is history. GitHub Copilot launched in 2021 as an underwhelming autocomplete tool, didn’t get chat until 2023, multi-file edits until late 2024, and full Agent Mode until early 2025. A lot of people formed their opinion during the autocomplete era and never updated it.

Microsoft’s legendary inability to name things clearly doesn’t help either. Even Simon Willison, co-creator of Django and one of the most respected voices in AI-assisted coding, tweeted asking “Is the Microsoft product called Copilot the same thing as GitHub’s product called Copilot?” If he’s confused by Microsoft’s naming, you definitely shouldn’t feel bad.

This confusion isn’t limited to users of GitHub Copilot though. It’s everywhere. In a recent Reddit thread about the Claude Code VS Code extension, one user put it plainly.

I can’t figure out if there’s a difference between CLI, web and VS Code extension. I feel like they all work.

u/imabev

To which another replied:

Same, as someone who does not know a lot about the technical bts, it’s kind of confusing to pick one.

u/JohnDoe99101

That exchange is a microcosm of what I’m trying to bring clarity to. The same exact confusion, playing out across AI coding tools, not just GitHub Copilot.

People are asking “which one is the best?” when the answer is that they’re all fundamentally the same LLM-powered, context window limited, Agentic AI, reading the same codebase (yours), calling the same models, constrained by the same token limits, just behind different interfaces.

That’s not to say the surface area you choose doesn’t matter at all. But it’s not what makes or breaks your results.

Hopping from GitHub Copilot Chat to GitHub Copilot CLI and typing the same prompt won’t change much, other than you discovering that LLMs are non-deterministic.

What actually moves the needle is Context Engineering. If you haven’t encountered the term yet, Philipp Schmid, a Staff Engineer at Google DeepMind, defines it well.

Context Engineering is the discipline of designing and building dynamic systems that provide the right information and tools, in the right format, at the right time, to give an LLM everything it needs to accomplish a task.

Philipp Schmid - The New Skill in AI is Not Prompting, It’s Context Engineering

It’s the evolution of prompt engineering. Instead of obsessing over how to phrase a single question, you’re engineering the entire environment the AI operates in. Instructions, tools, memory, examples, quality gates. Anthropic also frames it nicely.

Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.

Anthropic - Effective Context Engineering for AI Agents

Invest in Context Engineering, and every single one of those surface areas gets better. All of them. At the same time.

One GitHub Copilot, Many Doors

There is one GitHub Copilot. One.

The GitHub Copilot docs and the VS Code docs spell this out clearly. GitHub Copilot runs in different environments depending on when you need results and how much oversight you want. The two key dimensions are where the agent runs (your machine or the cloud) and how you interact with it (interactively or autonomously in the background).

From a single dropdown in VS Code, you can pick between all of them. Local GitHub Copilot Chat for interactive work, GitHub Copilot CLI for background tasks, or a GitHub Copilot Cloud Agent for PR-based workflows.

Or you can go directly to each surface area on its own. Run the CLI in your terminal or assign an issue to a Cloud Agent on github.com. They’re not different tools. They’re different windows into the same tool. The difference is the interface.

• GitHub Copilot Chat. VS Code, Visual Studio, JetBrains, etc. Agent Mode, chat, inline suggestions.
• GitHub Copilot CLI. Your terminal. Any terminal (including the one’s inside of IDE’s). Terminal-native AI coding assistant.
• GitHub Copilot Cloud Agent. GitHub. Assign issues to agents, get PRs back.
• GitHub Copilot on GitHub.com. Immersive chat about your repos.

The CLI Craze

Somewhere along the way, a UI preference got confused for a quality difference.

The Claude Code vibe coding craze has some people thinking that by using the CLI you are uniquely doing something you weren’t before. That the terminal is somehow producing better output because… it’s a terminal? It’s the same AI. Same models. Same codebase.

And here’s what’s left me the most perplexed throughout the CLI craze. There’s a terminal in VS Code. It’s been there for years.

The GitHub Copilot CLI works inside VS Code. You can use it and the chat at the same time. You don’t have to choose.

This is a rather obscure meme, or so I’ve been told, so click here for the origins of it.

Anyone saying stuff like “GitHub Copilot CLI is way better than VS Code Chat,” or “I switched to the CLI and my productivity 10x’d,” or “Stop using VS Code, the terminal is the future,” or “Why I ditched VS Code Chat and never looked back” is either misinformed, misleading others, or just flat out wrong.

Stop the cap. They’re not competing products. You should use what you feel comfortable with. I mean, VS Code will literally call the CLI for you if you set the chat window to “Background.” And again, there’s a terminal in VS Code.

I’m not the only one confused by the CLI craze. In a recent Reddit thread asking “What are the advantages of using Copilot CLI over VS Code?”, the top comment was.

You look like a hacker and people think you are smart.

u/Genetic_Prisoner

And another great point that I agree with 100%.

CLI inside of vscode is where it’s at. Easy to open files and access to IDE internal tools, with all the benefits of the cli.

u/mattgrommes

And then there’s someone who tried it at work and felt a purely CLI experience wasn’t it for them.

That was my thing. I had it installed as an experiment at work and I didn’t get it. It felt like I wasn’t supposed to look at the code, which is so very, very wrong.

u/SirMarkMorningStar

This is the part that concerns me the most. The CLI craze was popularized by vibe coders using Claude Code who don’t necessarily care about what the code looks like as long as it works.

That’s fine for side projects. But if you’re a software engineer at a job where bad code means getting paged at 3 AM, where an outage ruins your team’s entire week, where you’re accountable for what ships, you better be looking at the code. As Simon Willison puts it.

Your job is to deliver code you have proven to work.

Simon Willison

An IDE with a built-in terminal gives you the best of both worlds. You can review diffs, trace through code, and still fire off CLI tasks without leaving. A pure terminal on its own doesn’t give you that visibility.

Now, to be clear, the CLI absolutely has its place. Terminal-native workflows, background tasks, fire-and-forget automation. It’s great for all of that. Once I have a plan I trust, I give things to the CLI for it to do the needful.

But the reason any of it works well isn’t because the CLI has some magic that GitHub Copilot in VS Code or the other surface areas doesn’t. It’s because of good Context Engineering.

Context Engineering Is What Actually Matters

In GitHub Copilot’s ecosystem, Context Engineering comes down to a set of features that work across every surface area. They’re not tied to one interface. They live in your repo. For a detailed comparison, see the GitHub Copilot Customization Cheat Sheet.

• Custom Instructions. Tell the AI how your team works. Scoped broad or granular with glob patterns. (GitHub Docs, VS Code Docs)

• Custom Agents. Specialized modes for specific workflows like code review, documentation, onboarding new services, or migration. (GitHub Docs, VS Code Docs)

• Agent Skills. Packaged domain knowledge the agent loads on demand. Think of it like codified tribal knowledge that AI can use whenever. (GitHub Docs, VS Code Docs)

• Prompt Files. Reusable, parameterized prompts for repeatable tasks. (GitHub Docs, VS Code Docs)

• MCP Servers. External tool connections for databases, APIs, and internal services. I’ve written about MCP here. (GitHub Docs, VS Code Docs)

• Agent Hooks. Automated quality gates. Linting, tests, formatting, automatically. (GitHub Docs, VS Code Docs)

• Agent Plugins. Bundle all of the above for easy distribution across teams and repos. (GitHub Docs, VS Code Docs)

Same context, same instructions, same results. Regardless of which surface area you’re in. No surprises. No “it works differently in the CLI than in the Chat.” You can even hand off sessions between them, starting a plan in VS Code GitHub Copilot Chat and finishing with a pull request generated by the CLI running in the background.

This is where knowledge workers who understand the problems the business needs solved are still incredibly valuable. We don’t write all the code by hand anymore, but there’s still a lot of work for us to do for AI to not suck. AI doesn’t know your domain, your standards, or your edge cases. You do. Write it down. That’s the job now.

The Bottom Line

What produces better output is Context Engineering. Custom Instructions, Custom Agents, Agent Skills, Prompt Files, MCP Servers, Agent Hooks, Agent Plugins. These are the levers. They work across every surface area. Invest in them, and the AI gets better everywhere.

Stop optimizing where you type. Start optimizing your context.

Related Reading and Resources

• VS Code Context Engineering Guide. Walkthrough of how to apply Context Engineering in VS Code with GitHub Copilot.
• VS Code Agents Overview. Practical guide on which surface area to use for which task.
• Awesome Copilot. Curated collection of Context Engineering tools, plugins, and resources for GitHub Copilot.
• GitHub Copilot CLI for Beginners. Great starter course if you want to learn the CLI.
• Mastering GitHub Copilot for Paired Programming. Deeper dive into working with Copilot across workflows.
• Accelerate App Development Using GitHub Copilot. Structured Microsoft Learn path for those who want the full curriculum.
• Agentic AI: From Acronyms to Applications. My post on the broader Agentic AI landscape.
• Coding Is Dead. Software Engineering Isn’t. My post on how AI changes the craft of software engineering.

Have thoughts, questions, or want to share your own setup? Find me on LinkedIn.

GitHub Copilot in VS Code has a built-in tool called web (or fetch in some contexts) that pulls stuff from websites. The agent uses it on its own whenever it decides to research something online, and you can also trigger it explicitly by typing #fetch <URL> in a prompt.

Either way, by default VS Code prompts you to approve every single URL. Add this to your settings.json to auto-approve all of them:

"chat.tools.urls.autoApprove": {
    "https://*": true,
    "http://*": true
}

The https://* pattern wildcards every HTTPS domain, and http://* does the same for HTTP. Setting the value to true auto-approves both the request and the response. No more confirmation dialogs. No more interruptions.

Some Background

The official VS Code documentation covers URL approval in detail, including how the two-step approval process works and how to configure per-domain rules. You can read all about it in the Use tools with agents docs, and the setting itself is listed in the GitHub Copilot settings reference. What I’m showing you above is how to skip all of that and approve everything.

To be clear, this is not the same as auto-approving all tools. VS Code has a separate setting called chat.tools.global.autoApprove that disables approval prompts for every tool, including ones that write files, run terminal commands, and modify your environment.

That’s the YOLO nuclear option. What I’m recommending here is much more targeted. chat.tools.urls.autoApprove only affects URL requests made by the web (a.k.a. fetch) tool. It lets GitHub Copilot read web pages without asking, while still requiring your approval for everything else.

If you’d rather be more selective about which domains get auto-approved, you can specify them individually:

"chat.tools.urls.autoApprove": {
    "https://learn.microsoft.com": true,
    "https://*.github.com": true,
    "https://stackoverflow.com": true
}

Here’s the full description of the setting from VS Code’s hover tooltip:

Controls which URLs are automatically approved when requested by chat tools. Keys are URL patterns and values can be true to approve both requests and responses, false to deny, or an object with approveRequest and approveResponse properties for granular control.

• "https://example.com": true — Approve all requests to example.com
• "https://*.example.com": true — Approve all requests to any subdomain of example.com
• "https://example.com/api/*": { "approveRequest": true, "approveResponse": false } — Approve requests but not responses for example.com/api paths

How To Open settings.json

If you’re not sure how to get to settings.json, open the Command Palette with Ctrl+Shift+P (or Cmd+Shift+P on Mac), then type Preferences: Open User Settings (JSON) and select it. That opens the raw JSON file where your VS Code settings live. For more on how VS Code settings work, check the official docs.

Final Thoughts

I have a custom agent that does research for Charlotte Third Places, a project where I catalog spots you can hang out and chill around Charlotte, NC.

The agent’s entire job is to visit URLs and gather information about places. You can check it out on GitHub if you’re curious. When I run it as a background agent or cloud agent, it visits whatever URLs it deems necessary without issue. But when running it locally in chat, it stops to ask me about every single one. This agent needs to hit a lot of URLs. That’s its whole purpose. Stopping to approve each one defeats the point.

I appreciate VS Code erring on the side of caution though. Secure by default is the right call, and the fact that they expose a setting to control this is excellent design. Locked down out of the box, but configurable for people who want to loosen the reins. If something goes wrong, that’s on you. That’s how it should work.

That said, I do value being able to let it browse freely, loosen the parental controls a bit. I also use GitHub Copilot in Plan mode a lot, where I ask it to research things online and cite its sources. It’s not changing my code, it’s reading web pages. If you’re already trusting GitHub Copilot to help you write code, letting it read public web pages without a permission slip feels pretty reasonable.

Update (February 24, 2026): God answers prayer. A week after I posted this, I was scrolling along and came across this article from Axios Charlotte. Waymo’s driverless cars have been spotted in Uptown Charlotte! Does that mean someone from Waymo read this and said “we got you fam” before kicking off deployment to Charlotte? Unlikely, but a man can dream. So happy to hear they’re on their way to the Queen City. The hype is real ladies and gentlemen, Waymo is legit!

Disclaimer: Nobody asked me to write this. Nobody paid me to write this. I’m simply a man who got into a car with no driver and lost his mind at how wild that is. We’re living in the future out here!

Some Background

So I recently took a trip out west, like my boy Fievel (kudos to you if you get that reference). I spent the past few days in San Francisco exploring Silicon Valley and the Bay Area for the first time. The highlight of the trip, even with all the noteworthy sights, ended up being something I hadn’t given a second thought to on the way there. Waymo.

Waymo is a fully autonomous ride-hailing service owned by Alphabet, the parent company of Google. Which is something I only just learned, and honestly it explains a lot. Google has all the maps data one could ever dream of. No wonder Waymo is so good.

While in the area, I visited my employer’s offices in the region, stopped by the Googleplex and Apple Park (the famous spaceship campus), and hit a ton of Bay Area tourist spots. I didn’t get to go inside Google or Apple, but they have cool visitor centers, and I took plenty of pictures! Anyways, the topic at hand is Waymo, so let us remain focused.

Waymo Is Incredible

What word should I use to describe it? Incredible. Amazing. Outstanding. Remarkable. The experience of using Waymo is all of those things, but nothing demonstrates that better than the below recordings of my first few experiences with it. Check them out below. In reflection, I’m a little embarrassed at my childlike excitement, but given how insane it is that we now have fully autonomous self-driving cars in the real world, I’d say it’s warranted!

Now, I know if you live in San Francisco or one of the other cities that’s had Waymo for a while, you’re probably thinking “we been had that, what are you so excited for?” Fair. But America is big, the world is bigger, and Waymo isn’t in most places. So please, forgive those of us who are unable to remain nonchalant in the face of a technology once relegated to science fiction. Let us have our moment of giddy joy.

The thing is, I’d heard of Waymo for years. Literally a decade ago I was familiar with them. I love tech, I follow tech, I read the blogs, I’m in the communities. Waymo wasn’t new to me. But I’d never seen it live. I’d never experienced it, and now that I have, it’s literally science fiction made real. It feels surreal. Every time I got in one, I just couldn’t believe this was a thing.

I’m a lover of the poetic, epic, and regal sounding parts of the Bible, so I can’t resist sharing this passage that I think puts into words what I felt.

I had heard of You by the hearing of the ear, but now my eyes have seen You.

Job 42:4-6

Now of course, Job was talking about literally seeing God, and this is nothing even approaching that level, but still. For someone that has been aware of Waymo forever and joined in at times maybe thinking the hype was overblown, I have myself been blown away.

It’s as good as they claim it is. The hype is real. I know there’s plenty of prophecy about how knowledge shall increase but when you’re living through it, it’s like wow man. This is crazy.

It Dwarfs Uber and Lyft

If Waymo were in my city, I’d never use Uber or Lyft again. The prices are competitive, and the convenience of hopping in a car with complete and total privacy, control of the A/C and heat, control over the music, control over the amount of legroom, and above all just the peace of mind of being able to sit back and enjoy the road without any added minutiae, it’s unbeatable. As an introvert, I don’t think I’ve ever been so enamored with a technology as I am right now with fully autonomous self-driving (maybe the hype will pass who knows).

Furthermore, you have people who, for good reason, don’t feel safe getting into a car with a stranger, particularly one that is driving them to or from their place of living. Waymo solves that issue. It’s just the car man. Like, I can’t even put into words how crazy it is until you try it. You get into a car and it’s just you and that thing is DRIVING with nobody in it and it drives flawlessly. I felt completely and totally safe.

They’re Expanding

Some good news, Waymo is aggressively expanding. You can check out their latest expansion updates and their full rides map for the most current info, but here’s a snapshot of where things stand.

Waymo is currently offering fully autonomous rides in the following cities:

• Atlanta, GA (via Uber)
• Austin, TX (via Uber)
• Los Angeles, CA
• Miami, FL
• Phoenix, AZ
• San Francisco Bay Area, CA

And they’ve announced plans to expand to:

• Boston, MA
• Dallas, TX
• Denver, CO
• Detroit, MI
• Houston, TX
• Las Vegas, NV
• London, UK
• Nashville, TN
• Orlando, FL
• Sacramento, CA
• San Antonio, TX
• San Diego, CA
• Washington, DC

And they’re actively testing with manual drivers (meaning a human is in the car while the system learns the roads) in even more cities:

• Baltimore, MD
• Buffalo, NY
• Minneapolis, MN
• New Orleans, LA
• New York, NY
• Philadelphia, PA
• Pittsburgh, PA
• Seattle, WA
• St. Louis, MO
• Tampa, FL
• Tokyo, Japan

Funny enough, St. Louis, a city I consider my true hometown, is on that testing list. It makes me genuinely happy to see it on there. I eventually moved to Charlotte, and I hope with all my heart they add us too. If any Waymo executives are reading this, the Queen City is ready. We’d welcome you with open arms. We’ve already got DoorDash delivering by drone, so we’re clearly a city that embraces the future.

At this moment, I feel like I want everyone everywhere to try Waymo. You don’t appreciate it until you do. We have fully autonomous self-driving cars. There’s no gimmick. There’s no “well, but.” There’s no gotcha. The car drives itself, and it does so safely, securely, and without any concerns. Technology man, what a wonderful thing!

Note: This article was originally written for a workshop I created for computer science students, inspired by Canva and Meta allowing candidates to use AI in coding interviews. I’ve adapted it here for a general audience. Check out the Workshop Website, GitHub, and Slide Deck.

New: I built AI & Your Tech Career as a continuously updated resource site with practical answers, skills to learn, free courses, tools, and more. If this article got you thinking, that site is where to go next. Visit aka.ms/nocap.

Times Are Changing

AI has fundamentally changed what it means to be a productive software engineer. The question we’re all asking right now across the industry is “when AI writes almost all code, what happens to software engineering?”

There has to be something of value, of high skill, that justifies developer salaries. Something beyond writing code from scratch by hand. Most people assume that’s all software engineers do, but that wasn’t true before AI, and it isn’t true now.

So what’s left for engineers to do? The answer is mostly the same as it’s been in the many attempts to get rid of developers in the past.

Can you drive the software development life cycle end to end, ship something correct, and then maintain, enhance, and monitor it for the foreseeable future?”

That’s what actually matters.

I work at a company you’ve likely heard of and use GitHub Copilot in its various forms every day. I’ve done so since 2021, when it first hit the scene as a mediocre coding assistant that was little more than fancy auto complete. Since then, my goodness has it had a glow up. It’s far from mediocre, and I wouldn’t want to go back to a world working without it.

What I do most of the time now amounts to natural language programming. I describe what I want in jargon-laden technical prose, refine what AI generates, verify correctness, and integrate it into larger systems. That might make you think, “well then, of what value is your technical expertise? Couldn’t a random business person just vaguely describe what they want and cut out the software engineer entirely?”

No! Matheus Lima explains why well in AI Can Write Your Code. It Can’t Do Your Job.

Technical expertise is still essential across the entire software development life cycle, beyond the code itself. Understanding systems architecture, debugging weird edge cases, knowing when AI is confidently wrong, designing systems that scale, reviewing and validating AI-generated code, navigating organizational politics, aligning stakeholders, making build-vs-buy decisions with incomplete information, owning accountability when things fail in production, planning, testing, integration, DevOps, FinOps, security. That’s where the real skill lives.

Matteo Collina, maintainer of Node.js, Fastify, Pino, and Undici, and Chair of the Node.js Technical Steering Committee, captures this well in The Human in the Loop:

I provide judgment. I decide what should be built, how it should behave, and whether the implementation matches the intent. I catch the cases where the AI confidently produces something that looks right but isn’t. This isn’t a new skill. It’s the same skill senior engineers have always had. The difference is that now it’s the primary skill, not one of many.

When I ship code, my name is on it. When there’s a security vulnerability in Undici or a bug in Fastify, it’s my responsibility. I can use AI to help me move faster, but I cannot outsource my judgment. I cannot outsource my accountability.

Your Value Lies Beyond the Code

Nicholas Zakas, creator of ESLint, argues in From Coder to Orchestrator that the role is shifting from writing code to orchestrating systems. The skills that matter now are problem decomposition, validation, context management, and knowing when AI is wrong.

This isn’t speculation. Boris Cherny, lead developer of Claude Code at Anthropic, put it bluntly: “In the last thirty days, 100% of my contributions to Claude Code were written by Claude Code.”

But that shouldn’t scare you. Check out the OpenAI and Anthropic careers pages.

• OpenAI Careers
• Anthropic Careers

Anything with the word “Engineer” in it is a technical role. If AI is so capable, why are these companies still hiring technical staff? What would those engineers be doing that OpenAI Codex or Claude Code can’t handle with Sam Altman or Dario Amodei simply describing what they want?

Well, this is a tale as old as time. A few years ago, a new grad posted on Reddit, confused about why senior engineers spend so little time coding. They wanted to know, what are all these meetings about? What do staff and principal engineers actually do if not write code?

The top comment sums it up:

Because the real value in this profession isn’t writing code. It’s determining what code to write.

— u/MarcableFluke on Reddit

And the top reply to that comment as well:

and a bunch of clowns, who are screaming that AI will take our jobs, don’t realize this. They think we are monkeys mashing our keyboard all day. I welcome AI to do all my coding or 90% of it so I can focus on more critical stuff.

— u/VeryDryChicken on Reddit

A text-generating non-deterministic probability engine isn’t going to cut it at enterprise scale when all it has to go on is “make it faster,” “please fix all the security,” “make it compliant so we don’t get sued,” or “make it look better, the customers said it was ugly.”

Why LLMs Can’t Replace You (Yet)

I want to be clear about the limitations here. LLMs are powerful tools, but they have fundamental constraints that matter for real engineering work.

Zed’s article, Why LLMs Can’t Build Software, nails it. LLMs can generate code that looks right, but they can’t maintain mental models, verify their own reasoning, or truly understand the system they’re building into. You still need humans who hold context across codebases, reason about edge cases, and make judgment calls.

A quote from a start-up founder interviewed in a New York Times feature on AI coding, puts it plainly:

It’s a delusion to imagine that your AI agent will generate a whole project at once, in a “Big Bang” moment. Yes, you can get it to write 5,000 lines of code, but then you test it and nothing works. This is where their (a human’s) training and expertise are still needed: knowing how a big codebase ought to be structured, how to design the system so it’s reliable and how to figure out if the agent is sloppy.

— Coding After Coders: The End of Computer Programming as We Know It

Simon Willison, co-creator of Django, and a highly respected voice in the developer community these days regarding AI, makes a related point in Your Job Is To Deliver Code You Have Proven to Work.

Almost anyone can prompt an LLM to generate a thousand-line patch and submit it for code review. That’s no longer valuable. What’s valuable is contributing code that is proven to work.

Bridging the gap between ‘AI generated this’ and ‘this is production-ready’ is still a human job. Owning the outcome. When it breaks at 2 AM, ‘the AI wrote it’ isn’t an answer. You signed off on it.

Remember, a computer can never be held accountable, therefore a computer must never make a management decision. That’s your job. That’s what separates a developer from a vibe coder someone who just prompts AI and hopes for the best.

Is It Vibe Coding or Vibe Engineering?

There’s been a lot of buzz around vibe coding, a term coined by Andrej Karpathy, an OpenAI co-founder and technical heavyweight in the Machine Learning world. It refers to the fast and loose approach where you prompt AI and accept whatever comes out if it seems to work. Ironically, the term was coined by someone as technical as it gets.

Simon Willison coined a counterpart he calls vibe engineering, which he admits sounds a bit silly. It’s working with AI tools while staying “proudly and confidently accountable for the software you produce.”

The distinction matters. Vibe coding is fine for a lot of things. Even Linus Torvalds, creator of Linux and Git, is vibe coding these days. If he’s doing it, it’s clearly not beneath anyone. But for anything sufficiently serious, you shouldn’t even try it (and he says as much).

Willison’s concept of vibe engineering is more appropriate for production software, or anything you actually need to work and maintain. That means writing (or having AI write at your explicit direction) automated tests, planning before implementing, maintaining good version control habits, developing strong code review skills, and building the ability to recognize when AI is wrong.

As Willison puts it:

AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents.

The Illusion of Vibe Coding

This section’s title is pulled from a great article by Frantisek Lucivjansky I think you should read: The Illusion of Vibe Coding: There Are No Shortcuts to Mastery.

I’ll summarize. If you skip the hard work of actually understanding how code works, you will hit a wall. AI can generate code, but you need a technical foundation to debug it, extend it, and fix it when things break. And things always break. Always.

Joel Spolsky, co-founder of Stack Overflow and Trello, wrote about this dynamic back in 2000, long before AI coding existed. In Things You Should Never Do, Part I, he laid out what he called a “cardinal, fundamental law of programming”:

It’s harder to read code than to write it. This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.

It’s also why vibe coding falls apart at scale. When things break, you can paste the error back to AI. And when that fix breaks, paste again. But that’s a loop, not engineering. Context windows fill up. Context rot sets in. At some point, a human has to actually diagnose the problem. AI can help you fix it once you know what’s wrong. But you have to know what’s wrong.

Spolsky was writing about Netscape, the browser that dominated before Internet Explorer, which dominated before Chrome, but it still applies today. His article was about why companies shouldn’t rewrite codebases from scratch, but the lesson transfers perfectly to AI-generated code. Reading and maintaining code is the hard part. That’s where the skill lives.

This isn’t just opinion. Anthropic, the company behind Claude, published research confirming this.

In How AI Assistance Impacts the Formation of Coding Skills, they found that developers who offloaded their thinking to AI scored nearly two letter grades lower on comprehension tests. The largest gap was in debugging, the very skill you need most when AI-generated code breaks. But developers who used AI while still asking conceptual questions and building understanding scored just as well. The tool isn’t the problem. Mindless delegation is. This Reddit discussion about the research is worth reading too.

Here’s some insightful comments from that thread:

I’m not gonna lie, using AI is like a performance-enhancing drug for the brain. But it also helps me realize when I should independently spike and research, because it’s constantly making up sh*t that SHOULD work but just ain’t so. Human + AI is best, but juniors probably shouldn’t be using it, in much the same way that teenagers should not be drinking alcohol. Many will still be using occasionally, but not having good boundaries around it means you’re one big AWS outage away from having half your brain ripped out.

— u/Boxy310 on Reddit

There’s an important caveat here: “However, some in the AI group still scored highly [on the comprehension test] while using AI assistance. When we looked at the ways they completed the task, we saw they asked conceptual and clarifying questions to understand the code they were working with—rather than delegating or relying on AI.” As usual, it all depends on you. Use AI if you wish, but be mindful about it.

— u/ZenDragon on Reddit

The article is weird. It seems to say that in general across all professions, there are significant productivity gains. But for software development specifically, the gains don’t really materialize because developers who rely entirely on AI don’t actually learn the concepts - and as a result, productivity gains in the actual writing of the code are all lost by reduced productivity in debugging, code reading, and understanding the actual code. Which, honestly, aligns perfectly with my own real life perception. There are definitely times where AI saves me hours of work. There are also times where it definitely costs me hours in other aspects of the project.

— u/_BreakingGood_ on Reddit

So, you still need computer science fundamentals. Pick a language (I’d suggest Python) and invest time in understanding how programming, databases, operating systems, distributed systems, networking, and software actually work.

If you want a great resource for building that foundation, check out From Nand to Tetris, which is also on Coursera. It’s a project that teaches you how a general-purpose computer and its software function from the ground up. AI can’t accelerate you in real-world software engineering if you’re useless without it. Build the foundation first.

A Historical Perspective

Here’s a historical perspective that I find grounding. Stephan Schwab wrote Why We’ve Tried to Replace Developers Every Decade Since 1969, which does an excellent job showing how long before AI coding became a thing, people have been trying to get rid of developers.

This graphic by Kedasha Kerr on LinkedIn pairs perfectly with that article.

Did you know that business people in the 60s thought COBOL would let them fire all their developers? COBOL! The Common Business-Oriented Language. They believed it would let them plainly describe what they want and thus build software without software developers. How’d that turn out?

We’ve been here before. Every few decades, someone claims that a new technology will eliminate the need for developers. None of these predictions came true because the fundamental complexity of software development cannot be abstracted away. The complexity just moves.

This doesn’t mean AI isn’t transformative. It is. But it’s transformative in the way that power tools are for carpenters, or calculators for accountants. For anything actually important, and sufficiently complex, you still need to know what you’re doing.

The Junior Developer Question

One of the hottest topics in tech circles these days is “will AI kill entry-level software developer jobs?” It’s a fair concern given headlines about job market struggles and declining internship opportunities.

I think junior roles will survive, but this is a raging debate. We have job data, but it’s hard to tell if AI is actually doing the work or if companies are just pouring CapEx into data centers instead of hiring.

For a balanced overview of where things stand, start with Addy Osmani’s (a Software Engineer at Google working on GCP and Gemini) piece: The Next Two Years of Software Engineering

From there, here’s a collection of articles from people who have thought deeply about this. Read them and form your own opinion.

The case that juniors can thrive:

• New York Times (Clive Thompson) - Coding After Coders: The End of Computer Programming as We Know It
• Kent Beck - The Bet On Juniors Just Got Better
• Andrew Ng - Why You Should Learn to Code and not Fear AI
• Andrew Ng - An 18 Year Old’s Dilemma: Too Late to Contribute to AI?
• GitHub’s Blog (Gwen Davis) - Junior Developers Aren’t Obsolete: Here’s How To Thrive in the Age of AI
• Time Magazine (Marcus Fontoura) - You Should Still Study Tech — Even if AI Replaces Entry Tech Jobs
• Thomas Dohmke - Developers, Reinvented
• Nicholas C. Zakas - From Coder to Orchestrator: The Future of Software Engineering With AI
• Matteo Collina - The Human in the Loop
• Latent Space - The Rise of the AI Engineer

The case that things are getting harder (or…it’s over) for juniors:

• Stack Overflow Blog (Phoebe Sajor) - AI vs Gen Z: How AI Has Changed the Career Pathway for Junior Developers
• Michael Arnaldi - The Death of Software Development
• Kaustubh Saini - 9 Entry-Level Jobs Are Disappearing Fast Because of AI
• Time Magazine (Luke Drago and Rudolf Laine) - What Happens When AI Replaces Workers?
• Namanyay Goel - New Junior Developers Can’t Actually Code
• Fortune (Chris Morris) - Anthropic CEO Warns AI Could Eliminate Half of All Entry-Level White-Collar Jobs

Should I Still Grind LeetCode?

Yes. Not because it makes sense, not because you’ll ever solve clean and contained LeetCode style problems at work, but because companies are still asking those questions.

Even though AI can solve most all LeetCode problems instantly, companies still use those questions as a baseline filter. Can you think algorithmically at all? Do you understand time and space complexity? Can you reason about tradeoffs?

LeetCode is an imperfect proxy for these things, but it’s the proxy most companies still use. Until the industry catches up to the reality of AI-assisted coding interviews (like those offered by Canva and Meta), you have to play the game.

Here are the best resources for grinding effectively.

• The Tech Interview Handbook - The best “hand hold me through this” guide online.
• The Blind 75 - For a structured “what problems should I focus on” plan that’s been curated over years by the tech community.
• The Grind 75 - From the makers of the Tech Interview Handbook, a customizable approach to The Blind 75.
• The Neetcode 150 - The Blind 75 but with 75 more problems to really go hard.
• The System Design Primer - For everything you need to pass system design interview rounds.

But Isn’t Using AI Cheating?

If you haven’t been given explicit permission to use AI in an interview, then yes, using it is absolutely cheating. No debate about that. But that hasn’t stopped people, and there’s a growing industry around it. Check out this article: Meet the 21-Year-Old Helping Coders Use AI to Cheat in Google and Other Tech Job Interviews.

If you don’t feel like reading, the summary is there are now legitimately undetectable tools like Interview Coder, Cluely, and LeetCode Wizard that help people cheat coding interviews, and they really do work. Companies relying only on LeetCode are not happy about it, but that’s the world we live in. This is unethical, totally not what I’m encouraging, but it’s what’s happening.

Some companies understand that the old model is broken. Candidates are going to use AI whether you allow it or not. So instead of pretending it doesn’t exist, they’ve redesigned their interviews around it. Candidates are expected to use AI, but they still own the plan, the tradeoffs, the correctness, and the proof. The workshop I built around this idea enforces the same standard. You can use AI, but you must be able to explain what it produces and prove it works.

When I interact with students, I bring them the now. What I face every day working at a big tech company that’s aggressively pushing us to be more productive. I use AI every day at work to write code. That’s the job now. The knowledge of “grind LeetCode to get hired” is well known. There’s nothing of value brought by an industry person going to a college campus to tell students the obvious.

This is a new frontier, and my goal is to help students get ready for it. What they need is practice working with AI the way professionals actually do, driving the process, verifying the output, and owning the result.

Some Companies Are Letting Candidates Use AI In Coding Interviews

While LeetCode is still a thing, there are some companies catching on to the fact that with AI, it no longer makes sense to ask those questions. It doesn’t reflect what a person would be doing at work if they were hired. Check these out.

• Canva - Yes, You Can Use AI in Our Interviews. In Fact, We Insist
• Wired - Meta Is Going to Let Job Candidates Use AI During Coding Tests
• Reddit Testimonial - Canva’s AI Assisted Coding Interview
• Anna J. McDougall - You Can’t Outrun AI in Tech Interviews, So We Designed Around It

Some common themes across these new AI-assisted interviews are:

• They fully expect you to use AI. Copy/paste the problem into the chat window. They want to see what you’d actually do at work.
• You’re still expected to sit in the driver’s seat. AI is a copilot.
• You still own the plan, the tradeoffs, the correctness, and the proof.
• You will need to explain your thinking out loud. The solution AI built, the time and space complexity, what prompts you’re writing next and why. If you type “hey do all this work I have no idea what I’m doing” that’s a clear no hire signal. If you’re writing intelligent prompts that provide guidance, direction, and push back, that’s a pilot using a copilot effectively.

In Conclusion

The industry is still figuring things out, but the direction is clear. Coding as a task is being automated. It’s gone fam. If you want to write code by hand all day as a career, it’s over. But software engineering as a discipline, the judgment, the systems thinking, the verification, that’s becoming more valuable, not less.

Furthermore, I think people should read Latent Space’s AI Engineer article. If you’re even a little bit technical and know how to tinker and put things together, you can do amazing things quickly with AI, even if you’re no good at LeetCode. Just look at Moltbook, fully made by a vibe coder with plenty of security concerns to go with it.

Don’t fight the AI wave. You won’t win. There’s a new divide forming. Adapt or die.

Nerd Note: The gif above features the character Jim from the Disney movie Treasure Planet (2002), one of my all time favorites. When it came out, I was obsessed with its sense of adventure. Jim lived in a small town but had big dreams. He was longing, yearning, every day for a chance to see the universe, and when it came, he took full advantage of it. I’ve always been inspired by that to step out and explore. To me, exploring doesn’t have to be the kind of stuff that’d impress the social media crowd. America’s so big, I’ve done most of my exploring (so far) just by moving across the country from coast to coast. Treasure Planet flopped at the box office, but it has a special place in my heart. I remember they had really good McDonald’s Happy Meal toys for it, this was one of my favorites.

The Charlotte Observer – Looking for a New Hangout? This Website Helps Charlotteans Find a Third Place

One of my personal passions is adventuring, and I don’t mean just the kind that requires traveling all about. Social media has convinced so many of us that you can only adventure when you book a trip to some destination city that everyone’s going to think you’re cool, cultured, and “well-traveled” for having gone to.

I grew up poor, and only recently managed to make it to “there’s some disposable income for leisure” status in life, so I had to learn to adventure in place. No car, no flights, just my two feet and local public transportation. That’s how I explored.

I did that growing up in the greater Seattle area, during college in St. Louis, during internships in Omaha and Stamford, and I’ve kept the habit even now as a working professional with the ability to venture a bit further. Wherever I am, small town or big city, I’m going to look around. I’m going to try and check out every single place that interests me, and even ones that don’t, keeping notes and data points along the way. I’m the person in the friend group maintaining spreadsheets to organize to-do’s, stuff to watch, restaurants to try, all of it.

So, after moving to Charlotte during the pandemic, once things opened up, I did exactly that. I took full advantage of my remote work status to hang out anywhere and everywhere around the city. In 2024, I turned all that info into a website, Charlotte Third Places. I wrote about how I built the site in this post, although a lot has changed since then. Improving the site in my free time has become my go to hobby whenever I’ve got a spare moment.

All that said, the point is I got to chat with The Charlotte Observer about the project, how it was built, where the idea came from, my goals for it, and more. Check out the article below!

What’s up, if you don’t work with Microsoft Fabric (Microsoft’s latest greatest data everything platform) this article will make no sense. But if you do, welcome. Let’s get straight to it.

I’m here to clear up some confusion evidenced by posts like these from members of the Microsoft Fabric community:

• Lakehouse SQL Endpoint Access
• How to Share a Single Lakehouse Within a Workspace

For a given Microsoft Fabric Workspace, do the Lakehouse databases each have their own SQL Analytics Endpoint, or do they share the same one?

Answer: They share the same one. All Lakehouses in a given Fabric Workspace share the same SQL Analytics Endpoint. But it wasn’t always that way. Here’s what’s up.

Things Changed

According to this Microsoft documentation page:

The number of SQL analytics endpoints in a workspace matches the number of Lakehouse items.

What is a Lakehouse SQL Analytics Endpoint?

Reading that, you’d naturally think: “Okay, so if I have 3 Lakehouses in my workspace, I’ll have 3 different SQL endpoints to connect to.” Right? At least to me, that’s how the language comes across. And well, that used to be true, but not anymore.

Things Now

The only thing you need to know is: All Lakehouses within a single Fabric workspace share the same SQL Analytics Endpoint. When you copy the SQL Analytics Endpoint of any Lakehouse in your workspace from the Fabric UI, that endpoint is good to connect to all the Lakehouses.

There used to be one endpoint per Lakehouse, but that sucked and customers complained. Now, there is one endpoint per workspace, and each Lakehouse appears as a separate database on that endpoint.

An Example

Let’s say you have a workspace called ImportantDataHub with the following SQL endpoint:

SQL Endpoint: gibberish.datawarehouse.fabric.microsoft.com

You’ve created three Lakehouses in this workspace with cool names:

• Kumogakure
• Sunagakure
• Konohagakure

When you connect to that single SQL endpoint, you’ll see all three databases:

-- Connect to: gibberish.datawarehouse.fabric.microsoft.com

-- Available databases:
USE Kumogakure;   -- Your first Lakehouse
USE Sunagakure;   -- Your second Lakehouse
USE Konohagakure; -- Your third Lakehouse

This is actually closer to traditional SQL Server behavior. You can use USE statements to switch database context. At least, the USE statement works from SSMS 22. I’m less sure about whether it works from the Fabric Workspace UI where I had some issues. Point is, you don’t need a different connection string for every database.

Working With The New Endpoints

Now, since it’s an auto-created endpoint, as Microsoft states here:

There’s no need to create a SQL analytics endpoint in Microsoft Fabric. A SQL analytics endpoint is automatically created for every lakehouse, database, or mirrored database

What is a Lakehouse SQL Analytics Endpoint?

It’s an ugly URL. A bunch of gibberish. Pretty hard to tell what it’s pointing to if you’re in a situation where you have many Fabric workspaces.

Thankfully, the latest version of SQL Server Management Studio (SSMS) has added a feature to address this. When connecting to a Fabric SQL Analytics Endpoint, the pretty name of the workspace shows up.

Read the full details of SSMS 22 here: SQL Server Management Studio (SSMS) 22 is Now Generally Available

It ends up looking like this when you connect. You can see the Fabric language now integrated into the platform. The black bar, redacted for privacy, would show the name of the Fabric workspace on which the SQL Analytics Endpoint sits.

And side note, I’m digging the new SSMS logo. Makes me feel very modern, very suave, very cool. Like a hip, in the know, fresh, data modernist kind of guy, rather than an ancient on-premises SQL Server legacy infrastructure DBA type of guy, which I’m totally not. But looking at the old SSMS logo did at times make me feel like one of those legends (shout out to anyone who was doing data engineering before ChatGPT, you deserve your flowers).

Why This Is Better

I think this architecture is actually better. It makes my life easier at least. In the early days of Fabric (which, given how fast they release updates, is just months ago), each Lakehouse had its own endpoint. At some point recently, Microsoft changed this. The documentation just hasn’t caught up yet.

Here’s why having one endpoint per workspace is superior:

• You only need to manage one connection string per workspace instead of N connection strings for N Lakehouses. Makes your CI/CD pipelines and configuration files simpler.
• If you’re coming from a SQL Server background (which many working with Fabric are), this feels natural. One server, multiple databases. We already know how to work with this model.

Closing Thoughts

Microsoft Fabric is rapidly evolving, and sometimes the documentation takes time to catch up with product changes. They’ll get it updated eventually.

The best place to hangout, ask questions, and get the latest is r/MicrosoftFabric. The Fabric product team engages directly there, and the community keeps it real, both with frustrations and praise when deserved.

Now go forth and connect to your Fabric Lakehouses with confidence. You’ve got one endpoint to rule them all.