AI agents can write code, call tools, and navigate a codebase at lightning speed. But speed alone does not produce reliable software. In real-world software development, generated code is not yet a delivered product. A change only becomes valuable once it has gone through validation, review, acceptance, and delivery.

This session begins with a simple observation: onboarding a new developer into a serious software project takes time. That developer must build domain knowledge, understand the architecture, learn the testing strategy, follow team conventions, know the security rules, and understand how work moves from concept to production. So why do we expect an AI agent to be able to reliably do this same work based on a single vague prompt?

The problem isn't just that models hallucinate. The bigger problem is that much of engineering is implicit. Intent is embedded in conversations. Rules exist in people's minds. Validation is embedded in habits. Context is scattered across tickets, documentation, tests, API contracts, architectural decisions, and delivery pipelines. Agents make those vulnerabilities painfully apparent.

In this talk, we explore the Engineering Triad as a practical model for agentic development:

• Prompt Engineering makes intent explicit.
• Context Engineering makes knowledge explicit.
• Harness Engineering makes the design explicit.

Using a concrete password-reset example, we'll show how a simple request like "add password reset" actually involves many hidden engineering decisions: security rules, token policies, API contracts, email infrastructure, validation, logging, test scenarios, and human acceptance. We translate that vague request into explicit artifacts such as a SPEC.md, BDD-style scenarios, AGENTS.md rules, scoped custom agents, reusable skills, and validation gates.

The key takeaway: agentic development does not replace engineering discipline. In fact, it makes engineering discipline even more important. A good environment for agents is also a good environment for developers.