I encoded my own engineering judgment into an LLM agent and it's

I’ve spent over a decade building a single ecosystem from scratch. What started as a simple application has morphed into a massive web of libraries, APIs, orchestration layers, and CLIs that my entire organization now relies on. For years, I was the only one who truly understood how all these moving parts fit together. I was the single point of failure, the person with the high "bus factor" that everyone feared.

To solve this, I spent a long time rearchitecting everything. I moved to a REST API structure, introduced an MCP (Model Context Protocol) layer for extensibility, and modernized the entire CI/CD pipeline. But the real shift happened in January when I started moving toward a full agentic development workflow.

Instead of just using AI as a glorified autocomplete, I began treating the codebase as a way to encode my own technical DNA into the system.

The transition to agentic workflows

I didn't just feed the LLM my code; I built a context-rich environment designed specifically for AI agents to navigate. This involved several key steps in my AI workflow:

1. Creating specialized agent skills: I built tools that allow the agent to perform specific, high-level tasks rather than just raw text generation.
2. Writing comprehensive AGENTS.md files: Every repository now contains detailed documentation that serves as a manual for the model, outlining architecture, constraints, and naming conventions.
3. Building a system-wide harness: I created a loop where the agent can pull a ticket, write code, generate tests, and deploy to a test environment.

The codebase is no longer just source code. It has become a structured record of architectural boundaries and historical decisions. The agent doesn't just "guess" how to write a function; it inspects the database schema, reads application logs, and correlates failures with the existing code and data models. It uses the same information sources I use when I'm troubleshooting a production issue.

The moment the automation felt "too real"

I recently demoed this to a group of developers from another team who were about to start contributing to my codebase. I watched as the harness pulled a ticket, implemented the feature, wrote the unit tests, opened a pull request, and deployed the whole thing to a test environment—all within minutes. My role was reduced to a high-level reviewer.

The code it produced wasn't just "good for an AI." It was often indistinguishable from what I would have written myself.

The implications for senior engineers

This realization brought a heavy thought to the surface: I am effectively encoding my professional identity into the system. My technical knowledge, my architectural preferences, my problem-solving patterns, and my years of accumulated judgment are being distilled into these agents.

It took years of domain expertise and careful engineering to build the guardrails that make these agents effective. However, as LLMs get better at studying unfamiliar codebases and identifying their own context and constraints, that "manual encoding" phase might become obsolete.

If an AI can eventually study a repo, figure out the rules, and mimic the lead engineer's decision-making process with high fidelity, we have to ask ourselves what the long-term role of the human engineer becomes when our primary value—judgment—is successfully captured in a prompt and a deployment pipeline.