Prompting As Engineering Asset And Context Management
Sources: 1 • Confidence: Medium • Updated: 2026-03-25 17:54
Key takeaways
- Prompt engineering is iterative, and once a good prompt is found it should be made persistent (copyable or checked into Git) because additional verbosity can hit diminishing returns.
- Eric expects to supplement the book with guidance on local LLM options beyond Ollama, including LM Studio.
- AI evaluation can be done by saving model traces/outputs and using another model as a judge, but model comparisons can invert expectations if prompts are better tuned for a weaker model.
- Teams can codify AI guardrails via persistent repository files (including cross-provider concepts like agents.md), but cross-provider compliance is not guaranteed.
- OpenAI's API is usage-based and token-metered, and it is distinct from the ChatGPT subscription product billed monthly.
Sections
Prompting As Engineering Asset And Context Management
- Prompt engineering is iterative, and once a good prompt is found it should be made persistent (copyable or checked into Git) because additional verbosity can hit diminishing returns.
- Teams can check a reusable prompting-context file into Git so everyone uses the same boilerplate without retyping each session.
- Models can perform better on technologies with extensive public documentation and open development history because training data includes those artifacts.
- Internal standards such as naming conventions can be injected into LLM context via repo files checked into Git or via boilerplate instructions pasted at chat start.
- Prompt specificity improves usefulness because LLMs do not reliably infer unstated preferences; providing explicit technical context, examples, and output constraints increases the likelihood of a useful response.
- System messages can provide persistent context across chats, reducing the need to repeat instructions such as preferred technologies, roles, and response format.
Learning Path And Enablement Scaffolding
- Eric expects to supplement the book with guidance on local LLM options beyond Ollama, including LM Studio.
- The AI Networking Cookbook is organized from foundational AI setup to advanced topics including MCP, building copilots, and evaluating cost/performance tradeoffs.
- The book intentionally uses OpenAI as the primary provider early on to reduce beginner overwhelm while teaching transferable concepts like temperature and system messages.
- All code examples from the book are available in a public GitHub repository and are commented so they can be followed without the book.
- Community content moved from networkanimation.community to networkautomation.com, which offers free signup notifications and a Discord for real-time Q&A.
- The intended audience is a network engineer with basic networking knowledge (around Network+ or CCNA) and basic comfort reading Python.
Model Selection And Evaluation Pragmatism
- AI evaluation can be done by saving model traces/outputs and using another model as a judge, but model comparisons can invert expectations if prompts are better tuned for a weaker model.
- Competent LLM results often depend on selecting an appropriate model (not the cheapest default) and iterating prompts until the request is correctly specified.
- Eric currently prefers Claude Sonnet 4.6 with thinking mode for coding tasks and often uses Gemini for browser-based workflows where it can reference open tabs.
- Comparing outputs across multiple models is most worthwhile for high-stakes decisions or systematic evaluation and is usually unnecessary for routine tasks once a model is good enough.
- Eric expects that for low-risk coding-assistant tasks, output quality can be high enough that extensive double-checking may feel less efficient than trusting the assistant.
Guardrails Interoperability And Versioned Governance
- Teams can codify AI guardrails via persistent repository files (including cross-provider concepts like agents.md), but cross-provider compliance is not guaranteed.
- Combining global and project-local guardrails can constrain LLM behavior, with more specific local instructions overriding broader defaults.
- Guardrail files used to guide assistants are typically plain-English Markdown rather than a strict structured format.
- A proposed safer workflow is to start in planning/ask mode with a coding assistant, then summarize agreements into a file checked into a centralized repository for team reuse and change history.
Cost Pricing And Initial Access Friction
- OpenAI's API is usage-based and token-metered, and it is distinct from the ChatGPT subscription product billed monthly.
- Eric estimated that about $20 of OpenAI API credit was sufficient for his book examples and was not exhausted during his work.
- Many AI providers now require credit card verification or paid trials rather than broad free tiers, increasing upfront requirements to get started.
Watchlist
- Eric expects to supplement the book with guidance on local LLM options beyond Ollama, including LM Studio.
- Eric reported hearing that Mac minis are in high demand for local LLM use and that this popularity has contributed to shortages.
- Teams can codify AI guardrails via persistent repository files (including cross-provider concepts like agents.md), but cross-provider compliance is not guaranteed.
Unknowns
- Which specific AI providers changed free-tier and verification requirements, and when did those changes occur?
- What token usage, model choices, and task mix underlie the approximately $20 API credit datapoint, and how variable is it across common network-automation tasks?
- What are the measurable performance thresholds for local models (latency, throughput) across different hardware configurations and with/without GPU offload?
- How consistently do major assistants read and obey repository guardrail files (including agents.md), and what failure modes exist when they do not?
- What empirical success-rate improvements come from structured-output instructions (JSON/YAML) versus unstructured prompting for automation pipelines?