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.

This shift feels both fascinating and unsettling. Because of that, the need for clear rules and a neutral authority has never been greater. Such a framework must ensure balance so that AI develops in a way that remains fair, transparent, and aligned with human needs.

That need led to the creation of the Agentic AI Foundation (AAIF) within the Linux Foundation in December last year.

AAIF builds open, neutral foundations for agentic AI through collaboration – not control

AAIF mission focuses on neutral governance, open standards, and a collaborative ecosystem. The goal is to prevent a small number of proprietary companies and platforms from dominating AI.

In this context, the Linux Foundation provides reliable infrastructure, much like Linux does for operating systems or Kubernetes does for cloud environments. It ensures that these technologies remain open, secure, and interoperable.

Agentic AI Foundation hosts the Model Context Protocol (MCP), the emerging open standard that defines how AI agents communicate with external platforms, tools, and services. Companies that collaborate within AAIF will help determine which platforms will shape the infrastructure of the agentic AI era. Mazin Gilbert, Executive Director of the Agentic AI Foundation, stated:

The Agentic AI Foundation (AAIF) is the connective tissue, the plumbing behind how agentic systems operate. No one company can define or own these standards. We’ve seen this in cloud native with CNCF and in networking with the LFN. At every inflection point, the world moves from experimentation to production, and that shift needs open standards and community collaboration. With 170+ companies already in AAIF, we’re clearly at that inflection point in Agentic AI today.

What changes in the infrastructure when moving from APIs to AI agent-based systems

To better understand AAIF’s mission firsthand, I interviewed my colleagues, two developers from Infobip, a gold member of the foundation and the publisher of Shiftmag!

Josip Antoliš and Filip Srnec described how agentic AI transformation looks from a developer’s perspective, what changes it brings, which challenges arise, and what AAIF membership enables when it comes to participating in a global AI community.

We began by discussing what changes at the infrastructure level when moving from traditional APIs to AI agent-based systems. Josip Antoliš explained that MCP lets developers assign tasks to AI agents and ensures agents execute them in a standardized way. In practice, service providers who built products through HTTP APIs should now consider exposing the same functionalities through MCP.

In some cases, APIs can adapt automatically into MCP servers.

As an example, he noted that Infobip has open-sourced its own framework for exposing any HTTP API as MCP. He described this as only the first step. He explained that protocols like MCP let different agent systems connect, allowing one AI agent to delegate subtasks to another in a different environment through an MCP call. This makes it easier to build independent agents that collaborate, turning API providers into agent providers.

He also noted that AI agents become more valuable with every new tool they connect to, creating a positive feedback loop similar to network effects:

For example, an AI agent connected to an MCP server that tracks the stock market can analyze trends and suggest actions. If connected to a messaging provider like Infobip, it can send proactive SMS alerts when opportunities appear. Adding a trading tool then allows users to reply and instruct the agent to execute trades. Each new tool increases the value of all previous tools.

API providers are becoming agent providers

Filip Srnec expanded on this perspective by pointing out that Infobip’s mission to reach users wherever they are, through any available channel, naturally aligns with the agentic world. Their communication capabilities allow agents to interact through channels that users already know:

As we like to say, by using Infobip, AI agents gain communication superpowers. This applies across industries: agents that manage flight bookings and reminders, agents that run e-commerce processes, or marketing agents that create meaningful campaigns targeted at the right user segments.

He highlighted that Infobip has developed a range of products in the agent space, such as AgentOS, along with tools for connecting agents, including MCP servers. These solutions bridge the gap and enable agent-driven communication experiences:

From setting up communication through channel activation, sending messages, and feeding responses back to agents, Infobip covers the entire process. In addition, our platform offers advanced message optimization, fraud detection, and communication flow design.

Challenges in adopting MCP

Early-stage ecosystems often lack structure, and MCP is no exception. I asked my interviewees to identify the biggest gaps and limitations they encounter when building production-ready agent systems. Filip acknowledged that the ecosystem still feels unstructured, especially when it comes to adopting new standards and terminology:

I work in the MCP value stream, and we experience this firsthand. The biggest issue is that third-party client software, such as MCP clients, varies in maturity. Because of that, we cannot assume that everything behaves exactly according to the specification.

He added that specifications and terminology evolve quickly in this emerging space. These changes sometimes introduce breaking issues, both intentional and unintentional. Teams must remain agile and constantly balance product delivery with compatibility.

Josip pointed to another challenge. Anthropic originally developed MCP with a focus on coding use cases, particularly for its Claude Code assistant. Some assumptions from that use case remain embedded in the protocol:

For example, one of the two available deployment options requires the MCP server to run on the same machine as the AI agent. That works for servers that manipulate or compile local source files, but it becomes impractical when exposing functionality over the internet.

MCP does support remote servers, which enables broader use cases. Even so, authentication and authorization still require significant effort:

MCP adopted the OAuth specification. While this supports adoption, MCP relies on relatively niche parts of OAuth, which makes full compatibility harder to achieve.

How AAIF helps address these challenges

Since governance of the MCP specification moved to the AAIF, development and priorities have become more open and better aligned with the broader ecosystem, as Josip observed. The 2026 roadmap highlights key improvements such as scalable remote deployment, support for long-running tasks, and stronger enterprise readiness, including observability and integration with existing authentication systems.

These changes should make MCP servers easier to maintain and open the door to more complex use cases and new markets. Josip drew attention to the choice of Streamable HTTP as a transport protocol, which remains somewhat controversial:

Although it limits horizontal scaling, keeping it at this stage helps prevent fragmentation of the ecosystem. Planned improvements in this area will be especially important for DevOps and production environments.

He underlined the importance of support for long-running tasks. These tasks allow agents to manage processes that run for hours, opening entirely new categories of use cases. Improvements in enterprise integrations, especially single sign-on, will prove critical for broader adoption, since current complexity creates real barriers in production environments.

What does it mean to be AAIF member?

When discussing Infobip’s role as a Golden Member of the Agentic AI Foundation, I wanted to understand how this membership influences internal technical decision-making compared to simply adopting external standards.

Josip noted that the AI ecosystem evolves rapidly, and new standards seem to appear constantly. However, standards only create value when people adopt them. By participating in AAIF working groups, his team gains insight into the direction of key industry players:

We contribute by sharing our use cases and drawing attention to the challenges we encounter in our own implementations.

