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.

Remembering Christmas 2016, when she received her first Alexa device, Gillian Armstrong was fascinated by the idea of a technology that no longer needed humans to understand it – but instead had to understand us.

With this story, the Senior Solutions Architect opened her session at How To Web, illustrating just how far artificial intelligence has come in less than a decade. From chatbots and FAQs to generative and now agentic AI, technology is clearly evolving – from reactive tools to autonomous problem-solvers.

To illustrate this evolution, Armstrong introduced “Dan,” a character based on many industry clients she has worked with:

Dan loves technology. Five years ago, he came back from a conference saying how we need to use AI in everything. Two years ago, it was generative AI in everything. And earlier this year, he stared saying what really matters now is agentic AI.

Through Dan’s story, Armstrong walked through the stages of adoption and the pitfalls that come with rushing to embrace the latest AI trend without thinking about the actual business problem.

4 principles for building agentic AI systems

Armstrong framed her talk around four guiding principles that any business should follow when considering AI systems that can act autonomously.

1. Understand your models

Not every use case requires generative AI. Many problems can still be solved with simpler and cheaper tools, Gillian points out:

If your chatbot is really simple, you don’t actually need to move to a generative AI chatbot.

Different models vary in cost, speed, and suitability. Choosing the wrong one can increase complexity without improving outcomes.

2. Balance your risks

Generative and agentic systems come with new challenges like unpredictable responses, bias, and even manipulation attempts from users. That’s why evaluation frameworks and guardrails must be built in from the start:

You need to build your systems thinking about responsibility and safety and security upfront.

Armstrong highlighted the importance of internal testing, human-in-the-loop setups for early deployments, and guardrails that can intercept off-topic or harmful interactions.

3. Your fundamentals matter

Agentic AI relies on tools, databases, APIs, document repositories to actually perform tasks. Without those business systems being accessible and modular, AI agents remain just “fancy FAQ pages”:

Those tools are gonna make your agent so much more powerful… but remember, it’s going to be able to do things. So don’t give it too much access to everything.

Armstrong stressed the need for modular business components, exposed through APIs, as the foundation for any scalable AI strategy.

4. Embrace agility

The AI journey is not about tearing down existing systems, but evolving them step by step. Businesses should integrate new technologies gradually, keeping systems flexible for future updates:

Fit the technology to your business problem. Don’t try to find the problems to solve with the technology just because it’s new and shiny.

The real break lies in moving from chatbots to true AI agents

Gillian revisited the history of customer service technology. Early websites with FAQ pages gave way to search functions, then to chatbots powered by natural language processing. Adding speech-to-text and text-to-speech made them more interactive, but still rigid. They required pre-defined intents and responses.

Generative AI improved flexibility, but at the cost of control. Large language models can generate natural responses, yet they also introduce risks. That’s why evaluation, guardrails, and careful system design are essential.

Still, Gillian argued, generative chatbots are ultimately just a smarter version of the FAQ. The real shift happens with AI agents – systems that not only understand language, but can reason, make decisions, and act on them.

Take the example of an insurance claims agent. Instead of simply answering questions, the AI recognizes when a customer actually wants to file a claim. It can ask for missing details, access the policy database, and submit the claim itself through connected tools:

Every single one of those thoughts is a call to the model. And that will start to add latency and cost. You need to be aware of that when you’re building an agent.

Because of this complexity and risk, Gillian recommended modularizing agents. Instead of building one super-agent with access to everything, companies should design multiple specialized agents, each with a narrow goal and limited set of tools:

Not only do we need to modularize our business functionality, we need to modularize our agents. We can reuse them in different ways. We can keep our risk low.

Strong foundations – smarter AI

In closing, Gillian reminded the audience that AI adoption should be a journey of evolution, not revolution. Each stage builds on the previous one, and the best results come when businesses align technology with real problems – not the other way around:

Make sure you’re building your systems now so that they’re open and agile, and you can bring these things in.

For businesses wondering how to take the next step, her advice was clear: focus on strong foundations, balance risk with innovation, and design with agility in mind. That way, agentic AI systems can move from buzzword to genuine competitive advantage.

