What to Do When Software Engineering Becomes Context Engineering
In a Nutshell
Software engineering is shifting from writing code to engineering context for AI agents, as individual productivity gains stall at the team level because systems aren't designed for AI-native development. Senior developers must become context engineers who externalize tribal knowledge into maintainable instructions and agent skills, while teams adopt constraints engineering over traditional code review to manage the new review bottleneck. Success requires top-down investment in dedicated context maintenance, measuring system effectiveness through intervention ratios and rework rates rather than code volume, and treating context engineering as ongoing competitive infrastructure work.
These notes were generated by AI and may contain inaccuracies.
Kira Burn serves as director of engineering productivity and AI impact at JetBrains. Maxim Salnikov works at Microsoft as a senior solution engineer focusing on developer tools, specifically AI native or AI powered developer tools. Before joining Microsoft, Salnikov spent two decades in web development and continues to build daily, with his GitHub contribution graph showing increasing activity.
Salnikov describes himself as a full-time learner whose approach involves learning by teaching, training, and enabling at scale across approximately 100 enterprise customers and their developer teams.
Technical leads observe that individual developer productivity has increased by 50%, yet teams hit walls where system-level or organizational productivity gains are not realized. The core issue is that the system itself is not ready for this transformation.
Coding typically represents 30% maximum of enterprise development work. Even with 50% productivity gains in coding, this only affects a fraction of overall productivity. The deeper problem emerges when more code is produced at incredible speed, creating the next bottleneck: review.
AI-generated code presents a multi-dimensional review challenge. The code may be confidently wrong yet appear locally coherent while being globally inconsistent. AI agents ensure all tests pass, but this does not guarantee the code functions correctly within the broader application context. These defects are significantly more challenging to capture than traditional human-created bugs.
This explains why team and organizational productivity cannot scale proportionally to individual productivity gains. The solution requires changing the system, rewiring the system, and rearchitecting the system.
Context engineering represents what builds today's company intellectual property. The quality of context layers directly affects AI agent output quality. Software developers, particularly senior engineers who own and navigate domain knowledge, are evolving into context engineers.
This role extends beyond creating markdown files or instruction files. It involves skill, knowledge, and requires iterations. Context engineering is not just about RAG or simple instruction files but encompasses deeper knowledge management.
A critical gap exists in enterprise approaches to managing AI native dev primitives. While these assets become part of code repositories, the challenge lies in ensuring they remain up-to-date and properly maintained. Security concerns arise because agent skills from third-party sources, even from trusted vendors, can be compromised.
These markdown files function as executable code for agents. Agent skills specifications include scripts that maintain determinism, requiring validation of downloaded scripts from the internet.
Daniel Meila's agent package manager applies package manager principles to agent primitives management, including governance, versioning, and pinning to specific commit versions. This approach works within enterprise boundaries, allowing teams to validate, fine-tune, and detach skills from upstream sources while accumulating their own team or organization boundary of assets.
Knowledge compounds through this approach, with use cases including using instructions to improve instructions and using agent skills to build agent skills.
Teams must redesign themselves to move forward with AI native development, which requires going out of comfort zones. Viewing AI agents merely as tools represents legacy thinking from two to three years ago. AI agents function conceptually as digital team members.
A critical principle: AI agents should not operate with the same permissions as the developers running them. Tools and techniques exist to run AI agents with the least possible privileges.
AI agents require constant onboarding due to amnesia. Three new roles emerge for every developer:
- Someone to properly onboard AI agents as junior team members
- Someone to review AI agent output
- Someone to handle escalations when agents get stuck or enter infinite loops
These represent new responsibilities distributed across team members rather than separate individuals.
Senior developers become context engineers and system designers. Mid-level developers focus on creating detailed, explicit, step-by-step, and constrained specifications for tasks. The book "Agentic SDLC handbook" by Daniel serves as a reference for these concepts, validated through over 100 hours of hands-on workshops with enterprise teams.
Two anti-patterns emerge in AI native team structures:
- Creating teams of AI superheroes as sole knowledge owners for agentic development across the organization. This fails long-term because these individuals may not possess domain knowledge from every team and solution component.
- Building parallel tracks where critical code excludes AI while non-critical code permits AI. This creates tension around code categorization and contaminates true AI native development principles.
The best practice embeds context engineering knowledge, skill, and responsibility into every single team. This involves domain knowledge boundaries across teams, recognizing that context layers must evolve as products evolve, not merely represent snapshots of knowledge.
Review becomes the primary concern for technical leaders once coding becomes commodity. Adding more reviewers saves teams short-term but leads to technical dead ends and burnout. AI agents excel at checklists and can generate as many tests as needed, but AI-generated code may follow outdated APIs or violate project conventions that represent tribal knowledge.
Rather than adding more resources for reviews, teams need constraints engineering. Reviews should focus on whether AI agents obey carefully created, nurtured, and up-to-date instructions rather than reviewing code itself. When agents follow well-maintained instructions, code quality improves substantially.
Agents frequently struggle with architecture and may produce over-complex code. Reviews must verify whether agents follow provided architecture. Tribal knowledge that everyone knows but isn't externalized represents a significant blocker, as agents cannot access implicit team knowledge.
Auto-generated instructions from tools like slash init provide value as drafts but miss non-scannable, non-extractable tribal knowledge that must be manually externalized for agent consumption.
Teams across organizations build external harness layers because foundational AI dev tools, while maturing with major players emerging, remain insufficient for specific team needs. What differentiates teams is accumulated company knowledge that becomes true IP, not the dev tools or models used.
This external harness knowledge builds team confidence and company valuation. Teams can use AI to build AI layers through meta AI approaches.
Salnikov maintains agent skills for web platform and web AI, advocating for built-in browser APIs including web neural networks and web MCP. Agent skills can build other agent skills, with agentic workflows used for weekly specification updates comparing current agent skills against emerging standards.
Companies often see developers across different teams independently creating the same custom agents and automations, resulting in wasted development time and excessive token consumption. This duplication represents both inefficiency and unnecessary cost.
When evaluating AI tool adoption, organizations must account for more than just license and token costs. Building the contextual layer requires dedicated time and billable hours. Without intentional investment, results remain mediocre. Upskilling is essential and goes beyond random courses. Adopting AI-native development tools at scale requires a comprehensive program rather than one-time training.
The adoption process functions as a flywheel because new developers continuously join at different stages of tool understanding. Enterprise companies should integrate AI-native development topics into their regular ongoing programs rather than treating it as a separate initiative.
Metrics in AI-native development differ from classic software development. The focus shifts from measuring software itself to measuring the systems built to create that software. Vanity metrics and lowest-hanging-fruit measurements should be avoided. Lines of code as a metric remains surprisingly common despite being largely anecdotal.
Many companies measure the number of lines or acceptances of AI-generated code, which primarily indicates tool adoption rather than software quality. These metrics become less relevant after early adoption stages. More meaningful metrics include the ratio of human interventions required, with fewer interventions indicating better system performance.
Confident time-to-merge measures the duration from pull request creation to confident merge without deferred fixes. Rework serves as another valuable metric because AI agents can generate technical debt when proper context engineering is not applied. While some rework remains inevitable, tracking it provides insight into system effectiveness.
Engineering metrics like efficiency and adoption provide useful data but lack direct business relevance. The recommended approach measures productivity of the "garden" rather than the "gardener," shifting focus from individual to team and organizational productivity. The most practical metric compares current KPIs against baseline performance before AI implementation, recognizing that no universal standard applies across companies.
Team-level experiments with AI agent harnesses and context engineering approaches are acceptable when connected to potential business impact. These experiments can accelerate organizational progress or even create new revenue streams. Companies have pivoted from their original products to selling specialized tools they developed internally. The current environment resembles early Node.js days when essential packages emerged rapidly and gained widespread adoption.
Building organizational or team-level harnesses including context engineering cannot succeed through purely bottom-up efforts. Top-down support is necessary because developers require allocated time and resources. Change management principles remain applicable, with executive sponsorship being the primary factor driving successful change. This requires full commitment, communication, and transparency from technical leaders rather than superficial gestures.
Trust issues emerge between engineering teams and non-technical management as AI spending increases. Management must trust engineers to use resources wisely. Governance approaches span a spectrum from complete prohibition of advanced features to unrestricted bring-your-own-tool policies, with neither extreme being sustainable. Security engineers and CISOs should handle governance rather than burdening developers, providing clear transparency about available tools and restrictions.
The goal is implementing guardrails that enable rather than restrict experimentation. Developers should not fear making mistakes that halt their work. Compliance and audit requirements present new challenges because AI agents function as decision-makers rather than simple tools. Audit trails must capture not just generated code but the reasoning behind decisions, including which instructions and harness configurations influenced outcomes.
AI adoption follows a classic J-curve pattern. Initial excitement creates performance above baseline as developers experience productivity boosts. This phase may last weeks or compress to days depending on team dynamics. Performance then drops when agents encounter real codebases lacking proper context engineering, revealing implicit conventions, unused APIs, and other undocumented elements.
Organizations that abandon AI at the inflection point mistake context failure for agent or model failure. Recovery requires fixing the harness rather than just regenerating code. A diagnostic approach involves asking agents to regenerate instructions and identify root causes when they drift from expectations. This systematic improvement of the context layer leads to eventual hockey-stick growth and exponential improvement.
Developers must adapt with flexibility and openness to new approaches. Technical writing has become a crucial skill because agents require clear specifications rather than implicit human understanding. Initial specifications are rarely optimal and require iterative refinement. Agent orchestration is emerging as a distinct discipline within context engineering, involving construction of complete agentic loops rather than simple implement-and-review cycles.
Developers are transitioning from engineering software to engineering the software factory that produces that software. While tool ecosystems remain imperfect, significant opportunities exist for new solutions. Writing specifications and orchestrating patterns represent inevitable skill requirements. Larger organizations may create specialized roles like context engineer or agent operator, though these responsibilities might integrate into senior engineering positions.
Context engineering should be treated as a primary ongoing activity rather than a passive process. Inaction carries negative consequences because competitors actively build their context layers, creating differentiation in team capabilities and product quality.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