This involvement allows them to align new features and even entire products with the direction in which technology is moving:

Choosing the wrong technological direction can become expensive and create significant technical debt. By participating in AAIF activities, we ensure that we move in the right direction instead of following ideas that lead nowhere.

Through AAIF Josip stressed the importance of bringing real-world use cases into technical discussions from the very beginning. Standards that fail to address real user needs rarely succeed. Early input helps embed key concepts from the start instead of adding them later.

Filip described AAIF membership as a source of confidence and stability in the emerging agentic AI landscape. Open standards like MCP ensure that development does not rely solely on commercial interests. The community develops, maintains, and governs the technology together:

From the perspective of a developer building agent-based applications today, open standards provide strong foundations, best practices, and proven design patterns. This ensures that solutions remain robust and independent of any single vendor.

He pointed out that MCP acts as a universal connector for external tools and data sources. Building on open technologies allows individual engineers to become part of a global community and even influence the future direction of technology.

Filip concluded by noting that global collaboration remains essential at this stage, especially when it comes to reliability and security. The era of agentic AI has already begun. Many agents already operate in production. Now is the time to build a stable ecosystem that allows everyone to develop and use this technology safely.

The post How Agentic AI Foundation and MCP Are Redefining the Infrastructure for AI Agents appeared first on ShiftMag.

This is exactly what Anthropic claimed to have achieved with Claude Mythos, its newest and most powerful model which‚ according to Anthropic‚ is too powerful to be released to the public.

In its announcement, Anthropic said its new model identified security problems in several operating systems (Linux, OpenBSD, FreeBSD), browsers (Firefox), and widely-used software libraries (FFmpeg)..

Making such a powerful tool available to anyone (including bad actors) would be irresponsible, so Anthropic only gave access to a small group of “launch partners” (among them AWS, Apple, Google, Microsoft, and the Linux Foundation) under Project Glasswing. The idea is to give important organizations and open source projects advance warning and tools to find more security problems, while Anthropic decides what to do with the wider release of Mythos.

The fine art of Doom Marketing

Of course, the idea is also to hype up the capabilities of the new model.

OpenAI already played the “Our new AI is so powerful, we can’t give it to you” card with GPT-2, a model that today anyone can train for under $100.

