Once again, we brought together some of the finest minds Infobip has to answer tricky questions about the future of software.

This time around, we spoke to four Infobip engineers about how they use AI in their daily work and how they view the AI revolution happening now.

Research, plan, execute

With rapidly changing AI infrastructure, the things that used to be normal in software development are getting different, but some things stay the same.

Petar Dučić, Engineering Director, said that the company’s mantra “you build it, you own it” has remained the same in the AI era. This simply means that engineers are responsible for whatever they build.

Senior IT Research Scientist Ante Kapetanović, added that engineers need to separate their work phases efficiently:

You have to separate your research phase, your planning phase, and your coding implementation, whatever phase. This ultimately means that you own each step of the way. And basically, it is not AI-assisted coding, it is more human-assisting AI.

Engineering is now becoming even more necessary…

It’s true that using AI tools is, in many cases, a cheaper alternative to real people, but Petar pointed out that engineering is now becoming even more necessary, because there’s so many things that can go wrong, and we need real people to check them and undestand what’s going on.

Senior Software Engineer Rino Čala pointed out that there’s three types of mistakes agentic tools make: logical mistakes, code-based mistakes and security mistakes. The solution is, as Rino puts it, just more tests:

So it is definitely important to run tests, to run some local tests, CI tests, and do some static checks as well.

Zvonimir Petković, Staf Engineer, then explained that security issues are the number one flaw with AI software tools:

Security is the main risk with deploying Gen-AI generated code. With the whole Vibe coding setup, nobody looks at the code, and oftentimes we have also non-engineers deploying code. The hiding sensitive data within the source code itself, this is the number one problem.

The second problem for Zvonimir is scalability. Something that is built in a couple days might work fine for a small team, but cannot be scaled to 5,000 people easily.

… and engineers are now more orchestrators than code writers

A stark contrast to the narrative of AI taking away jobs for engineers is that, with more people actively using AI, there’s a bigger need for someone with a technical background to help with not just support, but education.

“We’re slowly becoming context engineers”, added Ante, saying that engineers are now spending a lot of time managing their context in different AI tools. He is personally a big advocate for writing your own code and feels like this is a major part of being an engineer. Still, Ante admits that might not be the case in a couple years.

Zvonimir, interestingly, had a take about exactly that:

The total trend is that in a few years’ time, we’ll have the situation where nobody writes the code manually. Software engineers will be like persons who are the experts in that field, so they will be able to review what gen AI has generated.

In conclusion, as Rino puts it, engineers are now more in the role of orchestrators and organizers than they are code writes, since they spend a lot of time managing AI models to do things properly.

Want to hear more? Check out the video.

Special thanks to our fellow colleagues at Infobip, the publisher of ShiftMag!

The post A Future Where Nobody Writes Code Manually Might Be Closer Than It Seems appeared first on ShiftMag.

That question led Paolo Rizzi (sustainability principal at ustwo), Nayan Jain, Executive Director of AI at ustwo and Nick Hegarty (Executive Director of Technology at ustwo)to start looking for tools that could help developers see the environmental cost of their AI usage while they worked.

Having found no real tools for this, ustwo and the University of Bristol built one: PRISM. It launched last week, and we sat down with Nayan to talk about how it works and what it aims to change.

PRISM uses AI token activity to estimate energy use and emissions

The tools that were available mostly focused on data centers or broad “big picture” ideas, but none catered to the developers actually using AI tools.

That gap led the ustwo team to think about ways to connect AI usage to real-world energy:

We quickly ran into a challenge that still exists today: a lack of transparent data from model providers. Without reliable information on energy consumption and infrastructure, it is difficult to build and validate a model with confidence.

Working around that, they decided to rely on tokens, a visible and relatively accurate measure of AI spend.

The idea was to use token activity as a proxy for compute demand and estimate energy use and emissions using published research and carbon accounting principles, including the Green Software Foundation’s Software Carbon Intensity framework.

Nick Hegarty, who helped narrow the focus: could they help developers understand the environmental impact of their AI use while they worked? That made the project possible.

From idea to IDE

The answer was to create an in-editor tool, where the developer could see an estimation of their token costs and impact on energy consumption in real time.

The theory here is that, with this data, engineers can see their habits and perhaps be more conscious about their usage:

Our theory is that making this visible can guide engineers into more mindful habits around their AI consumption in the moment. Because AI providers don’t publish complete energy or emissions data, PRISM acts as a proxy for energy consumption by surfacing an estimate rather than an exact measurement.

PRISM directly monitors token usage, the model being used, and the provider. For other tools, like GitHub Copilot, PRISM reads local activity logs. AI requests made by an application at runtime are captured through a local interceptor.

The app then combines input and output tokens into an estimate. Nayan notes that these will be separated “as soon as robust factors exist”.

How red was that prompt?

In practice, PRISM is more of a subtle indicator than a big flashing number that appears after every call. Nayan explained how it feels to use it:

In the editor, a status indicator reflects your most recent call, colour coded. The headline feature is Relative Impact Classification, where each interaction is rated Green, Amber, or Red based on where it sits compared with the other requests in the same project.

Nayan continued to explain the colors:

Green is below the median, Amber sits between the 50th and 90th percentile, and Red is the top tenth. A few requests need to accumulate before the colours become meaningful, because the whole point is comparison within your own project rather than against an arbitrary threshold.

Clicking around the dashboard more, users can get information broken down by model usage, as well as other interesting metrics:

• Timeline of estimated carbon over the course of development
• Heatmap that shades from green through amber to red
• Breakdowns by branch and other visualisations.

However, Nayan explains that a relative, percentile-based design was chosen due to the inability of estimates to present absolute carbon figures. The goal of the tool is to explain and raise awareness more, and hopefully educate engineers on how their usage looks like from the eco standpoint.

The impact is awareness, not less AI use

Ustwo has tested PRISM with UOB students and across the company’s engineering team, and the results have been positive so far:

Several users said that seeing estimated emissions made them more deliberate with AI tools.

Nayan added that engineers, having seen the data for their usage, tried to make adjustments to their style and became a bit more conscious of how they refine requests.

Some wrote shorter, more precise prompts instead of using multiple iterations, and others paid closer attention to model selection after seeing how much environmental impact different models could have for similar tasks.

But as Nayan said, what interested them the most wasn’t that developers used AI less, but that they became more aware of how they were using it. “Once the data was visible, users started noticing things they hadn’t considered before.”

