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.

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.

The Fix

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.

Warning: This article contains light spoilers for a movie from 2007. You should still watch it though. In fact, I’d love if you watched it first then came back to read this. It’s a short film, and I don’t spoil much, but going in blind is always better!

A Nostalgic Return to Viewing Simplicity

We’ve lost something. All of us, we’ve lost something. With IMDb, Twitter, TikTok, Instagram, Facebook, Snapchat, YouTube, Reddit and Sora (shudders in dystopian fear), we’ve lost something.

It’s watching movies based on your interest alone. No reviews. No IMDb scores. No checking what others are saying online. Just you. What do you think of the synopsis? Does the VHS or DVD cover catch your eye? What about the poster at the video store? Did the trailer grab you? Or maybe you heard about it from someone you actually know? That’s how we used to decide what to watch.

Well, I got to return to that world one rainy morning at Visart Cafe, a vintage video store and cafe hybrid run by a nonprofit that’s been supporting film literacy since the 80s. I was there to work remotely, and seeing as I was the only customer, they graciously asked if I wanted to choose a film to put up on their big (small) screen.

I walked through their massive collection of VHS tapes and DVDs and settled on two options. Things We Lost in the Fire (2007) featuring Halle Berry and Benicio del Toro, and Reign of Fire (2002) featuring Christian Bale and Matthew McConaughey.

I left it in the capable hands of the staff to choose which to show first, and I’m glad I did. They chose Things We Lost in the Fire, and in what was my first viewing of the film, I was pleasantly surprised. Touched really. I needed a film like it. Something that highlights maintaining hope through the pain, and living life one step day at a time.

More than a decade after its release, it has a 7.1 on IMDb and a 65% on Rotten Tomatoes, which is a reminder of why you should just watch movies. Tune out the cacophony of opinion hailing from people you don’t know. I went in blind, no expectations, no preconceptions. Just a movie I’d never heard of from 2007 that I ended up enjoying. That’s how it should be. Just live man. Just live.

Not Your Typical Love Story

Things We Lost in the Fire is a beautiful drama, so I’m going to try and review it without spoiling too much. You should watch it! One of the film’s major themes is love, but not just the romantic kind. All four of the loves make an appearance in some way, shape, or form.

You start off thinking to yourself okay I know where this is heading. This is going to be a typical Hollywood find-a-way-to-put-two-really-good-looking-people-together movie, but it’s more than that. The film subverts those expectations and goes deeper.

Audrey Burke (Halle Berry) loses her husband Brian Burke (David Duchovny) in the opening of the film. Brian was everything you’d want in a husband and father. Compassionate, loving, and loyal to a fault. He refused to abandon anyone, especially his childhood best friend Jerry Sunborne (Benicio del Toro), despite Jerry’s ongoing battle with heroin addiction.

After Brian’s death, Audrey has to navigate grief while raising their two children, Harper (Alexis Llewellyn) and Dory (Micah Berry). She’s always resented Jerry, seeing him as proof of her husband’s “foolish” need to see good in everyone. Yet she surprises herself by inviting Jerry to the funeral. Going even further, she tries to honor Brian’s memory by extending the same love he showed Jerry. What follows is an unexpected arrangement where Jerry moves into the family’s garage as he attempts to get clean.

The film explores whether two broken people, both grieving and clearly attracted to one another, can help put each other back together without crossing boundaries that shouldn’t be crossed. It’s about honoring the memory of someone you love by loving the people they loved, even when it’s hard. Even when you don’t want to. Even when society might judge you for it.

The Diversity of Love

What touched me most about this film is its depiction of love that goes well beyond romance. Brian loved his best friend Jerry, and Jerry loved him, unconditionally, even though he was a heroin addict. Brian never gave up on him, never stopped seeing him, never stopped mentioning him to his wife and kids, never stopped celebrating his birthday.

That right there, that’s Agape love, the fundamental tenet of the teachings of Jesus Christ. It doesn’t matter how many times someone messes up, you’re there, you’re forgiving, you’re loving, while that same love flows back to you from God above.

Check out The Four Loves by C.S. Lewis to understand how we’ve oversimplified the word love in English. Other languages use different words for “I love chocolate” versus “I love my family” while we just have one word that we discern by context.

I enjoyed how as the film progressed they kept you off balance as to whether or not Jerry (Benicio del Toro) and Audrey (Halle Berry) would be hooking up. My initial reaction was this is a very tough situation for them both. Your best friend is dead, you want to be there for the family, but you don’t want to take his place or try and do anything sheisty.

It reminds me of the movie Brothers with Tobey Maguire, Jake Gyllenhaal and Natalie Portman. Different premise but similar with the thought of someone passing and what that does to your bro code when stepping in to be there for the family.

Halle Berry Shines

Halle Berry did some of her finest acting in this film. I mean, my whole life I seriously can’t say I’ve ever seen her in a movie where her acting alone is what made me enjoy the time I spent watching.

But in this one, her exceptional good looks fade to the background, and she does a great job at showing grief in various ways. It lingers over her through empty stares, mechanical movements, and moments of sudden exhaustion that overtake her mid-conversation. Even when she’s with her kids, it’s like she’s there but not fully there.

