I’m a principal engineer at a large organization, and for more than a decade I’ve led a project that has always felt particularly close to me. I wrote nearly every line of code, aside from a handful of features built by interns over the years.
What started as a single application gradually became an ecosystem: a library, APIs, an orchestration layer, CLIs, scheduled jobs, and more. Today, the organization depends on it in some way.
That complexity did not appear all at once. It accumulated over years through new requirements, integrations, edge cases, architectural decisions, and changes in how the organization operates. Each layer solved a real problem, and the knowledge required to understand the system grew along with it.
Eventually, it became too much for one person to manage while also building every downstream feature people requested. So I rearchitected much of it. I retired obsolete components, created a REST API layer, introduced an MCP layer so other groups could build on top of it, modernized CI/CD and testing, and rebuilt or retired user interfaces. The goal was to make the ecosystem easier to extend and reduce my bus factor.
Since January, as AI models have improved, I’ve also moved toward agentic development. I integrated coding agents into the workflow, created specialized agent skills, and wrote detailed AGENTS.md files for the repositories. The codebase has gradually become more than source code. It now provides the models with an encoded record of the system's architecture, constraints, conventions, and history.
The system can help write feature tickets and implement them reproducibly. It produces code grounded in the existing codebase, writes appropriate tests, respects architectural boundaries, and can mount and exercise the underlying library to validate assumptions.
It can also go beyond the repository. It can inspect the database schema, read from and write to the database within defined permissions, and autonomously retrieve application logs while troubleshooting. It can correlate those logs with the code, architecture, and data to investigate failures and validate its assumptions. It has access to many of the same sources of information I use when diagnosing or implementing something myself.
Yesterday, I demonstrated the workflow to a couple of developers from another team who will be contributing to the codebase for a new project.
The harness pulled a ticket, wrote the code and tests while following my constraints and guardrails, opened the pull request, and deployed everything to the test environment within minutes. Our remaining job was largely to review and test it.
It worked as intended, but it also made me think about where this is heading.
Over the past several months, I’ve effectively been encoding more of myself into the system: technical knowledge, architectural preferences, conventions, constraints, problem-solving patterns, and some of the judgment that comes from working on the codebase for years.
The harness now produces work that is often very close to what I would have written myself.
Getting it to this point still required years of domain knowledge, architectural decisions, modernization work, and careful construction of the context and guardrails that make the agents effective. I’m also still the final review gate, and many decisions require broader technical and organizational judgment.
It seems entirely plausible to me that future systems will increasingly be able to study an unfamiliar codebase, identify its conventions and architectural boundaries, construct their own context, and determine the guardrails needed to work within it safely.
If more and more of my knowledge, judgment, and way of working can be encoded into the systems around me, how much longer are they going to keep me around?
For example, I have a '$rest-api-design' skill that acts as a guardrail whenever work involves the REST API. That same skill gets used at multiple stages of the process: when writing the ticket, when designing the feature, during implementation, and again as part of the final review.
A typical workflow might start with a meeting with a stakeholder. The meeting transcript becomes part of the context, and I have a skill that can pull that meeting directly into the harness. I may also provide some additional context about the feature that was not captured in the meeting and ask the agent to write the feature request.
From there, the agent may trigger other skills automatically. One of those gives it access to the project's .NET library. This is a full compiled .NET library, not just a collection of scripts. Since PowerShell itself runs on .NET, the harness can load the library DLLs directly into the shell and invoke their types and methods interactively. In practice, that lets the agent use the library almost like a CLI without me having to build a separate command-line interface for every operation.
That is useful because the agent can call into the same underlying code and abstractions that the application uses. It can use that capability to verify claims made in the meeting transcript or in my prompt, inspect existing behavior, query underlying systems, validate assumptions, retrieve data, or even put together a small proof of concept before it writes the ticket.
Once it has enough confidence in what is being requested and how the system currently behaves, it produces a Jira ticket for me to review. If I am satisfied with it, it can submit the ticket to Jira.
At a later point, I can pull that same Jira ticket back into the harness and ask the agent to implement it. All of the context captured in the ticket comes with it. At that point, the '$rest-api-design' skill triggers again and acts as a guardrail during implementation.
While it is writing the code, it also knows to call another skill I wrote called '$simplify'. That skill encodes a lot of my preferences around code structure, simplicity, readability, and style, so it further constrains how the implementation is produced.
Once the agent believes the work is complete, I can deploy it to test and go through the normal testing process. If everything looks good there, I run the implementation through a review process. That review invokes many of those same skills again to verify that the code follows the architectural, API design, and implementation constraints I have defined. By the end of that process, I usually have something I am pretty comfortable with.
Getting to this point took a lot of time and iteration. I have spent a significant amount of effort refining the skills, the 'AGENTS.md' instructions, the tooling available to the agent, and the context it can access. It also helps considerably that I have deep domain knowledge of the codebase because I built it from the ground up.
The system is not perfect, and I do not expect it to be. When I notice that the agent did something strange or violated one of the constraints, I usually go back and ask it something like, "Why did you do X, and why didn’t skill Y prevent it?"
It can usually give me a useful explanation of how it arrived at that decision and why the existing guardrail did not catch it. If I agree with that reasoning, I update the skill, the instructions, or the guardrail to cover that edge case.
So the process is iterative. When something gets through that I do not like I try to understand why the system allowed it to happen and then improve the harness so that the same class of problem is less likely to happen again. Over time, those failures effectively become new constraints and additional institutional knowledge encoded into the system.
P.S. I apologize for the wall of text.