The Vague Question Gets the Vague Answer#
If you ask an AI model to “configure a network” or “fix my BGP issue,” you’re going to get a generic answer, and it might even be wrong for your situation. This isn’t a flaw in the model. It’s a predictable result of what you gave it to work with.
Think about what happens when a junior engineer opens a ticket that just says “network is slow.” You can’t do anything with that. You don’t know which network, which site, which device, or what “slow” even means to the person reporting it. You’d send that ticket back and ask for details before you touched a single interface.
An AI model can’t send the ticket back. It just answers with whatever’s most statistically probable given the words you gave it. If you didn’t tell it you’re running IOS-XE 17.9 on a Catalyst 9300 stack with a specific spanning-tree topology, it’s going to answer as if you’re running some average, imaginary network that exists nowhere, because that’s the only network it can infer from a vague prompt. Garbage in, garbage out. That rule didn’t stop applying just because the thing processing your input is an AI model instead of a person.
What Context You’d Give a Human, You Should Give the Model#
When you escalate a problem to a senior engineer, you don’t just say “BGP is broken.” You give them the platform, the software version, the relevant configuration, and the specific symptom you’re seeing. That’s the same information an AI model needs, and for the same reason. It has no access to your network. It only knows what’s in the conversation.
Here’s an example of a prompt that will get you a mediocre, generic answer:
My BGP neighbor won't come up. What's wrong?Compare that to a prompt built the way you’d write a real troubleshooting note:
I have two Cisco ASR 1001-X routers running IOS-XE 17.6.4, directly
connected via a /30 on Gi0/0/1. eBGP peering, AS 65001 and AS 65002.
The neighbor state is stuck in Idle (not Active or Connect). I can
ping the neighbor's IP successfully. No ACLs on the interface.
show ip bgp summary shows the neighbor with 0 uptime. Here's the
relevant config: [paste config]The second prompt gives the model exactly what a competent engineer would need to reason through the problem. Notice that the fact the neighbor is stuck in Idle rather than Active is a specific, meaningful detail. It rules out a whole category of causes (like TCP session issues) and points toward something earlier in the process, like the neighbor not being configured at all on the other end, or neighbor shutdown still being applied. A vague prompt like “won’t come up” throws that diagnostic information away before the model ever sees it.
Treat the Chat Like a Ticket Handoff, Not a Search Bar#
The mental shift that actually changed how I use these tools was simple. I stopped treating the AI chat window like a search engine and started treating it like I was handing off a ticket to a senior engineer covering my shift.
When you search Google, you type a few keywords and skim results, because you’re the one doing the synthesis. When you hand off a ticket, you write a paragraph or two of context because you know the other person has to pick up cold and act on it. Those are fundamentally different modes of communication, and most network engineers default to the search-engine mode with AI tools because that’s the muscle memory they already have from twenty years of googling error messages.
A proper handoff includes the topology, or at least the relevant slice of it. It includes what’s already been ruled out, so you’re not sent back down a path you’ve already tried. It includes the exact error text, not a paraphrase of it, because paraphrasing frequently drops the one detail that matters. And it includes what you’re trying to achieve, not just what’s broken, because the fix for “I want redundancy” looks different from the fix for “I need this working again in the next ten minutes.”
Structure the Prompt Around Your Own Methodology#
The engineers who get the most out of tools like Claude aren’t the ones who paste a raw error message and hit enter. They’re the ones who feed the model through the same structured process they’d use themselves.
If your normal troubleshooting flow is something like define the problem, gather data, form a hypothesis, test it, then your prompt should walk through those same stages explicitly. Tell the model what you’ve already observed (the data), what you suspect (the hypothesis), and what you want it to help you do next (test the hypothesis, or suggest an alternative one). This isn’t a new skill you have to learn from scratch. It’s the same discipline you already apply to a hard ticket, just typed out instead of held in your head.
This matters more with networking than with a lot of other domains, because so much of network troubleshooting depends on state that isn’t visible unless you explicitly surface it. Two devices can have identical running configs and completely different behavior because of a stale ARP entry, a mismatched MTU somewhere upstream, or a route learned from the wrong source. The model can’t ask you clarifying questions the way a colleague would (some do, but you can’t count on it), so you have to front-load the details yourself.
It’s Still About Inputs and Outputs#
I keep coming back to this idea because it applies here just as much as anywhere else in engineering. If your input is a vague, half-paraphrased error message, your output is going to be a vague, half-useful answer. If your input is the same structured detail you’d give a colleague you respect, the output starts looking like something a colleague you respect would actually say back.
The good news is that this isn’t a mystical new competency called “prompt engineering” that you need a course for. It’s the same rigor you already bring to writing a good ticket, reading a topology diagram correctly, and not jumping to conclusions before you’ve gathered the data. You already know how to do this. You just have to remember to do it with the AI chat window open instead of assuming it can read your mind.
Featured image by boris misevic on Unsplash