Managing the Employee Who Knows Everything and Understands Nothing

Welcome to the 2nd post in this series. I hope you find it useful. Vibecoding is here and is not going away.  The biggest part of vibecoding, whether you're a decades-old coder or someone who started coding 5 minutes ago, is that you have to look at it as a manager, not a coder. You manage a coder, not write the code. Sure, you may type some code now and then, but in the long term you will prompt the AI to do it.

Somebody at work found out you'd built a thing. So now there's a request: a small internal tool, nothing fancy, something to replace the spreadsheet everyone complains about. You said yes, because these days you can say yes.

Two weeks later it works. Four people use it every morning. Then one of them asks what happens if two of them hit save at the same instant, and you have no idea. You'd never thought about it. The AI never brought it up, because you never asked, and it doesn't volunteer information unless you told it to. 

That's not a story about you being unqualified. That's the actual job, and nobody handed you a description of it when you took it. Welcome to vibcoding.

You started at the top

Most writing about AI and coding assumes you have written code before. That may be true, but what if it's not? You may be brand new to coding. You may have worked with coders before but never done any code at all. Either way, if you coded before or never coded, the approach to vibecoding has changed how things are done. Now you supervise something that writes it. Here's how your career or future has changed shape.

Plenty of people don't have a before. They started here. No years of syntax, no CS degree, no stint on a team where somebody senior reviewed their pull requests and explained what was wrong with them. They had an idea and a tool that could build it, and that turned out to be enough to produce software that real people now depend on.

You didn't get promoted into management. You were hired into it, on day one, to supervise an employee whose job you have never done.

This is not a rare situation anymore. In a Zapier survey of 818 U.S. workers who'd shipped a tool with AI in the previous year, fielded in May 2026, 34% had no formal programming background at all. More than half of everyone surveyed said their tools were seen by customers or the public rather than staying safely inside the company. So: not toys, not sandboxes, and in a lot of cases not reviewed by anybody who's done this before. This does have some trip hazards if one does not understand them.

What you're actually managing

People will tell you it's like having an eager junior developer. You may never have worked with one, so let me save you the trouble of finding the analogy useful: it's wrong. 

A junior learns. Correct them Tuesday and by Thursday they've stopped doing it. They pick up your project's history, they get a feel for which parts are fragile, and their confidence roughly tracks their competence. When it doesn't, you can usually hear it in their voice.

Your new AI employee does none of that. It has read more code than any human ever will, and unless you deliberately build its memory (project files, standing instructions, notes it loads at the start), it walks in every morning with no recollection of yesterday. It never gets a feel for anything. It has never seen your project before, no matter how many times you've shown it. It forgets the moment you close the window. We will talk about memory and skills and other things you can set up to prevent this, but even with those, there are still issues. This topic of memory is several posts, all coming in the future.

The AI employee can guess and fill in gaps that you don't give it, and those gaps can cause a lot of problems. It's your job to question, give the AI all it needs, and verify it.

The part you can't skip

The good news is better than most people in this argument will admit: you don't need to learn to write the code.

The bill comes due elsewhere. You do need to understand what the code is doing. Not line by line. At the level of concepts and flow, which is a different skill and a learnable one.

Take the question from the top of this post. Two people hit save at the same instant. That situation has a name, several actually, depending on where it bites you: a race condition, a lost update, a concurrency bug. You don't have to know how to prevent it in your particular database. You have to know that the category exists, so that the word "save" makes you ask a question instead of nodding.

That's the whole skill, and it repeats endlessly. What happens when this fails halfway through? What happens when the input is garbage? What happens when there are ten thousand of these instead of ten. Who else can see this data? Every one of those is a concept with a name, and the names are learnable in an afternoon. You are not missing years of practice. You are missing vocabulary, and vocabulary is the fastest thing in this field to acquire.

In a lot of years around IT shops, I'll say this plainly: the people who could write the code and the people who could explain what the system actually did were never quite the same group. The people who could code generally were not the ones who came to the meetings to explain what it did. If they came, they often came with someone who helped explain what they said. Now this is not always true, but you get the idea.

Your questions are the curriculum

The strange and genuinely lucky part of this job is that your employee is also the only tutor you have, and it is an extraordinarily good one when you make it teach instead of letting it deliver. You just have to admit to it and ask it to dumb things down.

Asking "does this work?" gets you a yes. Ask instead: Explain what this code does in plain English, as if I'll have to defend it to someone who didn't write it. Then tell me the three most likely ways it breaks in production. Another question could be: Does this code meet Microsoft's best-practice standards? Does this have any privacy or security issues that could cause a problem?  The answers to that second question are worth more than the code. They're a list of things you didn't know you needed to know, generated by the only thing in the room that's read everything.

Then ask why it chose this approach over the obvious one. Then ask what else it changed to make this work, which is the question that catches the quiet edits nobody requested. The list can go on and can become a loop. So depending on your goals and your needs, you will learn when you have asked enough or if you need to keep asking.

Also, don't question 5 things at once; question one thing at a time, and tell the AI to ask you questions if it does not understand what you mean. Have an actual conversation; think of them as an employee, not a computer. I know this sounds strange, but in the last year I have gotten more from this approach than most others.

Nobody is senior at this

It's worth knowing that the experienced people are improvising too.

Andrej Karpathy coined "vibe coding" in February 2025, describing a mode where you "forget that the code even exists," pitched as fine for throwaway weekend projects. By November 2025, it was Collins Dictionary's word of the year. In February 2026, Karpathy proposed dropping the term for professional work in favor of "agentic engineering," which he described as the same workflow with "more oversight and scrutiny." The person who named the practice spent the following year adding guardrails to it.

Simon Willison, who writes about this more carefully than most, holds a line I'd steal for anyone at any level: he won't commit code he can't explain. You don't need a decade of experience to apply that rule. You need to be honest about the moment you can't explain something, which is a much cheaper thing to buy. Knowing what the code does is the most important thing.

What's coming next here

If the missing piece is vocabulary, then the fix is vocabulary. The next six posts each take words you've probably heard and never had to define. What it classically meant, what it means now that a machine writes the code, and the guardrail that falls out of it.

Take them in any order. The point isn't a curriculum, it's ammunition for better questions.

This week's guardrail: Keep a "didn't understand that" list. Every time you accept code you couldn't explain, write down the one concept you were missing. Look up one item a week. That list is your syllabus, and it's already sorted by what your project actually needs.

Receipts

Comments

Post a Comment

Popular posts from this blog

The Machine Codes Better Than Us, and That Is Not the Problem

Image
After 30 years in IT support, networking, training, and a variety of other areas, I have come to realize that technology gets better over time. Wow! I know what a revelation. There is still an argument about who is better, and to borrow a great quote, “From a certain point of view…” honestly, both viewpoints are right. That is the focus of this blog. AI is better at coding. AI can generate code faster and with fewer typos than a human. But can it generate better code? Yes and no. Yes, if it's guided properly, and no if it is not. Vibecoding, according to Webster’s, is a semi-recently coined term for programming by prompting an AI, which then writes the code. In vibecoding, the coder does not need to understand how or why the code works (which, in my opinion, is wrong, but we will get to that soon enough), and often must accept that a certain number of bugs and glitches will be present. I disagree with that last statement. In fact, I think the opposite is true. AI can help remov...
Read more