Engineering Needs Context, Not Instructions

I believe agentic skills should serve one purpose: documenting how to use external systems that an agent cannot inherently understand or operate correctly on its own.

Everything else is mostly unnecessary overhead.

We work with agents, and they are evolving remarkably fast. In the early days, the biggest challenge was getting an agent to complete a task while behaving in a predictable way. We spent a lot of time defining workflows, writing instructions, setting boundaries, and trying to control how agents approached problems.

It made sense at the time. The models needed that guidance.

Then came models like Opus 5, where the improvement was no longer just about following instructions or writing better code. You could actually feel the difference in reasoning, the ability to connect ideas, understand larger systems, and make engineering decisions without having every step explained.

Something interesting happened around that point.

Many of the practices we had developed to compensate for weaker models started becoming obstacles for stronger ones.

We kept writing larger AGENTS.md files, more detailed skills, stricter rules, and increasingly elaborate workflows. We were essentially trying to moderate the behavior of systems that were becoming better at reasoning through the problems themselves.

In many cases, the result was worse than what the model could have produced with a clear objective and enough context to understand the system.

We were optimizing for controlling the agent rather than enabling its intelligence.

I think this distinction will become increasingly important.

As agents improve, they need fewer behavioral directives and a better understanding of the systems they are working with. The value is shifting from telling an agent how to work toward making sure it understands what we are building, why we are building it, and what it needs to know about the environment.

Give it the external knowledge it cannot reasonably discover on its own. Build a clear mental model of the product, its architecture, and the outcome you expect. Then let the agent reason about the implementation.

This does not mean engineering standards or constraints are irrelevant. Defining workflows and enforcing specific practices still makes sense in governed environments, where compliance, consistency, or organizational requirements demand them.

But outside those constraints, I increasingly prefer a different approach.

Research the problem properly. Understand the product you are building. Establish the objectives and the important boundaries. Then let the agent make engineering decisions, evaluate the results, and iterate.

The responsibility of the engineer is not disappearing. It is moving to a different level.

We need to become better at understanding systems, evaluating technical decisions, identifying meaningful problems, and coordinating multiple engineering agents toward a common objective.

That requires staying close to the technology. Keep your tools and tech stack current. Follow the people building the systems you depend on. Understand how others are using them, experiment with approaches that work, and adapt those ideas to your own environment.

There is little value in repeatedly reinventing solutions that already exist.

Of course, every project has different requirements, and autonomy should reflect the consequences of getting things wrong. But we should also recognize what we have available today.

We are working with systems capable of increasingly sophisticated reasoning. Treating them as rigid automation tools that need every engineering decision prescribed is becoming counterproductive.

The more capable the agent becomes, the more important it is to know what to leave to the agent.

Good engineering is no longer just about knowing how to build something.

It is also about knowing when to stop telling the system how to build it.