How software engineering is changing: a product company perspective

Last month, I took part in the Pragmatic Engineer essay challenge. I decided to write about my experience as an employee of Camunda and a member of the bpmn.io project.

How software engineering is changing: a product company perspective🔗

One year ago, I was full of doubt regarding the usage of GitHub Copilot beyond smart autocompletion. I preferred to write code by hand, because I was not satisfied with the generated one. Fast-forward one year, I rarely write code by hand. Most of my code work is done by an agent.

I work as a senior software engineer and a tech lead of the Core Modeling team at Camunda. My tenure at the company has just surpassed 8 years, and I have seen it transform several times since I joined it as an associate engineer back in 2018. The current agentic wave is yet another such transformation, perhaps comparable in the impact to the transition towards a global, remote-first company (yes, we have never returned to offices after covid).

Camunda is a product company. We build and offer our own enterprise platform for agentic orchestration. Our product allows companies to orchestrate humans, systems, and AI agents across business processes. In the very recent The Forrester Wave: Adaptive Process Orchestration Software, Q3 2026, we were named a Leader. Camunda helps enterprises to join the deterministic side of business processes with the indeterministic nature of agentic systems. We build technology to tame and adopt AI, but at the same time are also affected by the AI wave going through the industry.

The product’s notation for modeling business processes is an open standard of BPMN. BPMN is also the point where my team comes to play. We are a team built around the mission of making BPMN available everywhere, for everyone. We build in public, and most of our work is either open source or available under a permissive license of the bpmn.io project. With our modeling solutions one can model business processes to run on Camunda, but the use of the libraries is not limited to the company product (Camunda is not open-source though). They have been also used in purely modeling solutions or as an education tool. Besides the JavaScript libraries composing our core projects: bpmn-js, dmn-js, and form-js, we maintain and develop an Electron-based desktop application: Camunda Desktop Modeler. The application enables a local-first modeling of business processes. The team’s codebase consists of over 100 public repositories on GitHub, and around 20 of them are developed on a day-to-day basis, also via external contributions.

There are several aspects that have changed within the year regarding both the work at the company, and the open-source project that I am a member of. I would like to first present the company perspective.

As with any change in the industry, one can try to oppose it or embrace it. At Camunda, we decided on the latter. How was it rolled out? Initially, the AI tool available to all engineers was GitHub Copilot. This came natural as GitHub is the central place for the development within the company. Then, the early adopters of AI started using alternative solutions like Claude. The company supported the experiments, so we were able to get early experience.

Then, the decision to go all in was announced. We have decided to become an AI-first company. Everybody at the company got access to AI tools with Claude as the most notable of them. The engineers retain access to GitHub Copilot, so there is no vendor lock-in. Usage of AI is endorsed with a clear policy to mitigate risks. Worth noting, the adoption of AI within engineering came naturally. We did not need token-maxing or token usage leaderboards to start using AI tools. We realized that the new technology helps us to be successful, so we did not resist it. The main driver of adoption was autonomy: you could experiment with AI, but nobody imposed it on you. That, joined with curiosity of the engineers, was enough to adopt the agentic tools.

Within a couple of months, we transformed from a company where code is written by hand, sometimes with the help of the AI autocompletion, to one where the natural medium to produce code is Claude Code or GitHub Copilot. AI tools are present at several stages of the software development lifecycle.

The initial research and idea validation is often aided by a conversation with an agent. There is no silver bullet way to solve that part as the problems can vary in size and the number of alternative solutions. However, thanks to the agentic tools, prototyping is now much easier and cheaper. Prototypes are also more robust as there is no need for an engineer to fully focus on building them, and the agents do a relatively good job at doing that. Hence, we use that technique more often than previously, and it is done in code, not via wireframes. Also, you don’t need to be an engineer or ask an engineer for help to prepare a prototype. All things considered, I notice both benefits and risks of ease of prototyping. There is no doubt that verification of the hypotheses at the early stage is beneficial as it allows one to choose possibly the best solution and reduce overhead of changes at the later stage. However, I have also seen a situation when too many prototypes made it more difficult to make a final choice. One needs to know when it is time to stop prototyping and move towards a solution.

The implementation of solutions was transformed completely. It is very rare now that somebody starts implementing a solution by hand. The natural starting point is an agentic coding tool. Even if at some point of time a manual change is applied by an engineer, it is rather an exception than a rule. At the same time, there is no single tool that is used by everybody. The engineers have freedom of choice within the wide set of options adopted by the company. They decide which tool they use, and how they use it. It’s not uncommon for an engineer to use Claude Code for day-to-day work but also leverage GitHub Copilot within the GitHub UI.

