“Voice AI is an infrastructure problem because voice itself is an infrastructure problem,” says Kosta Pribić, a Senior Principal Engineer at Infobip.

He works with voice services – real-time communications across the globe, across multiple data centers, and for everyone reachable on the planet. Yep, it’s a lot.

That scale makes voice AI a much more complex challenge than developers might initially expect.

Developers can take control of the call in real time

Kosta sees voice AI as a two-layer system. Smaller models built into phones can handle real-time issues like packet loss and background noise. They should do their work quietly in the background, so the device just feels like it works.

Larger models, meanwhile, usually run in the cloud and need access to the audio being exchanged between devices. That’s where Infobip comes in: it provides the communications infrastructure developers need to process that audio in real time.

We give you control over the call. We enable you to interject, do something smart with the media.

He says a lot of the infrastructure behind this, from global data centers to enterprise deployments, was originally built for web pages. But web pages aren’t real-time communication.

So when teams use that infrastructure for voice AI, they end up carrying over decisions that were made decades ago. Those systems weren’t built for a live AI-assisted call, which means developers are often stuck working around constraints they probably wouldn’t choose if they were starting from scratch today.

Biggest challenges are real-time performance and cost

Developers entering voice AI often expect hallucinations to be the biggest challenge. But Kosta says they usually run into a different set of problems first, like custom signaling protocols, real-time delivery, and tricky networking edge cases. Networks aren’t built for this kind of traffic by default, so for developers without a voice background, it can feel like a completely new set of problems to learn.

“The main problem is understanding all of this. It’s completely new,” he says. That’s why Infobip’s first internally built LLM-enabled application was a voice AI troubleshooter. Kosta sees troubleshooting as a practical place to start, because teams first need to understand the communication problems they’re actually dealing with.

From there, model choice comes down to the business case and the margins. Kosta says a large model can make sense when latency isn’t a major concern and the economics work.

If your business case allows for using huge LLMs and you don’t care that much about latency, great, go for it.

But in most cases, he says, latency matters. Teams may need smaller LLMs to process calls, or fast, lightweight models to handle audio. Cost matters too, especially when a model is running on every call, because a large model can become expensive fast.

Voice AI has to be private, reliable, and real-time

People expect voice-enabled communications to be private and confidential, Kosta says. They also expect calls to be as reliable as the telecom services they already use, which he describes as operating at “five nines.” Once that trust is lost, it’s much harder to win back.

For developers who are new to voice, understanding those expectations is part of understanding the system they’re building.

That becomes especially clear in assistive use cases. Kosta points to an Infobip customer using a generative model to create voices for people with damaged vocal cords:

They can speak in a whisper while the person on the other end hears the generated voice. That’s, I think, the most heartwarming implementation I’ve ever done.

In the end, before choosing a model, developers need to understand how a call works, where it can break down, and how much delay and cost the application can handle. Even the best model won’t help if its response can’t make it back to the caller in time.

The post The Real Problem in Voice AI Is Latency appeared first on ShiftMag.

Luis Velasco, Forward Deployed Engineer at OpenAI, says we’re entering a new field: meta software engineering.

Instead of building software that follows a predefined sequence of operations, engineers now need to build the systems around AI agents giving them context, tools, skills, constraints, and ways to evaluate their work.

The hardest part is always the context

Code is easier for AI agents to work with. A codebase is structured, and the results are easy to check because the code compiles and tests pass. Business workflows are a lot messier, Luis explains:

In business workflows, the context is fragmented and spread across people and systems. A Slack message may explain why a decision changed, a legacy application may hold the data state, and an experienced colleague knows the part nobody wrote down. The work item we’re trying to automate depends on all of that.

For an agent to perform that work, engineers first have to reconstruct the context in which the work happens. Velasco breaks this down into three elements: data, processes and systems.

Data gives the information and domain knowledge for decisions. Processes define the rules, exceptions, and timelines. Systems provide the apps and APIs that let the work get done, with the right permissions.

The agent needs a context layer that stays current and gives it the information relevant to the task. Processes can be turned into agent skills, while APIs and other systems give the agent the ability to execute the work. Velasco showed this with an insurance claims workflow: the agent read an email and attachments, checked information across multiple apps, verified the claim, calculated the settlement, and prepared the response in 22 seconds instead of 20 to 30 minutes.