The post How to Build Competitive Advantage with Agentic AI appeared first on ShiftMag.

For years, SaaS companies cruised on easy per-seat pricing and almost-free scaling. Enter AI: every query burns power, every model costs cash, and suddenly startups are in a pricing puzzle.

In his talk Pricing for AI Agents at the How to Web Conference 2025 in Bucharest, Emanuel Martonca (Founder, Pricing Strategist at Soft Fight) dives into why traditional SaaS pricing no longer works – and what it takes to build sustainable business models in the AI era.

Let’s start with an example

Emanuel opens his talk with a simple story:

Imagine you’re an angel investor having lunch with a founder who’s built an AI platform that helps large companies map their employees’ skills.

The founder explains that the tool lets sales teams quickly find experts in niche technologies across the organization, making it easier to sell IT services.

In a company of 10.000 people, sales representatives are often far removed from the engineers doing the actual work. So, when a client in New York asks about a specific technology, the salesperson might have no idea whether anyone in the company has that expertise – or even where to find them.

The founder claims his AI solves this problem in days, not months, and points out the lucrative potential. After all, some companies currently pay almost $400.000 annually for software solving the same problem.

However, Emanuel warns – there are couple of critical considerations when thinking about AI pricing.

Think SaaS, think small. Think AI, think big (and expensive)

AI is fundamentally different from traditional SaaS, explains Martonca. While SaaS benefits from near-zero marginal costs for additional users and high gross margins, AI is computationally expensive:

A single AI query can consume ten times more energy than a Google search. Such costs must be considered in pricing, along with other factors like marketing, positioning, differentiation, and risk

Unlike SaaS, where the main concern might be looking like a glorified spreadsheet, AI introduces far more complex risks.

Traditional SaaS frameworks and mental models don’t translate to AI startups – they require a different approach. In particular, common SaaS seat-based subscription models often fail in the AI context.

As Martonca highlights, AI frequently replaces the very people you might charge for, making seat-based pricing impractical.

Moreover, many AI projects, proofs of concept, pilots, or experiments never reach production:

Every AI pilot that doesn’t go to production represents lost revenue for software vendors, and AI accelerates development, reducing the need for large teams – further impacting legacy software revenues.

Price the problem, not the technology!

Currently, there is no standard model for AI pricing.

Unlike SaaS, where “good-better-best” packages and per-seat subscriptions were well-established, AI pricing is complex and still experimental:

You can price by input, output, outcome, or performance. The choice depends heavily on the problem being solved and the client’s perceived value, rather than purely on technological complexity.

Many founders get caught up in explaining how their AI works so they talk about the models, the architecture, the agents, but clients care most about solving a business problem.

A central lesson is to price the problem, not the technology, Emanuel points out.

In the skills-matching example, instead of charging for the software or the AI engine, the vendor could charge for each successful match of employee to project. This approach shifts risk to the vendor, but aligns price with the value delivered to the client.

Companies used to be product- or service-focused. Not anymore.

Emanuel also highlights the blurring line between products and services in AI. Traditionally, companies were either product-focused or service-focused. AI challenges this distinction.

OpenAI, for example, sells consulting services alongside its technology platform. Delivering outcomes and real business results has become the primary source of value, not just providing access to software.

AI budgets also differ from traditional IT budgets:

SaaS historically took money from IT departments. AI often taps into HR or services budgets, which are significantly larger.

Always start with the customer and their problem

For both startups and established companies, Emanuel’s advice is clear: start with the customer and the problem they need solved. Identify what they value and what they’re willing to pay for – only then design a solution and assess its economic viability.

Most AI vendors currently use a hybrid model: a flat base price for platform access, some included usage, and additional charges based on usage or tokens. It’s a pragmatic – if temporary – solution in an environment full of unknowns. Yet the fundamental principles of pricing still apply:

Understand the value delivered, choose the right metric for your model, and price according to the problem solved, not just the technology deployed.

This is important beacuse getting pricing wrong can be fatal. Companies that adapt their models to reflect value and outcomes, rather than legacy SaaS logic, will be best positioned to succeed in this new era.

The post You Built an AI Agent – But How Do You Price It? appeared first on ShiftMag.

