AI development in practice: What does it mean for your business?

4 min read

Today I fixed three bugs in Kiip. It took me 15 minutes in total. (1) I explained the bugs to code agents from my phone, by voice, 2 min. (2) I reviewed the suggested code changes from each of the agents. One of them I could include in the codebase right away. The other two I gave feedback on, 5 min. (3) I checked the two improved code changes; both were good now and were included in the codebase, 2 min. (4) I manually verified that everything worked as it should and deployed to production, 5 min.

A few years ago, for each bug, we would have had to add time to find the bug, fix it, test that the fix worked and didn’t break anything else, and not least wait for a reviewer (another developer) to look over the code and give feedback.

What has changed?

We can break the process down into 5 steps:

  1. finding the bug,
  2. writing the code that fixes the bug,
  3. automatically verifying that the bug is fixed and that no new bugs have been introduced,
  4. manual code review and quality assurance, and
  5. deploying the new code to production (usually already automated).

Steps 1, 2 and 3 consume a lot of resources and consist of idle time in the form of waiting for processes that block the subsequent steps. As a result, even small code changes can require a lot of resources.

If the workflow for collaboration between agent and developer is set up correctly, steps 1–3 can be outsourced to an AI agent, and the developer can take on the role of the reviewer who looks over the code and gives feedback. The reviewer role, which previously made up around 15% of a developer’s time and focus, now becomes the entire job.

In terms of time, it’s not certain that the AI agent does the job as fast or as well as a skilled developer who knows the codebase well. Therefore, code changes may now need to go through the feedback-improvement loop multiple times before the code can be included in the codebase. But at the same time, we save the entire workload of the developer who had bug fixing as their main focus. Keep in mind that most businesses don’t need perfect code. They need code that solves the problem.

What is the result today?

Developers get a lot of time and focus freed up. What previously would have taken up most of the day and been the main activity has been moved into the background.

How should businesses capture this as a gain? Should fewer developers be hired while productivity is maintained, should you increase speed or expand the scope of what is being built? Here are some of the direct consequences today.

IT is no longer an isolated order-taking department

Instead of sending requests to an IT department, the role of the developer will be more closely tied to the business, and expertise at the intersection of technology and business becomes more important. Product developers instead of software developers. This also means the end of giant development teams and heavy coordination processes between developers.

Outsourcing loses its value

There are already many companies that outsource exactly the part of the work that AI agents are good at. I believe that this type of outsourcing — with a reviewer in-house and the coding outsourced — is the most direct process that no longer makes sense. As long as the right AI-assisted development processes are put in place. I see the outsourcing of IT consultants as one of the areas that will be hardest hit by the shift we are now facing.

The future

It is quite possible that the reviewer steps in the future can be taken over by AI in a responsible way. When this happens, the expertise of developers becomes redundant. You no longer need to know how the system works under the hood.

I think a good analogy for this, which may show us what lies ahead, is photography. In the past, only photographers could take pictures, and the process consisted largely of chemistry, technique, and post-processing. Today we have smartphones and everyone can take pictures, without any special knowledge. Everyone became a photographer. But the value shifted. From technical execution to: knowing what is worth photographing, telling a story, choosing the right moment. In the same way, the value shifts from writing code to knowing what should be built. Everyone becomes a developer when the code becomes invisible.

Next time you hire, don’t look for people who are good at writing code. Look for people who are technical, but also understand the business problem, who have an understanding of what is possible and the creativity to figure out what should be built.