Everything works fine until it has to run at scale

Getting one agent to complete a workflow is just the beginning, because the real challenge starts when that workflow has to run at scale. Then agents have to work in parallel, workflows can become interconnected, and one agent’s result can become the input for another:

This can be handled with agents and sub-agents that share context, or with an independent environment where agents can read and write shared state. That state helps them recover what has already been done and figure out what needs to happen next.

That’s why the infrastructure around the agent matters: queues, worker processes, checkpoints, and an artifact store with results, evidence, and reports. The goal is a durable execution environment that can recover if something crashes and avoid doing the same task twice.

Multi-agent systems need more than extra model calls

Velasco showed what this looks like at a much larger scale with an experiment focused on CPU design: a campaign controller spread goals, budgets, and work across different CPU domains, with 512 agents working on areas like arithmetic, memory ordering, and control flow.

The agents, he explained, had different roles: some looked for potential bugs, critic agents challenged their findings, and verification agents tried to reproduce them. The campaign ran for four days, used about 1.4 terabytes of data, and produced evidence that could be shared with verification engineers before a problem reached production.

It shows that multi-agent systems need coordination, shared state, verification, and a way to manage work across many agents, not just extra model calls.

The system can learn without changing the model

Another important part of Velasco’s approach is that the model itself doesn’t always need to get more capable for the whole system to improve. He compared it to an experienced employee:

A senior employee may have the same basic intelligence as when they joined a company, but after years of experience they know the systems, common failure modes and small details that make them more effective.

For an agent, that experience lives in the system around the model.

Updated context can provide relevant knowledge, updated skills can refine how work is performed, and evaluations can check behaviours that need to be verified. The model weights may stay the same while the system around the model gets better through repeated execution.

Velasco said successful runs, failures, and human corrections all help here. Successful runs show what to reinforce, failures show what needs improvement, and human corrections reveal gaps in the agent’s skills. Over time, those patterns can update memory, context, skills, or evaluation sets.

He showed this with a tax preparation agent: it started by completing about 25% of the required fields, and after six weeks of repeated runs, evaluations, and skill updates, it reached nearly 90%.

Engineering will become meta software engineering

This changes the engineer’s role. As more execution is delegated to agents, engineers spend more time designing and improving the system doing the work. But engineering doesn’t disappear, humans still set the goals, make the trade-offs, and decide where human intervention belongs.

That leads to Velasco’s broader definition of what engineers are building in an AI-assisted environment:

The highest value software artifact that we may be creating is not the code base itself, but the system of intent, the constraint, and the evaluation from which code can be produced in a systematic and repeatable way.

He calls this emerging discipline meta software engineering: building the environment around AI so agents have the right context, tools, skills, coordination, and feedback to do the work and get better over time.

The next chapter of software engineering is about building the systems around the code.

The post OpenAI Says the Real Work in AI Coding Is Building the System Around It appeared first on ShiftMag.

If AI can already draft code, fix bugs, and untangle unfamiliar systems, what’s left for junior engineers to learn the hard way?

We spoke with three experienced engineers: František Lučivjanský (Senior Principal Engineer), Kevin Antonio Moreno Melgoza (Senior Quality Engineer) and Maida Barlić (Staff Engineer), about how AI is changing the way junior developers learn, work, and build software.

Does speed in coding translate to speed in learning?

AI can help junior developers ship working code much faster than before. But the bigger question is: does writing code faster also mean learning faster? Our panelists have different views.

Kevin argues that AI does not accelerate learning. Programming, he says, is still learned through trial and error, while AI makes it easier to complete tasks without fully understanding them. Junior developers are particularly exposed because they are still building the foundations of their craft:

Developers who started before the AI era already went through that stage and learned by doing, so they already built that foundation. Juniors are still building it, so if they rely too much on AI, there is a bigger risk of skipping part of that process and ending up able to build things without fully understanding them.

František agrees that this risk exists, but believes AI can become a powerful learning tool if developers actively question its answers instead of simply accepting them:

Ask questions like: how does this work, what does this line mean, why is it done this way, what alternatives exist, can you explain it step by step, and can you quiz me about it afterwards? I would frame it like this: if we go into a meeting together and I ask you technical questions about the solution you built, can you explain it without AI? If yes, you are using AI well. If not, then you are only generating code, not really engineering the solution.

