The Gray Box Method
How I Learned to Stop Worrying and Love AI
It’s July 2026, I’m flipping through my LinkedIn feed, and I see people are still arguing about the ills of vibe coding and questioning the quality of AI-generated source code? We’re way beyond that now. To be fair, this change happened fast, but to put it bluntly, humans don’t need to create software anymore, at least not the way we’ve done it in the past. In fact, with the frontier-class AI coding models available to us today, it’s not even a good idea. Compared to the speed, efficiency, and accuracy of AI, humans just get in the way now. I’m disappointed that so few of my colleagues understand this fact. Best I can figure, this is because:
They don’t understand how to use the current generation of AI software engineering tools effectively, or...
They don’t want to use the current generation of AI software engineering tools effectively.
Group 2 needs to get it through their heads that they need to abandon any anti-AI sentiment they harbor if they want to continue to participate in information technology. Maybe they genuinely don’t want to remain in IT, and that’s fine, but that’s not a decision made lightly, and they better have a plan in place for their transition out of the industry.
Group 1 needs to change how they think about software engineering at a fundamental level to succeed with AI. And make no mistake, anyone who wants to stay employed in this field needs to master the use of AI in software engineering. It’s not enough to take a class or two. It’s not enough to tinker with it on weekends. It’s not enough to pile up certifications. They need to be using it all day, every day, starting right now.
So are we computer engineering types now completely useless? No, because AI has no initiative, vision, or drive. It just sits there waiting to be told what to do. But what do you tell it? That’s precisely where so many people are getting it wrong. They’re working with these new AI tools without understanding how fundamentally the game has changed.
Since the invention of computing, software engineers were focused on one goal: Explaining to the computer how to solve a problem. Programming languages, IDEs, SDLC frameworks, Scrum, these were the tools we used carve out a set of instructions that explained to a computer how to perform a task that solves a problem.
We don’t need to do that anymore. AI can do it. AI is better at it. AI isn’t flawless, but it’s less flawed than its human counterparts. However, to make it all work out, we need to think differently about software engineering. We need to stop telling computers how to solve a problem, and instead focus on describing the problem that needs to be solved. That problem statement is what we present to AI. Let the AI take it from there. If the problem statement is incomplete, it will interview us to fill in the gaps. If it encounters an issue it can’t solve itself, it will pause and ask us for clarification and guidance. Don’t tell it to use any particular architecture, language, algorithm, or approach, beyond what’s already provided to it in the problem statement. Let it construct the whole system, review it, test it, document it, and train people on how to use it. But don’t expect it to do all these things with no human involvement at all.
The Gray Box
Most people are familiar with the concept of Black Box analysis in software testing. There’s also Gray Box and White Box analysis. I’m going to borrow these terms because I think they translate nicely onto software engineering with AI. Black Box, in this context, would be using AI to create a system that we never ever inspect or review ourselves. We only care about what goes into the box and what comes out of it, nothing else matters.
At the other end, White Box would be using AI to engineer a system, but where humans still do manual reviews of all the generated code. Sometimes people might make manual changes to that code. The box is left open, and both humans and AI manipulate its contents. But neither black box or white box are the right way to think about AI-assisted software engineering.
What would “Gray Box” be in this context? Think of the whole nascent computer system as being inside a transparent box. We (humans) can see what’s inside the box. However, we never actually go inside that box. That is, we don’t make any direct changes to its contents. That’s AI’s territory. We let AI take the lead on designing and building the contents of the box.
On occasion, we might take a peek in there and see something that seems off. We might be inclined to go in there and try to rearrange things ourselves, after all, that has been our job for decades. But it’s not our job anymore, so we need to resist the urge to meddle. Instead, we ask the AI about it. “Is that part of the system well-designed? It seems off to me. Why did you do it that way? Wouldn’t this other way be better?”
Sometimes, we’ll find that our fears were unfounded, and the AI will be able to explain exactly why its design decisions make sense. Just as often, the AI will consider what we’ve said and agree with us, and then adjust the contents of the box accordingly. And should that be so surprising? We do have quite a bit of experience with these things after all. Still, the actual refactoring is best left to AI... it’s really good at refactoring code. Much better than a person.
This is a big change in how we do things. But it’s a good change, or at least it could be if we let it. When the printing press was invented, I’m sure the scribes of the time grumbled and griped about this terrible new contraption. “Oh look, this one letter here is upside down! Ha ha! This thing will never catch on!” But we don’t look back on history and bemoan the evils of the printing press. It made books available to a broad audience and made literacy attainable by all.
Sounds Great, What’s The Catch?
The people who are comfortable with this new way of thinking about software engineering have a significant advantage over those who aren’t, of that I am sure. The method I described above is what I am doing right now, every day, and I can see with my own eyes how much more efficient and effective it is compared to the old way of doing things. It’s not even close. AI is better at designing and building software than people.
“But that’s just vibe coding!” I can feel some people thinking as they read this.
We need to ditch that term right now. The technology has evolved faster than the slang we use to talk about it, and “vibe coding” was never a well-defined term in the first place. In any case, it carries connotations that are no longer appropriate. Creating and maintaining a computer system without touching any source code, or even fully understanding exactly how that code works, isn’t “vibing” anything. It’s simply the way software engineering works now. “But... but...” But what? Any objection one could raise to that assessment can be addressed with technology we have at our fingertips right now. If anyone thinks I’m wrong about that, I genuinely want them to tell me, what am I missing?
The only valid “but” I can think of is “but if I’m not employed doing software engineering, how will I pay my bills?” That’s a valid question, and I don’t have an answer for it. But that’s more economics than pure technology. Still, it’s the question we should be working on right now, because the rest of the story has already been written.