The development environment is undergoing a radical shift at the intersection of software engineering and AI. No longer just about writing clean code, developer experience today is about crafting systems that collaborate with humans and increasingly with AI agents.

This was the central theme of a panel conversation titled “Investing in Dev Tools in the Age of AI” that featured Jesse Robbins (Heavybit), Peter Zakin (Codeium), Kenneth Auchenberg (AlleyCorp), and Ivan Burazin (Daytona) at the Infobip Shift Miami conference.

Speakers first reflected on how developer experience has evolved—from desktop to mobile, from static tools to dynamic, collaborative environments. But as Jesse put it, we’re now entering a new phase where delegation is the new automation.

Traditionally, improving developer experience meant offering excellent documentation, strong community support, clear APIs, and plenty of example code. But today, that’s not enough, Jesse points out:

If you’re building software now, you’re not just designing for humans. You’re designing for agents, too. And they need the same things—documentation, context, and clarity of intent.

Jesse compared the rise of autonomous agents in dev workflows to a new kind of SEO, where developers optimize their tools for discoverability and cooperation with AI agents. Whether it’s delegating tasks, workflows, or entire design processes, success now depends on how well tools can communicate their purpose to humans and machines alike.

Engineers as Fleet Generals

This shift is redefining what it means to be a developer. Kenneth described it in striking terms:

We’re all going from being software engineers writing code to model operators—code composers. It’s like being an art director, hovering over the shoulder of your agents.

He likened the future of development to managing a “fleet” of AI workers, where engineers must learn to orchestrate, debug, and direct multiple agents:

Every engineer is becoming a fleet general. You’re not just an IC anymore—managing autonomous contributors.

That may sound intimidating, but Peter argued that humans will continue to play a central, even irreplaceable role:

What remains when AI removes all the toil—the boring work? Humans are still responsible for the labor. We’re the backstop. We’re the audit log. And that’s not going away.

As the panelists agreed, there’s an emerging class of problems—ethics, oversight, accountability—that only humans can solve. Responsibility remains a human job even in a world run by autonomous agents.

Cursor, Windsurf, and the Agent Race

The latter part of the discussion focused on recent AI-native tools that are transforming the developer landscape—Cursor and Windsurf. Cursor, an enhanced version of VS Code utilizing AI agents, is now valued at $9 billion.

Windsurf, a similar tool, was just acquired by OpenAI for $3 billion. These figures raised a provocative question often heard in investor conversations: “What if AWS or Microsoft builds this?”

Kenneth, who was part of the original 12-person VS Code team, had a candid response:

Cursor and Windsurf aren’t really in the business of building a code editor. They’re using the VS Code base as a shipping vehicle. The real innovation is the agent.

Building an editor like VS Code from scratch is a massive endeavor, one only a few tech giants could undertake. But the opportunity now lies in building the best agent experience on top of that infrastructure, Kenneth points out:

We’re moving toward an agentic future where everyone will have agents on their engineering team. That’s the business. That’s the value.

This paradigm shift means the next battle in dev tools isn’t about IDEs—it’s about who builds the most effective co-pilot.

Open Source as the Foundation

Jesse pointed to the importance of the open-source ecosystem in enabling this transition. He’s an investor in Continue, an open-source plugin integrating VS Code and JetBrains tools to bring AI into developers’ everyday workflows:

Because of this open-source ecosystem, I started writing code again. It felt joyful. This moment in time makes that possible. You get prompted, and you learn.

It’s what I remember loving about development. Experiencing joy in collaborating with tools instead of fighting them may be the most important change of all.

The developer landscape is undergoing a seismic shift, driven not only by breakthroughs in AI but also by developers’ changing roles. Whether through tools like Cursor and Windsurf or evolving team dynamics that blend engineering with product thinking, the panelists painted a future where developers are not just builders but strategic decision-makers.

In an era where AI is both collaborator and competitor, the key challenge remains: staying adaptable, curious, and aligned with long-term value, regardless of whether you’re coding the next billion-dollar product or redefining what it means to build software.

The post The Future of Dev Tools is Autonomous, Engineers Will Become Fleet Generals appeared first on ShiftMag.