And her interactions with Benicio del Toro’s character Jerry, who grapples with addiction, seal the deal on her performance. A favorite scene of mine is when she finds out that Jerry didn’t actually take money from their car when her late husband went to visit him, after she’d accused him of being a thief to her husband that same day. It’s golden how she shows us without words that feeling of “man I’ve been such a jerk.”

It also reinforces that Jerry, a former lawyer, now heroin addict, is honorable. He wouldn’t steal from his friend or risk being a burden on him. He wouldn’t even show his face around the house until he was clean. He wasn’t a bad guy, he was just a man who fell off the wagon, who made mistakes, and was trying to work his way back.

Love That Heals

As the film progressed, my initial reaction of “ayo this is wild having this man move in when your husband just died like give it some time” started to fade. I began to understand that Audrey is driven by guilt. She openly admits to hating Jerry for being friends with Brian, and now that Brian is dead, she wants to make amends by loving the person her husband loved, carrying on his legacy of compassion.

Side Note: Shout out to the dead husband for setting his family up to never worry about money. That’s how you do it fam if you’re going to up and die playing hero (watch the film to learn more). Make sure your people are good.

Audrey’s trying to extend that love, and the guilt she feels at her prior hatred is real. So it makes sense that she moves Jerry in, but there’s one really weird scene where he helps her with her insomnia that I just, like listen man, that was weird. Watch the movie, you’ll see what I mean.

Grief That Lingers

By extending love to Jerry to honor her husband, Audrey slowly begins to find peace. That’s what took her past grief, letting go of her hatred, opening her heart. It brought not just her but her kids together and gave Jerry the motivation to get clean.

Now look, I see Jesus in everything. It’s often said that two people can look at something, one person sees trash, the other treasure, or the glass half full or half empty. There’s truth in those clichés. I see Christian themes of love in this film. I saw the same in Naruto, in Harry Potter, in Game of Thrones.

If you ever run into me, ask me about any film, movie, show, or anime I’ve seen and I’ll find a way to show you Jesus through it. And so, redemption being a core theme of this film, and that being offered through love from Audrey to Jerry in honor of Brian’s initial love?

Yeah, that speaks to me. Because what is grief, if not love persevering?

The Supporting Cast

The relationship between the kids and Jerry was well done. The kids, played by Alexis Llewellyn and Micah Berry, weren’t annoying, which is rare for child actors (who are now adults the same age as me lol). Their behavior and mannerisms were in line with how you’d expect a kid to talk.

The only thing I think is weird is how quickly they moved away from their Dad towards Jerry. I mean I get that grieving children are going to look for comfort, but it would’ve been more realistic to show them resisting their Mom moving a man in so soon after Dad’s death. Their father was great to them, yet within weeks they’re already treating Jerry like a replacement dad.

That minor gripe aside, the rest of the supporting cast really brings this film to life. I especially loved John Carroll Lynch’s character Howard as comedic relief and just as a really solid guy. He didn’t judge Jerry for his addiction, and was instantly willing to hear him out and return his honesty with honesty of his own. Just a jolly fellow, sincere and down to earth.

I also really liked how Audrey’s whole family ends up embracing Jerry without judgement. They didn’t look down on him. They extended to him the same love that his best friend, their lost husband, brother in law, son in law, father, had extended to Jerry. They continued that love in his honor, despite never meeting Jerry while Brian was alive. I loved seeing that.

Other Thoughts

The movie takes place in Seattle, which is something you can miss if you’re not paying attention.

I grew up in the greater Seattle area so when I heard Jerry was down in Renton on a heroin bender, I was like you know what, that tracks lol. Although Renton has been gentrified these days, back in the 2000s and 2010s, it wasn’t exactly a nice place to hangout.

The thing I miss about the Seattle area is surprisingly the rainy weather. For some, it makes them want to stay at home and do nothing. But it makes me want to sit in a coffee shop or bookstore by the window and read something good, drink a hot tea, and watch the rain. Then walk home without an umbrella, with my hood only half drawn, so I can feel that patented spray bottle pitter patter misty Seattle-style rain on my face.

Also, when it’s gray and rainy, all the coolest places in a city are less busy. You can go and get the whole place to yourself. The moment it starts raining, I find the hottest trending Instagram or TikTok spot and finally go check it out. It’ll be me, the staff, and one or two other people who don’t let the weather stop their mojo.

Anyways, Seattle man. For all its problems, it’s not the geographic region that’s the cause of any of it. The Pacific Northwest is beautiful!

I also think the film’s title Things We Lost in the Fire is beautiful. The scene in the film where they finally say it is so very well done. I had a moment like this Family Guy clip of going “they said it!”, but in a good way. It wasn’t random. It fit. It was natural. Bravo.

Box Office Bomb, Artistic Triumph

Cash rules everything around both you and me, despite that being a terrible way to live, and the movie industry is no exception.

Things We Lost in the Fire was a box office bomb. Budget of $16 million, worldwide gross of only $8.5 million, but who cares? Some of the best films tank at the box office (looking at you my beloved Treasure Planet). This is one of them.

The closing scenes are deeply emotional. Audrey drives through the rain to pick up flowers left at her door, with the film’s motif playing. It’ll leave you in tears if you’re the crying type. I’ll admit I got teary-eyed near the end. I didn’t cry though (although if I did, you’ll never know), since I was watching it in public (shoutout Visart Cafe).

