Prompt Engineering Basics for Optical Network Engineers
A practical primer on getting reliable, accurate outputs from AI tools — covering specificity, constraint framing, verification prompts, hallucination reduction, and why using AI is one of the best things you can do for your brain.
1. Introduction
AI tools are now part of the optical network engineer's daily toolkit. From diagnosing Optical Signal-to-Noise Ratio (OSNR) degradations to drafting automation scripts for NETCONF provisioning, large language models (LLMs) can accelerate work that once took hours. The quality of what an AI returns, however, depends almost entirely on the quality of what you ask. A poorly structured query produces a confidently wrong answer. A well-structured one produces a reliable starting point.
This article addresses the gap between how engineers typically ask questions and how AI tools actually process them. Optical networking is a domain where incorrect values carry real consequences — a wrong OSNR threshold or an inaccurate Forward Error Correction (FEC) gain figure can mislead a design decision. But beyond accuracy, this article makes a more fundamental point: using AI is not a threat to your expertise. Used correctly, it is one of the most powerful tools for growing it.
ITU-T ION-2030 frameworks explicitly position AI as central to optical transport automation. Engineers who can query AI tools effectively — and critically evaluate the outputs — will work faster and with greater depth than those who do not engage with these tools at all.
2. AI as a Professional Development Tool
"The engineer who uses AI to accelerate their work and then validates, questions, and builds on the output is developing at a rate that was previously impossible. The engineer who avoids AI entirely is not protecting their skills — they are simply working more slowly."
The validation step is where the real learning lives. When you cross-check an AI-generated OSNR formula against ITU-T G.697 and find it matches, your understanding of that formula deepens. When you find a discrepancy, you have identified something worth examining closely. Either way, the outcome exceeds what passive reading alone would produce.
3. Building Practical Tools Without a Development Background
Domain expertise is the scarce input. Code generation is not. Your knowledge of how EDFA gain tilt affects channel uniformity across a multi-span link is exactly what makes a tool useful — AI alone cannot produce that. You bring the domain; AI brings the implementation speed.
4. How AI Tools Process Technical Queries
LLMs do not look up answers. They generate statistically plausible continuations of your input based on patterns learned from training data. This means they can produce an answer that sounds authoritative but draws on a misremembered standard, a conflated product specification, or a training example that mixed up two technologies. In optical networking — where ITU-T G.694.1 channel grids, OTN multiplexing hierarchies, and EDFA noise figures are highly specific — this risk is real.
Three mechanisms work in your favour when you understand this model. Context anchoring — the more relevant detail you provide in your prompt, the less the model needs to fill gaps from potentially unreliable training patterns. Constraint framing — telling the AI what format, scope, and assumptions to use reduces the degrees of freedom it has to produce unwanted content. Verification triggers — asking the model to flag uncertainty or cite the standard supporting each value gives you signals about where to cross-check independently.
5. Five Principles for Reliable Technical Prompts
5.1 Specificity
Vague inputs produce vague outputs. When you ask about OSNR without stating the technology generation, amplifier type, modulation format, or distance, the AI will answer with averages that may not apply to your network. Replace general category names with exact technical parameters wherever possible.
5.2 Constraint Framing
Tell the AI what it should not do as well as what it should. Optical networking spans SONET/SDH, OTN, DWDM, coherent, and packet layers — an unconstrained answer will often blend these inappropriately. State your technology layer, equipment generation assumptions, and the format you want the answer in.
5.3 Context Loading
Paste your actual data into the prompt. Alarm text, measured power levels, BER readings, span loss values — all of this gives the AI real information to work with rather than forcing it to assume typical values. The closer the prompt reflects your actual network state, the more relevant the response.
5.4 Verification Ask
Explicitly instruct the AI to flag values it is uncertain about and to state which standard supports each technical claim. This does not guarantee accuracy, but it surfaces the outputs that need human cross-checking.
5.5 Iterative Refinement
Treat the first response as a draft. Follow up with targeted corrections: adjust one variable, ask for a recalculation, or request a specific section to be expanded. This is more productive than attempting a perfect single-shot query.
6. 15 Copy-Ready Prompt Examples
Each example shows a weak prompt followed by a stronger version. Use the copy button to grab the improved prompt directly. The weak versions are included so you can recognize patterns to avoid.
How do I calculate OSNR for a long-haul link?
Calculate the end-to-end OSNR for a 1500 km terrestrial DWDM link: - 20 spans of 75 km each - EDFA only (no Raman), noise figure = 5 dB - Launch power per channel = 0 dBm - Fiber: G.652.D, attenuation = 0.2 dB/km - 32 channels on 100 GHz ITU-T G.694.1 grid - DP-QPSK modulation, symbol rate = 32 Gbaud Provide the OSNR equation you are using, define all variables, and state the source (ITU-T or IEEE reference). Flag any values you are assuming rather than calculating.
Why it works: every input parameter is specified, the equation is requested explicitly, and the AI is asked to flag assumptions — making it easy to spot where to verify.
How does noise figure affect my network?
In a cascaded EDFA chain with 10 amplifiers, NF = 5 dB, gain = 15 dB each: 1. Calculate the OSNR contribution of the amplifier chain alone (ASE noise accumulation formula) 2. Calculate the OSNR penalty if NF degrades from 5 dB to 6 dB on three of the ten amplifiers Show all calculation steps. Use the standard ASE accumulation formula. Do not include fiber nonlinear impairments — only ASE noise. State any assumptions explicitly.
Why it works: split into two specific sub-tasks, nonlinear effects excluded, and the formula type is named.
My optical link is degraded. What should I check?
Troubleshooting a 100G DP-QPSK coherent channel on a 4-span link. Active alarms: - SD-FEC pre-FEC BER increased from 1e-3 to 4e-2 over 6 hours - OSNR at receiver dropped from 22 dB to 17 dB - No LOS or LOF alarms on any span - Optical power at each amplifier output within ±0.5 dB of baseline List the three most likely root causes in order of probability. For each: - What additional measurement would confirm it? - Which network element to check first? Do not suggest causes that would produce a LOS alarm — there is no LOS.
Why it works: actual alarm data is embedded, impossible causes are excluded upfront, and the output format (ordered list with confirmation steps) is specified.
Explain OTN hierarchy to me.
Explain the OTN multiplexing hierarchy per ITU-T G.709: - How a 100GbE client signal maps into ODU4 - ODU0/ODU1/ODU2/ODU3/ODU4 gross bit rate values - How multiple ODU1 tributaries are multiplexed into ODU3 Present as a table: ODU type | Client rate | Gross bit rate | Max ODU0 tributaries. Do not include OTN-over-packet (FlexE) — traditional OTN only. If any gross bit rate is approximate, state "approximately" and give the ITU-T reference.
Why it works: the exact ITU-T document is named, output format is specified, and FlexE is excluded to prevent scope creep.
Write a NETCONF config for an optical amplifier.
Write a NETCONF RPC XML payload using OpenConfig optical amplifier YANG models (openconfig-optical-amplifier): - Component name: "EDFA-1" - Target gain: 20 dB, mode: constant-gain - Max output power: 17 dBm Use RFC 6241 NETCONF edit-config on the running datastore. Add XML comments explaining each element. Do not include vendor-specific augmentations. If uncertain about any YANG leaf name, mark it: <!-- VERIFY YANG LEAF NAME -->
Why it works: the YANG model and RFC are named, vendor extensions excluded, and uncertainty flagging is built in.
How do I handle dispersion on long haul links?
Legacy 10G NRZ-OOK (non-coherent) DWDM link: - Total length: 800 km, fiber: G.652.D (CD ≈ 17 ps/nm/km at 1550 nm) - 10 spans of 80 km with inline DCF - Target residual dispersion at receiver: ±100 ps/nm Calculate: 1. Total accumulated dispersion before DCF 2. Required DCF dispersion coefficient (ps/nm) per span if residual is split equally 3. Whether a post-compensation module is needed at the receiver Do not apply coherent DSP-based CD compensation — this is a legacy system without DSP. Show each step clearly.
Why it works: the technology era (legacy, non-coherent) is stated to prevent DSP-based assumptions that do not apply.
Write a Python script to get data from my network device.
Python 3.10 script to: 1. Connect to gNMI streaming telemetry endpoint at 192.168.1.1:57400 2. Subscribe to OpenConfig path /components/component/optical-channel/state/output-power, SAMPLE mode, 30s interval 3. Parse gNMI SubscribeResponse and print: timestamp | component-name | output-power-instant (dBm) 4. Handle connection errors with 3-retry backoff (2s, 4s, 8s) Use grpcio/grpcio-tools. Use pygnmi or cisco-gnmi if more appropriate — state which and why. Add inline comments for each gNMI operation. Do not use SNMP or NETCONF. Mark uncertain proto field names with: # VERIFY: field name
Why it works: Python version, library, path, subscription mode, and protocol exclusions are all specified.
What modulation format should I use for coherent optics?
Compare DP-QPSK, DP-16QAM, and DP-64QAM for a metro DWDM link: - Distance: 300 km, 5 spans of 60 km, EDFA NF = 5 dB - OSNR margin target: ≥3 dB, symbol rate: 64 Gbaud, fiber: G.654.E For each modulation format provide: - Approximate spectral efficiency (b/s/Hz) - Minimum required OSNR at BER = 1e-2 (pre-FEC SD-FEC threshold) - Whether 300 km is feasible at this symbol rate Present as a comparison table. Use values consistent with OIF or IEEE 802.3 where applicable. Flag any approximated values.
Why it works: the three formats, fiber type (G.654.E changes nonlinearity assumptions), and table format are all fixed.
Explain ROADM architecture.
Explain colorless, directionless, and contentionless (CDC) ROADM for a node with 8 line-side degrees and 40 add/drop ports. Address specifically: - What "contentionless" means when two channels at the same wavelength need to be added at the same node - WSS count and configuration typically required for CDC at 8 degrees - Whether flex-grid (ITU-T G.694.1) changes the CDC architecture vs. fixed-grid Do not describe legacy non-CDC ROADM architectures. Focus only on CDC and its variants. If WSS port counts vary by implementation, state the range and the determining factor.
Why it works: legacy ROADM types are excluded, the specific contention problem is framed precisely, and flex-grid vs. fixed-grid is a targeted sub-question.
How do I find a fiber cut?
OTDR trace from 60 km SMF span (G.652.D, 1550 nm): - Connector at 0 km: 0.3 dB (expected) - Splice at 18.2 km: 0.05 dB loss (expected) - Reflection event at 41.7 km: 6 dB return loss spike, noise floor beyond this point Based on this data: 1. Classify the event at 41.7 km (fiber break, connector, macro-bend, or other) 2. Estimate actual fault location using fiber refractive index = 1.4682 3. Describe the field repair procedure for a buried cable route Do not include OTDR calibration procedures — focus on event interpretation and fault location.
Why it works: actual OTDR data is embedded, refractive index is given so the AI does not guess, and calibration is excluded as out of scope.
Help me set up intent-based networking for my optical network.
Draft a TAPI connectivity service request (JSON) using ONF TAPI v2.3 northbound interface: - Service type: point-to-point optical path - Endpoints: Node-A eth-1 to Node-Z eth-1 - Capacity: 100 Gbps - Protection: 1+1 optical - Latency constraint: ≤25 ms Include connectivity-service, connection-end-point, and capacity structures. Add comments explaining each JSON object. Flag any TAPI attribute name you cannot confirm with: // VERIFY: TAPI v2.3 attribute
Why it works: the API standard, version, and all service parameters are specified, with uncertainty flagging built in.
How much capacity do I need for AI traffic?
3-year capacity model for a DCI link: - Current traffic: 2 Tbps avg, peak utilization 85% - Growth driver: GPU cluster expansion — adding 4,000 H100 GPUs/year - East-West ratio shifts from 70/30 to 60/40 by year 3 - Technology: 400G DP-16QAM coherent, 80 channels, flex-grid DWDM Provide: 1. Projected bandwidth demand at Year 1, 2, 3 (show growth assumptions explicitly) 2. When current system reaches 90% utilization at peak 3. When 800G upgrade becomes necessary State your traffic growth model (linear/CAGR). Flag any GPU-to-bandwidth figures you are estimating rather than citing from a verified source.
Why it works: the growth driver is specific (GPU count), the traffic split model is given, and the AI is asked to state its growth model and flag unverified figures.
What FEC should I use and what's the BER threshold?
Compare for 400G coherent applications: 1. G.709 Hard-Decision FEC (RS(255,239) + BCH baseline) 2. Soft-Decision FEC (SD-FEC, OFEC class per OIF 400ZR) 3. Concatenated SD-FEC with staircase code For each provide: - Pre-FEC BER threshold (max input BER corrected to post-FEC ≤ 1e-15) - Net coding gain (dB) at target post-FEC BER - Overhead percentage Present as a table. Cite OIF, ITU-T G.709, or IEEE 802.3 as source. If a value is implementation-dependent, state the typical range and note it is not standardized.
Why it works: three specific FEC schemes are named, the application (400G) is given, and the AI is asked to distinguish standardized from vendor-specific values.
How do submarine cables use repeaters?
Submarine DWDM cable system: - Route: 6,000 km transoceanic - Fiber: G.654.E (effective area ~150 µm²) - Undersea EDFA NF: 4.5 dB - Target OSNR margin at landing station: ≥4 dB - DP-16QAM, 64 Gbaud. No Raman pumping. Calculate the maximum allowable repeater spacing (km) meeting the OSNR margin requirement. Show the OSNR cascade formula, define each variable, and state the launch power assumption. Do not apply terrestrial EDFA noise figure assumptions — note how submarine EDFAs differ. Flag if any deep-sea fiber attenuation value deviates from ITU-T G.654.E typical values.
Why it works: submarine vs. terrestrial differences are flagged explicitly — a common source of error in this domain.
Summarize the 400ZR standard for me.
Summarize OIF 400ZR Implementation Agreement for a senior optical engineer design review. Cover only: 1. Target application and link distances 400ZR is optimized for 2. Modulation format and symbol rate 3. OSNR sensitivity (pre-FEC BER threshold) 4. Form factor and power envelope (QSFP-DD) 5. Management interface — how the module is controlled and monitored Do not include ZR+ (OpenZR+) — 400ZR only. No marketing history. For each point: if a value is defined in the OIF IA document, label it "specified." If it is a typical implementation range, label it "typical." Never present a typical value as a specification.
Why it works: ZR+ is excluded, five required sections are listed, and the AI is instructed to distinguish specified values from typical ranges — essential for a design review.
7. Quick Reference — Prompt Patterns by Task Type
| Task Type | Key Prompt Elements | What to Exclude Explicitly | Verification Request |
|---|---|---|---|
| Link budget / OSNR | Span count, distance, NF, launch power, modulation, fiber type | Raman (if EDFA-only), nonlinear (if linear budget) | "Flag assumed values. Cite equation source." |
| Fault diagnosis | Paste exact alarms, measured values, timeline | Fault types inconsistent with observed alarms | "List what measurement confirms each cause." |
| Standards lookup | Name the exact ITU-T, IEEE, or OIF document | Related but different standards (e.g., ZR vs. ZR+) | "Distinguish defined values from typical ranges." |
| Configuration templates | YANG model, version, RFC reference, operation type | Vendor-specific augmentations (unless needed) | "Mark uncertain YANG leaf names with a comment." |
| Automation scripting | Python version, library names, protocol, OpenConfig path | Protocols not in scope ("no SNMP") | "Mark uncertain field names with # VERIFY." |
| Modulation comparison | Fixed set of formats, distance, fiber, target OSNR margin | Formats outside the comparison scope | "State if any value is approximated, not from a standard." |
| Capacity planning | Current state, growth driver, target horizon, technology baseline | Unrelated traffic types | "State growth model used. Flag unverified figures." |
| Tool building (architecture) | Plain-language specification, data model, component list | "Do not write code yet" | "List assumptions about the user workflow." |
Table 1: Prompt engineering patterns mapped to common optical network engineering tasks, including tool building.
8. Reducing Hallucination Risk
Hallucination occurs when AI produces content that is plausible in form but incorrect in fact. In optical networking, the highest-risk areas are: product model numbers and chipset names (which the model may confuse across vendors or generations), exact standard specification values (which may have changed between document versions), and formulas involving multiple interacting parameters (where the model may combine elements from different equations incorrectly).
Ask for Uncertainty Disclosure
Add "List any values you are not confident about" to every prompt. An AI that discloses uncertainty is safer than one that presents everything with equal confidence.
Separate Facts from Analysis
Ask the model first to list relevant known facts, then separately to perform analysis. This forces the AI to surface its assumptions before they influence the conclusion.
Avoid Vendor-Specific Spec Requests
Do not ask for vendor product specifications (baud rates, chip names, port densities) unless you plan to verify them independently. Stick to standardized values from ITU-T, IEEE, or OIF.
Cross-Check with a Second Prompt
After receiving an answer, run: "What are the three most likely errors in the answer above?" This exploits the model's ability to critique output — which is often more reliable than its initial generation.
Specific vendor product names and chipset designations. Exact FEC gain values tied to a specific implementation. OSNR margins narrower than 1 dB — the model may not account for all impairment contributors. Any value described as "the OIF specifies" without you having verified it against the published IA document yourself.
Main Points
- Using AI is not a shortcut that bypasses thinking — when you read, review, validate, and build on AI output, you are engaging in exactly the kind of active cognitive work that deepens expertise.
- You do not need to be a developer to build tools. Your domain knowledge is the valuable input; AI handles implementation. Start with small utilities and grow from there.
- For complex tools, define the architecture and data model before writing any code. Maintainable code starts with a clear structure, not a clever prompt.
- Specific, constrained prompts with real data embedded produce dramatically more reliable outputs than vague, open-ended questions.
- Always name the exact standard (ITU-T G.694.1, OIF 400ZR IA, IEEE 802.3) rather than referring to it generically.
- Ask the AI to flag uncertainty and distinguish standardized values from typical implementation ranges — this tells you exactly where to cross-check.
- Never rely on AI output for vendor-specific product specifications without independent verification against datasheets or official documentation.
References
- ITU-T G.709 — Interfaces for the Optical Transport Network, ITU-T Study Group 15.
- ITU-T G.694.1 — Spectral Grids for WDM Applications: DWDM Frequency Grid, ITU-T Study Group 15.
- OIF 400ZR Implementation Agreement — Optical Internetworking Forum.
- ONF TR-547 — TAPI v2.3 Reference Implementation, Open Networking Foundation.
- ITU-T GSTR.ION-2030 — International Optical Networks towards 2030 and Beyond, ITU-T Study Group 15.
- Analysys Mason, "Automation strategies for multi-vendor, multi-domain optical networks."
- D. Rafique et al., "Cognitive assurance architecture for optical network fault management," Journal of Lightwave Technology.
- H. Zaid et al., "Multi-Agent Design for LLM-Assisted Network Management," OFC.
- Sanjay Yadav, "Optical Network Communications: An Engineer's Perspective" – Bridge the Gap Between Theory and Practice in Optical Networking.
Developed by MapYourTech Team
For educational purposes in Optical Networking Communications Technologies.60% of this article is written with cosmetic changes by AI only.
Feedback Welcome: If you have suggestions, corrections, or improvements to propose, write to us at [email protected]
Optical Communications & Network Automation Expert | Author of 3 Books for Optical Engineers | Founder, MapYourTech
Optical networking engineer with nearly two decades of experience across DWDM, OTN, coherent optics, submarine systems, and cloud infrastructure. Founder of MapYourTech. Read full bio →
Follow on LinkedIn