At this year’s Shift conference in Miami, Emanuel Lacic (Principal Engineer, Infobip) provided a glimpse into the future of agentic AI, where large language models do more than just generate text – they can actively shape the real world.

His talk centered around Infobip’s integration of the Model Context Protocol (MCP), a new open standard that enables AI agents to directly access and execute remote API calls — including Infobip’s own CPaaS tools like SMS, Viber, and WhatsApp — without glue code or manual integration. MCP is quickly emerging as a major trend in the tech industry, with many companies jumping on board. Let’s look at how Infobip plans to integrate its CPaaS tool channels in the near future to drive automation and improve usability.

Enabling AI agents to do more than just talk

Rather than simply diving into the buzz around generative AI and autonomous agents, Emanuel began by challenging the status quo. Instead of focusing on the conversational abilities of large language models, he posed a more ambitious question: “How can we make agents not only talk, but actually do something meaningful?“

Traditionally, implementing actions required developers to manually stitch together APIs, write middleware, and carefully orchestrate how LLMs interacted with external tools. However, as Emanuel explained, this approach doesn’t scale, especially when every API has its own specifications and quirks.

Infobip’s answer is to remove this friction entirely.

Infobip’s CPaaS is now agent-friendly

Infobip’s CPaaS platform is known for enabling messaging across SMS, Viber, WhatsApp, and other channels. Until now, integrating these services into an AI pipeline required traditional API work: reading documentation, generating JSON payloads, and writing manual code. With MCP, LLMs can now do all of that themselves, Emanuel explained:

We wanted to eliminate the need for glue code entirely. Developers shouldn’t have to write a single line of custom logic just to send a message or trigger an action. With a prompt and an agent, it should simply work.

Infobip has launched its own MCP endpoint – currently in beta – that opens up its communication tools to agentic AI. Developers can now instruct a language model to send messages, retrieve account data, or manage users using a simple prompt. The agent handles method discovery, request formatting, and real-time execution. Emanuel explained:

Our APIs are now machine-readable and model-understandable.That means agents can independently explore what our platform can do — and use it without any human intervention.

How does this actually play out in practice?

To illustrate what’s already possible, Emanuel shared two examples.

In a real customer support scenario, a company might use an AI pipeline to analyze customer sentiment. If a negative message is detected, the system automatically drafts and sends an apology via WhatsApp. Previously, developers had to manually integrate sentiment analysis with Infobip’s messaging API. Now, with MCP, an agent can manage the entire flow – from interpreting feedback to sending the message – all from a single prompt.

The second example was a bit sweeter: imagine launching a new chocolate product and wanting to send a Viber campaign with an image and message. All the agent needs is a prompt containing the product description, image, and recipient details. From there, it composes the message, identifies the appropriate API call, and sends it, even intelligently splitting the content into text and image components when necessary.

The future is prompt-driven

The key takeaway?

MCP marks a fundamental shift in how we build AI applications. Instead of manually integrating APIs, developers can simply describe the desired outcome, and let the agent handle the rest.

It’s all about removing the glue code. You don’t need to code anything. Just use generative AI, and it should do all the work for you.

The Model Connector Protocol represents a step toward making AI agents more capable, reliable, and adaptable in real-world systems. By shifting the burden of integration from developers to the agents themselves, MCP opens the door to new possibilities for automation and intelligent behavior.

While the technology is still evolving and early in adoption, its potential impact is clear – especially for platforms like Infobip that are already central to communication workflows. As more developers experiment with MCP, its role in shaping the future of AI infrastructure will become increasingly important.

Explore the Infobip MCP servers on GitHub, or build your own MCP server using the open-source Infobip OpenAPI MCP framework. 

The post How We’ve Built An MCP Server For Messaging appeared first on ShiftMag.

Tejas Kumar, an AI DevRel Engineer at DataStax, took the stage at the Infobip Shift conference with a no-hype, straight-to-the-point talk on AI.

He broke down what AI engineering looks like today, sharing techniques for cutting costs, avoiding hallucinations, and what’s going to be key for building the next wave of AI systems.

RAG solves the top 3 AI limitations

