I keep seeing a dangerous assumption in IT: that AI can hand you the right answer even when you do not fully understand the underlying technology.
That is dangerously wrong.
I have worked in IT for more than 25 years as a network architect, and I use AI every day. It has become a legitimate part of how I research, troubleshoot, document, and evaluate technical designs.
But AI does not eliminate the need for technical fundamentals. In many cases, those fundamentals matter more than ever.
If you do not understand the technology, you may not know what information matters, which questions to ask, or whether the answer you received is technically sound.
Vague Questions Produce Shallow Answers
The first problem is simple: if you do not understand a technology, you probably do not know what to ask.
Someone might enter a question like this:
“Can we use BGP? My boss wants us to use BGP.”
An AI model may respond with a general explanation of BGP, followed by some version of, “Yes, but it depends.”
That answer is not necessarily wrong. The question simply does not contain enough information to support a meaningful design recommendation.
A better question would look something like this:
Current Design
- Data Center 1: OSPF Area 0
- Data Center 2: OSPF Area 0
- Remote Site 1: OSPF Area 1
- Remote Site 2: OSPF Area 2
- Remote Site 3: OSPF Area 3
- Remote Site 4: OSPF Area 4
We currently operate two data centers and four remote sites. OSPF is used throughout the environment, with the data centers in backbone Area 0 and each remote site in a separate area.
We want to migrate from OSPF to BGP while minimizing downtime. We are considering a separate autonomous system number at each location, and we do not need to stretch subnets between the data centers.
What migration approach would you recommend, and what routing, redundancy, and rollback considerations should we address?
That is a much better engineering question. It gives the model a current-state design, a desired end state, and several important constraints.
But even that question leaves major decisions unresolved.
What happens while OSPF and BGP operate at the same time? How will administrative distance, redistribution, route specificity, and routing policy affect path selection? Will the design use active-active or active-passive paths? Should Local Preference, AS-path prepending, ECMP, or BFD be used? Are the circuits equal in capacity, or should traffic prefer a 50 Gbps link over a 10 Gbps link? What is the rollback plan if the migration does not behave as expected?
An experienced engineer recognizes that those variables matter.
Someone who does not understand BGP may not even know they need to be discussed.
That is the real limitation. This is not simply a prompting problem. It is a technical judgment problem.
More detail does not automatically produce a better answer. Relevant technical context does. You need enough knowledge to identify which details could materially change the design.
The Real Risk Is Not Knowing Whether the Answer Is Wrong
The second problem is verification.
AI models can produce answers that sound polished, specific, and authoritative. That does not mean the answer is correct for your environment.
Consider a different example.
An ISE node is attempting to join an Active Directory domain and returns an error similar to this:
“Please check credentials or time synchronization between the ISE node and Active Directory.”
If you enter only that message into an AI model, it will probably recommend checking the username and password, NTP synchronization, DNS, network connectivity, and Active Directory permissions.
Those are reasonable starting points. They are also generic.
Real troubleshooting depends on understanding the environment and asking the right follow-up questions:
- Has this ever worked before?
- Is this a new ISE node or a rebuilt server?
- Can the node resolve the domain and locate the correct domain controllers?
- Is the time difference within Kerberos tolerance?
- Are the required ports allowed through the firewall?
- Is there already a conflicting computer object in Active Directory?
- Is the service account locked, expired, or restricted?
- Does the account have domain-join rights in the correct organizational unit?
- Is a privileged-access system limiting which servers the account can access?
In a hardened enterprise environment, domain-join permissions are often restricted to specific service accounts, groups, organizational units, or provisioning workflows.
A person working only on the ISE side may not know how those controls were implemented. Someone with broader Active Directory, security, and network experience is more likely to recognize the dependencies immediately.
The AI may identify some of these possibilities. There is no guarantee it will prioritize the correct one, understand your organization’s controls, or recognize an undocumented dependency.
More importantly, there is no guarantee the person reading the answer will know whether the recommendation makes sense.
That is where experience matters.
AI Does Not Know Your Environment
An AI model does not automatically know your topology, routing policies, firewall rules, application dependencies, operational history, change-control process, or previous failed attempts.
It does not know that a route is being redistributed from BGP into OSPF before reaching the core.
It does not know that a service account is restricted by a privileged-access management platform.
It does not know that two links advertised as redundant terminate on the same physical device.
It does not know that a previous team created an undocumented static route three years ago to work around an outage.
You have to provide that context.
And you can only provide it if you understand the environment well enough to know what matters.
Even then, the model may still make incorrect assumptions. It may apply a technically valid recommendation to the wrong platform, overlook a vendor-specific limitation, confuse control-plane behavior with data-plane behavior, or recommend a design that works on paper but creates an operational problem during failure.
AI can help you reason through a system. It cannot independently discover every hidden dependency in that system.
How I Actually Use AI
None of this is an argument against using AI.
I use it heavily.
The difference is that I treat it as an engineering partner, not as a guru.
I Give It the Actual Design
I provide the current topology, routing protocols, autonomous system numbers, circuit capacities, redundancy model, known constraints, target state, and acceptance criteria.
I also explain what has already been tested and what failed.
The more accurately I can describe the environment, the more useful the response becomes.
I Ask It to Challenge the Design
I do not only ask, “Will this work?”
I ask questions such as:
- What assumptions am I making?
- What failure scenarios have I missed?
- What could cause asymmetric routing?
- What happens during a partial failure?
- Which route wins at each stage of the migration?
- What telemetry should I capture before and after the change?
- What would make this rollback fail?
- Argue against this design.
AI is often more useful as a structured critic than as a source of final answers.
I Compare Multiple Models
I sometimes present the same problem to multiple AI models and compare their reasoning.
When several models independently reach the same conclusion, I treat that as a useful signal, not proof. Models may share similar training data, repeat the same common misconception, or make the same hidden assumption.
When they disagree, that is often more valuable. The disagreement identifies an area that requires deeper investigation, vendor documentation, lab testing, or peer review.
I Use RAG With Material I Trust
I also use a private retrieval-augmented generation, or RAG, knowledge base connected to my own books, PDFs, notes, standards, and technical guides.
That allows the assistant to retrieve information from sources I trust instead of relying entirely on general model knowledge.
This is not the same as training a new model. The underlying model is still the same. RAG gives it access to a controlled set of reference material at the time of the query.
That can improve grounding, but it still does not eliminate the need to verify the answer against current vendor documentation and the actual environment.
I Verify Before I Implement
For consequential changes, AI is not the final approval authority.
I verify recommendations using some combination of:
- Official vendor documentation
- Configuration guides and release notes
- Existing device state
- Routing and forwarding tables
- Logs and packet captures
- Lab validation
- Peer review
- Controlled testing
- A defined rollback procedure
The more significant the blast radius, the less acceptable it is to implement something simply because an AI model said it should work.
AI Makes Skilled Engineers More Effective
AI can accelerate research, improve documentation, compare design options, identify missing considerations, generate test plans, explain unfamiliar concepts, and help organize complex technical problems.
Those are substantial benefits.
But AI is most useful in the hands of someone who already has enough knowledge to direct it and challenge it.
An experienced engineer can use AI to move faster because that engineer can distinguish a plausible answer from a correct one. They can recognize when the model is overlooking a dependency, applying the wrong protocol behavior, or assuming a cleaner environment than the one that actually exists.
A less experienced person may receive the same answer and implement it without realizing what is missing.
That does not mean junior engineers should not use AI. They absolutely should. But they should use it to accelerate learning, not bypass it.
Ask the model to explain why a design works. Ask it to identify assumptions. Ask it to compare alternatives. Then verify the explanation, test the behavior, and understand the result.
Do not copy a configuration you cannot explain.
Do not implement a routing policy you cannot troubleshoot.
Do not accept an answer simply because it sounds confident.
The Bottom Line
AI is not going to solve every technical problem in a single prompt, especially in enterprise IT, where the outcome depends on variables the model cannot see.
It does not know your topology. It does not know your security controls. It does not know your operational history. It does not know your undocumented technical debt.
You have to bring that context, and you can only bring it if you understand the technology and the environment.
Treat AI as an engineering partner. Use it to challenge assumptions, compare designs, accelerate research, improve documentation, and identify issues you may have overlooked.
Do not treat it as a final, trusted authority.
The engineers who thrive with AI will not be the ones who know the least and depend on it the most.
They will be the ones who know enough to ask the right questions, provide the right context, and recognize when the answer is wrong.