GET IN TOUCH

Send a message and I'll follow up over email.

Submitted details are used only to respond to your message. Nothing is shared, sold, or added to any marketing list.

← All artifacts
framework

Context Over Prompts: How AI Widened the Engineering Gap.md

A practitioner's framework for building with AI, and why better tooling made judgment more valuable rather than less.

The technology is rarely the hard part

Before generative AI dominated the industry, Business Intelligence was the corporate focus. I started my career working directly with SAP products, earning certifications in data warehousing and ERP systems. Organizations used in-memory processing and real-time analytics to compress forecasting cycles and outpace competitors.

Every company wanted “data-driven” on their slide deck, much like they would later demand “blockchain” or “AI.” Vendors rebranded old products as intelligent, and executives wasted budgets chasing labels. The practitioners who actually shipped results were the ones who ignored the hype and connected the initiative to a stakeholder’s actual problem. That era taught me the lesson I still operate on today. The technology is rarely the hardest part of a project. Connecting the technology to the core value proposition is.

When the bottleneck shifted

The same hype cycle played out with generative AI, but the underlying tooling eventually matured. Early developer extensions improved workflows with inline suggestions, but they felt like a ceiling. Anthropic’s Claude Code and the release of Opus 4.5 in late 2025 broke that assumption. Bringing planning, generation, and testing into a single CLI interface shifted the development paradigm entirely.

When anyone can bring an idea to a functional prototype in minutes, the industry floods with undisciplined code that collapses under real-world pressure. For seasoned software engineers, this moment clarified a major shift. The bottleneck moved from keystrokes to judgment. Architecture, systems thinking, and domain knowledge became significantly more valuable. The new tooling did not close the gap between disciplined and undisciplined practitioners. It widened it.

Context engineering

To build reliable systems at this speed, the practice had to evolve from prompt engineering to context engineering. Prompt engineering focuses on crafting the right question. Context engineering architects the environment. It defines what information the model sees, what persists across interactions, and how outputs flow back into the pipeline.

I encode project strategy directly into instruction files where the agents can actually use them. The Product Requirements Document serves as an executable contract between me and my agents. If I cannot write a test for a requirement, the requirement is too vague. AI agents run parallel workstreams with test-driven development acting as the quality gate.

The step most engineering teams skip is validation. I deploy pre-programmed inspection agents to run visual and functional checks against the original success criteria. They catch the regressions and scope drift that human review often misses. Scaling this orchestration across multiple independent loops required a dedicated layer, which became the foundation of my Banh Mi Ops framework.

Closing the handoff gap

Test-driven development, specification-driven design, and multi-agent frameworks all exist independently across the industry. The integration is what matters.

Most organizational value leaks at the handoffs. A strategist defines what a system should accomplish, and an engineer builds it. Somewhere between those two points, intent gets translated, compressed, and approximated. The final product often answers a slightly different question than the one originally asked.

Owning the entire pipeline from strategy through validation removes the translation step. The person who sat with the stakeholder and understands why a constraint exists is the same person running the agents that enforce it. When a requirement turns out to be impossible, it is discovered by someone who can renegotiate the scope rather than someone who has to escalate an issue. Reading business constraints and writing the code to solve them are usually treated as two separate jobs. I have found far more value in treating them as one.


Search my experience