The main limitations developers face today when working with AI are hallucinations, knowledge cutoffs, and finite context windows. Tejas believes that these three “flies” can be swatted in one strike using a technique called Retrieval-Augmented Generation (RAG), which combines pre-trained language models with a real-time data retrieval system:

With RAG, you fetch data from an authoritative source and use it to enhance or alter the generated text from an LLM. This data reaches the LLM through prompt engineering.

Tejas demonstrated how RAG works with a simple example. Kumar illustrated the RAG process with just a few clicks: he inputs a webpage into an embedding model, which then numerically encodes the data.

This model performs a similarity search, pulling relevant information from the database to answer the user’s question. This process ensures that responses are based on the most up-to-date information, effectively eliminating hallucinations common in LLMs like GPT.

Chatbots are boring – AI should feel real

AI chatbots are everywhere today, but Tejas believes they’re mostly boring. They serve a purpose, but that purpose is very narrowly defined. That’s why Tejas offers an example of how a chatbot can be used more broadly-like searching Netflix.

Tejas entered “movies with a strong female lead” into Netflix’s search system, which traditionally might return incorrect or no results. However, if a search system uses semantic AI in the background—understanding the meaning of the user’s query rather than just keywords – the user experience can be significantly enhanced:

With semantic search, we improve search results and generate interactive user interfaces that understand user intent on demand.

Tejas illustrated how DataStax developed a tool for semantic search that not only delivers accurate results for such queries but can generate an interactive user interface (UI) on demand. This means that by typing “movies with a strong female lead,” Netflix could present relevant movie posters and trailers. This kind of interactive UI represents the future of AI, where developers can use models like Langflow to integrate AI into applications without disrupting the user experience, Tejas emphasized:

As developers, we have a responsibility to our users. We must build AI experiences beyond simple chatbots and deliver real, purposeful interactions.

SSMs instead of LLMs?

Looking ahead, Tejas sees a shift from general-purpose LLMs to small specialized models (SSMs), which is his (unofficial) term for AI systems tailored to specific tasks:

What if, instead of models like GPT-4 with 600 billion parameters, we had a smaller model with 7 billion specialized parameters? That’s the future, and that’s where we should invest.

Tejas believes companies will turn to smaller models focused on individual needs. That way developers will drastically cut costs while maintaining good product performance.

Building Responsible AI Must Come First

AI must be developed ethically, and one of the key things to watch out for is what Tejas calls “authority bias” – where users assume that results generated by AI are always correct simply because they come from an authoritative-sounding source:

We need to be transparent about the data used to train LLMs. AI should be able to say, “Hey, this data might be wrong.”

The future of AI is in creating tools that allow models to recognize the limits of their capabilities. When AI can’t provide an answer, it should be able to use external tools or APIs to retrieve the necessary information to ensure accuracy.

In conclusion, Tejas encourages developers to think beyond simple chatbots because he believes the future of AI is tied to combining the power of LLMs with specialized models and dynamic interfaces that enhance user experiences.

AI won’t replace developers, but some skills will disappear

Tejas could also be heard further on the panel “AI-Powered Development Tools: Enhancing or Replacing Human Developers?” where he was joined by Simi Olabisi, an AI expert from Microsoft, and the discussion was moderated by our executive editor Antonija Bilić Arar on the ShiftMag stage!

AI will do the opposite of what people expect. It won’t replace developers; it will make them better at their job, says Simi:

The tools we’re building at Microsoft are designed to handle repetitive tasks, allowing developers to focus on more complex and creative activities.

This brings us to the question of juniors and how they will learn. Simi believes they won’t need to spend time mastering basic tasks:

Just like floppy disks became obsolete, some fundamental skills may become less important to master, but that doesn’t mean they’ll skip important lessons. They’ll face challenging tasks early in their careers.

Think about this as an evolution from a paintbrush to a camera. Tejas pointed out that basic tools of human creativity are still necessary to solve 70 to 80% of coding tasks, but human oversight and creativity remain essential. Simi concluded that we’re not facing any dramatic change within the next five years. Tools will advance, and AI will continue to enhance our abilities, but developers remain a key part of the entire process.

The post Tejas Kumar: The future of AI isn’t LLMs, but affordable small language models appeared first on ShiftMag.