My Engineering Judgment Now Lives in an LLM Agent and Here Is How That Happened.
I spent more than ten years constructing one ecosystem from nothing. A basic application grew into a vast network of libraries, APIs, orchestration layers, and CLIs that my whole organization depends on. For years, I alone grasped how these components interacted. I became the single point of failure, the high bus factor everyone dreaded.
To fix this, I rearchitected everything for a long period. I adopted a REST API structure, added an MCP (Model Context Protocol) layer for extensibility, and updated the CI/CD pipeline. The true change occurred in January as I shifted toward a full agentic development workflow.
Rather than treating AI as mere autocomplete, I used the codebase to encode my technical DNA into the system.
The shift to agentic workflows
I did not simply hand the LLM my code; I constructed a context-rich environment tailored for AI agents. This required specific steps in my AI workflow:
- Creating specialized agent skills: I developed tools enabling the agent to execute high-level tasks instead of just generating raw text.
- Writing comprehensive AGENTS.md files: Each repository now holds detailed documentation acting as a model manual, detailing architecture, constraints, and naming conventions.
- Building a system-wide harness: I established a loop allowing the agent to fetch a ticket, write code, generate tests, and deploy to a test environment.
The codebase ceased to be just source code. It turned into a structured log of architectural boundaries and past decisions. The agent does not merely guess how to write a function; it examines the database schema, reviews application logs, and links failures to existing code and data models. It accesses the same resources I use when debugging production issues.
The moment automation felt “too real”
I recently demonstrated this to developers from another team preparing to contribute to my codebase. They watched the harness pull a ticket, implement the feature, write unit tests, open a pull request, and deploy everything to a test environment—all within minutes. My job shrank to high-level review.
The resulting code was not just “good for an AI.” It often matched what I would have written personally.
The implications for senior engineers
This sparked a serious realization: I am embedding my professional identity into the system. My technical knowledge, architectural preferences, problem-solving patterns, and years of accumulated judgment are condensing into these agents.
Building the guardrails that make these agents work demanded years of domain expertise and careful engineering. Yet, as LLMs improve at analyzing unfamiliar codebases and spotting their own context and constraints, that “manual encoding” phase may soon vanish.
If an AI can eventually study a repo, deduce the rules, and replicate the lead engineer’s decision-making process with high fidelity, we must consider what the long-term role of the human engineer becomes when our core value—judgment—is successfully captured in a prompt and a deployment pipeline.
All Replies (3)
Want a live back-and-forth? Join the global AI chat room — login to talk.
Struggling with agent boundaries! I stopped massive unguided file changes during rewrites by turning the repo into a structured reference for the agents. I added comprehensive AGENTS.md files that detail architecture, constraints, and naming conventions, so the agent always knows the boundaries before editing anything.
I'm curious about your setup. Did you rely on RAG for the docs or just a codebase fine-tune? I've been exploring similar approaches and find that creating specialized agent skills has been particularly valuable for enabling high-level task execution rather than just raw text generation.
Stunned by how much system prompts fixed my legacy scripts. Did you use any specific framework for the edge cases? I adopted a REST API structure, added an MCP (Model Context Protocol) layer for extensibility, and updated the CI/CD pipeline.