One year ago, I wouldn’t have been able to write this article. Not because I didn’t have opinions about software development, years and years in engineering leadership will give you plenty of those, but because I hadn’t written production code in years. When I went back to the IDE as a solopreneur, I expected to be slow. I expected to struggle. What I didn’t expect was to become faster than I ever was in my twenties, and I don’t think it’s because I’ve gotten smarter.
The reason is AI coding agents – Claude Code in my case to be precise. And the pattern that runs through everything in this article is simple: I make the decisions, the agent does the work. I am the architect, the reviewer, the quality gate. The agent is the executor, tireless, fast, and unbothered by tedious tasks. Once you internalize this division of labor, you start seeing opportunities to apply it everywhere in your development workflow.
But first, let me show you what a typical interaction looks like, because if you haven’t worked with a coding agent yet, the rest of this article won’t make much sense otherwise:
- Developer enters into the terminal:
Take a look at issue #94 - Agent pulls the issue from GitHub, reads the task including all comments, pulls any attached mockups, and makes a plan how to implement it. Then asks one or two clarifying questions.
- Developer answers the questions, reviews the plan, maybe adds a remark or two, points the agent to a piece of code or documentation to include. Then approves the plan.
- Agent does all the implementation, usually in one shot. The developer works on something else in the meantime, often a different issue with a different agent instance.
- Developer tests everything thoroughly, makes sure the data structures and migrations are correct, reviews the implementation, verifies automated tests are covered. Then tells the agent to commit, push the change, and close the GitHub issue with a summary of what was done for QA.
That’s it. The entire cycle. I decide what gets built and whether it’s good enough. The agent handles the how. This pattern repeats across every single area I’m about to walk you through, from research to documentation, from architecture to security.
Here’s what we’ll cover:
- Technology Research and Evaluation
- Creating and Closing Issues
- Sprint Ceremonies, Status Reports, and Meeting Prep
- Architecture and System Design
- UX and UI Design
- Taming Legacy Code
- Code Reviews, Security Reviews, and API Reviews
- Automated Testing
- Updating Libraries and Dependencies
- Runbooks and Documentation
1. Technology Research and Evaluation
Starting a new project, picking a technology, choosing a hosting provider. All of these used to involve hours of Googling, reading comparison blog posts of questionable quality, and asking around in your network. Don’t get me wrong, asking people you trust is still valuable. But the initial research phase? That has gotten dramatically faster.
When I started my own business, I needed infrastructure that fit me as a solopreneur. It couldn’t cost the world, and it had to not stand in my way but accelerate me instead. When I brainstormed this with Google’s Gemini, it suggested Coolify, a self-hosted PaaS I had never heard of. It fit my requirements perfectly, and I now have an environment that does a lot of the heavy lifting without the usual DevOps headaches. Would I have found Coolify eventually through my own research? Probably. But instead of half a day of reading comparison articles and Hacker News threads, I had a shortlist in fifteen minutes and a running instance by the afternoon.
The point isn’t that agents replace your judgment. They don’t. But they give you a solid, well-structured foundation to make decisions on, at a fraction of the time it used to take.
2. Creating and Closing Issues
I don’t write issues anymore. Whenever new requirements come up, from whatever direction, I put them into Claude Code in rather unstructured form and ask it to make sense of them, create an issue for me to review, then push it into GitHub.
And I don’t close issues anymore either. When implementation is done, tested, and reviewed, Claude writes the closing comment, documents what was done, and closes the issue. Same with commit messages, by the way. I haven’t written one in months. The agent sees the diff, understands the context from the issue, and writes a message that is usually more descriptive than what I would have produced myself.
This might sound like a small thing, but it adds up. Writing good issues is important. Your QA people need something to test against, your team needs clarity on acceptance criteria. But it’s also not the most fun task in the world. By decoupling the work of creating issues from working on them, I get well-structured tickets without the overhead. Win-win.
3. Sprint Ceremonies, Status Reports, and Meeting Prep
Whether it’s preparing for a daily standup, a sprint review, or a backlog grooming, taking a bunch of issues and summarizing them, sizing them, or reviewing them used to be tedious. That has changed completely.
Why play planning poker if, in the same time, Claude can create a complete implementation plan that makes the resulting estimate way more accurate than what I could produce in a few minutes of discussion? Why not ask Claude to write your weekly status report, if your company still demands one from you, in which case, to be honest, you might have a problem that an agent cannot help you with 😊. Why not ask for the best way to demo the features the team worked on last sprint, and get a script to follow?
I remember spending more than an hour every other week creating a release mail for my team’s stakeholders. One prompt and two minutes of work is all it takes now.
Or here’s one for your Scrum Master: have the agent pull a list of closed issues since yesterday and summarize them, along with the long-running ones, so you can focus in the daily on whatever is required to actually reach your sprint goal, rather than talking about things that make you feel comfortable. If you want to understand why I feel so strongly about this, have a look at my article about why your sprints might be a coin-flip and what the Scrum Master’s actual job should be.
All of these tasks can be handled by agents today, and all of them free up humans for the work that actually matters.
4. Architecture and System Design
Architecture is supposed to be the deeply human, creative part of software engineering, and it still is. But agents have become remarkably useful as a sparring partner.
I use them the way I used to use a whiteboard with a fellow architect. Should we go with event-driven or request-response here? What are the trade-offs of splitting this service? How does this design hold up under 10x load? The agent won’t make the decision for you, but it will lay out options, poke holes in your thinking, and force you to articulate your reasoning.
What I’ve come to value most is using agents to document decisions in Architecture Decision Records (ADRs). You’ve just had a 15-minute back-and-forth about whether to use a message queue or direct API calls. Instead of letting that reasoning evaporate, ask the agent to write it up as an ADR, capturing the context, the options considered, and the rationale for the choice you made. No more excuses for undocumented architecture decisions.
Of course, this doesn’t always go smoothly. Once we get past the design phase and into concrete implementation, I find myself pressing “stop” maybe once or twice a day, telling Claude it’s going in the wrong direction, adding data to the wrong entities, copying code again when it should refactor, or forgetting for the tenth time that it should not commit before I can review. But considering how much value I create every day now, I find this more than acceptable. The agent is not perfect. It is, however, extraordinarily fast, and correcting its course is still much quicker than doing everything myself.
5. UX and UI Design
UI and UX design used to be a super-specialized discipline that could eat enormous amounts of time. Designers spent days creating pixel-perfect mockups in Figma so developers could stop worrying about how things should look. Those times are changing, at least if you have the skills to recognize good UI when you see it.
One of the most valuable things I’ve done is using an agent to create a component showcase, a living document of all your UI elements with the right documentation and usage examples. This used to take a developer days or weeks. With a bit of guidance, an agent can produce one in a couple of hours.
And the showcase pays dividends far beyond documentation. Without one, agents will invent an entirely new solution every time you ask them to create a feature. This sounds fine in theory, until you realize you’ve built an incoherent mess that is extremely hard for anyone to use. Users like a consistent experience, where things follow the same patterns over and over. It makes them feel in control, makes them feel at home. Having a showcase to lean on means you can always pull the agent back into familiar territory, pointing it to established patterns rather than letting it invent something new every time. Consistency by design, not by accident.
The caveat: you still need taste. An agent will produce a UI that is technically functional but aesthetically questionable. Knowing what good looks like, and being able to steer the agent there, is the human skill that matters here.
6. Taming Legacy Code
Here’s a dirty secret of our industry: most developers hate working on legacy code. The complaints are always the same. “Nobody understands this anymore.” “There are no tests.” “Whoever wrote this is long gone.”
Agents don’t care about any of that.
For them, there is no bad code. There is no “this is too complex.” They will dig into a codebase that nobody has touched in years with the same enthusiasm they bring to a greenfield project. They’ll trace dependencies, understand patterns, identify what the original developer was probably trying to do, and then refactor it into something maintainable. In minutes. Or hours at most.
This makes agents extraordinarily valuable in a space that used to be one of the biggest time sinks in software engineering. That migration everyone has been putting off for two years? The module nobody wants to touch? The service that “works but nobody knows why”? Point an agent at it. It will not complain, it will not drag its feet, and it will not ask for a raise before agreeing to look at it.
As I’ve written before, the “legacy code myth”, the belief that your codebase is too complex for AI, is exactly that: a myth. With just a little guidance, agents can navigate complex architectures and execute changes in 30 seconds that might take even an experienced engineer a week.
7. Code Reviews, Security Reviews, and API Reviews
I remember how long a good code review used to take. And how little fun they were.
Today, specialized tools exist for this, or you just use whatever agent you have available. Claude Code, for example, will take on a task like “review the last commit from user Alex according to our coding standards” without hesitation. This is a massive time-saver, as it lets you focus on the parts of the code that really matter: the architectural decisions, the business logic, the edge cases. All the usual “this variable doesn’t follow our naming convention” chatter is handled (and ideally fixed on the spot) by an agent.
But it goes further. Here are two prompts I’ve come to value a lot:
“I need you to do an API review for our backend. What are the industry-standard things to check? Create a checklist, let me review it, then work through it for all of our endpoints.”
“I need you to do a thorough security review. Come up with a checklist based on industry standards and OWASP guidelines. Let me review it, then work through it.”
Gone are the days where you needed to be a prompt engineer to get useful results. Modern coding agents have become very good at understanding what you want. My cheat code: whenever I don’t know enough about a topic myself, and that happens a lot, I ask for the industry-standard way to do it. I learn something along the way every time.
Something that used to take days to do correctly will now be done in minutes. I remember having endless risk-management discussions about which security risks I was willing to accept in my role as CTO. Now, my advice would be very different: “I don’t want to discuss this, just fix it.” How the times have changed, at least for companies who have welcomed coding agents into their workflows.
8. Automated Testing
I could cry when I think about all the precious time in my life I have spent writing automated tests.
Writing good tests, choosing the right amount of testing on the right level of the testing pyramid, isolating edge cases worth spending time on with dedicated tests. All of this can be complicated and drain a lot of developer time.
Here’s what it looks like now: building my last QA strategy took less than an hour. Implementing the first unit tests, integration tests, and end-to-end tests, two hours in total. After just a couple of days of continuously asking for tests to be added to every new feature or change, I was at over a thousand tests, without feeling the pain. If you have never experienced this, trust me: the first time you do it will leave you in awe.
Modern coding agents are extremely good at test automation. With just a little bit of guidance, they won’t just create tests but also build a QA strategy that makes sense, set up the right tooling, write the tests, run them, fix any issues that come up, and help you deploy them. The excuse of “we don’t have time for tests” no longer holds, because the time investment has dropped by an order of magnitude or two.
9. Updating Libraries and Dependencies
Especially when working with the usual suspects in web development. JavaScript, React and Node, I am talking about you. Every month, or at most every quarter, a dreadful task awaits: updating your dependencies. This is as unfun a task as it gets, because after tedious hours of work, the only visible change should be an increased version number in your package.json.
And how much work that can be. I remember situations where developers worked on a single dependency update for weeks. These days? Piece of cake.
If you’ve followed my previous advice and invested a bit of time into test automation, all that’s needed is a git worktree to create an undisturbed workspace, and then ask your agent to do the update, compile, run the linter, run the tests, and fix all issues that come up. In my experience, 9 out of 10 times it will do the upgrade for you without breaking a sweat. It might take some time, sometimes even a few hours, but you can work on something else in the meantime and leave the agent alone in your local branch. Happy times.
10. Runbooks and Documentation
When you’re introducing DevOps, or really any other major change to your processes, it is usually a good idea to invest time into documentation and runbooks. The only problem: nobody likes to write them. And therefore, it’s very hard to get good ones.
Enter your friendly neighborhood coding agent. Ask it to analyze your codebase and your deployment documentation, which you hopefully have, and if not, ask to create that first, and produce a runbook according to industry standards. The agent will churn through whatever documentation it can find, cross-reference it with your codebase, maybe ask you a couple of questions, and then give you a runbook that is probably not perfect but more than good enough to start with.
All of that in a couple of minutes, instead of days. Isn’t it lovely to be a developer right now?
What’s Next
If you take one thing away from this article, let it be the pattern: you decide, the agent executes. Not the other way around. The moment you flip that relationship, or worse, stop paying attention entirely, quality goes downhill fast. I know this from personal experience, and I’ll write about that in my next article, where I’ll explore how working with agents has changed not just what I do but how I work, including the traps I’ve fallen into along the way.
For now, if you haven’t tried working with a coding agent yet: just start. Pick the most tedious task on your backlog, the one nobody wants to touch, and hand it to an agent. You might be surprised how much of your day you can reclaim.
And if you’re a CTO or engineering leader and this resonates but you’re not sure where to start with your team, I’ve been through this transition myself and I’ve helped others navigate it too. Feel free to reach out.