Given that the code is no longer written by hand, what is the role of an engineer? Their part in the implementation is still invaluable. It is the engineer who drives the architecture of an application. We noticed that the agents are eager to reproduce bad patterns in the repository. If your code contains tight coupling and other code smells, the agent will propose a solution of similar quality. Hence, we are conscious that in the age of AI we need to be double-vigilant to leave the code base in comparable or better state after each change. The scout rule has never stopped to apply, and right now it is more important than ever. Therefore, what we bring to the table is the ability to judge the solutions. We drive the agent and assess its work. We need to be able to understand the system to apply changes. If we don’t, we risk introducing broken windows which an agent will eagerly reproduce next time it enters the code base.

Then, the code review is a place where things have not settled yet. We are heavy users of GitHub Copilot for review. Sometimes, we use Claude to perform additional rounds. However, the automated review has not replaced the human one. Especially on the frontend, an agent cannot try out a solution in a way a human would. Therefore, even the smartest model cannot replace a real user. At the same time, a person creating a solution is also responsible for trying it out as the user. There can be changes which are not critical, imagine fixing a typo, updating dependencies, or even a small UI bug. Those may not need a full-blown review. Still, we are not at the stage of robots reviewing and merging code produced by robots.

The shift in the way we work has also triggered organizational changes. The leadership of the company came up with a reorganization based on the assumption that the growth of agentic tools reduces the moat between different roles within the product. Non-engineers can build too. This way the role of a product builder was born. The product part of the company was essentially divided into two sections.

The section called Experience is all about agents-aided product building. Former designers, product managers, and engineers were divided into small units responsible for different parts of the product experience. They all share the nominal role of product builder. Naturally, they retained the skills from their former roles, and those skills are supposed to be used by them in their new profession with the aid of agents. So, a former product manager uses their experience within the contact with customers to uncover the needs and identify problems that need to be solved. Then, they can use an agentic tool to prepare a prototype or even a pull request to directly contribute the solution. Their former-engineer colleague may be asked for help in getting the contribution merged. At the stage we are now, the agents driven by non-engineers are not always able to produce solutions which can seamlessly be merged into the production code base, and it is rather expected that an engineer aids to get the pull request into the final state. So, while the effort of producing a solution is approaching zero, it is at the cost of increased time spent on the validation.

To ensure the stability of the product, the part of the product department responsible for the mission-critical components retained the nominal roles of engineers. This part of the product department is called Core. While the engineers within it have also adopted agentic tools, the main change introduced by the organization affected the rest of the product.

The introduction of AI has had a huge impact on how we work within Camunda. On one hand, it sped up some of the work. It is now much easier and faster to prepare contributions. Implementation of simple bugfixes takes minutes and not hours or days. When a problem is noticed, instead of placing a new issue in the backlog, we can have an agent prepare a fix in the background. The increased velocity comes also with a cost. It’s not viable anymore to thoroughly check each line of code introduced via an always growing number of contributions. We focus more on the high-level perspective, trying out the solution from the user’s perspective.

Then, there is also the aspect of broadening the group of people who can contribute. A non-engineer is now capable of preparing a pull request. They are not only a source of feedback, but also a source of solutions. That comes with a challenge as a non-engineer cannot usually judge the quality of the contributed code. It leads to an increased strain on the engineers who need to assess the solution. There is therefore a risk that a contribution gets stalled, or even worse - gets accepted on the LGTM basis. Still, this problem does not occur within the areas of the codebase which are considered mission critical as such contributions are not a thing there.

Engineers are also able to contribute outside of their area of expertise. It does not seem to happen often, but the wall between backend and frontend can be breached thanks to agentic tools. More often however engineers from different teams contribute to each other’s codebases within the frontend field.

The changes that I described above apply to the company or its parts and are consequently applicable to my team as well. However, I believe that it makes sense to look at the team specifically, because (1) I know it first hand, and (2) I can present a unique perspective of an open-source project.

As mentioned in the beginning, most of the work done by my team is done in public, and the outcomes are free to use for anybody. We track our work on GitHub via issues, and even our task board is publicly available. The introduction of AI has not changed it. An issue or a contribution goes into the inbox, gets assessed, lands in the backlog or gets processed and eventually closed. The process is still the same, but the aspects of the process are different now.

