AI Agent Use and Engineering Thinking
1. Where I Am Now
My current work includes intensive experiments in personal projects, comparisons across several models, substantial agent involvement in coding, and a more cautious assessment of enterprise adoption.
The question is not simply how to use AI. It is how to bring agents into an engineering system without making them an additional burden.
2. How Agents Participate in Development
I have used agents for backend and frontend work, database schema design, API definitions, refactoring, unit-test generation, and changes spanning multiple files. My working model has moved from treating an agent as an auxiliary tool toward treating it as a participant in collaborative coding.
3. The Cost I Observed
Without strict constraints, token spending could reach around $18 in a day, even on a personal project. Cross-file reading, expanding context, imprecise Markdown instructions, and agents broadening the area they inspect all contribute to that cost.
My working conclusion is that controlling cost starts with controlling context.
4. What Enterprise Work Taught Me
In my previous enterprise environment, the codebase ran to millions of lines. Module dependencies were complex, business knowledge took time to acquire, and many changes involved technical governance.
At that time I used agents conservatively: to generate unit tests, assist with code review, and complete small pieces of code. Humans handled most core implementation. Uncertainty, uncontrolled change scope, and the cost of correcting mistakes made broader use less attractive.
5. A New Set of Engineering Problems
Traditional difficulties included architectural coupling, complicated business rules, and hidden module dependencies. More recently, I have spent increasing effort on the design of agent instructions in Markdown, workflows, knowledge-base structures, MCP integrations, and the organization of context.
Some complexity has shifted from code into the structure needed for an agent to understand the work.
6. The Hidden Maintenance Cost
Documentation needs ongoing maintenance. As the business changes, Markdown instructions need to keep up. Workflows, knowledge-base structures, and constraints also need revision. Otherwise, agents may misunderstand the system, produce inconsistent results, ingest misleading context, and consume even more tokens.
There is a possible cycle:
Faster coding
-> more documentation and workflow maintenance
-> higher maintenance cost
-> reduced or lost productivity gains
The workflow has to be designed so those maintenance costs do not outweigh the coding gains.
7. The Structural Lesson
I now see an agent workflow as more than a coding tool. It is also a system for organizing knowledge and decisions. It has learning, maintenance, design, and iteration costs of its own; at some stages it can be more complicated than the code it supports.
8. What I Need to Improve
- Define the smallest useful set of constraints.
- Avoid excessive documentation.
- Keep the knowledge base easy to evolve.
- Bound what an agent needs to understand for a task.
- Keep documentation maintenance below the productivity benefit.
- Close the feedback loop without adding unnecessary layers.
The goal is for agents to improve productivity without becoming a cognitive burden.
9. A Change in Focus
My focus has shifted from “How do I get an agent to write code?” to “How do I design an agent engineering workflow that remains sustainable?” That is a shift from using a tool to designing the structure around it.