And then we get a final monologue from Benicio del Toro’s Jerry. It’s hauntingly beautiful. A man 89 days clean of heroin, battling through it all, adopting the simple but true concept of taking life one day at a time.

That’s how Jerry gets clean. That’s how Audrey moves through grief. That’s how the kids learn to live without their father. That’s how we all get through the things we lose in the fire.

Love doesn’t die when people do. It just finds new ways to heal the living. Brian’s love for Jerry became Audrey’s love for Jerry. That love spread to her entire family, and Jerry reciprocated it in kind. And that love? It saved them all.

One day at a time man. One day at a time. The wind rises, we must try to live!!

Note: That gif is from the Studio Ghibli film The Wind Rises, a great watch if you’re looking for a hopeful reminder to take life one day at a time.

You can skip the prologue and hop straight to the core concepts by clicking here. This article is a companion piece to presentations delivered to PMI Carolinas and the Charlotte Women in Data Science (WiDS) Conference at UNC Charlotte. You can check out the PMI Carolinas deck here or the WiDS Charlotte deck here. The WiDS version includes a hands-on workshop where participants interact with a real AI agent built for the session.

Some Background

I generally find LinkedIn, when used correctly, to be a solid platform compared to the rest of social media. So long as you tightly control your followings (you don’t have to follow your Connections), you can find yourself in the midst of relatively valuable conversations about niche sectors of various industries, all of it mostly professional.

And yet, never before has LinkedIn been more of a pompous, pretentious, puffed up, hype-peddling wasteland than it is right now.

And it’s all because of one thing.

I’m a software engineer at a company you’ve likely heard of, and once upon a time, you used to be able to rely on the technical crowd to eschew itself from such nonsense. To speak about how things actually work, about what’s going on under the hood, to lean on the classic hallmarks of software development. Works like…

• Donald Knuth’s The Art of Computer Programming.
• Robert C. Martin’s (affectionately called Uncle Bob) Clean Code.
• Industry legends Kent Beck and Martin Fowler’s Refactoring.
• Andy Hunt and Dave Thomas’s The Pragmatic Programmer.
• Design Patterns by the venerable Gang of Four.

…and more. No matter how many new languages or frameworks or paradigms would come out, the core fundamentals of computing and software would remain the same.

But given the risen of AI, I’m here to tell you that…

…ALL OF THAT IS STILL TRUE!

That’s right ladies and gentlemen. Building software is still hard. LLMs can’t do it totally devoid of human involvement.

The do more with less CEOs, since the emergence of Generative AI in 2022, have finally…hopefully…learned their lesson. The rise of AI doesn’t mean you can axe your entire IT division, as Klarna had to learn the hard way.

In fact, with the rise of Agentic AI, you need your IT division to upskill.

Don’t just take my word for it. Both McKinsey and Bain, whose consulting wisdom 🙄 has shaped the Fortune 500 for decades, are running around telling CEOs the same thing.

You can’t just spin up an Agentic AI solution from Microsoft, Google, or Amazon and expect it to work magic out of the box. Despite what their marketing teams might suggest, there’s significant complexity under the hood that needs to be understood and properly configured.

The Show Goes On

Agentic AI’s ascension, which misinformed plebeians have taken to mean “it’s over for software developers”, has only increased the need for technical individuals to piece together multi-modal, multi-agent, distributed, scalable, cost-efficient, low-latency, federated systems that can do more than just be a chatbot.

And so, I present to you a meme from this iconic scene in The Wolf of Wall Street. One that perfectly captures the cathartic declaration of defiance that we, the technical workforce worldwide, have been needing since 2022.

That fateful year when everyone and their mama who knows nothing about software development decided our entire industry would be gone “any day now” because they vibe coded a to-do app in 30 seconds.

For each and every one of us, I say to you…

…and, like Leo’s character in that same scene after finishing his speech, I am, at the present moment, feeling like…

But all this raises the question: what is Agentic AI? Like…what is it really?

The Rise of Agentic AI (And Why Everyone’s Confused)

Agentic AI is being pushed so hard by the LinkedIn clout-chasing crowd that you’d think they’re all decades deep into understanding it.

But alas, such is not the case.

I can tell you confidently that even among developers, there isn’t uniform understanding of precisely what is meant by Agentic AI.

The terminology surrounding it is confusing. The lines between it and Generative AI chatbots like ChatGPT are blurry. The exact difference between something being Agentic and traditional automation we’ve had forever isn’t abundantly clear.

Meanwhile, the business folks are under immense pressure to sell Agentic AI as the promise of AI finally made real. Anything to justify the absolutely insane capital expenditures of building out data centers and buying up GPUs.

They’re talking ad nauseam about Agentic AI while themselves not really understanding what it is. And honestly, I don’t blame them. They’ve got bosses pushing them to “sell, sell, sell!” and thus must hit the road to push tech that most developers don’t fully understand how to build with yet.

And so, I write to inform. Let’s move from confusion to clarity together.

What Agentic AI Is

Agentic AI is AI that can make decisions and take actions independently with minimal human oversight.

It’s given a mission, not a conversation. Once you set the goals and guardrails, it plans, decides, and acts autonomously.