Before I go into the details, I would like to share more about the foundations on which the team is built. When the bpmn.io project was established, the base statement of the team was also coined: BPMN everywhere, for everyone. We believe that our tools need to be available to a broad audience. However, there is no one-size-fits-all solution with such a goal. Hence, the bpmn.io toolkit was built around extensibility and embeddability. You can take our core library bpmn-js, add your custom code to it, perhaps rip some parts off, and you should still be able to embed it in your application. My team’s mission sets therefore a high standard for the software we build. We build a platform for others, both within and outside of the company. We cannot accept that we introduce breaking changes by accident, because there are people out there who rely on our work. Our standards are defined by the definition of done and the design principles that anyone can read on GitHub.

The high standards of the team have not been changed by the introduction of AI. While the initial quality of the Copilot-produced pull requests was not acceptable, the coding agents nowadays can create solutions which are comparable to those coded by hand by humans. Therefore, we decided to adopt AI, and strived to make our code base ready for it.

The bpmn.io project is open to contributions. The community around it reports found problems and improvement ideas via issues, and we regularly get pull requests from external contributors. Naturally, as the coding agents got adopted in the industry, we started getting pull requests generated with agentic tools. This poses a potential challenge of a flood of contributions which we would not be able to assess. Because of that, we tried to at least make sure that an agent job kicked off by a contributor adheres to our standards. We published our definition of done and placed an instruction file for the agents in each of the repositories that points at it. In addition to that, we recently added a CI action which validates the pull requests against our pull request template. The agents seem to like to invent their own templates, so at least the CI fails in case they do that. The validation action is also useful for internal contributions, so it is not for community pull requests only.

However, the flood has not come (yet?). We did not need to close the gates for the external contributors unlike some other open-source projects. That is perhaps due to the relatively niche field of the project. However, the contributions that we get are now different. They include tests. The fixes are often going into the right direction. We do not get outright spammy pull requests and even though most of the contributions cannot be merged right away without adjustments, they seem to be a good starting point. This leads me to a conclusion that the quality of contributions is getting higher than before.

Also, it seems that we got an influx of contributors trying to fix ages-old, not prioritized bugs, which allowed recently to close a couple of issues. I doubt that we could get these contributions without agentic tools in the hands of the contributors. Overall, it seems that the impact is positive for my team.

Coming back to the process discussion, the AI tools enabled us to smoothen the process out. Previously, building a custom tool was a rather rare exception. We did that only if the pain of using an already existing solution was too high, or there was no solution on the market. Now, it is relatively easy to build internal scripts or small libraries that can replace external tools. One notable example is an in-house solution for releasing monorepositories. At one point, an engineer decided to bootstrap a tool to replace a JavaScript library lerna which contained several hundreds of transitive dependencies, and we used only the release feature of it. We reduced the dependency graph by a great deal, so we are now less vulnerable to a supply chain attack. Without agentic tools, I could not see it as an option that we dedicate time and effort to building it by hand. Now, we can incur the small cost implementing it, and benefit from a much more secure supply chain.

Another example is the impact of the automated review. While it is certainly not perfect, it acts as a first line of defense against potential bugs or shortcomings of the contributions. We use it widely as a next stage above linter. Copilot’s review allowed us to catch problems that could have gone unnoticed if we had relied only on a human reviewing the change. In addition to that, the team has developed internal review instructions which make the agent evaluate the pull request from the team’s definition of done and design principles perspective. So overall we are better off with the new tools in the review area.

Still, the improvements in the review have not caught up with the increased speed of implementation. The impact on the team is two-fold. Since contributing is now easier and faster, we can fix the newly found issues “on the go”, as a background job. We do that more often and ship more bugfixes this way. However, the throughput of changes is determined not only by the velocity of creating a pull request, but the entire process including review. So, the review is becoming increasingly a bottleneck. We need to remind ourselves that what is not merged, is not shipped. The priority after finishing a task is to investigate the items waiting for review, and not to start a new task. This is especially challenging as the contributions from the inside and the outside of the company increase the number of pull requests to review but can never decrease it.

For the engineers, I can share one key learning from the transformation of the AI age. As writing the code is less of a problem here, we as the engineers need to focus on the fundamentals. It is us who can make a judgement at the several stages of software delivery. We should be able to tell whether the solution design is reasonable, whether the architecture allows us to achieve our goals, and whether the quality is good enough. Agents can help us decide, but it is humans who are accountable.

Overall, the software delivery process has sped up with the adoption of coding agents. Our throughput increased. We can tackle more problems and deliver higher value at the same time. The changes in the velocity of the different stages are uneven, though. We can produce code more cheaply, but that only exposes the bottlenecks of review and validation. The introduction of AI has not removed any of the parts within the software delivery process. It shifted them.