PRISM won’t solve AI’s environmental impact, but it makes it more visible

Right now, PRISM can provide data and insights for cloud and assistant-based models by identifying them, capturing token usage, and calculating the energy factor from a list of supported models. Locally run models are not yet supported, but might be in the future.

As the tool grows, ustwo sees its ideal outcome at three levels.

For engineers, the goal is awareness: giving users more information about their environmental impact during their work. Nayan says this is not about telling people what to do, but showing them a fuller picture of the tools they’re using. For organisations, the goal is to create a shared picture and open up more conversations about sustainability, governance, and responsible AI.

Beyond those, ustwo is positive about the potential of collaboration in the field of environmental impact of AI. He concluded:

PRISM won’t solve the environmental impact of AI on its own, but if it helps make that impact a little more visible, and sparks better conversations and behaviours as a result, then we’ve achieved something worthwhile.

The post This IDE Plugin Shows the Energy Cost of Your AI Prompts appeared first on ShiftMag.

When companies start tracking engineer token consumption on internal leaderboards, something has gone wrong in the measurement chain.

Stephen Poletto, Field CTO at Span, used his CTO Craft Con talk in Toronto to argue that the AI tooling wave has arrived with a familiar problem attached: organizations are reaching for the most legible metric available rather than the most meaningful one.

The result is a rerun of every previous failed attempt to quantify developer productivity, but this time with a pretty substantial compute bill.

Burn, baby, burn

Poletto opened with a data point that frames the problem neatly. Uber and ServiceNow both burned through their entire annual AI token budgets within the first five months of the year. That pace of consumption is being held up in some quarters as a sign of healthy adoption.

Poletto’s position is that it mostly signals a measurement vacuum.

Just because you’re spending money and using these things doesn’t necessarily mean that you’re producing better outcomes. That’s the issue that I have with tokenmaxxing.

The leaderboard dynamic at Meta, where engineers were reportedly running expensive jobs purely to rank well on an internal token-consumption meter, illustrates the trap cleanly. Poletto named it directly: Goodhart’s Law.

Coined by British economist Charles Goodhart in 1975, it’s completely applicable to the 2026 problem: when a measure becomes a target, it ceases to be a good measure. Or, in today’s words: Set token usage as a goal and people will optimize for token usage, not for shipping software that works.

This isn’t a new failure mode. Poletto traced the same pattern through lines of code, pull request counts, and story points, each of which generated its own gaming behavior when elevated to headline metric status. Tokenmaxxing, in his framing, is:

The same old pitfalls of trying to quantify developer productivity all over again.

The alternative he proposed is a ratio: customer value delivered against the total cost of producing it, headcount, tooling, and token spend included. DORA metrics and PR throughput are not useless, he argued, but they measure the inside of the system, not its output. Treating them as primary goals disconnects engineering effort from the outcomes the business actually cares about.

What about controling the PR size?

Span’s own benchmark data, drawn from its customer base, puts some numbers around where teams currently sit. About half to two-thirds of net new code is now AI-generated, up from 10 to 20 percent a year ago. PR throughput is running at roughly 1.7 times pre-AI rates. Neither figure, by itself, says anything about whether those teams are delivering more value to customers.

The quality picture is more nuanced than the headline defect numbers suggest. Span’s analysis found that when controlling for pull request size, AI has a negligible independent effect on defect rates. The actual driver is that AI generates larger pull requests, and larger pull requests correlate with more bugs. That is, in principle, actionable: you don’t need to focus on the AI generated code, but to the PR scope discipline.

Different approaches to reduce human review burden

Code review is absorbing the strain more visibly. Poletto cited 30 percent more rework time on AI-generated code compared to human-generated code, along with more review round trips. Teams that are navigating this well are doing so through process changes rather than raw tooling, pre-review automation gates, semantic routing of review assignments by code ownership and reviewer availability, and environment-level QA that lets agents validate their own output before a pull request opens.

Stripe, Ramp, and WorkOS all came up as examples of teams that have built cloud environments where agents can run tasks more autonomously, with the explicit goal of disqualifying broken work before it reaches a human reviewer. Ramp’s approach to screenshots, attaching before-and-after visuals to PRs so reviewers can see what changed at a glance, is a small example of the same principle: reduce the human review burden by doing more verification earlier.

Fin from Intercom took a different angle, capturing agent-human interaction logs from development sessions and using them to provide personalized coaching to engineers on how to work more effectively with AI tools. Poletto noted they also tracked which agent skills were actively used versus deprecated, applying the same funnel analysis logic that product teams use for user flows.

The thread connecting all of these examples is that the teams seeing compounding returns are treating their development workflow as a system to be instrumented and optimized, not a collection of individual contributors to be nudged toward higher token counts.

Writing code is no longer a bottleneck

Poletto said in closing:

You should treat your development system as a system that can be optimized. Telemetry, observability, helping understand where those dynamics are, can help you be more confident in where you’re investing.

The bottleneck, his data suggests, is no longer primarily writing code but deciding what to build and validating that it works once built. That shift puts pressure on skills that most engineering hiring and evaluation frameworks are not set up to reward.

The post AI generates larger pull requests. Larger pull requests bring more bugs. appeared first on ShiftMag.

On June 9th, 2026, Anthropic released Claude Fable 5, its most powerful model ever. Fable is much faster than Opus 4.8, which is itself much faster than the ones before it. It seems like every AI model is faster, better and can do more, but what does that mean in practice? At AI Week Milano, we listened to Data Science Manager for the Research team at Anthropic, Gian Segato, explain how he views AI evolution.

In a few years, we’ve come from an AI chatbot that summarizes documents and writes a bit of code to a knowledge worker that is, by all intents and purposes, the closest thing to an “AI coworker” we have. These are jumps in capability that the general public struggles to follow, but they’re not the real reality.

Gian explained in his talk that most of these flagship and public features were developed months before Claude users used them. According to him, seeing a new feature such as coding or image creation is the best way to know where AI was a few months ago, not where it is now. Since AI capabilities move so fast, it’s hard to keep track of it all:

Products are fundamentally a lagging indicator. You cannot just judge capabilities by looking backwards. Products are built on top of capabilities.

The acceleration is accelerating

A good (or just more realistic) way to measure the speed at which models are getting smarter is to look at a new metric that Gian suggested, which works in three steps:

• Take a task, for example, the creation of a simple app, solving a particular problem or reading a data set;
• Find out how much it would take for a human expert to do it;
• Then check whether a model can do it and how much time it takes.

Doing this gives you a clean exponential and trajectory of where you are, and where you’re going. Right now, Gian thinks that the best models can autonomously complete work that would take a human expert around two days. Of course, he’s not talking about answering our emails or vibe-coding mini games, but complex work that requires in-depth knowledge of the matter at hand and particular skills.

The speed at which models can do these tasks is, however, doubling every four months. Just a few years ago, it was doubling every seven months; the acceleration is, as Gian puts it, accelerating. This means that the capabilities of models are doubling at a rate that is also becoming faster; they take less time to become twice as efficient.

What’s happening is relatively simple: we’re just throwing more power and information to AI models, and they’re responding to it well.

Give AI more power and it gets proportionally smarter

For those unfamiliar with how Anthropic was created, the mention of a paper in which researchers figured out that just giving more power to AI models makes the AI models smarter came as a revelation. This means, in Segato’s words, that the line that portrays AI capability in relation to the amount of processing power is just a straight line, and one that researchers currently see no end to.

The information is both slightly concerning and very impressive. Gian noted that the line spans eight orders of magnitude, which is immense and means that AI capability can scale incredibly while still not showing signs of vulnerability. For the sake of keeping this article short and easy to understand, let’s just say that this is almost unheard of, except in some physics research and laws of nature:

Typical things we build; engineering things, societal phenomena, you two or three-x them and they break down. There’s no equation that spans eight orders of magnitude except in physics and the laws of nature.

Calling AI a “law of physics” or a “force of nature” might be something that belongs in a conference keynote and is something an AI startup is just waiting to use for its new investor pitch after listening to this presentation.

However, this also means that there’s really no way of telling how “deep” or “smart” an AI model can get if all that it takes for it to get there is just more hardware, more RAM, and more learning material. It also means that we’ll see more AI data centers as companies like Anthropic throw more chips and money to their models.

The more capability, the more risks

Gian continued that AI is now in the “tasks” era. This means that projects that take dozens of minutes for a human are regularly delegated to AI models, which do them easily. In six to 12 months, we’re probably going to enter something Anthropic calls the “projects” era, where AI models will be able to handle work that would take dozens of hours for humans.

By then, we’re going to be looking at the equivalent of a CEO instructing a marketing director, rather than a human assigning a task to an AI tool. Seeing as the growth is both fast and linear, we’re approaching that era whether we’re prepared for it or not.

With this growth come risks that can’t be ignored. For example, the more work models do, the less supervision is possible for us as humans. For example, if a model is doing a marketing campaign, a human can’t watch its every step:

Necessarily there’s going to be some element where we have to accept some lack of supervision. That’s both intellectually interesting and pretty scary. This is a little unsettling.

Gian’s “encouraging” words aside, this was the part of the presentation where he connected the researchers who’ve discovered the connection between power and AI model capability as the founders of Anthropic. This served as a diving board to present that Anthropic is really serious in terms of security and monitoring its models. Still, AI creators telling you they’re “doing all they can” to contain AI doesn’t really fill you with optimism.

The talk from Anthropic’s researcher comes at a time when news of Mythos and Fable, the company’s extremely capable models and their effects on the internet are making headlines. Gian echoed this by saying that AI models that might potentially be used to engineer a new pandemic, having learned all there is to know about viruses and disease, might also be the best way to find out how cancer spreads and how the brain works.

Of course, he believes that the good guys will be the best way of stopping the negative sides of AI from shining through. Whether the world feels like Anthropic are said good guys is another story entirely.

Concluding his talk, Gian said that he believes the next period of human history will be the one where we will be able to “compress 100 years of industrial and scientific revolution into a very fun and interesting decade”.

The post Gian Segato, Anthropic: “AI Products Are a Lagging Indicator of Growth” appeared first on ShiftMag.

This May, I spoke with a CTO who truly understands the spirit of the moment and brings a grounded, realistic view of the current wave of AI expansion. He applies that perspective across a team of roughly 1,000 developers.

That is Izabel Jelenić, CTO of Infobip, first Croatian unicorn. As a co-founder, he has been there since the very beginning, when two university friends started a small startup that later grew into a billion-dollar global organization. Over the past 20 years, this veteran tech leader has navigated every major technological shift while helping scale the company worldwide.

The conversation comes at a moment when we are in the middle of the agentic AI era, where AI systems move beyond answering questions and begin executing tasks, supporting and automating real workflows. At Infobip, this shift has been embraced early and deliberately through an AI-first transformation that extends across the entire organization, engaging not only developers but employees in every function.

Developers should adopt AI gradually

I asked Izabel to explain what AI-first means and how the idea of shifting to an AI-first mindset emerged.

What followed was a comprehensive breakdown of its evolution, core principles, and practical execution. With over two decades in the tech industry, my interlocutor emphasizes that he has never witnessed a technological shift this monumental, signaling clear proof that AI is rapidly moving from mere hype into everyday utility.

That makes mastering these capabilities and maximizing their potential absolutely crucial. A common pitfall, however, is assuming AI belongs solely to developers, which completely misses the mark given the technology’s universal transformative power:

That is why Infobip promotes a mindset in which all technical and non-technical employees embrace curiosity toward AI so they can be part of the new business and technological order instead of letting it overtake them. That is the AI-first shift the company has chosen as its business philosophy for the future.

While technical teams naturally adopt new tools faster and more efficiently, he believes those outside software engineering shouldn’t be left behind. Providing non-technical employees with the right resources and training allows them to leverage AI agents as personal assistants, ultimately making their daily work both easier and faster.

When it comes to software developers, the Infobip CTO sees two extremes:

1. Some cling tightly to writing code and represent the anti-AI camp.
2. Others rely fully on AI and embrace vibe coding.

In his view, neither approach is correct.

Because technological development has not yet reached the “dark factory” stage (where systems run entirely automated and unassisted), rushing into a full AI concept remains premature. Instead, this direction serves as a north star—a long-term guide rather than an immediate reality. While it remains uncertain if a fully autonomous state is entirely achievable, forcing such an approach today is clearly unwise.

Developers should adopt AI gradually. They should understand which tools suit them best, such as coding, review, and testing.

If you are a bad developer, AI can’t help you