Sounds simple enough, right? Not quite.

A viral Twitter thread asked the tech community to crowdsource a definition of “agent” that could fit in a tweet. Engineers, researchers, developers all chimed in. No consensus emerged.

The Hacker News crowd is similarly struggling to pin down exactly what an “agent” is. There are litmus tests being proposed and debates raging. But one authoritative voice has emerged above the noise.

Anthropic, the company founded by former OpenAI employees, has become such a force that Microsoft told OpenAI “we’re not exclusive anymore” and welcomed their Claude models into Copilot. When they speak about AI, people listen.

Here’s how Anthropic defines an Agent:

Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

Anthropic - Building Effective Agents

Anthropic later distilled it even further:

We’ve gravitated towards a simple definition for agents: LLM’s autonomously using tools in a loop.

Anthropic - Effective Context Engineering for AI Agents

And OpenAI, the company that started this whole wave, frames it around three pillars:

An AI system that has instructions (what it should do), guardrails (what it should not do), and access to tools (what it can do) to take action on the user’s behalf.

OpenAI - Building Agents

Those three definitions together paint a clear picture. An agent is an LLM that has tools, follows instructions, respects guardrails, and acts autonomously in a loop to get things done.

Generative AI is reactive. It’s prompt and stop. You ask, it answers, it’s over.

Agentic AI is proactive. It’s plan and act. You give it objectives, and it figures out how to achieve them, taking multiple steps across different systems if needed.

Aside: Generative AI and Agentic AI are not competing concepts. They’re layers. An AI agent IS a generative AI model (like GPT) that becomes agentic when you give it tools and autonomy. The generative model does the thinking. The agentic layer gives it the ability to act. Saying “Generative” for chatbots and “Agentic” for autonomous systems is how the industry talks about it, but under the hood, agentic systems are built on top of generative ones.

These definitions aren’t perfect, and I’m sure someone somewhere is itching to hit me with a “well ackchyually”, but I think they’re sufficient to understand the gist of what’s going on.

What Agentic AI Isn’t

Now, given the sheer amount of confusion still out there, let’s be crystal clear about what isn’t Agentic AI. Sometimes figuring out what something isn’t helps you understand what it is.

• A chatbot is not an Agent.
• An automated script is not an Agent.
• A scheduled email is not an Agent.
• A Zapier workflow is not an Agent.
• A Power Automate flow is not an Agent.
• A cron job is not an Agent.
• A GitHub Actions workflow is not an Agent.
• An Excel macro is definitely not an Agent.

And for good measure, College Park is not Atlanta. Sorry, not sorry.

The Power and the Peril

All those things I listed follow predetermined rules. They don’t reason, they don’t adapt, they don’t make judgment calls. They’re automation, not autonomy.

An Agent, true Agentic AI, can look at a situation, understand the context, make decisions based on goals you’ve set, and take actions. Sometimes actions you didn’t explicitly program it to take, but that make sense given its mission.

If you’ve read this far and had a moment of “wait, if that’s what Agentic AI is, isn’t that kind of dangerous? Aren’t you guys letting the system go off and connect to things and do stuff and control things when we know AI itself isn’t sentient so it’s not like it really knows what it’s doing?”

Yes. Yes, you are right, and I applaud you for thinking that way. We can be friends.

Agentic AI is powerful, but also incredibly dangerous if you don’t set things up right. You should read these articles.

• Anthropic - Agentic Misalignment: How LLMs Could be Insider Threats
• MIT Technology Review - Why Handing Over Total Control to Agents Would Be a Huge Mistake
• MIT Technology Review - Cyberattacks by AI Agents are Coming

And to drive home my point, Microsoft is out here encouraging people to try out “vibe working” using Agent modes in their various products, like that isn’t the exact thing those aforementioned articles are talking about being a bad idea. There is no “vibe working”. Don’t do that. Don’t be a “vibe worker”, that’s the first step to being an “unemployed worker”, like what are you doing fam.

Key Acronyms Explained

We’ve covered what Agentic AI is and isn’t. Now let’s talk about some of the acronyms and concepts you’ll encounter when building or working with these systems.

• GPT (Generative Pre-trained Transformer): The AI model that started the present AI revolution. Creates new text by predicting what comes next using patterns learned from data. That “T” stands for Transformer, invented by Google in 2017 in the iconic paper “Attention Is All You Need.”

• Context (not an acronym, but crucial): The surrounding information that gives meaning to what’s being discussed. AI uses context from conversation history, relevant data, and the current prompt to understand what’s really meant, not just the literal words. A context window is how much info the AI can remember at once, its “short-term memory.” Larger windows mean better understanding of long conversations and documents.

• MCP (Model Context Protocol): A standard way for AI to connect to different tools and data sources. Think of it as USB-C for AI. One connector for everything. Anthropic created it and everyone supports it now. It’s the standard.

• RLHF (Reinforcement Learning from Human Feedback): How ChatGPT got so good. Humans rate AI outputs, and the AI learns from that feedback to be more helpful and less harmful. Invented by Paul Christiano while he was at OpenAI.

• GANs (Generative Adversarial Networks): Two AIs compete. One creates fake content, the other tries to detect it. Through this competition, both get better. Invented by Ian Goodfellow in 2014.