Maida also sees AI as a tool whose impact depends on how it is used. While it can encourage shallow learning, she points out that developers have long relied on frameworks without fully understanding how they work. Used intentionally, AI can make complex concepts easier to grasp:

I do think that AI can be very useful for learning because it can make concepts much easier to digest and help you understand them in a way that makes the most sense for you. You can also use it just to give you example of how to solve the problem, but still writing out code by hand as a part of the process of learning to be better developer.

In the end, all three agree that AI is just another tool. Whether it becomes a shortcut that weakens understanding or a tutor that accelerates learning depends entirely on how developers choose to use it.

Can you spot AI-generated code?

Experienced engineers can often tell when junior developers have leaned heavily on AI. The giveaway is code that works, but does so in a way that’s far more complex than it needs to be.

Kevin says AI becomes obvious when a simple task turns into an overengineered solution. It can help developers get through problems they might not have solved alone, but whether they actually learn from it depends on how they use it:

That can be very useful but the weakness is that learning becomes optional. It depends on the person, and some will use it as a way to learn, while others will just use it to finish the task and move on.

František has noticed similar patterns. AI often produces code that looks polished and well-structured, but he warns that appearance can be misleading. The real challenge is that AI tends to optimize for solving the immediate problem rather than considering the broader software architecture:

That is exactly why software engineers are still needed. Working code is not enough. We need people who can judge whether the solution is understandable, maintainable, and appropriate for the system.

Maida believes spotting AI depends on the size of the change. Small AI-assisted edits often blend in, while larger contributions can reveal familiar patterns. Like Kevin, she sees unnecessary complexity as a recurring weakness, although she also values AI for suggesting improvements and alternative approaches:

In my experience also, one common weakness is that AI code can be overly complicated for something simple. It can also sometimes suggest outdated approaches or use parts of a framework in a way that isn’t the most current. On the other hand, one of its biggest strengths is that it can suggest improvements, point out better ways to solve a problem, or offer ideas I might already be familiar with but haven’t thought of right away.

There are skills AI can’t learn for you

While AI can speed up development, the panelists agree that some skills still have to be learned the traditional way. Juniors still need solid programming basics to tell when AI is giving you the right answer – and when it’s confidently giving you the wrong one.

Kevin says junior developers should first understand the basics of the language, the framework, and the development practices they use. Without that foundation, it becomes much harder to tell whether AI is actually giving them a good solution:

A solution can work, but still not be what was really asked for, or not fit the project well. To identify that, you need that base knowledge.

For František, debugging is one of the most valuable skills juniors can develop. Learning to trace bugs, understand unfamiliar code, and reason through problems without immediately reaching for AI builds intuition that no language model can replace:

When I was junior, I recreated parts of frameworks just to understand how they worked internally. Today, AI can make that even more powerful. For example, try building your own small browser, framework, database, or even a simple LLM-related project. You will learn a lot, but only if you are not just letting AI do everything for you.

Maida also emphasizes reading code and debugging as essential skills. Even with AI writing parts of the implementation, developers still need to review pull requests, understand existing codebases, and verify that the final solution actually solves the problem:

It’s also important to learn how to test and verify your work, because AI can help you write code, but you still need to know whether it actually solves the problem. In the end, you should be able to start from any part of the codebase and work your way toward the problem.

What will companies look for in junior engineers?

While AI is changing how software is built, the panelists agree that it is also changing what companies will expect from junior engineers. Writing code will become less of a competitive advantage, while understanding, reasoning, and sound judgment will become increasingly valuable.

Kevin believes programming fundamentals will remain essential, but deep knowledge of a specific technology will matter less than the ability to think critically and evaluate whether a solution is actually the right one:

An expert in one technology can solve the same task as a junior with AI. Because of that, I think companies will value more people who can think critically, understand what is being asked, and judge if a solution is actually good or not. So strong fundamentals and good judgment will become more important, while knowing very specific details of one technology will become less important.

František expects coding skills to remain important, but no longer as the primary differentiator. Instead, he believes the strongest junior engineers will be those who can use AI effectively while understanding the tradeoffs behind every decision they make:

