AI Got Him Through. He Finished by Hand.

I have installed Linux on more machines than I can count. ThinkPads, Dells, an old Razer Blade that drained its battery in forty minutes. I have faced GRUB menus at two in the morning. I have recompiled kernels for Wi-Fi drivers that should have worked out of the box. Linux and I have history.

So when a friend mentioned wanting to leave his MacBook, I encouraged him strongly. I told him Linux was the answer. Freedom. Performance. Real control.

I forgot to mention the pain.

He wiped the machine and installed Fedora. It looked great. The hot corners worked the same way as on his Mac. But the Wi-Fi would not connect. It was not a weak signal. It was not a wrong password. The driver simply would not install. The machine had no internet.

He did what anyone would do. He opened ChatGPT on his other computer and started typing. Two-hundred-character terminal commands. One after another. Copy, paste, fail. Copy, paste, fail. He bought a USB Ethernet adapter. The adapter did not work either. He reinstalled Fedora. The packages became mismatched. Half the drivers installed, half did not. After a week, he gave up.

Then he came back. His ChatGPT free credits ran out. He bought ChatGPT Plus and tried Linux Mint. It booted. It looked terrible. The Wi-Fi still did not work. He tried Pop OS. The Wi-Fi finally worked. He said the desktop looked like it was designed for a child, but it worked.

He called me. Relief and frustration in his voice. Equal amounts of both.

I watched all of this unfold. And I realized something I had not expected. This was not just a Linux story anymore. It was an AI story.

The survival phase was pure ChatGPT. Without it giving him commands for the terminal, my friend would have abandoned everything and gone back to Mac. The AI did not teach him Linux. The AI kept him alive long enough to want to learn it. Every time he got stuck, he typed his problem into the chat box, got a block of text back, and pasted it without reading. He did not know what the commands did. He only knew they helped him move forward.

And then something changed.

Once the drivers worked and the desktop was stable, he discovered Hyprland. It is a tiling window manager that is configured completely through text files. The status bar, the terminal, the login screen, the animations, the hotkeys. Everything was a text file. He could control every piece of it. On top of that he learned Lua.

Here, he made a choice that surprised me.

He stopped using AI.

He started reading other people's dotfiles on GitHub. He read Stack Overflow threads from years ago. He read the source code of the compositor itself. He hand-wrote every line of his configuration in Lua. When he got stuck, he did not open the chat window. He kept investigating. ChatGPT sat idle while he learned how the system worked from the inside.

The config shipped. It was beautiful. More importantly, it was his. He could explain every line of it to me over a call. He did not say "the AI wrote it." He said "I wrote it. Here is why each piece is there."

This story matters because it shows a distinction that engineering managers need to see clearly. AI can work in two modes with your team. Both modes produce working code. The difference is invisible from the outside.

The first mode is survival. Your engineer is in territory they do not know. They do not understand the language, the framework, or the platform. AI generates commands, explains errors, and keeps them moving. The work gets done. The commit history looks productive. But nothing is being learned. The engineer is a bridge between the AI and the terminal. When the AI fails, and it will fail, they have nothing to fall back on.

The second mode is mastery. Your engineer knows the territory. They ask the AI to explain a module, summarize a file, or trace a path of execution. Then they verify. They read the source. They test the edge case the AI missed. The AI speeds up the reading phase. The engineer owns the understanding. When the AI fails, they already know the system well enough to fix it without help.

Both modes ship. Both modes look the same in a sprint review. You cannot tell which mode is active by looking at the velocity chart.

Here is how you tell. When your engineer finishes a feature, ask them to walk you through it without opening the AI chat window. Can they explain why the retry logic exists? Do they know what happens when the database connection pool is full? Can they trace the authentication flow from the browser to the database and back? If they can, they were in mastery mode. If they open the AI to answer you, they were in survival mode.

Think about it like a restaurant kitchen. A line cook with a recipe card can produce a dish. The plate looks correct. The ticket gets closed. But when the head chef position opens, the line cook who only follows cards cannot design a menu. They never learned why the flavors work together. The engineer who only uses prompts is the line cook. The engineer who reads the source is the chef.

Neither mode is wrong. Survival mode is how you get through the week when a production incident hits a system nobody knows. Survival mode is how you onboard a new stack without a mentor. Survival mode has saved many projects. I am grateful my friend had ChatGPT during the worst of it. Without it, he would have quit.

But survival mode cannot be the only mode. If your team never leaves it, you are building something fragile. Every line shipped without understanding is a line that will break in production. And when it breaks, nobody will know how to fix it. The AI will not carry the pager.

The twenty dollars my friend spent on ChatGPT was the best money he ever spent on Linux. It got him through the part where most people quit. But the config that actually shipped, the one that made the machine his own, was written by hand. He understood every piece of it. I pushed him into Linux. ChatGPT pulled him through the worst parts. He finished the rest himself.

That is the distinction. Survival versus mastery. This is the conversation every engineering lead should have with their team right now. Not whether to use AI. But how you use it. And whether you know when to put it down.