From the CTO’s perspective, Infobip developers have adopted an AI-first mindset naturally and with little friction, though overdoing it remains a risk. There is a critical need to retain ownership and maintain a strong architecture, especially since AI often acts as an amplifier, scaling both good practices and underlying flaws:

If you are a bad developer, AI will not help you write good code. If you are a good developer, AI can help you a lot in terms of speed. But you have to know how to guide it and recognize its mistakes, because it can be very convincing.

He explains that an AI-first mindset changes how organizations operate. AI speeds up processes by automating everything that can be automated. People can master this technology by adopting engineering logic, and they gain a strong advantage for the future.

By ignoring AI, a person pushes themselves out of the industry. Izabel finds it surprising that some smaller companies do not adopt AI faster. They are in a growth phase where AI could make a huge difference. They could implement it quickly because teams are small and compact. Despite this, adoption remains low.

The Infobip co-founder sees a common misconception that AI is mainly for developers. The biggest impact actually appears in GTM because AI automates business processes extremely well. Hyper-personalization becomes fast, advanced, and efficient. It can significantly help business scaling:

You can automatically analyze the market, get a list of potential clients, identify use cases that clients need, and do outreach. With hyper-personalization, you can prepare content in a way that immediately helps a person understand what a company sells, but from their perspective.

AI will reshape roles in tech companies

Even though AI can quickly improve business organization, he notices that people mostly focus on coding. Coding has never been the biggest problem in IT businesses, the real bottlenecks usually appear in sales.

This is where AI transforms work, making processes more efficient and cost-effective. Far from replacing client relationships or removing the human element, the goal is simply to automate repetitive operational tasks, leading to a much more streamlined workflow:

People need to get on the AI train. If they do not use AI, new companies will emerge that are AI-native. They start with two people and AI. Their approach will feel more natural and much faster than those who use AI only for software development.

When asked to describe what an AI-first transformation looks like from the inside (using Infobip as an example) and whether the company will abandon certain processes or redistribute roles, the answer is far from black and white. This transition will happen gradually, marking the most significant technological shift in over two decades.

Ultimately, enthusiastic professionals eager to learn will be the ones expanding their roles by actively implementing these new technologies:

People experienced in one specialization can now work much more broadly. They can keep their core role, but they can accomplish much more. Someone who used to be only a backend developer can now work with databases or frontend. They may not reach the level of an experienced database engineer, but they can handle simple tasks. They do not need to wait for anyone.

The concept of Agentic AI is another major focal point, pointing toward a future where everyone operates with multiple digital assistants. By helping manage core business tasks faster and more efficiently, these agents streamline daily operations while actively expanding a professional’s overall skill set.

AI agents are still nothing without people

As part of its AI-first mindset, Infobip is building its own Model Context Protocol (MCP), integrations, enabling AI agents to easily consume and interact with Infobip services. CTO believes this is vital because AI agents will soon be everywhere, embedded in business systems, running on personal devices, practically on anything you can imagine:

Once it became clear that AI agents are the primary means of interacting with the outside world, adoption accelerated rapidly. Companies realized how easy it is to connect these agents to external systems and services. The key point is that AI agents can now perform real-world tasks by consuming various APIs, especially those available on platforms like MCP. This capability makes them an integral part of business operations, and it’s why we believe their presence will become ubiquitous in the near future.

However, he stresses the importance of human involvement. It should not disappear:

Communication must continue to exist. We cannot fully hand it over to AI agents. They can help, but communication becomes even more important because everyone becomes more productive. Without alignment, you can end up with many generated tools that no one understands.

There is also a clear warning regarding hyperproduction, which can easily spiral into chaos if teams begin operating without proper coordination.

There are fewer junior developers, but they are still valuable

I also wanted to ask an experienced professional what will happen to junior developers. Demand for them has decreased globally. AI now generates much of the code that juniors used to write.

At the same time, a generational shift could lead to a talent shortage. Looking back at the end of the pandemic when the IT sector saw a massive influx of talent, Izabel notes that many recent layoffs in US companies are likely happening under the cover of AI:

They use AI as an excuse for inflated numbers and inflated costs. That is why fewer juniors get hired. I think balance is returning. We will not see excessive hiring from before, but there will still be a need for young, smart people who bring new ideas and fresh energy into processes.

To combat these talent gaps, Infobip runs targeted internships and collaborates closely with universities, frequently transitioning these students into permanent roles. In CTO’s experience, these fresh perspectives bring genuine value and innovative ideas to the team.

AI plays a pivotal role in this onboarding process by granting immediate access to learning resources, allowing junior engineers to upskill rapidly. By leveraging AI as a 24/7 virtual mentor alongside human guidance, juniors can accelerate their professional growth and secure key positions within the company much faster

Experienced developers face an identity crisis because of AI

Skepticism among experienced developers toward AI, in the view of Infobip’s co-founder, stems from a natural feeling of disappointment and an ego hit that is not easy to accept. At the same time, he points out that over twenty years, workflows, frameworks, programming languages, and machines have all continually evolved:

You spend 20 years writing code as a developer, refining it, running it, seeing how it works, writing tests, and then suddenly you stop looking at the code and start talking to a tool. You experience an identity crisis because you used to identify with the code you wrote.

My interlocutor views these feelings as entirely legitimate, but encourages professionals to expand their scope and boost productivity. Ultimate purpose does not need to remain locked within a single job description when fulfillment can be found in wider responsibilities.

This adaptation is admittedly difficult, but as he points out, once people move past the “this is useless” phase, they position themselves for rapid growth by embracing the new reality.

Speaking from his experience as a CTO for 20 years, Izabel describes the transition to an AI-first mindset:

These changes are quite painful. We also went through turbulence, but at some point you see that AI brings value and you have to use it. Claims about AI being prohibitively expensive often serve as mere excuses. Open-source models can already run locally on standard laptops, completely bypassing the need for intensive training in many scenarios. Ultimately, running a model and training one are two entirely different concepts. Today, hardware capabilities and overall quality are night and day compared to what was available just a few years ago.

The question may be how good an LLM you use, but you will not be able to work without it. The technology is here to stay. It is important to understand its strengths and weaknesses and use it as soon as possible.

The future is uncertain but exciting

Finally, when asked what the next twenty years of Infobip will look like, the answer was a candid “I don’t know.” Just as no one could have predicted the current shift, no one can definitively predict the next. Still, one thing is certain: there is immense excitement about this change.

Within Infobip, both technical and non-technical teams are fully embracing AI. Another deep reshaping is underway, business as usual no longer exists. Instead, the industry is witnessing a real transformation:

Twenty years ago we said “We are just starting”, and now we are in the same situation again. That will probably continue for the next 20 years. Our best people keep learning new things that drive them forward instead of standing still.

This mindset feels humble, but also necessary in a time of major technological transformation. It reflects the Socratic idea that true wisdom begins with understanding how little we know.

Infobip is the publisher of ShiftMag, recognizing the need for high-quality content for developers.

The post 20 Year Old Unicorn Goes AI-First Without Mass AI Layoffs appeared first on ShiftMag.

Trisha Gee has spent over two decades in software development, from startups to global enterprises – equally at home discussing DORA metrics and SPACE frameworks as business outcomes and organizational design.

At Devoxx UK, she gave a talk about how software engineering principles stay the same regardless of what tooling era you are in.

I wanted to understand what that means right now when AI is writing a significant portion of the code.

AI exposes the weakest link, not just the fastest path

Trisha frames AI as an amplifier, not a solution. When I asked what that looks like beyond demos, she put it simply: it exposes the problems that were already there, the ones you didn’t know you had.

The most common thing I saw (I was working at Gradle, so we dealt with a lot of build tooling) was more code, more tests, and tests taking longer. The continuous delivery pipeline took a lot of pressure.

The broader pattern she describes is straightforward but easy to miss when you are excited about shipping faster. “Whichever part of your system is the weakest, it’s going to expose that part,” she said.

Reframing it this way, while most conversations about AI adoption focus on what gets faster, Trisha highlights what deteriorates first.

When code gets cheap, everything else gets expensive

When I asked Trisha where teams should focus once code generation becomes cheap, her answer was everywhere.

What she means is that optimizing the writing of code without understanding the surrounding system does not move the needle.

It’s not about one thing which is going to fix one problem, it’s about really understanding the whole system, it’s about understanding even the whole organization, the whole enterprise. Where does IT and technology and software fit into that? What are you really trying to deliver? What is the business benefit?

She described this as working across two ends of the process. On the input side, teams need to get better at questioning requirements before writing anything. On the output side, they need to look at build pipelines, test parallelism, flaky tests, and DORA metrics.

“If you can measure those things (your DORA metrics, build times, whether delivered requirements actually give users value) you can start to see which parts of the process are working and which need attention,” Trisha explained.

Measuring the wrong things optimizes the wrong things

She also makes a sharp point about measurement and optimization.

If you measure lines of code for productivity, you’ll get more lines of code. But really productivity is not just about what we call these activity metrics. It’s not just lines of code. It’s not just pull requests, merges, features delivered.

The thing teams consistently miss is the full arc of delivery.

Developer experience and productivity is the whole piece. Did it get out to the user? Did it meet the user’s needs? Is the user paying for more of our stuff? Is the business getting what they need from what the developers are doing? What you’re measuring there impacts what you’re going to optimize.

That last line is worth sitting with. If your productivity metrics stop at pull requests merged, you are optimizing for pull requests merged.

The SPACE framework and why three metrics beat one

When I asked Trisha what teams should measure, she pointed to the SPACE framework. SPACE stands for satisfaction, performance, activity, communication and collaboration, and efficiency and flow.

DORA metrics, which most teams are more familiar with, are a subset of it. Her recommendation is to pick metrics from three different dimensions rather than relying on a single category. The reasoning is that single-category metrics tend to be easy to game without improving anything real.

So yes, you can write more code, but no, you didn’t do what the business wanted.

She also brought up Fred Brooks and communication overhead as something the industry consistently underweights. The harder metrics to capture, like satisfaction and flow, are often more revealing than the activity metrics that dashboards make easy to track.

The business outcomes she keeps returning to are specific: “You need to measure, did it do what you wanted it to do? Did it get out to the user in time? Did they start spending more money with us? Did it fix your retention problem?”

Those are the things which matter much more to the business.

What to fix before adopting AI

I wondered what teams need to get right before AI tooling can actually help them. Trisha’s first answer was essentially: stop adopting AI the way you have adopted everything else.

We generally get requirements, write the code, chuck it out there, and then you’re kind of done. That’s not how it should work.

What she advocates for instead is applying the scientific method to engineering decisions, which sounds obvious but rarely happens in real life.

Have a hypothesis, do your investigation, measure the results, have a conclusion. Generally speaking, we have not been great at that in our industry.

Applied to AI adoption specifically, that means being precise about what you are actually trying to achieve. What are we trying to achieve with AI? Do we want to deliver more features more quickly to the customer or do we want to perhaps deliver higher quality features? Because those two things are not necessarily the same thing Trisha concluded.

Therefore the practical instruction she gives is to run short experiments, measure one change at a time, and iterate. But have a hypothesis, figure out how to measure it, measure it, get feedback, and iterate over that.

The post Trisha Gee: AI Won’t Fix Your Broken Pipeline – It Will Break It Faster appeared first on ShiftMag.

Sander Hoogendoorn has been writing code for over 40 years and is currently CTO at iBOOD, a Dutch e-commerce company.

His talk at Devoxx, The Last Pull Request, was a live report from a team that quietly dismantled most of what the industry considers non-negotiable, and then kept shipping.

Now there’s a new concern.

AI didn’t change everything. Change didn’t wait for AI.

Sander opened with a timeline: source control, IDEs, the web, mobile, the cloud, microservices. Each wave reshaped what developers could build and how. AI is just the latest.

AI is going to change everything? No. Everything already changed everything. And this is not the last step.

The point wasn’t to diminish AI but to put it in context. Every major shift expanded the tooling, and the problem space alongside it. For most teams, that problem space now sits in what Sander calls complex territory: no best practices, only things that might emerge from experimentation. Dave Snowden’s Cynefin framework is blunt about this: in a complex context, there is no right answer to find. You have to invent one.

That’s the actual job, Sander says. Not typing code. Solving problems that have never been solved before.

Selfware

Sander introduced a concept: selfware. Software built by non-developers (marketers, finance teams, executives) using AI to solve their own problems without involving engineering.

At iBOOD, the content director is already doing it. So is the CMO:

We as tech are not fast enough. And I’ve seen this before. In the 80s and 90s, everyone started writing Excel spreadsheets.

The difference now is that the output isn’t a pivot table, it’s software. Unmanaged, untested, running on personal accounts with passwords nobody reviews, exporting customer data in ways that would make your compliance team cry. This is happening right now, and most engineering teams haven’t figured out what to do about it.

