Coding Agents in Software Development: 5 Insights from AI-Powered Projects

Key thesis: The bottleneck in the project is shifting.

Coding agents are changing how software is developed. They can implement features, write tests, prepare pull requests, analyze code, and generate documentation. In our projects, we are seeing that AI can now handle a substantial share of routine implementation work.

But faster coding does not automatically lead to faster project delivery. As implementation accelerates, other activities become more important: understanding the problem, clarifying requirements, making sound technical decisions, and validating new features with the people who will use them.

We saw this firsthand in a recent HMS software project. The goal was to rebuild an application landscape that had evolved over roughly 20 years in a complex business domain. Many workflows had grown increasingly sophisticated but were only partially reflected in the existing software. Teams also relied on spreadsheets, files, emails, and separate applications to fill the gaps.

Simply reproducing the existing functionality would not have been enough. We first needed to understand how people actually worked and how those processes should be supported by a new, integrated application.

We did not begin with a fully developed framework for agent-based software engineering. Instead, our approach evolved as the project progressed. Five lessons stood out.

Coding agents can accelerate software implementation, but they also change where teams need to invest their time. Our experience at HMS points to five practical lessons: a clear understanding of the business problem becomes more important as implementation gets faster; early prototypes help teams clarify requirements with users; AI-supported development workflows should evolve in response to recurring problems rather than be designed in full upfront; testing and user feedback must keep pace with implementation; and software engineers increasingly need to combine technical expertise with domain knowledge, communication, and critical judgment. The main takeaway is that companies should not focus solely on generating code faster. They should improve the entire development process, from understanding the problem to delivering a solution that has been tested and validated.

In many traditional software projects, implementation was a major constraint. A requirement might be described in business terms, but translating it into working software still required considerable design and coding effort.

Coding agents can reduce that effort significantly, provided the task is well understood and the system offers sufficient technical guidance.

This changes the balance of work. Implementation can progress faster than the team can clarify requirements or verify whether the resulting features solve the right problem.

Several questions become critical :

• Do we understand exactly what problem we’re trying to solve?

• Have we spoken with the right users?

• Have special cases been clarified?

• Can users test the result in a timely manner?

• Do we know how to tell if the implementation is actually correct?

In our project, the team increasingly needed to spend time on requirements engineering, stakeholder coordination, and technical clarification—activities that had previously taken up a smaller share of the effort compared with backend development.

These activities are not separate from software development. They are essential to making sure that faster implementation produces useful results.

Another change concerns how early teams can put ideas in front of users.

Building a prototype used to require enough time and effort that it was not always practical to create one for every open question. With AI support, teams can develop initial workflows, interface concepts, and working prototypes much earlier.

We used this opportunity to explore existing processes with users and discuss how the future application should support their work. Initial designs and prototypes gave us something concrete to discuss rather than relying solely on written requirements.

That matters because abstract descriptions can leave room for different interpretations. A working prototype quickly raises more specific questions: Is a step missing? Does the sequence make sense? What information does the user need at this point? What should happen in an exceptional case?

A prototype is therefore more than an early version of the software. It is a practical tool for discovering and clarifying requirements.

Our goal is to involve users as early as possible. Instead of waiting months to present a nearly finished application, we want to show initial results, gather feedback, and use it to guide the next iteration.

This is particularly effective when experienced users can test realistic scenarios with their own data. Doing so often reveals details that are missing from tickets and process descriptions.

We did not start the project with a fully defined process for AI-assisted development. Initially, we worked with relatively simple instructions for the coding assistant.

As the project progressed, recurring problems became apparent. Interfaces were implemented inconsistently, architectural decisions had to be explained repeatedly, and routine tasks had to be carried out manually for each pull request.

We addressed these problems incrementally.

We made architectural documentation available to the agents and incorporated Architecture Decision Records more consistently into the development workflow. For larger changes, we introduced a structured sequence of planning, implementation, and testing. We also developed prompts for recurring tasks, such as drafting pull request descriptions and supporting code reviews. Later, we added tools and integrations where they offered clear benefits.

The principle was straightforward: address recurring sources of friction instead of trying to design the perfect development setup in advance.

If an agent repeatedly needs the same architectural guidance, that information should be documented and made available. If code reviews regularly uncover the same issues, relevant checks can be incorporated into the review process. If a repetitive task requires little human judgment, it may be a good candidate for automation.

This approach allows the development workflow to mature alongside the project. It also avoids spending too much time building an elaborate framework before the team understands which problems actually need to be solved.

Faster implementation can create a new bottleneck: features are completed technically but remain untested, await user feedback, or are held up by outstanding decisions.

A coding agent offers little practical benefit if requirements are clarified weeks later or users cannot try new functionality until long after it has been built. The processes surrounding implementation need to become faster, too.

In our project, we involved experienced users early and gave them opportunities to test new features with their own files and realistic scenarios. Their feedback fed directly into subsequent development.

The same principle applies to technical quality assurance. As changes arrive more frequently, reviews and tests need to keep pace. We therefore also streamlined and automated recurring review tasks to reduce the risk of quality assurance becoming a bottleneck.

The relevant measure is not simply how quickly a team can turn a specification into code. It is how quickly the team can move from understanding a problem to implementing, testing, and validating a solution.

Shortening that entire cycle is what turns faster coding into meaningful project progress.

Perhaps the most important change concerns the work of software engineers themselves.

When coding agents can handle a substantial part of implementation, writing code is no longer the only skill that determines how much a developer can contribute. Understanding the problem behind a requirement becomes increasingly important.

Software engineers need to work closely with users, question existing processes, understand the business domain, and recognize when a requirement describes a proposed solution rather than the underlying problem. They must also retain enough technical expertise to make architectural decisions and assess whether AI-generated code is reliable, maintainable, and appropriate for the system.

This combination of domain knowledge and technical judgment is particularly valuable.

AI systems can only work effectively with the context and constraints they are given. Ambiguous requirements can lead to incorrect implementations. Insufficient architectural guidance can produce inconsistent solutions. And without adequate testing and review, faster code generation does not guarantee a better outcome.

The role of software engineers is therefore not disappearing. Rather, it is expanding to include more responsibility for understanding the system as a whole, solving the right problems, and ensuring that AI-generated work meets the required standards.

One project is not enough to establish a universal method for AI-assisted software development. However, our experience has highlighted several practices worth applying and testing in future projects.

Establish a strong understanding of the business domain and involve users early. Use prototypes to clarify requirements before too much implementation work has been completed. Improve the AI-supported development workflow in response to recurring problems. Keep testing, feedback, and business validation close to implementation. And direct the time saved through automation towards the activities that have the greatest impact on the overall project.

For us, that has meant investing more time in requirements engineering, working more closely with future users, and shortening the cycle between an idea, its implementation, and a result that can be tested and validated.

Coding agents do not make software engineering obsolete. They change where engineering effort can have the greatest impact. The central questions increasingly become: What should we build? Why does it matter? And how can we establish that the solution actually works?

For complex software projects, finding better answers to those questions may be one of the most important benefits of AI-assisted development.