The strongest juniors will be able to say: “I tried multiple approaches, compared the tradeoffs, and I think this one fits best because…” So the signal will shift from “I can write code” to “I can use AI to build faster, but I understand what I built and can defend the decisions.”

Maida agrees that AI will make technical judgment even more valuable. Faster code generation does not reduce the need to understand systems, debug problems, or recognize whether AI has produced a correct and maintainable solution.

I don’t think technical depth becomes less important, if anything, it becomes more important to know what good code looks like and how to judge whether AI-generated code is actually correct.

Special thanks to our fellow colleagues at Infobip, the publisher of ShiftMag.dev, who participated in this article.

The post AI Is Making Junior Developers Faster, But Is It Making Them Better Engineers? appeared first on ShiftMag.

For most people, NVIDIA means GPUs. But at WeAreDevelopers World Congress in Berlin, CTO Michael Kagan barely mentioned them.

Instead, he focused on the infrastructure behind AI: networking, energy, software, data centers, robotics, and the massive engineering challenge of scaling it all. NVIDIA’s framing was clear: modern AI is no longer just hardware – it’s an “AI factory.”

AI is changing how people interact with computers

Kagan compared AI to past tech revolutions. Electricity came through a wall socket. Cloud computing put infrastructure on demand. Now AI is changing the interface again making computers accessible through natural language instead of code.

Before AI, only a few million people on Earth could operate computers by programming them. Now everybody can program the computer and run the AI, and if you don’t know how to do it, just ask AI. It will tell you.

In other words, users no longer need to understand the technical details behind computing. If they’re unsure how to do something, AI can often explain it or do it for them.

Kagan framed AI less as a software category and more as a new computing layer that expands access to technology. The computer stays the same – the interface between people and machines is what’s getting much simpler.

How NVIDIA linked thousands of GPUs

One of the most interesting parts of the discussion focused on Mellanox, the networking company Kagan co-founded in 1999 before NVIDIA acquired it in 2020.

Mellanox was originally built for large-scale cloud computing, helping connect servers across massive data centers. But as AI workloads grew, that networking layer became even more important because the challenge was no longer just building individual processors, but making thousands of them work together efficiently.

That’s why Kagan says modern AI systems should be viewed as single computers made up of huge numbers of GPUs spread across racks and data centers:

The computer is not a box under the table anymore.

That made the Mellanox acquisition strategically important: it gave NVIDIA the networking needed to connect GPUs and train larger AI models at scale.

AI factories turn energy and data into intelligence

Kagan repeatedly used the term AI factory because, in his opinion, it better describes the role modern AI infrastructure plays.

Traditional data centers store data and process requests. AI infrastructure does something different: it uses huge amounts of data and power to train models and run inference across applications. “AI factories take the energy and the data and convert it to intelligence”, says Kagan.

He compared the process to a power plant generating electricity. It’s a metaphor, but it captures how NVIDIA sees AI infrastructure: as a production system where intelligence is the output.

When asked what an AI factory looks like, Kagan said:

The first thing you notice when you go to the AI factory is cables.

Those cables connect hundreds, thousands, and eventually millions of GPUs into one computing environment. NVIDIA breaks that challenge into two parts: scale-up, which links GPUs with NVLink, and scale-out, which connects those systems into massive clusters.

As those systems grow, networking becomes essential. Every processor has to stay in sync, and NVIDIA says lowering the cost of generating AI tokens remains one of its key goals.

AI is now limited by software and power, not just chips

AI performance used to improve mainly as hardware improved, but Kagan says the challenge is now more complex.

A big reason is the rapid growth of inference. Traditional computing follows a simple pattern: a user sends a request, the computer processes it, returns a result, and waits for the next instruction. Agentic AI works differently, with models constantly exchanging information with software tools and other services while completing tasks. That creates far more communication inside the data center.

Those interactions happen much faster than humans can issue requests, while Moore’s Law is slowing down. That means smaller and faster transistors alone are no longer enough to meet demand.

That is why building larger processors alone is no longer enough to keep up with growing AI workloads. According to Kagan, CUDA has become one of NVIDIA’s biggest long-term advantages because it allows developers to fully exploit the company’s hardware:

Chips without software are just expensive sand.

