The main challenge was rewriting a 15-year-old legacy ASP.NET WebForms application into an ASP.NET Core 8 backend with a Vite, React and TypeScript frontend.

The language versions were old, the stack was old, and everything was built around legacy technologies I had never worked with before. Translating that application and pulling out the business logic was the main bottleneck to even begin the project.

A couple of years ago, there was an attempt to convert this project into an ASP.NET backend and Angular SPA frontend, but it failed because of the complexity of the application and the system it was sitting on.

Well, let’s start with where AI agents didn’t come in yet.

For AI agents to work, they need a clear vision of what they’re going to build. And it looked to me like this project also needed a clear path from the beginning to the finish line.

Since the application had been in production for 15 years, I couldn’t just jump in and translate page by page without a complete vision, or a proper architecture that respects the system it’s built on.

So I used Claude to map the legacy application into an Obsidian-compatible vault. It held the contracts, pages, APIs, design system, glossary, user journeys, business logic and other necessary information.

Once I had the whole thing mapped, a running application on my machine, and an approved stack to build on, I created a short list of high-level tasks, some architecture diagrams and documents with the help of AI agents.

After a few rounds of review, we were able to lock in the frameworks and libraries we were going to build with.

Finally, I could set up the project and start translating. And this is where I started using AI agents to build it.

The reason I’m saying all this before talking about AI agents is that the way software is built hasn’t changed. We’re still working in the same languages, on the same frameworks, and we’re still building software for humans. AI agents have accelerated our development speed.

As software engineers, our job is to build software that lasts, that can endure failures, and that can be easily fixed when something goes wrong. We also need to make sure the code is readable and understandable to someone who comes to rewrite it 20 years later.

I’ve seen quite a lot of tools that help with coding with AI agents. There are role-based, spec-based and many other agentic development systems.

For someone like me, who has been a full-stack engineer from the beginning, the spec-based approach made more sense. But what I used to rewrite this application is a blend of role-based agents and spec-based skills. Let me elaborate.

I’ve built the adlc-toolkit, the Agentic Development Life Cycle toolkit, which has 18 skills and 13 agents.

Each request goes through a five-phase pipeline:

1. Spec
2. Architect
3. Implement
4. Review
5. Wrap up

Each phase calls out to different sub-agents to perform the task it’s given.

For smaller tasks, it runs a lighter three-phase pipeline: plan, implement, then review and ship.

The toolkit also creates an Obsidian-compatible vault inside the code repository, where it stores memory, the decisions made, and updates about tasks.

I think agents are doing fine as they are, if they’re given the right commands with proper context. The adlc-toolkit handles this very effectively.

Before spinning up any sub-agent, the main agent gives it enough context, a proper goal, and details about how to execute and how to report back once it’s done.

The validation model is pretty simple with how the toolkit is designed. After each step, it provides a summary of what has been done and what’s left. So my job is to make sure those are right.

So now I had the plan for the project ready, the legacy app mapped into an Obsidian vault, and an agentic development tool ready to work.

Every day when I start work, I run /status, which tells me what I’m working on, what’s been done and what’s next. I pick the task for the day and run the whole pipeline with the /proceed command.

The first thing it does is understand the request. It spins up a codebase-explorer agent, then asks me questions about what I want to work on and how I want to build it, with its own suggested approach. Then it writes a spec file for that task.

After I approve the spec, it moves to the architect phase. It searches the codebase again for all the related files and functions we may touch and creates a plan based on the facts it has.

It also runs an architecture-adversary sub-agent that questions the decisions before they reach me.

Once the agents have finalized the architecture and planned the request, it asks me to approve or revise the plan. After reviewing, I can ask for changes or approve the plan, and the implementation phase begins.

In the implementation phase, a number of sub-agents are spun up. They work either sequentially or in parallel, depending on the task dependencies.

Once that’s finished, the review phase begins with its reviewer agents:

• reflector
• architecture-reviewer
• quality-reviewer
• correctness-reviewer
• ui-reviewer, when necessary

Each reviewer agent is told to act as an independent reviewer, to be a critic of the work while respecting the conventions and rules followed by the repository.

They show me the issues they’ve found, what’s not working and why. Then I run another round of implementation for those fixes. It reviews again and finally moves to the wrap-up stage.

The wrap-up skill handles everything after implementation: it commits the changes, creates the pull request draft, updates the docs, and makes sure everything is aligned and documented in the codebase.

I don’t write code by hand anymore, but nothing goes into my code without me knowing.

A few small bugs appear now and then, but that’s normal and expected.

Now, this is exactly how I used to work before AI came along, except that now AI agents are finding and writing much faster than a human.

Well, from my experience, it used to take around a month to deliver 3,000–4,000 lines of code. And it’s not just delivering the code. There’s planning, finding bugs, maintaining conventions and docs, and so on.

Now I can deliver a 4,000-line pull request in two days with this adlc-toolkit, with the same confidence.

Look, I can’t give you exact numbers, but I’ve finished this project, with new features that weren’t in the legacy application, in less than three months.

And I’m a workaholic, so you shouldn’t compare others to me based on output.

But I can say that everyone on that side was very surprised and impressed with the speed I delivered at. They hadn’t even planned the next steps when I started delivering features.

It was a new project, and I was experimenting with AI to get the best outcome in the shortest amount of time.

And since I didn’t have to reinvent any business logic here, only the application layer, I was able to deliver much faster than I initially thought.

That said, I think without AI agents, it would have taken me about a year and a half to complete the work I’ve done in the past three months.

Look, anyone who has watched some construction work can build a house by themselves. But an architect will measure, analyze and design, and only then start laying the groundwork before building.

So the engineering work still needs to be done.

You can’t vibe code a production-grade application that’s going to be used by major broadcasters around the world. The problem with vibe coding is that you think after you do. But like we’ve always been told, it’s better to think before doing. That’s the engineering part.

AI agents are gathering information and executing commands in the fastest way we’ve ever seen.

It’s our job to use our engineering knowledge and experience to get the best out of this tool called AI by harnessing its capabilities.