• NLP (Natural Language Processing): The field that lets computers understand human language, whether written, spoken, or even emojis and slang. Been around since the 1950s.

• LLM (Large Language Model): The foundation of modern AI. Trained on massive text collections with billions of parameters to predict what comes next.

• Tools (not an acronym, but essential for agents): A tool is a function an agent can call to interact with the outside world. Checking the weather, querying a database, posting to a website, looking up who’s in space. These are all tools. Without tools, an LLM is just a chatbot answering from its training data. With tools, it becomes an agent that can take action. When MCP talks about connecting AI to “tools and data sources,” this is what it means.

• RAG (Retrieval-Augmented Generation): A technique where the AI retrieves relevant information from external sources (documents, databases, websites) before generating a response. Instead of relying solely on what it learned during training, the model pulls in fresh, specific data to ground its answers. This is how you get an AI that can answer questions about your company’s internal docs without retraining the whole model.

Agentic AI Platforms

Listen. Listen to me.

The Agentic AI world is moving absurdly fast. By the time this post goes live, something here might already feel dated (I’m exaggerating…barely).

What follows are the platforms that currently matter in enterprise scenarios. Think end-to-end offerings, not just frameworks. Honorable mentions to CrewAI, LangGraph, LlamaIndex, and Atomic Agents.

• LangChain: Open-source, industry standard for agent orchestration.
• Azure AI Foundry: Pro-code platform for enterprise agents with built-in governance.
• Microsoft Copilot Studio: Low-code/no-code visual builder for business users as well as developers. Making building agents a click, drag, and drop experience.
• Amazon Bedrock Agents: Pro-code API-based agent development. Developers write code to connect AWS services and Lambda functions.
• Google Vertex AI Agent Builder: Low-code platform using Google’s Gemini models. Visual interface for building agents with RAG and tool calling.
• Salesforce Agentforce: Low-code agent builder for CRM workflows. Click-based configuration with pre-built templates for sales and service.

If you’re interested in the skills needed to build Agentic AI systems, check out my AI Engineering guide. AI Engineering is the emerging field for those who build this stuff. That’s what they’re calling the industry. You could call it Software Development, because that’s what it is, but I guess AI Engineering sounds cooler.

Try It Yourself

I built a hands-on workshop that lets you interact with a real AI agent, toggle its tools on and off, and then build your own custom agent with personalized instructions. No coding required. It runs entirely in your browser through Visual Studio Code for Education.

The agent has access to live tools that call real APIs: weather data, who’s currently in space, recent earthquakes, NASA’s Astronomy Picture of the Day, Charlotte Third Places from charlottethirdplaces.com (a project of mine cataloging cafes, libraries, parks, and hangout spots in the Charlotte area), Charlotte cinnamon roll rankings (from yours truly), anime recommendations, and more. You start with no tools to see the agent’s limitations, then progressively add them to watch its capabilities grow. By the end, you’re configuring your own agent from scratch.

Built with the Vercel AI SDK, powered by Microsoft Foundry on Azure. The workshop was first delivered at the Charlotte Women in Data Science (WiDS) Conference in March 2026.

Try it at aka.ms/aaw. All you need is a Microsoft or Google account. If you’re prompted for a workshop key, reach out to me on LinkedIn and I’ll get you sorted.

Essential Reading

Here’s some good stuff. These articles will get you up to speed on Agentic AI, and really AI in general, from the fundamentals to the cautionary tales to even more terminology worth knowing.

• Latent Space - The Rise of the AI Engineer
• Conrad Irwin - Why LLMs Can’t Really Build Software
• MIT Technology Review - Why Handing Over Total Control to AI Agents Would Be a Huge Mistake
• MIT Technology Review - Cyberattacks by AI Agents are Coming
• Anthropic - Agentic Misalignment
• Cerbos - The Productivity Paradox of AI Coding Assistants
• ShiftMag - The Illusion of Vibe Coding
• Microsoft - 10 AI Terms Everyone Should Know
• Microsoft - 10 More AI Terms Everyone Should Know
• IBM - Agentic AI vs Generative AI
• Forbes - Generative AI vs Agentic AI: The Key Differences
• Agentic AI: From Acronyms to Applications - Hands-On Workshop

A Final Note

There are very few seasoned experts in Agentic AI right now. We’re all figuring it out together. The technology is moving fast, but the fundamentals remain the same. You need humans who understand systems, can set boundaries, and know when the AI is hallucinating nonsense.

Agentic AI is powerful. It’s also dangerous if you don’t know what you’re doing. But if you take the time to understand it, to learn the tools and concepts, you’ll be part of building the future instead of being replaced by it.

The show goes on, my friends. The show goes on.

Be sure to connect with me on LinkedIn to continue the conversation about AI, tech careers, layoffs, anime (watch Steinsgate 🙌), Marvel (The Fantastic Four: First Steps 🔥), the new DCU (Superman 👏), Christianity, society, philosophy, you name it!

New: I built AI & Your Tech Career as a continuously updated resource site that consolidates much of what’s in this article and more. Skills, tools, free courses, student perks, and answers to the questions I keep getting asked. Visit aka.ms/nocap.

What’s Up