He explains that NVIDIA wants to give developers a stable platform while the hardware keeps evolving. Too much general hardware can be inefficient, but too much specialization can quickly become outdated. CUDA gives developers the flexibility to support new workloads without starting from scratch.

Power is another major limit. Kagan said electricity is now one of the biggest constraints on new AI data centers. NVIDIA is working on ways to connect multiple sites over long distances so they can act like one system, with training done where power is available and inference closer to users.

Progress in AI depends on understanding complex systems

The session concluded with advice for young engineers: rather than recommending a specific programming language or AI framework, Kagan encouraged students to develop strong foundations in mathematics, physics and chemistry before specializing.

He also reflected about his childhood curiosity, saying he used to take new toys apart just to see how they worked. If he were starting school today, he said he’d seriously consider studying digital biology, since understanding the human body is still one of the most fascinating engineering challenges:

The most complicated machine that is out there is a human.

Even though the conversation touched on GPUs, networking and AI infrastructure, Kagan kept coming back to one idea: progress in AI depends on understanding complex systems. Whether that’s millions of processors, distributed data centers or the human body, engineering starts with curiosity and a desire to figure out how things work.

The post NVIDIA CTO Says AI is Now About Software, Networking And Power – Not Just Chips appeared first on ShiftMag.

What began as an internal hackathon project, where a small team at Infobip set out to create and launch a marketing campaign for a fictional chocolate brand using AI agents, evolved into the company’s first MCP servers running in production.

At Devoxx UK, Filip Srnec, Principal Engineer at Infobip and lead of the company’s MCP team, explained how they built the OpenAPI MCP Spring Boot Starter, a tool that turns any OpenAPI-documented API into a fully capable MCP server, without the need for rewrites or custom integration code.

Why not just build custom MCP servers?

Filip kicked off his talk by asking the audience if anyone had an HDMI adapter so he could point out a common challenge in technology:

Protocols evolve, and systems don’t necessarily upgrade in sync.

Most of the systems AI agents need to interact with today already expose REST APIs. REST APIs helped us build the world that we now today. Mobile apps, smart devices, command-line tools, and interactive user interfaces all rely on them, running on top of decades of standards, tooling, and shared knowledge. Now AI agents need a way to use that same infrastructure.

MCP, announced by Anthropic in November 2024, was positioned as “a USB-C port for AI applications.” That immediately raised the question of whether every existing API (the HDMI cable) would now need custom glue code (an adapter) to become agent-accessible.

Infobip’s answer was no.

The OpenAPI connection

The breakthrough came when the team compared the structure of an MCP tool with an OpenAPI operation. The two map directly onto each other at the field level. MCP tools define elements such as a name, title, description, input schema, and annotations, while OpenAPI operations include an operation ID, summary, description, parameters, and request body. Comparing the two side by side shows that most OpenAPI operation metadata already has a direct equivalent in MCP:

The name can be an operation ID, because operation ID uniquely identifies an operation in the specification. For a title, we can use a summary. Description is obvious. We have a way to define the input schema by combining parameters and the request body.

Infobip already had OpenAPI specifications for all of its public APIs. Since those specifications were powering the company’s API platform and SDK generation process, building a bridge to MCP made more sense than creating custom servers from scratch.

Let’s take a look at how the OpenAPI MCP Spring Boot Starter works in two phases.

How the framework works

The process begins by reading the OpenAPI specification and turning it into MCP-compatible tool definitions. Because the connection is dynamic, updates to the API are reflected on the MCP side as well.

At runtime, on every tool call, the framework validates credentials, maps tool arguments to HTTP requests, enriches and forwards those requests to the downstream API, handles errors, and returns the result to the agent.

The setup is intentionally minimalistic. It requires only the OpenAPI specification URL and the base URL of the API being exposed. As Filip explained:

You just point it at your OpenAPI specification, and your API instantly becomes an MCP server. This is something that we’ve been running in production for months now.

Not every endpoint should become a tool

Filip pointed out that exposing an entire API surface to agents is a bad idea. Irrelevant operations add noise, increase costs, and can mislead the model. A larger surface also extends the potential attack surface for prompt injection.

The framework tackles this through an OpenAPI filter chain. Before tools are exposed through MCP, developers can adjust the specification. That means removing endpoints, tweaking schemas, or changing how operations are presented. The good thing is that this approach works even when the API is maintained by someone else.

