Let’s be honest: In 2025, the breathless pace of AI model updates has started to feel … well, a bit incremental. We’re still getting improvements, but the massive paradigm-shifting leaps of the last few years seem to be incremental for code generation … on the model side, at least.
But AI-driven innovation in the software development lifecycle hasn’t disappeared — it’s just shifted. It’s no longer just about the raw power of the model — it’s about context engineering.
While the headlines are dominated by complex, external tech such as Model Context Protocol servers linking to discrete elements of your stack, a powerful revolution is happening quietly right inside our integrated development environments (IDEs). This revolution is about how we manage and persist context for our AI coding agents — because even the most powerful model is useless if it doesn’t understand your intent.
The High Cost Of “Agent Drift”
We’ve all been there: You give a coding agent a prompt, and it builds something astonishingly fast — and completely wrong.
I’m not talking about a simple syntax error. I’m talking about “agent drift” — the silent killer of AI-accelerated development.
It’s the agent that brilliantly implements a feature while completely ignoring the established database schema. It’s the new code that looks perfect but causes a dozen subtle, unintended regressions. It’s the “finished” task that’s a world away from your actual architecture, forcing you to spend hours debugging the AI’s work (or simply throwing it away and doing it yourself).
This is the central problem: Our tools are powerful, but our ability to control them is lagging. We’re drowning in AI-generated rework.
From Agent Fixer To Agent Conductor
Most people by now have spent significant time managing fleeting prompts in AI chat windows that degrade as context increases. But the bigger issue with this pattern is how discrete and siloed it is. It lacks persistence and often drifts from the big picture.
The new high-leverage skills needed are orchestration and alignment. Instead of a one-off prompt, developers are now curating a “brain” for their AI agent that lives alongside the code. The most practical way this is manifesting is through a simple set of markdown files.
A prime example is the open source Conductor methodology, built around a simple .conductor/ directory. Think of it as the complete sheet music for your AI.
I’ve used this myself quite extensively, and the improvement is notable. Where there are context gaps, coding agents tend to fill in those gaps with their own assumptions or training. When an agent has access to these files, it significantly limits this guesswork with high signal context that helps keep the agent aligned to your project.
For an existing project, it takes a little work to get the .md files populated (your agent can help with this, too). Let’s walk through what this looks like in practice once you have everything set up:
It reads prompt.md first. This isn’t just a prompt; it’s a mission briefing. It sets the agent’s persona and, most critically, commands it to read all the other files.
It then reads plan.md. This is the master blueprint. The agent doesn’t just see one task — it sees the whole project.
It next consults status.md. This is the “as of: Jan. 12, 7:45 p.m.” snapshot. The agent knows the exact micro-status, what you just finished, and what the “next action” is, allowing it to pick up precisely where you left off with far less hand-holding.
It then consults architecture.md. This is the nonnegotiable technical spec. The agent is less likely to make a mistake such as using the wrong framework. “We use Flask, SQLAlchemy, and PostgreSQL. All database models must include … ”
It follows code_styleguide.md. This is your team’s PEP 8. The agent is bound by rules such as “All functions require type hints” or “Clarity over cleverness: Avoid nested list comprehensions.”
It even reads the prose_styleguide.md. This file defines the project’s voice. The agent knows the “look and feel” the project demands.
Finally, it adheres to workflow.md. This is the “definition of done.” The agent knows it can’t just write code: It must follow the workflow, which might state, “All new features must follow TDD [test-driven development] and achieve >80% code coverage.”
Stop Debugging Your Agent: Start Conducting It
With this level of structured context, “agent drift” doesn’t disappear, but it is dramatically reduced. The agent is far less likely to violate your architecture because it has the architecture file. Its work stays aligned with the master plan because it can read the plan.md and status.md files.
This is the shift we’re observing: a move from developers as simple AI users to developers as sophisticated AI conductors. The context, written in plain markdown and living in the IDE, is the baton.
This signals a change in what high-level development skills look like. The most effective developers of 2025 are still the ones who write great code, but they are increasingly augmenting that skill by mastering the art of providing persistent, high-quality context.
This is a critical trend that we are seeing across the developer platform ecosystem. Products such as AWS Kiro and Claude Skills have these methodologies baked in, as well. Why all this investment in context engineering from developer platform companies? Teams are spending significant time fighting their agents due to the context deficit. While not a magic cure-all, this problem isn’t likely to be solved by a “better” model alone. The solution lies in a more robust, deliberate strategy for managing the context that the model consumes.
If you are wrangling with these problems yourself, schedule a guidance session with me! Let’s talk about what works and doesn’t work in the world of conducting agents that develop software.