The tactic still works‚ the media (another example) and the wider public have bought Anthropic’s doom marketing wholesale. Fear sells, and an AI that can hack anyone is as bad as it gets (or as good as it gets, if you’re in marketing.

Where there’s smoke…

Just because it’s marketing doesn’t mean it’s not true.

For a while now, many security researchers have been increasingly impressed with AI cybersecurity capabilities.

In their testing of Mythos, the AI Security Institute (part of the UK government) “found significant improvement on cyber-attack simulations“.

Open source developers have seen an increasing number of security reports, too: Linux kernel developers (participants in Project Glasswing) said “All open source projects have real reports that are made with AI, but they’re good, and they’re real“. In a similar vein, the developer of the popular open source utility “curl”, who was very vocal about bad AI bug reports in the past, recently used AI to find 50 real bugs in the project.

Even the NSA, the feared U.S. cybersecurity agency, is reportedly using Mythos despite Anthropic being banned from U.S. government use just weeks before.

The scariest AI of them all?

Based on all the reports, there seems to be some substance to Anthropic’s doom marketing. But let’s stop panicking, breathe for a bit, and try to rationally unpack what might be happening.

The new model is certainly very capable, but it’s not obvious that it’s miles ahead of what’s already there. In fact, the researchers at Aisle tasked small local models with finding the same bugs with (limited) success, concluding that the most important part is the approach, not model capability.

Basically, you can ask the model to carefully review every single part of the codebase and find security bugs. The AI never gets tired of the tedious grind and is happy to spend a lot of time and burn a lot of tokens (and money) in the effort. And if there is something suspicious, there’s a high likelihood it’ll find it.

The researchers point out that more capable models will do better, but you don’t need an out-of-this-world capability to achieve these impressive results.

So, on one hand, we don’t need to be scared of Mythos. It’s likely an incremental improvement over previous models. On the other hand, this means everyone can already do this, and probably already is.

Now, you can panic.

GPT enters the Chat

As further proof, just a week after the Mythos announcement, OpenAI released GPT-5.4-Cyber, a dedicated AI model for cyber defense.

Available only to “verified individual defenders and teams responsible for defending critical software“, the new model shows that no great leap forward is required for such a tool.

In fact, both OpenAI and Anthropic have since released newer versions of their flagship models, GPT-5.5 and Claude Opus 4.7, respectively.

The AI Security Institute tested GPT-5.5 as well, and noted that “GPT-5.5 shows that rapid improvement on cyber tasks may be part of a more general trend“.

These models have been trained to refuse cybersecurity-related requests (unless you’re in the program), but the Chinese models are just a few months behind in general coding capabilities, and have no such guards.

Where do we go now?

To quote one of the security researchers, “vulnerability research is cooked“. There’s no going back; motivated actors can already do a lot with the current AI tools, and we’ll only get increasingly powerful ones in the future.

In the short run, this can look pretty bad: expect more exploits, hacks and bugs across all kinds of software, from critical infrastructure to supply chain attacks against popular software libraries.

In the long run, however, I believe this is a good thing: motivated attackers with a lot of money already have stashes of 0-days (unpublicized vulnerabilities). Now, more people will be able to use AI to find these problems in their own code and patch them, leading to more secure software overall.

This is why Anthropic’s Glasswing and OpenAI’s “Trusted Access for Cyber” programs are a good first step, even though they’re available only to select participants. In the future, using open-weights models in a similar manner will bring these capabilities to everyone, cheaply.

Buckle up, it’s gonna be a bumpy ride.
 

The post Claude Mythos Opens The Cybersecurity Pandora’s box appeared first on ShiftMag.

Top experts from global tech leaders will share how they build and scale some of the world’s most complex systems, with real-world lessons from production environments.

Across multiple stages, the program features panels, workshops, and talks focused on deep technical insight and practical experience. Speakers include Katie Gamanji (Apple), Igor Dmochowski (NVIDIA), Sven Peters, Bette Lyon Delsordo, and many others.

You don’t need silicon valley for world-class tech

Igor Dmochowski, Head of Developer Relations for Central and Eastern Europe at NVIDIA, said that Infobip Shift is already internationally recognized, and added that he is especially excited to meet local developers whose potential is increasingly visible on the global stage:

Croatia has exceptional technological talent and a strong AI community, and I’m glad to be part of an event that puts this into a global context. True tech innovation comes from connecting people and ideas, and Shift has that energy.

On the other hand, Ivan Brezak Brkan, the Director of Developer Experience at Infobip, said that Infobip Shift is rightfully the largest tech conference in this part of Europe and one of the largest in the world.

You don’t have to, especially in today’s conditions, travel to the other side of the world to exchange experiences with people whose technological solutions power the world. If you want to advance your career not only through knowledge but also through connections, you need to be at Shift.

No professional speakers and marketing presentations

“Infobip Shift is built on two foundations: high-quality content and a relaxed atmosphere that encourages networking. We ensure strong content by carefully selecting speakers who share real-world experience from people actively working in the industry,” said Stipe Cigic, Director of the Infobip Shift, adding:

We avoid professional speakers, marketing-driven presentations, and topics overloaded with buzzwords and hype. That has become especially challenging today, when roughly every second submitted topic is somehow related to AI. Our speakers are real developers – people whose knowledge our audience truly values.

He also said the second foundation of Shift is its relaxed, laid-back atmosphere – a vibe the team aims to create each year. It can’t be forced, but they work to make the event feel light, summery, and welcoming. That kind of atmosphere makes networking more natural and fun.

Meeting new people is the biggest opportunity for attendees. I know at least 2 projects that started from casual chats at last year’s Shift. High-quality content plus a summer vibe, that’s what makes it memorable.

Knowledge gets you started, networking takes you further

With increasing reports of layoffs and disruption in the global IT industry, networking is becoming even more important. Stipe says the goal is for developers to leave Shift not only with new knowledge, but also with greater confidence and reassurance in their skills, value, and future in the industry.

I believe that, when it comes to networking and professional connections, Shift has no real competition in this part of Europe within the developer industry. A junior developer can casually grab a coffee with a senior engineer from companies like Netflix. The exchange of knowledge and experience in conversations like that is something our community rarely finds at nearby conferences.

Stipe concluded that Shift is a long-term platform developers can rely on, not just to meet peers, but also potential employers, clients, and partners. It offers many opportunities, whether for networking or simply enjoying great talks, food, and drinks under the Mediterranean sun.

Interested in Infobip Shift? Explore what we have planned!

The post Infobip Shift 2026 Returns to Zadar, Bringing Apple and Nvidia to the Stage appeared first on ShiftMag.

I’m a software engineer who works on domains that represent the messy corner of the internet.

In this corner, there are bad actors doing bad stuff and us trying to make their lives harder. Hence I spend a lot of time looking at what people do when they’re trying to slip something past a system. This led me to developing a slight paranoia about anything that reads untrusted input and then does something with it.

So when half my Linkedin timeline started losing their minds over OpenClaw, I developed a specific kind of curiosity:

What happens when this thing reads an email that’s actively trying to manipulate it?

So I tried… and the model caught me on the first try.

That’s the disappointing part. The interesting part is what happened when I tried harder – and what I realized about where the defense actually lives.

The hype isn’t manufactured, which is the whole point

But first, let me be honest about why this thing went viral. OpenClaw is genuinely impressive.

The first time I asked it to triage my inbox in detail and it actually did, I had the same reaction every other dev on X or LinkedIn has been having: oh now we are talking. This is the thing!

That reaction is part of what makes this complicated. Because the same architecture choices that make OpenClaw feel magical are the ones that create some genuinely hard security questions. The type of questions the broader industry hasn’t figured out how to properly answer yet.

15 minutes from npm install to AI reading your Gmail

Fifteen minutes. That’s how long it takes from npm install to having an LLM agent reading your inbox. The installer warns you this is a hobby project and still in beta – which, with 360k GitHub stars and 1.500+ contributors, reads more like a legal disclaimer than a self-description. The warning is the project being honest: security isn’t the primary concern here.

The onboarding wizard asks which channels you want, which model provider to route through, and walks you through the gateway setup. Gmail takes a little more work. OpenClaw doesn’t ship a “Connect Google” button because Google’s OAuth verification for production Gmail apps is strict, so every developer rolls their own Google Cloud project. The flow:

# 1. Create a Google Cloud project, enable Gmail API, download credentials JSON
# (console.cloud.google.com → New Project → APIs & Services → Library)

# 2. Install gog — OpenClaw's OAuth bridge for Google Workspace
brew install gog

# 3. Authenticate
gog auth --credentials ~/Downloads/client_secret_xxx.json
gog auth add me@example.com --services gmail,calendar,drive,contacts

gog auth opens your browser and walks you through Google’s consent screen with a scary “this app isn’t verified” warning (technically correct – it isn’t, you just installed it). You grant the scopes. Done.

That’s what the wizard shows you. Four defaults it doesn’t show matter more.

Gateway auth is off by default. The gateway runs on localhost, sure. But the moment you expose it, it’s wide open. Bitsight found over 30.000 OpenClaw instances exposed directly on the open internet in their February report. If you’re one of them, anyone who can reach your WebSocket can issue commands as you.

Permissions are off by default. Out of the box, OpenClaw runs with no filesystem restrictions. A skill can reach anything the OpenClaw process can reach – ~/.ssh, browser credential stores, shell history. You configure restrictions yourself in openclaw.json.

Set chmod 600 openclaw.json to restrict file permissions. And if you’re testing skills from unknown publishers, run OpenClaw inside a Docker sandbox.

That’s from the project’s own docs. Read it again. The maintainers know what happens if you don’t sandbox the agent.

Skills are markdown files. OpenClaw learns new tools by loading a SKILL.md This is a YAML file with a body describing, in English, which CLI commands it can run. The model reads the description, decides when the skill is relevant, and runs the commands the markdown tells it are available. Here’s a trimmed version of the real gog skill:

---
name: gog
description: Google Workspace CLI for Gmail, Calendar, Drive, Contacts.
metadata:
  requires:
    bins: [gog]
---

# gog
Use `gog` for Gmail/Calendar/Drive/Contacts. Requires OAuth setup.

## Common commands
Gmail search: gog gmail search 'newer_than:7d' --max 10
Gmail send:   gog gmail send --to a@b.com --subject "Hi" --body "Hello"

That markdown file is the entire trust boundary. Malicious instructions in a SKILL.md and legitimate ones look identical to the model, because they are identical. The only thing differentiating the “read my mail” prompt from “send mail to a stranger” is the model’s judgement about it.

OAuth scopes are all-or-nothing. The three scopes gog asks for – gmail.readonly, gmail.send, gmail.modify – apply to every email in your account, ever. No “only this or only that” variant. That’s a Google API design decision, not OpenClaw’s fault, but you inherit it the moment you wire them together.

The test I came here to run

So I sent myself an email from a burner account. The visible body was a generic delivery confirmation. At the bottom, using an ancient trick of white text on a white background, I embedded a quiet exfiltration request dressed up as a routine maintenance message. These instructions told the agent to forward emails containing password-manager keywords to an address I controlled.

Then I opened the chat interface and asked the agent a simple question: Are there any emails today?

The model saw through me

It flagged the sender as suspicious – a personal Gmail issuing a corporate-sounding directive. It called out the hidden text explicitly. It refused to act on the instruction. It categorized the message alongside the day’s normal mail, presented its reasoning, and asked whether I wanted to flag the suspicious one as spam.

I’ll be honest, I was kind of disappointed. I’d sat down expecting a war story. Instead, I got a well-aligned frontier model doing exactly what a well-aligned frontier model is supposed to do.

So I tried harder

I thought about what had triggered the defense and iterated.

The first attempt hit at least three trained heuristics at once: suspicious-sender detection, hidden-text detection, and a pattern-match against “silent operation, don’t tell the user” phrasing.

I removed the tells one at a time. Visible text instead of hidden. Plausible sender framing instead of a personal Gmail. Configuration-style payloads instead of one-shot exfiltration. Setting up an ongoing workflow rather than asking for something bad right now.

Against the frontier model I was routing through, every version I tried got caught. Sometimes immediately, sometimes with a clarifying question, but the model never silently complied.

Against lighter models, that’s not what happened.

Same architecture. Same skill. Same agent. Cheaper model. And the defenses that were reliable at the top of the hierarchy became probabilistic as I moved down. I’m not going to publish specific payloads. Not because the finding is novel (Cisco, CrowdStrike, and Barracuda have all been saying this for months) but because the payload is not the interesting finding here.

The gradient is.

The defense isn’t where you think it is

Here’s the thing the defensive and offensive communities both already know, and that almost nobody installing OpenClaw on a Friday night has internalized.

The security of these agent systems lives at the model layer, not at the architecture layer.

OpenClaw doesn’t defend against the attack. The model does. The skill doesn’t defend. The tool framework doesn’t defend. If the model you’re routing through has been trained to spot the pattern, the attack gets caught. If it hasn’t or if it was trained to spot last month’s patterns but not this month’s – the attack lands.

Which means the security posture of your OpenClaw install depends almost entirely on which model is sitting behind your API key that day. And most developers running personal agents are doing one or more of the following:

• Routing through whichever model is cheapest this week
• Using a fallback chain that drops to lower-tier models under load or rate limits
• Not paying attention to which model they’re on, because the agent works regardless

Every one of those is a security decision. Most developers don’t realize they’re making one.

Why this is the failure mode that matters

The architectural problem doesn’t go away when the frontier model defends perfectly. Three facts stay true:

1. The agent reads untrusted external content: inboxes, fetched pages, message bodies.
2. The agent has tools that can act on what it reads: send email, run shell commands, call APIs.
3. Skills declare capability in plain English: which means, at the token level, an instruction in a skill and an instruction in an email are the same thing.

The model is what stands between those three facts and an exploit. For the frontier model I tested, the model was enough. For the lighter ones, less so. And the model is a training artifact. This means the defense you have today is not necessarily the defense you have tomorrow, and the defense at the top of the model stack is not the defense at the bottom.

This isn’t just an OpenClaw bug; it’s a universal one. It’s the current shape of personal-agent architecture, and it’ll probably take several generations of isolation patterns, capability frameworks, and signed skill registries before the industry has an honest answer.

In the meantime, the defense you get is whatever your provider shipped this quarter… and the defense the developer across the room gets is whatever their provider shipped, and those are not the same thing.

Where this goes from here

What I came away with is that OpenClaw is the most honest version we have of where personal agents are going and it’s exposing a question the whole industry is going to have to answer:

When the only thing standing between an untrusted email and a privileged action is the model’s judgement, and model judgement varies by an order of magnitude across the price curve, what is the security posture of the system?

Right now the honest answer is: whichever model you happened to pick. I believe that shouldn’t be the case.

If you want to play with OpenClaw, play with it but do it in a hardened environment with throwaway credentials, pin your model explicitly in config, keep it away from your real inbox until the safety story catches up to the capability story, and read the hardening docs before you read the tutorials.

The post I Tried to Get OpenClaw to Betray Me. The Model Caught Me on the First Try appeared first on ShiftMag.

At the MCP Dev Summit North America earlier this month, I was listening to Meghana Somasundara, (Agentic AI Lead, Uber), and Rush Tehrani (Senior Engineering Manager leading the Agentic AI Platform, Uber) talk about what they’re building.

By their account, more than 90% of Uber’s 5.000+ engineers already use AI monthly for agentic workflows. They also have over 1.500 monthly active agents internally, running more than 60.000 executions per week.

What stood out to me was Meghana’s framing of the real risk: not deliberate misuse, but an agent causing serious damage by accident, faster than any human could react:

It takes us humans a lot more effort to break things. But with agents, it’s a lot faster, a lot quicker, and the blast radius is a lot higher.

What problems did Uber face when scaling AI?

Meghana and Rush’s talk focused on three problems that nearly made those numbers impossible to reach. The first was the lack of a shared way of building.

When agent adoption spreads organically across a large engineering organization, teams tend to build independently. At Uber Technologies, with over 10.000 internal services, that meant dozens of teams were building MCP servers and custom integrations on their own, without shared standards, central oversight, and any real way to reuse what others had already built.

The result was predictable: duplicated work, and a growing stack of systems that only the original team really understood, as Meghana Somasundara explains:

The simple truth was, if you can’t manage the development lifecycle, you just can’t trust it in production.

When agents start making decisions across systems, inconsistent implementations stop being a minor issue but they become harder to track, debug and even harder to trust.

The second problem included security. Agents operating across a complex service landscape could unknowingly call endpoints they shouldn’t, expose sensitive data, or trigger operations nobody intended. Add third-party MCP servers into the mix (Uber uses many external systems) and the governance problem scales quickly.

They needed full visibility into call patterns: who was accessing what data, under what conditions, and what happened when things went wrong. Without that, running agents in production at scale becomes a trust problem.

Finding the right tool quickly became the third problem, Rush asked himself:

How does an agent or the engineer building it actually find the right one?

Not just any MCP server, but one that’s reliable, performs well, and doesn’t quietly degrade everything built on top of it.

When discovery is left unmanaged, agents default to whatever is most visible rather than what actually works best. At smaller scale, that’s an annoyance, but across thousands of services, it becomes a systemic quality problem.

How Uber addressed these challenges

Uber’s answer to all three problems was a centralized MCP gateway and registry.

Meghana describes it as a central control plane that turns Uber’s endpoints into MCP tools, with service owners deciding what gets exposed and how it’s defined.

Every change flows through pull requests, passes security scans before deployment, and is continuously monitored in production, while a central registry (acting as the single source of truth) removes duplication and enforces tighter scrutiny on third-party MCPs.

In their no-code Agent Builder, as Rush explained, engineers can pre-select specific tools from an MCP server so the model doesn’t have to decide which one to use, and they can also lock down parameters so the agent doesn’t have to infer them at runtime, ultimately reducing the number of decisions and things that can go wrong.

Getting the infrastructure right shows up in adoption: their coding agent Minions generates about 1.800 code changes weekly and is used by 95% of Uber engineers, but that’s the output, not the real lesson.

On the roadmap are evaluation metrics in the registry to help teams spot reliable servers before committing, and “skills”, reusable MCP patterns with built-in A/B testing that bake evaluation into how knowledge is shared.  

Does any of this apply if you’re not Uber?   

Uber operates at a scale most engineering teams never see (10.000+ services in play) but while the complexity is extreme, the underlying failure patterns Meghana and Rush describe aren’t unique to them.  

Teams often end up building the same integrations in parallel, with governance only becoming a priority after something breaks, and discovery treated as an afterthought. These problems appear well before reaching 1.500 agents – once multiple teams start using the same MCP infrastructure without a shared layer.

The Uber model won’t translate directly to smaller organisations. But if you’re already running MCP servers across more than two teams and nobody owns discoverability or access control yet, that gap could surface soon. 

The post Uber Shares What Happens When 1.500 AI Agents Hit Production appeared first on ShiftMag.

AI is a blessing for some, but a headache for everyone else. 

That was one of the clearest takeaways from our CTO dinner in London, where my colleague Ivan Brezak Brkan IBB (Developer Experience Director, Infobip) and I hosted a dinner with CTOs from a dozen great engineering organizations. 

Not that I didn’t suspect it, but hearing it out loud, black and white, makes your assumptions impossible to ignore. 

For some, AI is putting the fun back into coding. For others? Welcome to AI shaming. Champions are treated like heroes; skeptics get rolled over, dismissed, or quietly frowned upon. 

Oh, to finally build again! 

As our conversation made clear, it’s no surprise that leaders and C-level execs are more excited about AI than most employees. But that excitement isn’t always about business – sometimes it’s just curiosity, fascination, or even fun. 

And I was struck by how many participants talked about the sheer joy of working with AI, finally getting to build again instead of just managing others. 

AI has allowed leaders and CTOs to bypass the so-called “atrophy” of framework-specific knowledge, letting them focus on problem-solving and architecture.  

In practice, this means more time is spent creating ideas and prototyping, rather than learning the specific technologies needed to build things. One participant noted: 

I’d say there’s a bunch of things I always wanted to do but never had time for. I’d either have to get someone else to solve the problem or just live with it. 

Now, if I’ve got an itch I want to scratch, I can build it myself. That freedom to solve my own problems also means I can solve more problems for others. 

On the topic of prototyping, multiple participants agreed that tasks that used to take several days now take just a couple of hours. This allows leaders to experiment and prototype their own ideas without overloading their engineering teams. 

And so far, so good. 

Using AI across the organization sounds like a no-brainer: ideas flow, everyone’s impressed at the speed of routine work, and it feels like you’re on the right track. But then it hits you –you haven’t really thought about the people who are actually writing and reviewing the code.

AI shame, shame, shame 

While many companies (especially Infobip) actively encourage the use of AI tools in the workplace, an unavoidable “AI stigma” still hangs over the tech space. 

This fear often comes from worrying about being perceived as incompetent – or as someone leaning on AI for work they’re “supposed” to do themselves. 

We concluded that you could approach it in one of two ways: 

1. Embrace the early Facebook mantra: “Move fast and break things.”  

2. Pause regularly to ensure that the “break things” part isn’t causing too much damage. 

The participants of the dinner echoed these statements, with one participant mentioning an example where a pull request was not reviewed because “it looked like AI-driven code”: 

One of my engineers was helping an ML engineer make a change in the iOS app. They relied primarily on Claude Code to write it but worked closely with the iOS engineer to test everything thoroughly. They checked and refined the code wherever necessary.

However, when the change was submitted for code review to the team that owned this codebase, it was immediately rejected, with the assumption that the authors hadn’t tested anything beforehand. 

I believe there’s no single right or wrong way to approach this. Being overly zealous about AI has its drawbacks: teams may resist because they feel pressured. On the other hand, being too conservative risks falling behind, arriving late to the AI party, and scrambling while competitors are already there, relaxed and sipping champagne. 
 
We all know that in the AI world there’re no universal playbook. What worked in some cases (rushing to full engineering adoption) might be a masterstroke for one organization and a disaster for another. 

At the dinner, participants pushed back on the very definition of “AI usage.” Is it opening a tool once a week? Using it daily? Or only when it actually changes how work gets done? Turning employees into internal AI Ambassadors, where colleagues help each other was one of the more promising ideas around the table. 

The foundation is laid. Now what?  

For us at Infobip, this conversation was something we’ve been living for a while now. We held hackathons, organized education programs, and made moves in infrastructure and security. This made adopting tools like Claude as easy as possible. We’re now at a point where over 80% of the company uses AI tools daily. 

But here’s what the dinner made me think about: the subjective experience and the data don’t always agree. When we talk with our engineers, they report feeling more productive. But when we look at DORA metrics or business outcomes, the improvement isn’t easy to correlate. 

The funny thing is that everyone feels more productive and energized, but it’s hard to put a finger on the exact metric.  

And if the dinner told us anything, it’s that we’re not the only ones thinking about that gap.  

Which brings me to the real takeaway: we’re entering a new phase, where it’s important to make AI usage count. That means top-down initiatives that change how teams work, including bringing non-technical teams in more. 

There might not be a “best” AI adoption strategy. But for those of us who’ve got adoption off the ground, the question is no longer quantity – it’s quality. 

The post 13 CTOs walk into a bar and realize: There is no best AI adoption strategy appeared first on ShiftMag.

By 2026, I don’t need to tell you vibe coding is useful, you’ve probably already tried it. Still, thinking about it as a way of thinking that will solve all of your problems is probably a bit too optimistic.

It’s easy to get carried away while you’re typing prompts, but there are several real challenges with vibe coding that you need to think about. It almost always works until it doesn’t work anymore.

Where vibes are immaculate

From a personal (and business) standpoint, vibe coding at the start of a project is probably its best use. Since I feel a personal example is better than three abstract claims, I’ll share my own.

Throughout my career, I often got overwhelmed by tasks and had troubles organizing them in a way that my brain likes. Projects, writing, editing, sending interview questions and getting them back, for example. None of these are big tasks on their own but they’re very different in nature.

Finding a good task manager app was next to impossible, but I have managed to create a simple dashboard web app that has all the things I need and nothing more.

For many, my AI tool might be useless, but for me it’s the only one that works precisely the way my brain does.

The appeal is real, and undeniable. Because you know best what you want, getting AI to do it is just a matter of sending messages and tailoring the “thing” into whatever you’d like. For me it was a real solution for a problem I face every day, but for someone else it might be a prototype of a new app or service that went from brain to screen in three hours.

Where the vibes get bad

The problems start when vibe coding moves into production, and I’ve seen that with my eyes as well. While we all know what things should look like for the end user, most of us from non-technical fields do not have any idea what’s happening under the hood. That’s why you need to think about more than just vibes.

Code you don’t understand is code you can’t maintain. Easy enough; if you create a beast of a tool, app, or an entire service you intend to share with others, it’s very tricky to maintain it if you know nothing about it.

For example, it’s fine to create a massive SaaS solution you would use since you can troubleshoot issues with AI in your own time; there’s no real risk. But if you’re shipping the service to others, what happens if something breaks at 3 am for someone who paid for that service?

Security gaps stack up. Every security expert will tell you that nobody cares about security until something goes wrong. With vibe coding and AI, the “wrong” part can be built-in during the creation of the tools. AI sometimes just embeds API keys or other secret info in the code, doesn’t sanitize the code properly, and leaves a lot of open doors in general. If you’re not savvy and don’t think about this, you’re going to have a bad time. Also, remember that hackers also use AI to find weaknesses.

The DORA AI report shows what we’re all thinking. The 2024 DORA report found that AI adoption actually correlated with a 7.2% reduction in delivery stability. More telling: 39% of respondents said they had little to no trust in AI-generated code, yet nearly everyone was using it anyway.

The risk here is over-reliance on AI tools that leave you, their creator, sitting on the sidelines wondering what’s even going on.

Keep an eye out for over-vibing

In my experience, there are a few signals that you are perhaps in too deep into vibe coding, and it’s starting to become a liability. I’m not saying you should go and seek professional help, but for some of these help is really the only solution.

• You can’t explain what the code does, only what you asked the tool to make. If you try to explain it to a real engineer, the conversation is short and unpleasant for both sides.
• You’re using AI to explain code that AI wrote, which makes the explanation wrong as well.
• You’ve stopped writing tests because “AI will catch it”. And AI is, of course, not catching it for some reason.
• You’re patching AI patches. The original AI solution had a bug, you asked AI to fix it, that fix introduced another issue, and now you’re three layers deep.

I know that asking a senior engineer to help you fix your vibe coded app might be one of the more stressful experiences in your life, but if you’re set to be a vibe coder, that’s a chance you’ve got to take.

I’m not trying to ruin your vibe, but…

Don’t get me wrong here, I’m not saying that you should lose Claude Code and start typing everything manually (or by pasting from StackOverflow).

What I’m saying is that the ones who make the most out of vibe coding apps are the ones who could, theoretically, make the same apps themselves.

What I’ve found in the last month is that AI adoption and tendency to vibe code things is a pendulum: you either think it’s bad, complex and don’t want to touch it, and once you do start you can’t get enough of it. I’ve heard comparisons with “prime Call of Duty”, which is a reference only gamers would understand, but paints the picture.

A good vibe coding experience is like driving a convertible on a coastal road at sunset.

In 2026, people are exceptionally interested in making anything with Claude Code and other tools and the truth is that we don’t really need 90% of those.

So when vibing, I’d advise you to think small, and think about problems that you have. It’s ok to create a task management tool for you, and not to make money on, and it’s okay to vibe code a prototype of a new idea before presenting it.

I’d just like you to make sure to understand that using a tool mainly used by software engineers does NOT make you one, and you need to spend a lot of time understanding what the tool built in order to get close to the “real world.”

FAQ:

The post A Non-Engineer Look at Vibe Coding Mistakes (And How to Avoid Them) appeared first on ShiftMag.

A field that, just a few years ago, felt stable and full of opportunity now comes with more uncertainty -breaking in is harder, and staying relevant takes constant effort.

We spoke with software engineers who have more than 10 years of experience to hear how they’re navigating these changes.

Thinking back on your career, what’s helped you stay relevant as technologies and trends kept evolving?

Denis: “I was always looking for ways to improve my workflow, so I could spend more time on the interesting, creative parts of the job and less on repetitive, routine tasks. I focused on really understanding problems and possible solutions, which meant building deeper knowledge rather than relying on quick fixes from the internet. I read books, followed blogs, attended both live and online conferences, and learned from experienced people in the industry to get different perspectives and form my own conclusions.

To stay relevant, I focused on real user use cases and the problems behind them, building solutions that create real value.

I also made a point of staying close to the products, users, and solutions over time to see what actually works and what doesn’t, regardless of hype or trends.

Working in teams and collaborating closely helped a lot, as there are always tough questions and healthy discussions that lead to better decisions in the end.”

Marina: “Staying relevant over the years came down to curiosity and hands‑on learning. I regularly read blogs and watch online conferences to keep up with new technologies, but I learned the most by trying things out through small POCs. Experimenting helped me understand problems more deeply and see what really worked.  

Changing teams also played a big role. Working with people who had different backgrounds and experiences exposed me to new ways of thinking and pushed me to grow.  

Finally, working on real products in production environments (especially in larger teams) taught me lessons you simply can’t learn alone. Collaboration, shared ownership, and learning from others helped me continuously adapt as the industry evolved.”

Marko: “For me it’s a combination of continuous learning and a strong focus on fundamentals. I always tried to explore new technologies and different domains, but with an emphasis on really understanding the core principles behind them. That way, the knowledge stays useful even if my career moves in a different direction, and it becomes much easier to build on top of it later.

Just like for the other guys, another important factor was working on real products running in serious production environments, especially in larger teams. Collaboration, communication, and learning from others in a shared codebase bring insights you simply can’t get when working alone. Those experiences helped me grow not only technically, but also in how I approach problems and make decisions in the long run.

I’d describe myself as a cautious early adopter. I enjoy experimenting with new technologies, but I try to understand the fundamentals behind them first, so I can evaluate where they truly make sense and how they contribute real value rather than just following hype.

Finally, self-reflection played a big role. Regularly asking myself what skills I’m missing, how I can contribute more to my team or company, and then actively working towards that has led to many good long-term career decisions.”

Mario: “Talking to other people, watching what others build, and experimenting myself plus exploring open source projects, YouTube videos, and Udemy courses on 2x speed to quickly understand what’s possible with unfamiliar tools. I also follow Hacker News and similar newsletters.

But staying relevant isn’t just about knowing what’s new; it’s about knowing what’s actually worth adopting – and when.

Understanding the high-level concepts and the problem I’m trying to solve is what allows me to pick something that looks like the right tool. After that, trying it out and getting first-hand experience: how it feels under the fingers, and whether it really solves my problem and makes my life easier – is mostly the deciding factor for me, but not the only one. If I’m doing a quick throwaway POC, I can try anything and really find the best tool.

But if I’m working in a team environment where cognitive load is already high, I’m careful not to introduce new technologies every other day just because it’s the new cool shiny thing – even if it actually is the best tool. It’s a tradeoff, and one that needs careful consideration. And sometimes the best isn’t even needed – something that works is good enough.”

In your opinion, is long-term success more about being a deep specialist or a broad generalist? Has your perspective changed over time?

Denis: For long-term success (whatever that is), it’s generally better to develop M-shaped skills. That will take some time, but only with great collaboration and multiple deep expertise areas can you be innovative and versatile, bringing measurable value and not be easily replaceable.

Marina: Earlier in my career, I believed that being a T‑shaped developer was the ideal path and I assumed that trying to learn more than one thing deeply would only lead to superficial knowledge and that focusing on a single specialization was the safest way to grow. Over time, my view changed.

Through real-world experience, I realized it’s possible to build strong, meaningful expertise in multiple areas without losing depth. As systems became more complex, having deeper knowledge across several domains helped me understand the bigger picture better, make better technical decisions, and collaborate more effectively with others.

Today, I believe long‑term success comes from combining depth with breadth – developing strong expertise in more than one area and continuously expanding that range as technology evolves. This flexibility has helped me stay relevant and adapt as roles and technologies have changed.

Mario: I wonder if it’s possible to be M-shaped For a long time, I was a firm believer that T-shaped is the way to go – a broad overview, but with at least one area of genuine deep expertise. And I still think that’s a solid foundation for any engineer.

But over 20+ years, curiosity kept pulling me in different directions: low-level Linux internals, networking, compilers, containers, orchestration, and large-scale distributed systems, working at different layers of the stack. And each time, I went deep enough to solve a real problem. That experience adds up over time.

Understanding the problem and figuring out which layer it needs to be solved in matters more than the technology layer itself, and then it’s about stitching everything together.

Do that long enough, across enough domains, and you naturally grow more spikes. So my view has evolved – I started as a T-shaped believer, and somewhere along the way I became something closer to M-shaped. Not by design, but by following the problems. And if you ask me what I’m an expert at specifically, I’d say solving problems, if that counts as expertise. That’s at least what I currently strive for.

Marko: Today, I’d describe myself as somewhere between T-shaped and M-shaped, maybe N-shaped, still evolving. Early in my career, the T-shaped model made perfect sense, broad knowledge with depth in one area. Over time, as access to knowledge became easier and technologies evolved faster, I realized how valuable it is to develop depth in multiple areas

What ties all of this together is problem-solving. Technologies change, but problems remain. Being able to learn continuously, adapt, and apply concepts from one domain to seemingly unrelated problems becomes incredibly valuable over the long term.

If I were to advise myself 10 years ago or to others today, it would be to stay curious, keep learning, and surround yourself with people you can both learn from and teach. Also, don’t be afraid to broaden your horizons, look for ways to contribute beyond your narrow specialization, pick up complementary skills, and take some risks. Growth often happens outside your comfort zone.

How do you see AI tools impacting long-term developer careers?

Mario: AI impact is real, especially in engineering. We’re much faster at writing code, and I can smart-search unfamiliar codebases and quickly understand how things work (something that used to take a huge effort).

But there’s a price.

The amount of generated code is huge, yet humans still need to review, understand, and own it. AI isn’t the one waking up when something breaks. Creating PRs with AI is easy, being responsible for them is another story.

Our role has shifted to making sure code that looks ok is actually ok – fits the intended architecture, the broader system, the business rules, all the things AI isn’t aware of. The value is the same: understanding whether the code works as intended and preventing it from degrading into a ball of mud nobody can understand or fix at 3am.

What’s changed is how much harder that challenge has become with code being generated at this speed. Young developers are in a tight spot – suddenly expected to skip writing code by hand but still have the same depth of understanding.

And I’m not sure you can skip that part. There’s something about writing code by hand, hitting a wall, debugging it yourself, and feeling the pain of it not working that builds intuition you can’t shortcut. Even if AI is faster and easier. The best advice is to learn the concepts, fundamentals, and engineering best practices that hold regardless of AI.

You need to be able to look at AI-generated code and know whether a for loop is acceptable or a dictionary lookup fits better, that’s software engineering 101. AI can generate the code, but we still need to understand whether it actually fits.

Write as much code by hand as you can. Use AI to review it, ask for other options, and have it challenge your approach, and then actually think through the answers. That way you learn faster while still building real understanding.

And don’t skip debugging AI-generated code step by step; I do it regularly. It’s how you move from just looking at code to actually feeling it. That difference becomes obvious once you try it.

You’ll often be surprised how much you miss just by reading – sometimes it’s “this is not how I thought it worked”, sometimes it’s “I did not expect this at all.” Both are valuable, and both come from actually stepping through it.

Marko: AI tools already have a huge impact on my daily work, from writing code and understanding codebases to reviews, idea generation, debugging, and learning new topics. Overall, I see AI as a strong positive force for developers. It significantly reduces the time spent on repetitive or low-value coding tasks and frees up more space for thinking about architecture, system design, and solving complex problems that truly matter in production.

That said, some things won’t disappear. Understanding the problem and broader context, making architectural trade-offs, communicating well, and taking ownership are still firmly human. When something breaks at 2 a.m., it’s still engineers who make decisions and take responsibility. AI is powerful, but only as effective as the person using it.

For junior developers, don’t skip the fundamentals. Expectations are higher than ever, but strong foundations are key for a sustainable career. The good news is that access to knowledge and AI tools is better than ever. Use AI to accelerate learning, not replace understanding. Give yourself time, build experience, and master the basics—that investment pays off for decades.

Marina: AI tools will significantly change how developers work, but I don’t see them replacing strong engineers. Instead, they will amplify those who understand what they are building. For younger developers, the key is to learn with AI, not just watch AI work.  

It’s important to question AI output, understand why it made certain changes, and how those changes affect the system. Treat AI as a learning partner rather than a shortcut. Blindly accepting generated code can limit growth, while actively analysing and improving it builds real expertise.  

Younger developers should also focus heavily on architecture and system design. When you understand how systems are structured, how components interact, and what trade‑offs exist, AI becomes far more powerful. It’s much easier to ask the right questions (and get useful results) when you already understand the problem space.

Denis: AI tools have made coding skills almost irrelevant. Still, other skills and practices related to quality, such as trunk-based development, TDD, continuous delivery, modularity, cohesion, DDD, etc., are more valuable than before.

AI tools are a powerful amplifier, and they need guidance, so software engineers with those skills will remain relevant and in demand for a long time. Understanding of the (business) problem and the solution shouldn’t be outsourced to the AI. Software engineers still need to understand trade-offs, architecture, and code. 

The post What 4 engineers with 10+ years of experience say about staying relevant in the AI era appeared first on ShiftMag.

Digging through portals and LinkedIn profiles is a total drag. That’s why we at ShiftMag launched a handy guide that packs the career ladders of major tech corps into one place! We already tackled Amazon, and today, Microsoft is on the menu!

To build this guide, I cross-referenced multiple sources: Microsoft’s official career site, Levels.fyi compensation data, LinkedIn profiles of current and former Microsoft engineers, and publicly reported industry data including salary leaks and engineering blogs.

Where sources conflicted, I noted the discrepancy rather than picking one arbitrarily. Compensation figures reflect self-reported U.S. data from Levels.fyi and should be treated as estimates, because they vary by location, team, and negotiation.

Microsoft’s engineering levels

In Microsoft, there are a number of standard job titles. Entry-level engineers start at L59–60 (SDE I) and progress through mid and senior roles up to L67–68 (Distinguished Engineer / Technical Fellow). The ladder splits into two tracks: management (Engineering Managers) and individual contributor (IC).

L59–60 – Software Engineer (SDE I)

Entry level for new graduates or engineers with under two years of experience. Engineers implement features, write and debug code on well-scoped tasks, and work under close mentorship. The primary focus is learning systems and coding practices.

L61–62 – Software Engineer II (SDE II)

Mid-level engineers with roughly 2-5 years of experience. They own more complex features end-to-end, write scalable code, and begin mentoring SDE Is. They influence design decisions within their projects but still receive technical guidance from seniors.

L63 – Senior Software Engineer (Senior SDE)

Engineers with approximately 5+ years of experience who own multiple features or projects and set technical direction within their domain. Senior SDEs lead design discussions, ensure long-term maintainability, and partner closely with product and engineering leads.

L64 – Principal Software Engineer

A senior IC role typically reached after 8-12 years of experience. Principal SDEs lead large components or entire technical domains, architect systems, and drive technical strategy. Some external sources label L64 as “Staff Engineer,” but Microsoft’s internal title is Principal SDE.

L65-66 – Principal Engineer II / Partner-Level

Principal-level engineers with broader organizational scope. These roles sometimes straddle IC and management tracks, with titles including Senior Principal or entry-level Architect. L65 is often where the formal “Principal” designation begins internally.

L67-68 – Distinguished Engineer / Technical Fellow

Top-tier IC roles focused on company-wide innovation and long-term technical strategy. Distinguished Engineers (L67) have deep domain impact across the organization. Technical Fellows (L68) are among the most senior technical positions at Microsoft and are extremely rare. These levels are not promoted into on a fixed timeline, they are typically nomination-based and require demonstrated impact at scale.

Cross-company level mapping

The table below shows rough equivalents across Google, Meta, Amazon, and Microsoft. These mappings are approximate – scope, expectations, and compensation vary significantly by company even at equivalent titles.

Compensation

Microsoft’s total compensation (base salary + bonus + RSU grants) rises steeply with each level. The figures below reflect U.S. median total compensation as reported on Levels.fyi. These change frequently and vary by location, team, and negotiation.

Compensation data sourced from Levels.fyi. Figures are self-reported estimates and should be treated accordingly.

A note on RSUs: Microsoft grants RSUs on a 4-year vesting schedule with a one-year cliff, after which shares vest quarterly. At senior levels (L63+), RSU grants make up an increasingly large share of total compensation – often exceeding base salary at L65 and above. Annual refresh grants are awarded through Microsoft’s performance review process (called “Connects”).

The post Microsoft Engineering Levels and Salaries: The Complete SDE Career Ladder (L59–L68) appeared first on ShiftMag.