One example involved OpenAPI’s discriminator feature. It is commonly used to select different schemas based on a property value, making server-side validation more flexible. The catch is that discriminators are not valid JSON Schema constructs, while MCP tool definitions require strict JSON Schema compliance. To solve the problem, the framework automatically rewrites discriminator-based schemas into oneOf structures that MCP clients can consume without issue, Filip explained.

Unfortunately, exposing the right tools solves a part of the problem. For an AI agent to use a tool correctly it needs to understand both what the tool does and when to use it.

Naming, descriptions, and making agents actually use your tools

LLMs select tools based on names and descriptions and both matter more than most developers realize.

The framework gives developers several ways to name tools. They can keep the original operation ID, use a simplified version with special characters removed, or generate a name from the API endpoint itself when no operation ID is available. It also includes safeguards for clients that impose strict limits on name length.

Tool descriptions require just as much attention because every description from every connected MCP server is loaded into the model’s context. These descriptions need to be concise and easy for AI agents to interpret. The framework can enrich them with summaries and examples from the OpenAPI specification, which Filip highlighted as especially useful when matching requests to input schemas.

The tools, however, still need to work with existing authentication and authorization systems.

Solving authentication without reinventing it

Authentication has been one of the more debated aspects of MCP and because of that the framework takes a pragmatic approach by relying on existing mechanisms rather than new ones. Filip explained:

Your API already knows how to perform authentication and authorization. It knows how to reject bad credentials.

Instead of introducing a separate authentication layer, the framework forwards credentials to a configurable endpoint that already handles it. As a result, any method supported by the underlying API, whether API keys, basic authentication, or JWTs, works through the MCP server as well.

For OAuth, the framework proxies OpenID configuration calls and authorization requests to a configured OAuth server, and performs automatic scope discovery from the OpenAPI security definitions:

To have full OAuth support, you need to point it at your OAuth server. And you’ll get minimal scope discovery automatically directly from the framework.

It is important to mention that building the features was, once again, only part of the story. The team was also developing the framework while the MCP ecosystem itself was still taking shape.

Building on a moving train

Filip was candid about the challenges the team faced. As Infobip was building and shipping the framework, the MCP specification evolved, with changes affecting everything from transport mechanisms and authentication flows to client behavior:

Sometimes we need to pick between features and compatibility. We decided that we wanted to move fast. We wanted to be in that space. The spec was still being written while we were shipping production code.

Along the way, the team had to deal with a growing list of compatibility issues. Different clients imposed different limits on tool name lengths, some sent nested objects as escaped strings instead of valid JSON, and OAuth implementations often behaved differently despite following the same specification:

My point here is that sometimes you can’t wait for the ecosystem to mature. You ship and you adapt.

The demo

Filip wrapped up the session with a demonstration. Using the framework, he connected an OpenMeteo weather forecast server and Infobip’s production SMS MCP server, then showed how an AI agent could retrieve the next day’s weather forecast for London, generate a short summary, and send it as a text message. The point was how quickly an existing API could be turned into an MCP-compatible service. As Filip put it:

Your API may already be a hidden MCP server. Try to use this framework, point it at your specification, and ship it.

• Listen to Filip’s entire talk on YouTube
• The framework and examples are open source and available on GitHub.
• Infobip’s production MCP server is accessible at mcp.infobip.com.

The post Your API Is Already a Hidden MCP Server, You Just Need to Discover It 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 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.

Welcome to the engineering hierarchy of one of the world’s biggest tech companies, with nearly 200K employees… and I’ll be your guide.

Since Amazon doesn’t publicly publish an official breakdown of its career levels, I reviewed various sources such as Dev.to articles and salary websites.

To start with, AWS is famous for a decentralized, high-ownership environment where engineers don’t just write code, they must run what they build. Understanding the AWS career ladder is essential for any developer looking to enter the ecosystem that powers over a third of the cloud.

The AWS leveling system

Amazon (and by extension AWS) uses a structured leveling system that spans from L1 to L12. However, most software engineers operate between L4 and L8, with higher levels reserved for a very small number of highly influential technical leaders.

While some companies hire engineers at lower levels, AWS typically starts its professional software engineering track at L4.

