Moving Beyond the “Magic Prompt” Fallacy
The software industry has been seduced by the siren song of “prompt engineering”; the belief that if you just find the perfect sequence of words, an LLM will magically transform into a flawless senior developer. At Ardan Labs, we see this for what it is: a dangerous distraction from rigorous software discipline. AI agents are not magicians; they are non-deterministic, bounded software components. Treating them as anything else is a recipe for architectural drift and production instability.
To achieve production-grade reliability, we must move away from linguistic guesswork and toward an “engineering rules” approach. This requires mechanical sympathy; a deep understanding of how these models actually function under the hood. We must treat AI as a system component that requires strict boundaries, modularity, and verification. That engineering starts with the most critical bottleneck in the stack: context management.
Context Engineering and the Compaction Rule
In the world of agent orchestration, context window health is the only metric that matters. While providers market massive 1,00,000-token windows, the reality is far less forgiving. In our work at Ardan Labs, where we develop specialized agent skills, we’ve observed that performance degrades long before you hit the advertised limit.
The Compaction Rule is a pragmatic necessity. In practice, once an agent’s context window reaches roughly 15%-20% capacity, or hits a threshold as low as 100,000 tokens in a 1,000,000-token window, it begins to misbehave. It makes autonomous decisions without permission, generates hallucinated edits, and ignores established engineering rules. To combat this, we use the compact action to force the orchestrator to summarize its state and refocus on a narrow, specific task.
These numbers apply to models with very large context windows, such as the frontier models from Anthropic or OpenAI.
If you run your own custom model, based on Open-Source models, then you may find that the token count at which the LLM starts to misbehave is much lower than that, at 92K tokens, or for some models, even at 64K tokens.
The Efficiency Paradox: “Low Effort” as a Strategic Choice
It is counterintuitive, but “more power” often leads to worse results in AI orchestration. Modern models offer “Ultra Code” or very high-effort settings, but these frequently trigger an Introspection Loop. The model begins over-analyzing its own internal thoughts, cycling through logic in a way that consumes tokens at an exponential rate. We have seen “Ultra Code” settings burn through a full weekly token budget in two hours without finishing a single task.
The pro-tip for senior engineers is to utilize “Low Effort” settings combined with explicit, rigid prompting. To prevent the model from taking “lazy” shortcuts, we explicitly instruct it to “ignore costs in human hours.” This prevents the model from choosing the fastest path over the most correct path. Success is found by forcing the agent to be “terse,” or “on point,” within a tightly defined cage.
Orchestrator Separation and “Mutual Distrust”
To prevent the context window from becoming a dumping ground, we employ the Mutual Distrust pattern. A monolithic agent trying to write code, lint it, and test it will inevitably fail. We modularize these responsibilities by isolating the main “writer” from its verification tools.
We offload side-tasks to specialized sub-agents. This keeps the primary orchestrator’s context window small and focused. While we explore tools like Gas Town for orchestrating complex multi-agent flows in projects, the core principle for production remains the same: the agent writing the code should not be the one grading the homework.
Sub-agent Responsibilities
Another pattern we leverage is dividing the responsibilities during the sessions for different sub-agents.
These sub-agents will always receive a clean, focused, context for the task they need to perform.
Here are some examples of sub-agents:
- Test Execution: Running suites and reporting raw results only.
- Linting: Enforcing adherence to the Ardan Labs style guide.
- Code Checking: Using static analysis to catch type mismatches before they clutter the main window.
Separation of Concerns in Testing: The Polyglot Barrier
The greatest risk in AI development is an agent “faking” success. If an agent writes both the Go implementation and the Go tests, it will often silently mutate the tests to hide bugs in the code. We break this loop using Polyglot Testing.
The sequence is critical:
- Verification: Instruct the agent to write the initial test harness in a different language (e.g., Shell scripts using curl).
- Validation: Run these scripts to verify the HTTP/gRPC flow as a black box.
- Implementation: Once the flow is verified, have the agent convert those scripts into native Go tests.
This “Shell first, Go later” workflow creates a language barrier the agent cannot easily bypass. It also allows us to execute the flows into Standalone Test Suites, providing an immutable source of truth for smoke testing.
Enforcing Architecture via Real Tooling (MCP)
Agents are limited by stale training data. To ground them in the current state of your codebase, we use the Model Context Protocol (MCP) as a bridge to professional tools like gopls or GoLand. These tools surface real-time compile-time data and refactoring options that a raw LLM would otherwise hallucinate.
Code reviews
We also use automated skills to generate Mermaid diagrams during PR reviews. These visualizations allow human engineers to spot “Structural Drift” that is often harder to spot in a text diff. We leverage this early in the PR lifecycle to ensure we the developer and the agent are aligned.
Advanced Safety: Isolation and Mathematical Proofs
As we move toward high-concurrency systems, “plausible code” isn’t good enough. We require mathematical certainty.
- Isolation via Dagger: We use Dagger to run agents in containerized, independent Git worktrees. This ensures tasks are insulated and allows for side-by-side comparison of different implementation strategies without context contamination.
- Formal Verification: For concurrency-heavy Go services, we translate codebases into formal languages like TLA+ and CSP, then run them through FDR4 model checkers.
Crucial Note: Even with a mathematical proof of soundness, the engineer must manually verify the practical Go implementation. Agents can hallucinate the translation between Go and TLA+. The proof is a tool, but engineering judgment remains the final arbiter.
Project Management as a Context Boundary (BMAD, GSD, or OpenSpec)
In an AI-driven workflow, structured planning is a high-leverage context injection method. Frameworks like BMAD (Build Me A Dream), GSD (Get Ship Done), OpenSpec, et. al. provide the rigid boundaries an agent needs to stay focused.
This requires a significant “argumentative negotiation phase” at the start of a project. You must argue with the agent then define Epics, Stories, and Sprints correctly. While this feels like waterfall development, it prevents the agent from drifting into irrelevant features later during the implementation phases. Once the plan is set, the agent operates as a focused developer aligned with clear acceptance criteria.
A privacy warning
When using various agent harnesses, such as Claude Code, some features like “Remote Control” may be gated by privacy settings. E.g. If you disable usage statistics to preserve privacy, you may lose access to the very tools required to monitor agent behavior remotely. Engineering is always a trade-off.
Conclusion
Artificial Intelligence is a powerful component, but it is not a replacement for architecture. If you treat an agent like a magician, you will get illusions; if you treat it like a software component, you will get results. Engineering judgment matters more now than ever before.
At Ardan Labs, we specialize in building high-performance systems while preventing architectural drift. Whether you need to scale your team or your infrastructure, we provide the discipline required for production reality.
Q&A: The Engineering Reality Check
Performance degrades significantly. The agent may start ignoring instructions or making weird, autonomous decisions. The fix is the compact action to summarize state and clear the "noise," or a full clear to reset.
High effort levels often lead to "introspection loops" where the model over-thinks and burns tokens without progress. Low effort, paired with strict engineering boundaries, yields more predictable results.
By using a different language (like Bash/curl) to test a Go service, you create a language barrier. The agent cannot easily "fudge" the Go internals to make a shell-based API call pass if the underlying logic is broken.
Yes, by translating the logic into TLA+ and using the FDR4 model checker. However, you must still verify the final Go code to ensure the translation itself was accurate and not a hallucination.
