2025, the year software development changed paradigm
2025 was a real-time experiment conducted across the entire tech industry: AI's software engineering capabilities were put to the test against human technologists. And while the year began with AI looking all-powerful, the transition from "vibe coding" to what is now called "context engineering" demonstrated one thing: developers' work is evolving profoundly, but it remains absolutely critical.
This shift can be read in the technology radars that leading tech consultancies publish regularly: edition after edition, they show the emergence of techniques and tools designed to help teams better manage the context supplied to LLMs and AI agents, and the disappearance of bets placed on models' raw power alone.
Taken together, these signals point in a clear direction, for software engineering and for AI at large: after years in which the industry assumed progress depended only on model scale and speed, it is now established that what matters is the ability to manage context effectively. By mid-2026, this is no longer an intuition: it is the foundation of team practice.
Vibe coding: early promises and revealed antipatterns
It was in February 2025 that Andrej Karpathy coined the term "vibe coding." Dropped almost in passing, the expression took the industry by storm. It captures the initial approach many took with AI assistants: give the model a general direction, a "vibe" of what you want, then iterate until the result feels right, the software equivalent of improvising a melody without a score.
The approach feels liberating at first: no more detailed specifications, no more edge cases to anticipate, just let the AI generate code until it produces something close to the need. But "close" is not good enough for production software, and antipatterns proliferated: complacency toward generated code, ever-longer prompts, and a comprehension debt piling up on codebases that no one truly mastered anymore.
The context inflection point
At Adservio, we observed the same pattern with our clients. Teams start with small, simple prompts and get encouraging results; emboldened, they increase prompt size and complexity, expecting the models to keep up proportionally. That is not what happens: past an inflection point, adding context degrades result quality. Models lose their way, generate contradictory code, or focus on the wrong parts of the context. It is like trying to communicate by shouting louder, past a certain volume, you are no longer solving a clarity problem.
Context engineering: structuring context as a discipline
That realization is what brought context engineering into being. When working with agentic coding assistants such as Claude Code, supplying the right context, sometimes called "knowledge priming",proves decisive: outputs become more consistent and reliable, rewrites decrease, and real productivity rises.
Select, structure, version, measure
Context engineering is not just about writing better prompts. It is a full engineering discipline resting on four moves: selecting the context genuinely needed for the task and excluding the noise that confuses the model; structuring it with formats and hierarchies the model processes efficiently; versioning and maintaining it like code, with reviews and tests; and measuring its effectiveness with metrics, rather than judging "by eye" whether results are improving.
This shift has an organizational consequence: context becomes a team asset. Instruction files, documented conventions, and canonical examples are no longer personal notes but shared artifacts, continuously reviewed and improved, on a par with CI or infrastructure as code.

Generative AI and legacy code: the abstraction paradox
Legacy codebases are one of the most powerful use cases for generative AI: almost every organization owns systems written years ago, often by long-departed developers, with sparse or nonexistent documentation. Where weeks of code reading and reverse engineering were once needed, a model properly fed with context, codebase structure, recurring patterns, available documentation, produces high-level explanations, identifies critical components, and suggests modernization strategies.
Describe the function rather than show the code
The counterintuitive lesson from our experiments concerns forward engineering: AI is more effective when it is more abstracted from the underlying system. To modernize a legacy system, two approaches exist: give the model detailed access to the existing code and ask it to transform it incrementally, or describe what the system does, at a functional level, and ask it to design a new solution.
The second often produces better results. Legacy code is saturated with historical decisions, technical workarounds, and outdated patterns: chaining the AI too tightly to that code leads it to reproduce those patterns instead of rethinking the solution. By providing high-level functional context, what the system must do, the business constraints, the performance requirements, you widen the solution space and genuinely leverage the model's generative capabilities.
Autonomous agents: context becomes a safety issue
The great accelerator of this awakening is the growth of agents and agentic systems, which organizations want both to build as products and to operate internally. The fundamental difference between a chatbot and an agent lies in autonomy: a chatbot reacts within a conversation, while an agent initiates actions, API calls, database queries, code execution, collaboration with other agents. A chatbot that misreads context produces a bad answer; an agent that misreads context takes bad actions: deleting data, exposing sensitive information, disrupting production systems.
AGENTS.md, agent memory, and reference applications
Tooling has consolidated around this need. The AGENTS.md file, now a de facto standard adopted by most coding assistants, documents for agents, rather than for humans, the permissions, constraints, and conventions of a codebase: which directories may be modified, which patterns to follow, which actions require human approval. Memory systems like Mem0 let agents build on past interactions instead of treating every task in isolation, and tools like Context7 inject up-to-date dependency documentation directly into the context.
We have also found success anchoring coding agents to a reference application: rather than describing in words how the organization builds software, you show a canonical example that embodies the standards. At Adservio, we maintain such references per project type, microservice backend, React frontend, data pipeline, which serve as ground truth for agents and for agent teams, whose orchestration reduces the context burden carried by each individual agent.

MCP, A2A, spec-driven development: the standards settle in
The space has matured as standards have taken hold. The Model Context Protocol (MCP) has become the reference protocol for connecting LLMs and agentic AI to sources of context: created by Anthropic, it was handed in December 2025 to the Agentic AI Foundation, a neutral foundation hosted by the Linux Foundation with OpenAI, Google, Microsoft, AWS and Block among its co-founders. By mid-2026, MCP exceeds 97 million monthly SDK downloads and is adopted by every major AI provider; the agent2agent (A2A) protocol, which standardizes interactions between agents, brings together more than 150 organizations under the same governance.
The history of technology teaches that open standards usually win in the end: HTTP beat proprietary protocols, Git replaced closed version control systems. The same dynamic is playing out in AI, instead of vendor-locked ecosystems, AI components are becoming interoperable.
Shared specifications and spec-driven development
On the practice side, spec-driven development has gained real traction, tooled notably by dedicated open-source frameworks: instead of starting with code, you write detailed specifications, tests, schemas, behavioral descriptions, which are then supplied to the AI as implementation context. The approach forces clarity, provides rich context, and creates an automatic verification suite; it does, however, challenge traditional agility. We favor a hybrid path: high-level specifications for the structure, rapid iteration for the details. And curated shared instruction libraries remain the highest-yield tool: the teams that succeed do not let every developer improvise their prompts, they capitalize collectively.

The software engineer, indispensable curator of context
The fact that the conversation has moved from questions of speed and scale to context puts software engineers back at the center of the game. Context is precisely where humans excel: we understand nuance, implications, the unsaid; we spot contradictions and ask clarifying questions. Models, however powerful, absorb enormous amounts of information but struggle to prioritize and to know instinctively what matters.
The skills that make the difference
The role is evolving without disappearing: orchestrating systems that include AI components rather than writing every line by hand, diagnosing complex interactions between models, agents, and traditional systems rather than debugging line by line. The key skills: context engineering itself, hybrid systems architecture, the evaluation of non-deterministic components, and the governance of agentic systems.
Paradoxically, the more coding is automated, the more critical human collaboration becomes. The most effective teams we support run prompt reviews the way one runs code reviews, hold retrospectives on what worked with AI, and document patterns and antipatterns together. Context is not a technical detail: it is the bridge that connects human intent to AI action, and mastering that bridge is the defining challenge of modern software engineering. It is also what makes the craft more interesting: less repetitive code, more architecture, more design, and more high-impact decisions.
STAY POSTED
Get our next analyses and field notes straight to your inbox.




