Context & harness engineering - The transition to agentic software delivery
Charlie Ponsonby
An Intro to Context & Harness Engineering
A primer for non-technical senior executives and Board members on the infrastructure that determines whether your AI software investment creates advantage or liability.
1. The transition to the agentic SDLC brings opportunity and risk
The SDLC (Software Delivery Lifecycle) - i.e. the process of building software - is changing incredibly rapidly.
Almost all software engineering teams use tools like Claude Code, Cursor and Codex. These tools are often no longer used as assistants that help developers write code. Instead, they are becoming the primary authors of code, operating with increasing autonomy inside your engineering teams.
The implications of this change are highly relevant for the Board:
It presents a potential 10x productivity improvement, but most organizations are only seeing a fraction of that improvement, as AI token use costs rocket
There are major compliance and security implications for uncontrolled use of AI tools in organisations - especially in the context of the EU AI Act, ISO 42001, FCA regulations etc.
With both of these in mind, it is very important to understand the key drivers of AI tool safety and productivity. These include ‘Harness Engineering’ and ‘Context Engineering’. Harness engineering ensures that all AI tool use is ‘harnessed’ – i.e. is within defined processes and guardrails.
And Context Engineering – which ensures that AI agents receive accurate and up-to-date context information, so that their output is useful and productive (i.e. rubbish in rubbish out).
2. The definition of Context Engineering and Harness Engineering
Context Engineering Deliberately curating and structuring the organisational knowledge — architecture decisions, coding standards, team conventions, domain rules — that is fed into an AI agent’s working memory before it writes code. The AI can only act on what it knows. Context engineering ensures it knows the right things. | Harness Engineering Building the evaluation infrastructure that measures what AI agents actually produce — catching regressions, enforcing quality thresholds, detecting drift from standards, and creating governance checkpoints before AI-generated code reaches production. |
Context Engineering is the briefing you give a highly capable new employee before they start work. Harness Engineering is the quality assurance, compliance review, and performance management system that ensures their output meets your standards. Both are essential. Neither exists by default.
Without Context Engineering, AI agents operate on incomplete or generic information, producing code that may ignore your architecture, violate your security patterns, or contradict decisions your teams previously. Without Harness Engineering, that output enters your codebase without systematic review — accumulating risk invisibly.
3. Why this matters at Board level
Organisations that establish these disciplines early will develop a competitive advantage: their agents learn from richer context, produce higher-quality output, and generate data that continuously improves both the context and the harness.
Those that do not will find themselves managing an expanding body of AI-generated code with no way to ensure its quality or alignment with business intent.
In addition, ‘Unharnessed’ AI tool use is a major security risk and will not be compliant with the EU AI Act, ISO 42001, FCA, SEC and other regulations.
Risk Summary of not having Context and Harness Engineering in place
Security & compliance | Unchecked agent-generated code AI agents write code far faster than humans can review it. Without evaluation harnesses, vulnerabilities and compliance violations accumulate in production at machine speed — creating audit exposure and breach risk that grows with adoption. |
Quality & reliability | Bug and escaped defect accumulation Without systematic regression detection, AI-generated changes quietly degrade system performance and reliability. Problems may surface as customer incidents rather than engineering catches — by which point remediation is costly. |
Competitive position | Generic AI with no proprietary edge Without context engineering, your AI agents behave like any generic model. Competitors who invest in organisational context will have agents that understand their systems deeply — a structural advantage that compounds over time. |
Technical debt | Tech debt accumulation AI adoption without governance does not slow technical debt — it accelerates it. Code that ignores architectural standards and domain conventions at human speed becomes a systemic problem when generated at AI speed. |
Institutional knowledge | Engineering knowledge erosion As agents take on more development work, the tacit knowledge that once lived in experienced engineers begins to atrophy. Without context engineering to capture and systematise it first, it may be lost permanently. |
AI productivity & ROI | Weak productivity gains Context and harness engineering fundamentally impact the effectiveness of the agents and hence the ability of the agents to actually deliver material impacts in engineering productivity. |
4. Potential questions for the CTO
Question | Why it matters |
|---|---|
Do we have a baseline? Can you show me the current state of AI-generated code in our codebase — its volume, quality distribution, and where it is concentrated? | You cannot govern what you cannot measure. If there is no baseline, there is no visibility. |
What context are our AI agents operating with? How is context curated and maintained, or are agents working from generic defaults and whatever happens to be in the repository? | The quality of AI output is directly driven by the quality of its context. |
What governance exists for AI-generated code before it reaches production? Is all AI tool use ‘harnessed’? Do we have automated quality gates, or is review entirely dependent on individual engineers? | Human review does not scale with AI generation rates. Systematic governance is essential. |
How would we know if AI adoption were quietly accumulating security vulnerabilities or technical debt? What instrumentation do we have? | The risks of ungoverned AI adoption are often invisible until they surface as incidents. |
What is our strategy to capture proprietary competitive advantage from AI — not just the productivity gains available to every competitor? | Tooling access is not a moat. Proprietary context and evaluation infrastructure is. |
Who owns this? Is there clear accountability for Context and Harness Engineering and related AI governance, or is it distributed informally across teams? | Diffuse ownership means no-one is accountable when problems emerge at scale. |
5. Why Developer Productivity Insight (DPI) tools are important
Context and Harness Engineering are disciplines that require data — and Developer Productivity Insight (DPI) platforms are the systems that generate, organise and surface that data.
A DPI platform sits across your engineering organisation, ingesting signals from code repositories, CI/CD pipelines, issue trackers, pull request workflows, and increasingly the AI agents themselves.
From this, it builds a continuous, measurable picture of how software is being built, which is the intelligence that both Context Engineering and Harness Engineering depend on.
For Context Engineering, DPI tools provide structured knowledge of the end-to-end software engineering process that can be fed into an agent’s working memory. And for Harness Engineering, DPI platforms provide the evaluation infrastructure itself: the baselines, the quality metrics, the anomaly detection, and the governance reporting that allow leaders to verify that AI-generated code meets the standards the organisation has set.
Introduction to Plandek
Developer Productivity Insight for the agentic era
Plandek is a leading Developer Productivity Insight (DPI) platform built for engineering organisations navigating the transition to AI-assisted and agentic software development.
Plandek connects across the engineering toolchain — from issue management, code repos, CI/CD, observability platforms and AI coding tools — to create a unified, continuously updated model of how software is being built across the organisation. This:
provides technology leaders with total insight, to drive the safe and compliant roll-out of AI tools, and to transform software engineering productivity and ROI
provides engineering managers and teams with a clever AI-driven virtual assistant to spot hidden blockers and suggest clever mitigations, so they are happier and more productive.
Plandek is based in London and is used by clients globally.
Written by
Charlie Ponsonby
Co-founder & CEO
Charlie Ponsonby is CEO and Co-founder of Plandek, the leading Developer Productivity Insight (DPI) platform that helps software engineering teams drive productivity and transition to AI-led engineering. He writes widely on the opportunities and challenges inherent in the transition to the agentic SDLC. Prior to founding Plandek, Charlie founded Simplydigital, which grew to become the UK's largest broadband and digital services comparison business before being acquired by Europe's largest consumer electronics retailer. He started his career at Accenture and has held senior leadership roles in retail and telco. Charlie holds a degree from the University of Cambridge.
See how your engineering efforts translate into measurable business impact
Measure delivery performance, AI impact, and engineering productivity with hundreds of metrics, OOTB dashboards and custom configurations.
Contact us
UK Office
Unit 313 The Print Rooms, 164-180
Union St, London SE1 0LH
US Office
Floor 4, 1515 Mockingbird Ln,
Charlotte, NC 28209, USA