This note summarizes part of an ongoing research project on architectural description languages for software engineering and machine learning systems.

For one project, I set a clear rule: I would use ISO 42010-style architectural descriptions to specify the system, but all implementation would be done by AI agents. My goal was not to test “no-code” marketing claims. Instead, I wanted to find out what architectural discipline is still needed when generating code becomes easy.

The answer was not that architecture becomes less important. It becomes more important. The less code the architect writes directly, the more the quality of the result depends on the quality of the abstractions, constraints, and recovery loops supplied to the agent. The following five lessons emerged from that process.

Treat Instructions as Architecture

An agent does not experience an instruction file as a note to be skimmed. It experiences it as part of the operating environment. Files such as AGENTS.md therefore behave less like documentation and more like a lightweight constitution for the system-building process.

In practice, this means that vague human intention is an unstable control mechanism. Agents perform best when instructions define responsibilities, boundaries, naming conventions, review expectations, and failure conditions explicitly. The prompt is not enough. Durable agent behavior requires persistent architectural context.

Generated Code Reflects the Quality of the Model Supplied

People often say AI-generated code shows how good the model is. In reality, it also shows how disciplined the input is. If the architectural model is weak, unclear, or inconsistent, the generated system has generic and average patterns. If the model is clear, specific, and well-structured, the output improves too.

This is the tough truth at the heart of agentic coding. Weak architecture cannot hide behind a strong model for long. The agent makes clear ideas clearer but also makes confusion more obvious.

Autonomy Requires Recovery, Not Just Automation

Many teams think they have more autonomy than they do because they mistake a successful first try for reliable execution. The real difference is handling errors. Scripts automate a known process. Autonomous agents are truly useful only when they can spot failures, adjust their plan, and keep going within set limits.

In my work, things improved only when I treated failure handling as a key design problem. What matters is not if the agent can produce code once but whether the system around the agent can detect problems, maintain its state, and resume work without losing track.

Context Engineering Depends on Selective Forgetting

A common mistake in agent workflows is keeping too much context. Old conversations, outdated decisions, and unused branches pile up, leaving the main task unfocused. The practical solution is to forget things on purpose, rather than trying to remember everything.

Ticketing systems helped with this. Finished work was saved as lasting records, and the agent was told to focus on the next task. This reduced context overload and made it easier to see where tasks begin and end. Good context engineering is less about adding information and more about choosing what stays active.

Established Engineering Vocabulary Still Matters

Agentic coding does not make older engineering terms useless. In fact, it often makes established vocabularies even more valuable. Standards like ISO 42010, design patterns, and other well-known frameworks provide agents with clear, well-defined meanings to follow, reducing confusion compared to made-up terms.

This is important because agent quality depends on having a solid base. When prompts use well-known concepts, the model is more likely to produce clear patterns and less likely to wander into vague or unhelpful ideas.

Conclusion

The main lesson from this experiment is clear: agentic coding does not remove the need for architecture, governance, or careful abstraction. It just changes where that discipline is needed. Instead of being mostly in hand-written code, it must also be present in instructions, interfaces, task boundaries, and recovery planning. That is why AI agents often seem like mirrors. They do not just expand what engineers can do. They also reveal the strengths, limits, and gaps in the engineering model they are given.