No scrum, sprints, pull requests…

The list of things they stopped doing is long: no scrum, no sprints, no retros. Fewer standups. No scrum master, no product owner. Minimal estimates. No pull requests – because every branch is a merge waiting to happen, every review costs time, and reviewers rarely know what the code was supposed to do in the first place.

What replaced it? Pair programming. Mob programming. Smaller changes, checked in faster, continuously. Everyone on the team is an architect. Everyone is accountable for everything, Sander says:

Perfection is achieved not when there’s nothing more to add but when there’s nothing left to take away.

Pair me with Claude

Today, Sander’s 13-person team pairs with AI through most of their working day. It became the natural way to work. Currently that means Claude, though that could change next week.

AI breaks things. Two weeks before the talk, Sander pushed AI-generated changes that silently removed all dependency injections from their web page constructors. None of the pages were serving data. He didn’t catch it until later:

I’m not saying not to use AI. I do it every day. But I do think we should check what it’s doing.

What worries him most is what he calls technical death – a state where a team spends all its time keeping existing software alive, with nothing left for anything new. Technical debt compounding under AI-generated code nobody fully reviews. Complexity accumulating faster than it gets cleaned up. That’s the real risk.

We asked Sander a few more things

Your team dropped pull requests. Was that an AI decision?

Sander: No, we did that a long time ago, it has nothing to do with AI. The problem with pull requests is that they slow you down. The longer you wait with merging back into main, the harder it gets, because other people make changes too. And what you see very often is that people reviewing other people’s code tend not to know or even understand what the code was supposed to do. So they check formatting, linting, naming conventions. Which is pretty stupid, because that you can automate.

Pull requests make sense in open source, where you have no idea who’s submitting changes or what the quality of their work is. But on your own team? I don’t see any problems with committing code from anybody automatically. We work together every day, we write code together. You just don’t need it.

AI is part of your team now. What happens when something breaks?

Sander: We don’t track who broke it. Everybody on my team is accountable for everything, including me. If I push something and the pipeline fails and I’m not around, somebody else picks it up. I have no doubt about that. So accountability is… I don’t care too much about it, because it’s distributed. We don’t blame people. We just fix it.

You’ve been critical of Agile. Is AI exposing that teams never really understood it?

Sander: I’m not critical about Agile. I think a lot of people misunderstand what Agile actually means. Agile does not mean Scrum. Actually, to be quite honest, Scrum is not really Agile. The Scrum Guide says Scrum is immutable, which basically means it’s not Agile, because Agile means you can improve on anything.

There is nothing in Agile that says you need to do sprints. The key statement in the Agile Manifesto is the one at the top: we are uncovering better ways of developing software. Everything else doesn’t really matter. As long as you have that mindset, there’s always something to improve. No default way of working is going to solve the problem for you.

Where does this go in two or three years?

Sander: I think we will soon realize that the English language is too ambiguous and not concise enough to specify to an AI what to do. So what will happen is that we’ll develop better ways of having conversations with AI – more precise, less ambiguous. And what those languages are called? Programming languages. We will develop programming languages that allow us to talk to an AI in a way that the AI is able to create lower-level code from it.

Programming will be programming, except with different tools. As they always have been.

The post Killing PRs was the easy part. Now Technical Death Keeps the CTO Up. appeared first on ShiftMag.

When incidents hit production systems, engineers rarely stay inside one tool for long, jumping from logs to dashboards to runbooks, trying to reconstruct what is actually happening.

Talking to other builders, it seemed like almost everybody faces this context-switching problem.

Rocío Bayon (Product Manager) and Sebastian Villanelo (Sr. Forward Deployed Engineer) from PagerDuty think MCP is how you fix it.

PagerDuty built their MCP to cut context switching

Rocío explained that their MCP is solving the issue of context switching:

When an incident hits, the engineer has to go between 5 to 10 different tools to understand what’s happening.

That’s the real problem they’re trying to solve.

PagerDuty’s framing of MCP was interesting: neither Rocío nor Sebastian described MCP as just another integration layer. They framed it as connective tissue that gathers logs, alerts, runbooks, and incident context into a single workflow.

What the MCP does, it brings all that context into one platform where engineers are usually already working.

Most engineering organizations already have enormous amounts of observability data. The real problem is that it is scattered across systems, and engineers end up reconstructing operational context manually during incidents.

Retrieve what you need, nothing more

Sebastian framed the problem as signal retrieval. Rather than feeding the model more information, the goal is pulling the relevant operational state around a specific incident.

If you have the right parameters or the queries and all this stuff, you will retrieve the exact information that you need.

That means narrowing context around the actual incident window. When an incident hits, it retrieves information around that time only, Sebastian explained.

That also changes how they think about efficiency, reducing context switching directly affects operational speed, token usage, and cost.

You will see that information only with one call. And that saves a lot of tokens and time. That’s money and time.

AI helps but engineers still decide

Still, both of them were careful not to frame AI as autonomous incident management.

Rocío repeatedly emphasized that MCP and AI systems are primarily helping with context gathering and operational visibility, while engineers remain responsible for the high-risk decisions:

The AI is helping you, but the engineer is the one who is assessing and making decisions where there’s a high risk.

That human layer is intentional. PagerDuty’s broader vision seems less about replacing on-call engineers and more about reducing the operational overhead surrounding incidents. Their MCP systems help gather information, surface relationships between systems, and accelerate investigation workflows, but humans still decide what actually happens next.

Rocío also mentioned that their SRE agent is designed to support larger incident workflows beyond information retrieval:

It can also help you trigger those incident workflows. So it can help you resolve the incident. And it learns as it goes.

“MCP – the connective tissue between tools”

I asked Rocío and Sebastian, how does MCP fit into the tools they already use without becoming just another silo.

And both of them clearly framed MCP as anti-silo infrastructure since it brings everything to one place. Rocío called MCP “the connective tissue between all these different tools.”

That framing probably captures the broader architectural challenge better than anything else in the interview.

Modern incident response already spans dozens of systems: observability platforms, deployment pipelines, CI/CD tooling, ticketing systems, infrastructure management, and communication layers.

AI systems inherit that fragmentation unless something explicitly connects operational state.

Engineers trust systems that behave predictably

Sebastian mentioned that teams often react very differently to MCP systems. Some embrace them immediately while others remain skeptical, especially around security and predictability. For him, trust improves once systems consistently produce expected outcomes:

When a person or a teammate says “ah, I’m retrieving what I’m expecting to retrieve”, that will help them to trust it.

A lot of AI tooling discussions still focus on model capability, reasoning quality, or benchmark performance. But operational systems are usually adopted much more pragmatically. Engineers trust systems that behave predictably, retrieve the right operational context, and fit into workflows they already rely on.

The post When systems go down, devs still juggle 10 tabs. PagerDuty says MCP fixes that appeared first on ShiftMag.

When humans maintained the GraalVM native image reflection metadata repository, coverage sat at just 14%. Tests were often stubs that technically compiled but covered nothing meaningful, nobody wanted to write them for someone else’s code, and the results showed.

At Devoxx UK, Vojin Jovanovic (Principal Researcher, Oracle Labs) and Mihailo Markovic (Software Engineer, Oracle), presented how they replaced that process with an autonomous AI agent pipeline.

The result is 90% dynamic access coverage across more than 1,000 JVM libraries, roughly 2 billion tokens spent, and a GitHub repository generating thousands of commits per week – while Vojin was at a hotel the night before the conference.

The problem with GraalVM reflection

GraalVM Native Image takes a Java application, performs static analysis, and AOT compiles it into a single binary. The benefits are significant: startup roughly 10x faster than a standard JVM, dramatically lower memory footprint.

But static analysis has a fundamental limitation: when a method calls Class.forName(“Foo”) with a dynamic argument, the analyser cannot determine at compile time what class will be needed. Reflection calls break the closed-world assumption.

The solution is reachability metadata – a JSON file that tells the native image compiler which classes, methods, and fields need to be accessible at runtime. Writing this metadata requires running tests that exercise all the relevant code paths.

For a library like Hibernate Core, that means covering 264 individual reflection call sites. For Tomcat, 205. Across the JVM ecosystem, the number is enormous, and until recently, it was almost entirely a manual process that humans were not doing well.

Start simple, then add feedback

The first approach was straightforward: give an LLM the library source code, tell it to generate comprehensive Java tests, collect the metadata via a JVMTI agent.

The results were not impressive – 5.7% coverage for logback, 2.9% for H2. Vojin noted how this doesn’t feel like AGI.

The shift came from adding GraalVM’s static analysis directly to the agent’s context. Instead of asking the LLM to guess which code paths matter, the pipeline runs a static analysis pass that identifies every dynamic access call site (the exact class, method, and line number) and feeds that report directly to the agent. With this addition, logback coverage jumped to 97%, H2 to 84.3%, in five iterations.

The next layer was JaCoCo integration. After each generation round, the pipeline correlates coverage data with the remaining uncovered call sites and feeds only the uncovered ones back into the next iteration. The agent knows exactly what it hit and what it missed. Vojin noted:

We always create a checkpoint in those systems so we can go back to it if something goes wrong. And in these LLM-driven workflows, something is always going wrong.

With this feedback loop: logback reached 100%, H2 reached 96.1%.

Coverage sometimes still isn’t enough

For larger, more complex libraries (Guava, Tomcat, MongoDB) even the feedback loop left gaps. The team added a third technique: PGO (Profile-Guided Optimization) profiling from GraalVM’s Graal compiler. The profiler samples execution and produces a call trace, which can be correlated with static analysis to identify exactly where a test nearly reached a reflection call but diverged.

The profiling feedback tells the agent not just what’s uncovered, but where in the call stack a test went in the wrong direction and what it would need to do differently. Results: Guava went from 50% to 72%, Tomcat from 45% to 83%, MongoDB reached 100%.

The feedback also tells the agent (and the engineers) why certain calls cannot be covered: a security service only available on Java 6, a cleaner class incompatible with the current JVM. “If you cannot reach it, tell us why,” the prompt instructs, and the agent does.

Cost, agents and model selection

Codex was the first agent framework the team tried. For logback (a library with 33 dynamic access calls) Codex spent $35:

If we’re spending $35 per library for a thousand libraries, we’re not replacing humans.

The alternative was P, a minimal agent that starts with a 200-token context describing basic file operations and bash execution. Same results, roughly 10x cheaper and the lesson is straightforward:

Simple task, use a simple agent. You already give it a lot of rules, a lot of context, and you’ve grounded it enough so it can perform on the level of these big agents.

On model selection, the team compared GPT 5.5 against several open-source alternatives – GLM, Kimi K2, DeepSeek, Gemma. GPT 5.5 consistently outperformed them on coverage. The counterintuitive finding was this: a more expensive model that makes the right decision in one shot can cost less overall than a cheaper model that wastes tokens going in the wrong direction.

The architecture that lets it run without you

The pipeline now operates as a third-generation system. When a user opens an issue requesting a library, the agent fetches the issue, runs the generation workflow, verifies the output, creates a pull request, reviews it, and merges or escalates to human review – automatically. The “human intervention” label on GitHub still exists, but its queue has shrunk dramatically.

Documentation, not smarter prompting, was what made the difference.

Vojin outlined what he calls the key context layers:

• raison d’être (why does this project exist, in two sentences),
• state of direction (where the architecture stands today),
• functional specification (how the system behaves),
• architectural specification (how it is built),
• decision records (what major choices were made and why), and
• comprehensive logs that serve as checkpoints for recovery.

When you do all of these things, it takes almost a few days for a very big project. You will reduce your work by 50%, 60%, 70%.

The payoff is that agents with this context can diagnose failures, trace them through logs, and fix the underlying system, not just the immediate problem.

The RAID system (an automated issue-resolution agent) was built in four prompts on a Sunday morning. It sweeps human intervention tickets, classifies them, performs deep analysis using the project logs, and either opens a GitHub issue for humans or attempts a fix in a forked branch with review. Jovanovic added:

Never work on the problem, always work on the system. You never go and fix a ticket. You always go fix the rules.

Where things stand

The repository currently supports 1,021 libraries. Without five large Hibernate libraries that predate the automated pipeline, dynamic access coverage across the ecosystem is 90%.

The GitHub repository has accumulated roughly 2,977 branches. In the week before Devoxx, it logged approximately 8,000-9,000 commits, with agents committing every few minutes around the clock.

Total cost for the project: approximately $1,700 in API tokens, plus personal compute on Jovanovic’s home desktop, running around the clock because the Oracle compliance process for cloud infrastructure takes time. The key point is simple:

Start with neural, simplest thing, get results, and then slowly chop off things and put them into algorithms, because they are much cheaper and faster.

We caught Vojin Jovanovic for a few more questions!

After the talk, we sat down with Vojin for a few minutes to ask him a couple more questions.

You tested over 1,000 libraries. What broke first when you tried to scale?

Vojin: Basically everything broke. We had mostly infrastructure issues, all kinds of GitHub failures. When you build a system at this scale, you need to assume that everything will fail and needs to recover. We broke GitHub rate limits. My machine was broken because it was running so many things. The key takeaway is that you need to build a system in a way that you can always continue. When things fail, you always checkpoint and continue from a checkpoint. We do work in sizable chunks, and when something fails, you just restart the chunk.

Is just asking the LLM enough?

Vojin: If you had asked me four weeks ago, I would say no. Now I would say you need to know how to ask it, and it will be enough. I was like, “GitHub is failing with a 504, abstract away all GitHub calls and retry.” It did it in two minutes. With today’s models, it’s a matter of minutes, not hours.

What did you learn about the trade-off between cost, speed, and coverage?

Vojin: I haven’t seen a situation when doing something with an LLM is more expensive than doing that by a human typing on the keyboard. Build a system that uses the most efficient LLM for the job — you’re going to get far and not cost much money at all.

When does using multiple agents make sense?

Vojin: Where I use it is for decisions and research. I use Claude Opus 4.7, Gemini 3.1, and GPT 5.5. I ask them all, let them discuss, and I discuss together with them. Each brings something to the table. Before, it was always Claude who was the smartest. Now GPT 5.5 is second and close to the first. Things are changing. The most important bit is getting the system designed right. Once you do that, coding, I don’t care who does it.

The post Teaching AI Agents to Test 1,000 Java Libraries – and Letting Them Run While You Sleep appeared first on ShiftMag.

The August 2026 deadline for the EU AI Act is getting close, and companies and developerds building AI products are starting to feel it.

High-risk AI systems need to be compliant by then, and the ones doing it well aren’t treating it as a last-minute legal scramble. They’re building compliance in from the start.

We sat down with Ervin Jagatic (AI Business Unit Director, Infobip) to talk about what that actually looks like at Infobip, and why compliance-by-design is turning into something engineers think about, not just lawyers.

Compliance starts in the design phase

AI Act compliance doesn’t start at deployment. Ervin is clear on this: it has to enter during system architecture, before a single line of agent code is written:

Compliance enters during the design phase – system architecture, data flow planning. Every layer of our AI Agents product, from planning to memory to tool execution, needs to be designed with traceability and human oversight in mind. We can’t bolt that on after the orchestrator is already coordinating multiple sub-agents autonomously.

The AI Act is changing product development in 3 ways

That shift has already changed how Infobip’s teams design and ship AI-powered features. Ervin points to three major changes that came directly from the AI Act.

1. Transparency and auditability

Transparency is the first. Infobip’s AI Agents documentation is explicit: “you cannot script exact responses” – agents “generate responses dynamically.”

That unpredictability is exactly why the company expanded its logging and analytics infrastructure, Ervin explains:

The AI Act’s transparency obligations pushed us to build comprehensive logging into our Insights and Analytics layer. Every agent execution now produces detailed logs – requests, responses, processing steps. That’s not just good engineering, it’s a direct response to auditability requirements.

2. Explicit guardrails instead of assumptions

The second shift relates to behavioral boundaries and guardrails. Infobip now requires customers to define capability boundaries, mandatory restrictions, and compliance rules directly inside every agent’s system prompt, Ervin points out:

Our own documentation warns that if you do not explicitly define these constraints, the agent makes assumptions. That design philosophy, forcing explicit guardrails rather than relying on implicit model behavior, comes directly from the Act’s emphasis on risk mitigation by design.

3. Human oversight is a part of the architecture

The third shift is human oversight – not as an external policy layer, but built directly into the product architecture. Ervin explains:

AgentOS uses a human-in-the-loop model where complex issues are escalated from AI agents to human agents. We are talking about a core architectural decision that applies human oversight requirements while also improving the product.

Why compliance-by-design is becoming the standard

Ervin believes compliance-by-design is quickly becoming the new industry standard, particularly for teams building enterprise-grade AI systems:

For developers and ML engineers at Infobip, compliance-by-design means several practical things. It means every AI agent we build has a defined architecture where an orchestrator coordinates sub-agents, each with explicit scope, tools, and behavioral rules.

It also changes how engineering teams think about data. “It means our engineers think about data lineage and provenance from the moment they design a training pipeline, not because someone from legal asked them to, but because the architecture demands it,” Ervin points out.

To support that approach, Infobip invested heavily in tooling and analytics infrastructure that now serves both operational and regulatory purposes, Ervin said:

Our Insights and Analytics platform is our compliance infrastructure. When a regulator asks ‘show me how this AI system made this decision,’ we need to answer that question with structured evidence, not anecdotes.

Risk assessment depends on the use case

Internally, the company approaches risk assessment through a framework closely aligned with the AI Act’s four-tier classification model: unacceptable, high, limited, and minimal risk. However, Ervin notes that Infobip applies this framework at the feature level rather than only at the system level:

This is important because a platform like Infobip’s serves vastly different use cases. An AI gamification tool for lead generation on WhatsApp is a fundamentally different risk profile than an AI agent that handles authentication.

The company evaluates risk based on several factors, including the sensitivity of the data involved, the autonomy of the AI component, and the intended use case, Ervin explains:

Our internal process follows a lifecycle approach. During identification, we map known and foreseeable risks, including risks from reasonably foreseeable misuse. During estimation, we assess probability and severity. During mitigation, we implement design controls, testing procedures, and human oversight.

Monitoring continues after deployment through analytics infrastructure designed for drift detection, incident investigation, and performance tracking. For enterprise customers, risk assessment also becomes a collaborative process between Infobip and client compliance teams.

A bank using our AI agents to automate customer support has different risk considerations than a retail brand using the same technology for product recommendations. The platform is the same; the risk profile is not.

August 2026 is approaching…

As August 2026 closes in, Ervin says the conversation has shifted:

The question is no longer whether to integrate compliance into product development. The question is whether you’ve built the infrastructure to do it at speed.

The post How Developers Should Build AI Tools – So The EU Doesn’t Lose IT appeared first on ShiftMag.