Level 4: Software Development Engineer I (SDE I)

The SDE I position at Amazon serves as the foundational entry point, typically designed for recent college graduates or engineers with limited professional experience. At this stage, the primary focus is on building a robust technical baseline. You are responsible for hands-on coding and debugging within well-defined tasks, contributing to the development of small features that integrate into larger projects.

While you are expected to deliver high-quality code, you aren’t expected to do everything yourself. AWS has a heavy emphasis on mentorship at this level. Because of that SDE I engineers receive significant guidance from seniors to help them navigate complex systems and understand specific development tools and practices. It is a period of incremental skills development.

Level 5: Software Development Engineer II (SDE II)

SDE II engineers are often the backbone of the company’s engineering organization. At this stage, it’s all about being fully self-sufficient. SDE IIs are expected to manage their own workloads with minimal supervision, prioritizing tasks effectively to deliver consistent, high-quality results.

Beyond just executing tasks, SDE IIs begin to take ownership of larger systems and components. They are responsible for designing and implementing solutions that specifically meet Amazon’s high standards for scalability, performance, and reliability. This is also the level where your influence begins to expand beyond your code, you start acting as a mentor to L4 engineers and begin coordinating on cross-functional projects.

Level 6: Senior Software Development Engineer (SDE III)

The Senior SDE role is an advanced position reserved for experienced engineers who have demonstrated strong technical and leadership capabilities. At this level, the scope of responsibility expands beyond individual contributions to owning larger systems and leading complex projects.

Senior SDEs are expected to design scalable architectures, make high-impact technical decisions, and guide the work of other engineers on their team and adjacent teams. Their influence is significant, though typically focused within a team or a group of closely related teams.

Level 7 & 8: Principal and Senior Principal Engineer

Levels 7 and 8 represent the elite tier of engineering talent at AWS. As a Level 7 (Principal Engineer), you move into a strategic role, shaping the technical direction across multiple teams or an entire organization. They work closely with senior leadership and are responsible for solving complex, high-impact problems that affect large parts of the business.

The Senior Principal Engineer (L8) sits at the pinnacle of technical innovation. These engineers define long-term technical vision for major areas of AWS, often influencing hundreds of engineers indirectly through architecture, standards, and strategic initiatives.

Level 10: Distinguished Engineer / VP

Beyond Level 8, the roles become extremely rare. It’s reserved for a small group of engineers with company-wide or industry-level impact. These roles focus on setting long-term technical direction, solving the most complex architectural challenges, and influencing Amazon’s strategy at the highest level.

Level 10 is reserved for world-renowned visionaries and thought leaders who have a remarkable track record of technical excellence. They are responsible for identifying future technology trends and anticipating market shifts years before they happen. They set the architectural principles and technical standards that position Amazon as a continued leader in the industry. As mentors to the company’s highest technical leaders, they foster a culture of innovation that ensures AWS remains at the cutting edge of what is technologically possible.

What makes AWS levels different?

1. Leadership Principles (LPs) as a metric

Technical ability alone is not enough for promotion. Engineers are evaluated against Amazon’s Leadership Principles, which are used as a framework to assess impact, decision-making, ownership, and long-term thinking. As engineers progress through levels, they are expected to demonstrate these principles with increasing scope and consistency. Promotion depends on how well your work maps to multiple principles, not just one.

2. The power of the “Doc”

AWS is a famously “silent” company. They don’t use PowerPoints, they use 6-page memos. Your ability to move from L5 to L6 depends heavily on your writing. Can you argue your architectural choices in a structured, data-driven document? If you can’t write, you can’t lead at AWS.

3. Total Compensation (TC) structure

AWS compensation is uniquely structured compared to Google or Meta. While they have recently increased base salary caps, a large portion of your wealth comes from RSUs (Stock) with a 4-year vesting schedule:

• Year 1: 5%
• Year 2: 15%
• Year 3: 40%
• Year 4: 40%This “back-loaded” vesting is designed to reward those who stay and grow through the levels.

AWS salary expectations (2026 estimates)

To provide an accurate picture of what these roles pay, we analyzed the latest 2026 data aggregates from Levels.fyi and 6figr.com, which utilize verified salary stubs from engineers in major tech hubs. Compensation at AWS varies significantly depending on team, location, and negotiation, but follows a consistent structure of base salary, bonus, and stock (RSUs).