Welcome! If you’re reading this, you might’ve scanned a QR code during my workshop at SEO’s 2025 Tech Developer Conference in New York. If you didn’t, that’s alright. The information written here remains relevant in perpetuity for anyone interested in the tech field and feeling anxiety.

That said, if you were at the conference and got a swag bag, I hope you enjoyed the fruit snacks! Speaking of which…

Aside: Funables are the apex fruit snack. Don’t talk to me about Welch’s. I know you grew up with them, so did I, but they’re trash. Motts, trash. Annie’s, trash. Gushers, not fruit snacks. Black Forest, solid. Scooby Doo, mid.

To learn more about me, you can check out my about page or my Charlotte Business Journal 40 under 40 profile. Otherwise, let’s get down to business.

Quick Guide

During the workshop, I promised resources and answers. Here’s where to find them:

Core Concepts:

• What Is AI Engineering? - Definition and why it matters
• It’s Easier Than You Think - Why you don’t need a PhD
• Why Coding Still Matters - The truth about AI and programming

Resources:

• What to Learn - The core competencies of AI Engineering
• Where to Learn - Free courses and tools
• Who to Follow - Key people and organizations
• What to Read - Essential articles
• Landing a Tech Job - Practical job hunting advice

Key Links:

• Workshop Slides
• AI Engineering GitHub List
• Free GitHub Copilot for Students
• Unlisted Microsoft Recruiters Group for Students

What Is AI Engineering?

It’s still a relatively new term, although it’s going mainstream, but here’s my attempt at a definition.

AI Engineering is the practice of building software that connects AI models to real-world systems and knowledge. While Machine Learning Engineers create the models, AI Engineers make them useful by providing the right context, tools, and interfaces for specific applications.

Real Spill: AI Engineering is just the evolution of Software Engineering. Most AI Engineers today still have “Software Engineer” or “Software Developer” as their job title, and probably will for a while.

I created this visual to illustrate what AI Engineering means in practice. It’s not perfect, but it gets the point across:

Aside: The image shows AI Engineer as the #1 fastest growing job title, which comes from LinkedIn’s 2025 Jobs on the Rise report.

Though honestly, this AI Engineer interview cheatsheet by Priyanka Vergadia is even better. This is really just about every domain you’d want to grow deep in if you want a future in tech on the technical side of things. This is stuff we still need humans to do that involves empowering, controlling, configuring, and working with AI.

Software development is so much more than writing code!

In general, think of Machine Learning Engineer vs. AI Engineer this way. They’re both athletes, but in different sports.

Maybe Machine Learning Engineers are playing baseball while AI Engineers are playing basketball. Both benefit from being athletic (technical skills), but they’re different sports requiring different tactics, and one is harder (baseball is harder than basketball, don’t @ me).

Or maybe it’s more like Machine Learning Engineers build the engine and AI Engineers build the car around it, customizing for how different kinds of people plan to use it.

I don’t know, no analogy is perfect. The point is, Machine Learning Engineers build the models, and AI Engineers take those models and build with them.

The term was popularized by Latent Space.

I think it is a full time job. I think software engineering will spawn a new subdiscipline, specializing in applications of AI and wielding the emerging stack effectively…The emerging (and least cringe) version of this role seems to be: AI Engineer.

The Rise of the AI Engineer

And it’s got approval from Andrej Karpathy, former Tesla AI Director, OpenAI co-founder, and one of the most influential voices in the AI community.

In numbers, there’s probably going to be significantly more AI Engineers than there are ML engineers / LLM engineers. One can be quite successful in this role without ever training anything.

Andrej Karpathy on Twitter

Another term you might hear is Context Engineering, which is essentially the same thing.

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 of Google DeepMind

The terms are still evolving in this space, but both have caught on because they capture the same core idea. Making AI useful by giving it the right context.

It’s Easier, and That’s a Good Thing

At first glance, the term “AI Engineering” might sound intimidating, but let’s keep things real 💯. It’s way easier than being a Machine Learning Engineer.

To be a proper Machine Learning Engineer, you need to be good at math. Like, really good.

We’re talking calculus, linear algebra, statistics, probability theory, all that. And it’s customary for them to have PhDs. To command the kind of respect that researchers at OpenAI, Anthropic, Google, and Meta have right now, you’d need one.

Your path to being one of those people Mark Zuckerberg is throwing pro-athlete level contracts at is much longer and harder than your path to being an AI Engineer…where you can make a solid 6 figures at companies that already hire software developers.

I’m not alone in this sentiment:

In the near future, nobody will recommend starting in AI Engineering by reading Attention is All You Need, just like you do not start driving by reading the schematics for the Ford Model T.

The Rise of the AI Engineer

Aside: Attention is All You Need is the research paper by Google that introduced transformers, the “T” in GPT. It’s a Machine Learning hallmark that paved the way for what eventually became OpenAI’s ChatGPT.

Funny thing is, I actually told people to read that paper in my AI learning guide. But you know what? I was wrong. You don’t need to go that deep to get paid in this field. You can, and should if you’re truly that passionate about AI, but to have a tech career both now and in the future, it’s not a must.

For me, you, and anyone wanting a tech career who isn’t great at math or trying to get a PhD, our reaction to the rise of AI Engineers should be:

Why Coding Still Matters

You can’t build serious systems, the kind companies up and down the Fortune 500 actually want, if you don’t understand code.

