A few years ago, a typical development day for Mikael Grön at Elastx looked much like it did for many developers. VS Code on the screen, the codebase checked out locally and a test environment running alongside it. Write code, save, test, debug and discuss solutions with colleagues. “You basically had to keep the entire codebase in your head. You knew exactly how everything worked. It required your full focus, otherwise you wouldn’t get anything done,” says Mikael. Today, his working day looks very different. Mikael no longer writes any code himself. “I literally haven’t written a single line of code since March. Not one.”
Instead, he works with AI agents that write, test, review and improve code, and that can also collaborate with each other. Mikael describes his own journey as going from being a programmer, to a programmer with autocomplete, and then to a programmer with a code review partner in a chat.
“Then I pretty quickly became a middle manager, telling my ‘employees’ what to do. Now I’m more like a middle manager with another middle manager below me.”
He says it with a smile, but it is also a fairly accurate description of how much his job has changed in a short period of time.
From autocomplete to agents
The first steps were relatively simple. Autocomplete in VS Code was followed by ChatGPT as a sounding board. Mikael could paste in some code, ask why something wasn’t working, get a suggestion back and try again.
“Sometimes you had to go back and forth ten times before it worked.”
When Claude Opus 4.5 arrived towards the end of 2025, things accelerated further. Mikael started using Claude himself in late January and quickly moved from using AI as an assistant to letting agents handle increasingly large parts of the development process.
But that also created a new problem. As AI wrote more of the code, Mikael found himself spending more time reading code written by someone, or rather something, else.
“Instead of sitting there writing all the code, you end up sitting there reading all the code. And that’s harder.”
When you write code yourself, you build an understanding of it as you go. When AI produces the code, that control has to be created in other ways. For Mikael, testing, reviews and verification have become central to the way he works.
An agent can make a change, run the tests, discover that something has broken, correct the code and test it again. In web development, visual testing is also used, allowing AI to analyse screenshots and identify issues with things such as layout and readability.
“The AI can make mistakes, but they don’t make it into production.”
Human responsibility, however, does not disappear.
“If I write and read the code myself, I’m responsible for it. When I tell AI to do something, it can feel as though that responsibility disappears. But it’s still my responsibility.”
From a month to a day
Elastx.se is a concrete example of how significant the difference can be. Previously, a change could involve several days of coding, testing, discussions and refactoring. Today, the process can start with a ticket or feedback submitted directly from the website and then be taken forward by agents working on the code, tests, visual checks and reviews.
That does not mean everything is automatically pushed into production. Elastx.se still has review and release processes that deliberately slow things down where necessary. But the difference in how much can be accomplished is substantial.
“The entire pipeline that might previously have taken us a month can now be done in a day. And that’s probably an underestimate.”
More than a coding assistant
Using an AI assistant for programming is no longer particularly unusual. A developer can install Claude Code or a similar tool and get quite far on their own. At Elastx, the question has therefore increasingly become how to build an environment around the models that makes agent-based work possible in a secure and scalable way.
An important part of that work is what is internally known as Boxen. Here, agents work inside isolated sandboxes rather than directly on employees’ computers. This creates a more controlled environment, while also making it possible to give agents access to shared resources and make tools developed by one person available to others.
For example, agents can access information about Elastx’s infrastructure and codebases, as well as documentation for the open source software the platform is built on, including OpenStack and Kubernetes.
“We get a distributed but shared workspace for AI-assisted work,” says Mikael.
Boxen also allows agents to work together across different codebases. Mikael describes how he can start a chat with two coding agents, each responsible for a separate but interdependent codebase, and give them a shared task with a single instruction. From there, the agents can divide up the work themselves, discuss dependencies and agree on how to solve the problem.
“They talk to each other, and the models have turned out to be very good at dividing up work, communicating needs and solutions, and quickly resolving issues. It’s incredible to watch.”
Claude, Kimi and GLM side by side
At the same time, Elastx has been working on another part of the equation: the models the agents use. When the company began developing AI as a Service, it quickly became clear that the smaller open models available at the time were not good enough for more complex tasks such as programming.
That has changed quickly. Today, Elastx runs models including Kimi and GLM on its own hardware. They are used extensively in our internal sandbox environment and in other AI services such as Elxa, our AI assistant built around Elastx products and documentation, while Claude remains an important and widely used model. The point is not to stop using Claude. It is about not building the entire way of working around a single model or provider.
“Even though we still use Anthropic, open models are steadily taking over more and more of our internal AI workloads,” says Mikael.
For Elastx, this provides greater freedom to choose the right model for the task and reduces dependence on individual AI providers’ pricing, availability and future direction. It also makes it possible to run an increasing share of AI workloads on Elastx’s own infrastructure.
The developer is still there, but the job looks different
The fact that Mikael has not written a single line of code since March does not mean he has stopped developing. Someone still needs to understand the problem, define the requirements and decide what should be built. And someone needs to decide how the agents should work.
Mikael describes it as a balance between what should be handled through instructions, what should be built as tools, and which parts of the process need tight control. Other parts work better when agents are given more freedom to find their own way forward.
This is not knowledge that came from a ready-made manual. The way of working has developed through experimentation, mistakes and Mikael’s previous experience as a developer.
At the same time, more people at Elastx are starting to use the agent-based environment. As the tools expand beyond developers to teams such as Ops and Business Development, new questions emerge. An interface that feels obvious to a developer may not feel intuitive to someone else. Mikael points out that this is essentially a classic UX problem: how do you make something easy to use without removing the capabilities that make it powerful?
The experience gained from this internal work is also helping shape Elastx Code, the working name for the AI-based development environment Elastx is now building.
In the next part of this article series, we take a closer look at why Elastx wants to build this kind of AI infrastructure under its own control, and what open source, freedom of choice and digital sovereignty mean when AI becomes part of the development environment itself.