Note: These figures reflect top-tier offers in high-cost US markets. For European hubs like Dublin, Luxembourg, or Berlin, expect a 15-25% reduction in base cash, though stock grants remain aggressive.

Is the climb worth it?

The AWS ladder is demanding and often associated with a high-performance culture. Engineers who progress through it tend to develop strong ownership, system design skills, and operational discipline.

While experiences vary by team, time at AWS is generally seen as a strong signal of technical capability and execution, particularly at senior levels. For those who align with its culture, the system offers a clear path for growth.

The post Inside the AWS Hierarchy: Engineering Levels Explained appeared first on ShiftMag.

For Mackenzie Jackson (Developer and Security Advocate, Aikido Security) modern security is a nonstop game of whack-a-mole, with alerts and vulnerabilities keeping teams busy putting out fires instead of preventing them.

But that chaos of cybersecurity is familiar territory for him: he investigates attacks and helps teams turn those findings into actionable steps.

But strip away the complexity, and his advice on security is surprisingly simple:

One of the biggest areas for smaller teams to focus on is simply stopping the bleeding.

You don’t need a flawless system, you need to regain control, and by implementing proactive measures companies neutralize threats before they ever touch production. It’s not a complete solution, but it’s a necessary foundation.

Cybersecurity rests on two pillars: people and access

From the outside, cybersecurity looks like a web of interconnected threats and technically, and it is. But when incidents are investigated, the story tends to collapse into something much more… human:

When you actually investigate a breach, what happened? Well, someone was probably phished, their credentials stolen, and that gave access to a system.

From there, attackers escalate, finding additional credentials, uncovering secrets, moving laterally through systems. Despite all the layers of technical complexity, most breaches still come down to two variables: people and access. This doesn’t make security easy, but it does make it clearer.

Brakes make race cars faster – and security works the same way

One of the oldest problems in cybersecurity is organizational: How do you convince leadership to invest in something that, ideally, prevents things from happening?

Fear is the usual tactic so you talk about reputational damage, financial loss, worst-case scenarios. It works, but only to a point and that is why Jackson suggests a different framing:

Brakes make race cars go faster.

It’s a counterintuitive analogy, but an effective one: without brakes, speed becomes dangerous. With them, drivers can push harder, take sharper turns, and move faster with confidence. Security, in this sense is an enabler:

If we build security now, we can innovate faster… establish your brakes so that you can go faster with confidence.

The alternative, adding security later, under pressure from compliance or customer demands almost always slows teams down.

Security tools are here to stay, but AI gives them context

The arrival of AI introduced a pattern: urgency first, understanding later.

After tools like GPT entered the mainstream, companies rushed to integrate AI into their security products. But much of that early adoption, Jackson suggests, was surface-level. The real value of AI lies elsewhere:

AI is a terrible scanner… but it’s great at understanding context.

Traditional security tools are deterministic and that is why they answer yes-or-no questions. Is there a vulnerability? Does this code contain a known issue? AI, by contrast, is non-deterministic. It doesn’t always give the same answer twice and that makes it unreliable for detection, but powerful for interpretation:

If you give it vulnerabilities and ask how severe this is, how exploitable it is that’s where AI becomes incredibly useful.

In other words, AI doesn’t replace security tools. It complements them, helping teams prioritize what actually matters.

AI doesn’t make attackers smarter, it makes attacks easier

So if AI isn’t fundamentally changing how attacks work, what is it changing? Scale.

AI has given script kiddies superpowers.

This phrase captures the shift precisely: AI doesn’t necessarily make attackers more skilled, it makes attacks easier to execute, faster to launch, and accessible to a much larger pool of people. But the core mechanics of attacks remain the same:

It’s not moving the bar up… it’s changing the scale.

And that, perhaps, is the most important takeaway. Because if the nature of attacks hasn’t fundamentally changed, neither has the foundation of defense. Good security hygiene. Strong access control. Protecting the software development lifecycle, Jackson points out.

The tools may evolve. The threats may accelerate. But the principles still hold

The post AI Won’t Replace Security Tools – It’s Helping Them Prioritize Biggest Threats appeared first on ShiftMag.