Vibe coding in its truest sense (no code review, just the end result) is not a real thing for people with paying jobs. There are no shortcuts to mastery.

To all my “vibe coding will get me hired in tech” people out there, I love you, but…

Aside: I haven’t watched Succession, and neither has Brian Cox, the actor in that gif. We’re both in agreement about avoiding good but stressful shows about deeply narcissistic, conceited, hedonistic people. I need at least one bastion of morality in my shows these days. Jon Snow, and Daenerys Targaryen before her tragic character assassination, are what got me through Game of Thrones. I need someone good, man. Someone.

Yes, AI can (and should) generate code for you, but if you have no idea what it’s doing, you’re flying blind. And no serious company is going to pay you to blindly copy-paste AI-generated code into their mission-critical (military, healthcare, infrastructure, financial, government, etc.) systems.

Sorry if that’s harsh, but I want to be sure I don’t have to go full…

…to get this point across.

So, are tech jobs going away? No! But they are for sure changing.

Sam Altman says the world wants 1000x more software. The CEO of GitHub says we need more programmers than ever. I’ve written extensively about this in my AI in tech careers post.

But the most compelling perspective comes from Andrew Ng. He co-founded Google Brain (they invented the “T” in ChatGPT), was Chief Scientist at Baidu, co-founded Coursera, and founded DeepLearning.AI. The entire Machine Learning community looks to him for training and guidance.

These two LinkedIn posts from him should reset your perspective on AI’s impact on tech careers:

Learning to code today isn’t about prepping for a future where you type every line yourself. We haven’t been doing that even before AI. High-level languages, Stack Overflow copy/paste, low-code tools, we’ve been doing anything and everything to make it easier to create software for a while now.

The future is being technical enough to orchestrate AI while you handle the problems that need human judgment.

Writing effective prompts, catching when AI hallucinates garbage, and debugging when things inevitably break. Those are the things no serious company will ever trust solely to a machine, and they’re what make you valuable and get you paid.

But you can only do these things if you can read and understand code, generate it with very specific prompts (essentially pseudocode), and occasionally, write it when needed.

AI in the Real World

Check out this Reddit discussion where software engineers and CTOs share their experiences with AI in the workplace. Companies that tried to replace humans with AI are regretting it, while those using AI to make their technical teams more efficient are getting more ambitious about projects. The result is more work than ever and a greater need for skilled humans who can use AI effectively.

This tracks with what Sam Altman said about the world wanting “1000x more software.” AI makes developers more productive (well…it depends), which means companies can tackle bigger projects and expand into new areas. Instead of replacing developers, this creates more demand for people who understand both technology and how to leverage AI tools.

For the technical analysis on why this happens, check out Why LLMs Can’t Really Build Software. It explains exactly why AI struggles with the mental models and iterative problem-solving that experienced developers excel at. The community discussions about that article on Hacker News and Reddit are also very insightful.

When it comes to building software, AI helps humans get things done. It doesn’t eliminate the need for them. It’s been a minute since OpenAI released ChatGPT in 2022. We’re not guessing anymore about how it’s impacting the industry. We know. AI Engineering is a real thing, and it’s the future of the field. One that keeps humans in the loop. Rejoice!

What to Learn

If you ever thought you could be a Software Engineer (or Software Developer, literally the same thing, don’t let anyone tell you otherwise), then you can be an AI Engineer.

The same fundamental skill of coding is required, but you also need a solid understanding of the technical areas that AI Engineers (mostly still called Software Engineers) work with day-to-day.

Many of these are areas that real-world software engineers already deal with. Its the stuff beyond just coding that often surprises new grads when they start building production systems at scale.

Here’s what you’ll need to get familiar with:

These aren’t things you need a PhD to learn. You don’t even really need a bachelor’s (although it certainly helps). You can learn all this stuff online.

Where to Learn

If you know basic Python, or any programming language, you’re ready to start. If not, begin with Google’s free Python course. After that, dive in.

Who to Follow

The tech community lives more on LinkedIn, Twitter (its real name), Reddit, and Hacker News than TikTok, Instagram, or Snapchat.

Tech people usually want to post and discuss without needing a picture or video to accompany it. Make a Twitter account just to follow these people if you need to.

What to Read

Must Read: Marcus Fontoura, Technical Fellow (the highest technical rank) and Chief Technology Officer for Azure Core at Microsoft, wrote You Should Still Study Tech—Even if AI Replaces Entry Tech Jobs for TIME Magazine. This op-ed perfectly captures why pursuing computer science remains a viable choice for students. This is the wrong time to run away from tech because the current job market and social media is scaring you. Its never been easier to be an effective technologist with AI handling a lot of the grunt work, and humans doing the real problem solving. Coming from someone who’s built search infrastructure at Google, cloud platforms at Microsoft, and has decades of experience leading complex technical organizations, his perspective carries serious weight. Read the article.

Landing a Tech Job

The shortest and sweetest advice I can give is apply early and often. It took me 112 applications back in 2020, 3 of which resulted in interviews, and only 1 of which resulted in an offer, to get in with my current employer.

Some people might hear that and think:

But that’s what it takes. You’ve got to hustle, hard.

