We were fortunate to already have a strong end-to-end test suite written in Python, so we could run the new application against the same tests and verify that the existing functionality was preserved. QA found around 20 bugs, which we fixed pretty quickly before launching.
After the migration, we also moved the application's authentication from Shibboleth to Entra OAuth and deployed it to our OpenShift infrastructure. We couldn't do that with the old WebForms application because our cluster doesn't have Windows worker nodes, so the legacy app had been stuck running on VMs. Getting it onto OpenShift gave us another operational and cost-saving benefit beyond simply modernizing the codebase.
I did this back in January, when the models finally became capable enough for this kind of work. I believe I used GPT-5.2 through Codex. Successfully completing this project is what finally got me fully on the AI bandwagon. I had used AI before, but mostly for smaller tasks like writing code, refactoring individual methods, or making isolated changes.
The application is now modernized, more stable, faster, and more functional than it was before.
I think the project worked as well as it did for two important reasons. First, I had deep domain expertise in both the application and its surrounding systems because I was the original developer. Second, our QA team's test suite was comprehensive enough to validate the functionality that actually mattered. AI dramatically accelerated the work, but there still needed to be someone who understood what the application was supposed to do and a reliable way to verify that the new implementation behaved correctly.
None of this means we couldn't have done the migration without AI. We absolutely could have. The difference is that AI made it possible to do it at practically zero cost in terms of engineering time and money compared with the alternatives.
We had wanted to move away from WebForms for years, but with the size of our team and the constant stream of new feature requests, there was never a realistic opportunity to stop development for months and focus on a rewrite. I estimate that doing the migration myself without AI would have taken at least six months to do properly. The other option would have been hiring a contractor, which I would estimate at $80,000 or more over six to nine months.
Based on my token usage, those roughly 48 hours of working with Codex to port the application cost about $150. Those were January prices, so I don't know what the equivalent cost would be today.
For me, that was the project that changed AI from something useful for assisting with individual coding tasks into something I saw as capable of fundamentally changing the economics of software engineering work.
My issue with this observation is that encoding ourselves into a codebase in the way I described is something our employers did not really get in the past. When you built something for an employer, they got the code and the end product. Sometimes that was a lot, but when an engineer left, they still took their skill set, experience, and judgment with them. Replacing that person was never guaranteed to work out.
Now, though, we are starting to leave behind much more of what made us capable of doing that job or building that product in a particular way. The code is no longer the only artifact. We are also encoding parts of our decision-making process, standards, patterns, and judgment into the systems surrounding it.
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.
Lately, I’ve been thinking more seriously about what AI and automation may mean for my role as a software engineer.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...