If you’re in college, literally when you arrive on campus in the Fall, it’s time to apply for internships. Set aside a few minutes every day, download LinkedIn to find positions, use Easy Apply, set up job alerts on Indeed.

If your goal is big tech, check the Microsoft, Google, Amazon, Meta, and Apple student career pages regularly. The big tech companies are always posting, and sometimes at different stages, so you really got to keep an eye on their websites.

I’ve written extensively about this in my AI in Tech Careers and Miscellaneous Tech Career Advice posts. But honestly, if you’re with SEO, you’re probably doing just fine with finding internships as they have great resources.

Note: You can skip my yapping and go straight to the workshop by clicking here.

Some Background

It’s summer, it’s hot, I just saw the new Superman movie (it’s incredible, bravo James Gunn), and I’m fresh off another edition of my Discovery Day program. It’s a field trip where students visit my employer’s office in Charlotte for a full day of career exploration, STEM activities, and networking.

For this latest one, I created a new workshop using the Petoi ‘Bittle X’ Robot Dog, which features a fun new addition to its capabilities. I continue with my habit of taking what I’m learning as a software engineer and bringing it to students in ways that are approachable, fun, but most importantly, relevant.

We need to teach students skills that’ll actually land them tech jobs in this new age of AI. Things have gone far beyond just learning to code (although you still should). These days, if your approach to STEM Education doesn’t involve AI, you’re doing your students a disservice.

Tech workers everywhere are being routinely yeeted by AI, either into increased productivity, or the shadow realm. It’s not a fad, it’s changing the way we work. It’s already made my job way different. A lot of my time is spent directing AI to write code, albeit with rather technically dense prompts, rather than writing it myself. And beyond that, it’s proven invaluable for research tasks.

Gone are the days of having 30 tabs open troubleshooting an issue. A back and forth conversation with good prompting can get you the information you need faster than ever. It’s undeniable, AI is the real deal, and it’s here to stay.

Bittle’s New Toy: A Robot Arm

I’ve had something of a love affair with Petoi’s products when it comes to engaging students of all ages. Check out some local news coverage and my LinkedIn recap of an event I hosted featuring their Bittle X. It’s safe to say I’m a fan of their stuff.

The Bittle grabs students instantly with the “wow” factor. Once you have their attention, it’s easy to teach them real skills. They can control the dog with their voice, use a block-based programming tool, or dive into Python (my preference).

So when they recently introduced a new product to their lineup, a robot arm that can be bought as a separate attachment or purchased with a new dog, I was all in.

It’s an awesome addition to their already impressive lineup of extensions. What makes it specifically cool is the precision required to control it. Students quickly learn that being specific matters when dealing with technology, whether they’re using code, prompt engineering, or voice commands.

I was fortunate enough to receive one for use in my workshops, and I finally got the chance to cook something up with it. The workshop I created works with both the arm-equipped Bittle and the standard Bittle X, all while tackling the topic that’s on everyone’s mind these days: artificial intelligence.

Context Is All You Need

The workshop centers around a simple but powerful concept. AI becomes useful when you give it good context. Students start with an AI chat interface that only knows a few basic commands for the robot dog. Through hands-on challenges, they progressively teach the AI new capabilities by providing it with more context about the robot’s full range of abilities.

This demonstrates the core principle of AI Engineering, which is connecting AI to specific knowledge to solve real problems. It’s like the difference between asking someone to “make coffee” versus telling them exactly how you like it. You know, with oat milk, two pumps of vanilla, extra foam, half the ice, or whatever complicated concoction someone might be into (I’m an herbal tea guy, no additives, so I wouldn’t know). Give someone your specific preferences and suddenly they can make your perfect drink every time.

As Andrej Karpathy (former Director of AI at Tesla and founding member of OpenAI) proclaimed, we’re entering the age of AI Engineering. The future isn’t just about using AI. It’s about making AI useful by connecting it to real-world systems and knowledge. AI Models are brilliant but need specific context to be useful. That’s where AI Engineers come in.

Traditional software engineers write code to directly control systems. AI Engineers take a different approach. They write code that teaches AI how to control those systems. It’s still engineering, but instead of coding every action, you’re providing AI with the knowledge it needs to figure things out. In many ways, it’s just an evolution of the job title.

This workshop gives students a taste of both worlds. They see how traditional code controls the robot directly, then transform into AI Engineers by teaching AI to control it. More importantly, they learn that with the right context and tools, they can solve problems faster than ever.

See It in Action

Here’s some clips from the Charlotte–Mecklenburg Schools “Bases Loaded” back‑to‑school event where I delivered this workshop, as featured on Microsoft’s LinkedIn.

Required Materials

• Petoi ‘Bittle X’ Robot Dog (one per 5-6 students)
• Laptops with Python and VS Code installed
• Python packages: openai, python-dotenv, and pyserial (install via pip)
• OpenAI API Key (get one on their site)
• Workshop Folder Contains both the code and instructions for the workshop, found on GitHub. Copy the entire AI Engineering folder to the laptop(s) being used.
• Optional: Robot arm attachment for the final challenge

Facilitation Resources

All the code required to run this workshop is available in the AI Engineering folder on GitHub. Copy the entire folder onto each laptop and create a .env file in the lib folder with your OpenAI API key.

The full facilitation guide is below. The latest version will always be on GitHub.