David Fung, ICF PCC, founder and executive coach at Coachful Coaching, spent over two decades in tech, most recently as a Senior Director at Salesforce leading Sales Engineering teams.

I had a chance to talk to him at CTO Craft Con in Toronto about the most reliable signal that something is wrong in the teams. Coincidentally, it is also the one most leaders misread.

One of the biggest signs that you may not be clear is if you hear silence. A lot of leaders take silence as alignment. But silence is actually a sign that maybe people are either not clear or they may have just given up fighting with you.

The pattern he described is familiar to anyone who has worked under a fast-moving founder or senior leader: repeated pivots train teams to stop pushing back. The resistance has proven futile in the past. And the result is a team that appears aligned but actually isn’t.

Less output, more filtering

Fung’s prescription runs counter to the default mode of most technology organizations right now. Instead of generating more output, more strategy documents, more direction, he argues leaders need to filter more aggressively. The job, as he frames it, is to reduce the surface area of what the team has to process so they can focus on what actually matters.

Your role now, especially as a leader in an age of AI noise and disruption, is to filter more. You need to be better at this so that your team can focus. And when your team can focus, there’s less confusion.

He’s not particularly optimistic that most leaders will find this easy. The same problem appeared across every organisation he spoke to at the CTO Craft Con. And those organisations range from small engineering teams to Fortune 500 companies – different scale, same dysfunction.

Don’t mistake volume for clarity

On the question of whether the problem gets worse with seniority, Fung redirected. “The problem gets worse when a leader is surrounded by yes people,” he said, drawing a pointed comparison to the behaviour of large language models: humans, he noted, were sycophantic long before AI was. The leaders who struggle most are those who have never built an environment where pushback is safe. And AI, by accelerating decision-making and reducing friction, makes that environment harder to maintain, not easier.

For technical leaders specifically, Fung identified a recurring failure mode: mistaking volume for clarity. Engineers who send fifty-paragraph emails or chain together Slack voice notes aren’t being thorough. They’re producing noise. His framework for actual clarity is straightforward: say what’s happening, say why it’s happening, and say what it means for the people on the receiving end. He calls it: Name It, Frame It, Invite It.

A lot of technical people forget the human part of it. What does this mean for the person hearing it? Why should they care? They forget that part

The aha moment, when leaders finally recognise their own role in the confusion, requires three things to land simultaneously: dissatisfaction with the current situation, self-awareness, and willingness to change. Any one of those missing and the realisation doesn’t stick.

Even if it’s not you, start with: Maybe I’m the problem. And what can I do differently to help the team?

AI won’t help with human problems

On whether AI will eventually make this class of problem smaller, his answer was straightforward: no. Speed will actually amplify it. And as long as humans remain in the loop, the underlying conditions, ego, fear, imprecision, nervousness, don’t disappear.

So long as there’s emotions involved, the human condition will exist. And it’s not a flaw. It is part of the human experience.

For the newly promoted senior engineer trying to avoid building the same dysfunctional dynamic from day one, Fung’s advice was the same three-part framework – what’s happening, why, what it means for you – applied in their own voice, not rehearsed or smoothed into someone else’s register.

Simple, as he acknowledged, but not always easy.

The post Engineering Leaders, You Should Be Worried If Your Team Isn’t Pushing Back appeared first on ShiftMag.

AI can generate code, seniors can review it, and entry-level salaries aren’t trivial – the argument for cutting junior engineers sounds reasonable on a spreadsheet. Christine Miao’s counter-argument starts at a different level entirely.

We’re in a growing industry where companies need to be able to continue and carry forward. In order to do that, they need to hire juniors. Foundationally, it’s about survival.

Survival, AI adoption and, honestly, good vibes

I had a chat with Miao, Founder and Researcher at Technical Accounting, after her talk at the CTO Craft Conference in Toronto. Her talk was followed by a presentation, one of the rare ones not (completely) generated with AI. It was fun and quirky, a bit like junior developers, who bring fresh perspective, followed by a bit of charming chaos.

They are essential for the companies’ and industry’s survival, Miao is certain, but that part is just the floor. Miao points to something harder to quantify: the organizational effect of having people experience a steep learning curve in public for the first time. Senior engineers who mentor a junior feel accountable in a way they simply don’t with an LLM.

I would certainly very much hope that no one feels responsible to an LLM the way they would feel responsible to a young person who is learning the ropes for the first time.

There is also an adoption argument. Juniors, she notes, have no prior workflows to protect. In organizations struggling to get engineers and other team members to actually use the AI tools they’ve licensed, hiring people without ingrained habits is a legitimate strategy.

The culprit for the current situation?

I asked Miao who is responsible for the current contraction in entry-level hiring. She traces it up the chain further than most critics do. The culprit, in her view, is investors who conflate cost reduction with value creation:

They can’t tell the difference between cutting costs to maintain EBITDA, versus building a new product and creating a new growth area. In their minds, because the numbers are the same, it all adds up.

That mindset propagates downward into management, and juniors, whose output is hard to measure visibly, become an easy target.

How to mentor junior engineers who use AI?

The mentorship question is where the conversation gets more complicated. Some senior engineers argue that AI-assisted development is producing juniors who generate output without understanding it, making them harder, not easier, to teach. Miao doesn’t dismiss the pattern, but she describes a bimodal distribution. On one end: juniors producing “really fast, really crappy slop” they can’t debug or explain. On the other: organizations where juniors leveled up in roughly three months, which brings down the cost of onboarding significantly.

The difference comes down to two factors. First, a genuine organizational commitment to mentorship. Not as policy language, but as actual practice. Second, engineering foundations that are already in reasonable shape.

If you have a good baseline, AI gets easier, junior engineers become easier.

The inverse is also true: legacy codebases, poor documentation, and no mentorship infrastructure don’t just slow junior development, they actively compound each other. Adding AI to that environment and then blaming the junior for the output is a category error.

On the question of what makes a strong junior right now. Miao is direct: it’s not code, but a want to level up, having the aptitude to recognize when a field clicks, and the grit to work through the parts that don’t. The market tightening is, in her view, a reasonable filter. Previously, anyone who could code could find a job; now the bar requires genuine engagement with the craft.

Companies that don’t hire juniors will fall into their own trap

The longer-term risk is structural. Organizations that stop refreshing their pipelines now will, Miao argues, find themselves trapped in five years: too brittle to adapt, carrying institutional knowledge that was never transferred, and too understaffed to train anyone new.

You hit a point where you are so busy keeping your head above water that you have no time to train anyone else. At that point, frankly, money won’t fix the problem.

For the organizations paying attention, the current environment is actually favorable: junior talent is abundant, under-hired, and, when developed properly, notably loyal. The companies that recognize this as a competitive window rather than a cost problem are likely to look very different from the ones that didn’t, and not in a recoverable way.

The post Don’t Hire Juniors to Write Code, Hire Them to Become Seniors appeared first on ShiftMag.

Ask anyone outside the industry why people go into software engineering and they’ll say: good money, remote work. Talk to the developers themselves and you get a different story.

For most of the 20 of our Infobip colleagues we interviewed, it started with genuine curiosity – a need to understand how things work, then build their own. Some caught the bug in childhood, others through gaming. But the thread running through nearly every story is the same: they fell in love with the craft long before they ever thought about the salary.

Josip Antoliš, Senior Principal Engineer, captures this sentiment:

It felt like playing with Lego, just for older kids. It was really about building and experimenting.

If money is the only reason you want to become a developer, you won’t make it

Money is part of the equation, and some developers are honest about it – job security and solid pay were what first pointed them toward the field. There’s nothing wrong with that. But most will tell you it only gets you so far.

Engineering is demanding, constantly evolving, and unforgiving to those who are just going through the motions. The developers we spoke to largely agreed: without a genuine curiosity for the craft, the motivation eventually runs dry, no matter what’s in your bank account.

Olga Koroleva, Staff Software Engineer, explains:

For me, it was not money driven. I just naturally like learning new things.

Not everyone had a master plan. For some of the developers we spoke to, the path into software was less a calling and more a series of small, accidental steps like following friends into a computer science program, or stumbling onto coding in their twenties and realizing they had a knack for logical thinking and breaking problems apart.

What matters less, it turns out, is how you got in. What keeps people thriving is the willingness to keep learning and adapting in a field that never really stands still.

Among younger developers in particular, gaming played a surprisingly direct role – less a hobby, more an early window into how software actually works.

Edvin Teskeredžić, Senior AI Software Engineer, remembers his Counter-Strike days:

We used to play a lot of Counter-Strike, and to play together we had to set up servers. Later we started modifying the game, and only later realized we were actually programming.

In the end, whatever brought them to the field, most engineers find a way to grow into it. As Denis Kranjčec, Staff Engineer, puts it:

I started programming 40 years ago, and money was fine, but it was not the only thing.

The best things about being a developer

When asked what they love most about the job, the answers kept circling back to the same themes.

• Cracking a hard problem in a clean, elegant way
• Shipping something that actually makes life easier for people – knowing your code is quietly doing its job out in the world
• Those rarer moments when a tangle of complex systems finally clicks into place, and what was chaos becomes something that just works

Creativity and problem-solving remain central themes. As Teskeredžić puts it:

I like solving practical problems and applying creative solutions.

Beyond the work itself, the setup matters too – remote work, autonomy, and long uninterrupted stretches to actually think. But as Olga Koroleva puts it, what really keeps people around is simpler than any perk:

The best part is staying curious.

The not-so-good part of a developer’s career

Ask about the downsides and the answers get a lot shorter. One word came up more than any other: meetings. Pointless ones, mostly. The kind that could’ve been an email.

Beyond that, developers highlighted several systemic frustrations that disrupt deep focus:

• Constant context-switching takes a significant mental toll.
  
• Bureaucracy and tedious reporting often fracture the time dedicated to core engineering tasks.
  
• Navigating undocumented legacy code and parsing ambiguous logs slows development velocity.

There’s also the relentless pace of change. Kristina Valjak, Engineering Lead, puts it plainly:

The speed of change means you constantly have to learn. You have to sacrifice things. It is not a job you leave at the door.

And then there’s the physical reality: long hours at a screen, tight deadlines, pressure that doesn’t let up. Even in teams doing interesting work, that combination can wear you down.

Would they choose this career again? Absolutely.

When asked if they’d do it all over again, there was barely a pause. Absolutely. 100 percent.

More pros than cons. Almost without exception, these developers would make the same choice and most believe tech still offers something few other industries can match: genuine stability and room to keep growing.

Ivona Škorjanc, Software Engineer, remains highly optimistic:

I would still choose it. It is exciting and I see myself growing in it.

A few said they’d have invested more in the fundamentals early on – the theory, the computer science basics that tend to get skipped in the rush to learn frameworks and ship code. But that’s a minor footnote to a bigger conclusion: this field is hard, and most of them wouldn’t trade it for anything.

Teskeredžić offers a final, inspiring perspective on the profession:

To me, engineers are like real-world wizards. Advanced technology is like magic, and if you can be a wizard for a career, why not.

Even the ones who occasionally miss working with their hands come back to the same answer: they’d choose this path again.

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

The post We Asked 20 Developers Why They Really Got Into Tech. It Wasn’t the Money. appeared first on ShiftMag.

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

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

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

AI exposes the weakest link, not just the fastest path

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

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

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

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

When code gets cheap, everything else gets expensive

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

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

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

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

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

Measuring the wrong things optimizes the wrong things

She also makes a sharp point about measurement and optimization.

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

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

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

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

The SPACE framework and why three metrics beat one

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

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

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

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

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

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

What to fix before adopting AI

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

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

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

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

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

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

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

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

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

Now there’s a new concern.

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

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

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

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

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

Selfware

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

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

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

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

No scrum, sprints, pull requests…

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

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

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

Pair me with Claude

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

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

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

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

We asked Sander a few more things

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

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

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

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

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

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

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

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

Where does this go in two or three years?

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

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

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

Put together, they form a consistent picture – not an official ladder, but a very real one that shows how engineers grow, gain influence, and move from writing code to shaping entire systems.

Compensation reveals the real hierarchy

At its core, Adobe uses a P-level system (Professional levels) that maps engineering growth from entry-level roles to company-wide technical leadership.

Adobe doesn’t hand out impressive titles quickly. But behind the modest titles, what’s actually expected of you keeps growing at every level. The ladder looks flat from the outside. From the inside, the gap between levels is real.

If titles are understated, compensation isn’t: across multiple sources, total compensation for software engineers at Adobe ranges from roughly $150K at the entry level to well above $500K at the top of the individual contributor track.

The numbers matter, but so does the curve. Pay grows steadily through early and mid-level roles and then jumps sharply after senior. That’s where Adobe starts paying for influence, not just output.

Senior level: where leverage begins

At P10 and P20, the job is straightforward: ship code, learn the systems, and figure out how Adobe builds and scales things. The goal is to become someone the team can rely on.

By P30, something shifts. Engineers stop executing tasks and start owning problems (taking a feature end-to-end), making real technical calls, and thinking about why something should be built, not just how.

At P40, the job changes for real. Senior engineers design systems, not just features. They cross team boundaries, shape architectural decisions, and lead bigger initiatives. For many, this is a long-term home – the next step demands a fundamentally different kind of growth.

Staff: the real career breakpoint

The jump from Senior (P40) to Staff (P50) is the most important one on the ladder. Same title family, completely different job.

Staff engineers operate as technical leaders without formal authority. They define architecture, guide technical direction, and shape roadmaps across teams. At Staff, you’re measured by what others can build because of you and compensation starts to reflect that.

Beyond Staff, engineering becomes increasingly strategic. Senior Staff engineers (P55) operate across domains, aligning engineering efforts with business goals and driving initiatives that span multiple teams.

Principal engineers (P60) move to a company-wide level of influence. They define technical vision, tackle ambiguous problems, and shape decisions that impact entire product lines. At this level, engineering is less about building and more about direction-setting.

Cross-company level mapping

One useful way to understand Adobe’s ladder is to map it against more transparent systems at companies like Microsoft. While titles and expectations vary slightly, the underlying progression is broadly aligned across Big Tech. Adobe’s levels tend to appear slightly compressed in naming, but comparable in scope, especially from Staff level onward.

The important nuance is that while the mapping is directionally accurate, scope matters more than exact title equivalence. A P50 at Adobe may operate closer to a strong L6 at Google or even edge into L7 territory, depending on the organization, reinforcing the idea that Adobe’s ladder is less about labels and more about impact.

What Adobe actually values?

One pattern runs through the whole ladder: scope drives everything.

• Early levels – Can you execute?
• Mid levels – Can you own?
• Senior – Can you design systems?
• Staff+ – Can you influence outcomes across teams?

That’s the real progression. The ladder feels invisible from the outside because titles aren’t the point — expanding impact is.

Adobe’s ladder stands out for how quietly it operates. No playbook, no loud framing, just one consistent logic: as you grow, you move from writing code to shaping systems to shaping decisions. At the top, one question defines everything: how much of the company changes because of your work?

The post Let’s Take A Look Inside Adobe’s Complete Career Ladder appeared first on ShiftMag.

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

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

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

PagerDuty built their MCP to cut context switching

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

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

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

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

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

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

Retrieve what you need, nothing more

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

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

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

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

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

AI helps but engineers still decide

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

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

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

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

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

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

“MCP – the connective tissue between tools”

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

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

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

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

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

Engineers trust systems that behave predictably

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

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

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

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

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

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

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

The problem with GraalVM reflection

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

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

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

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

Start simple, then add feedback

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

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

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

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

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

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

Coverage sometimes still isn’t enough

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

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

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

Cost, agents and model selection

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

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

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

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

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

The architecture that lets it run without you

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

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

Vojin outlined what he calls the key context layers:

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

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

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

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

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

Where things stand

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

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

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

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

We caught Vojin Jovanovic for a few more questions!

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

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

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

Is just asking the LLM enough?

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

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

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

When does using multiple agents make sense?

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

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

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

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

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

Compliance starts in the design phase

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

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

The AI Act is changing product development in 3 ways

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

1. Transparency and auditability

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

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

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

2. Explicit guardrails instead of assumptions

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

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

3. Human oversight is a part of the architecture

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

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

Why compliance-by-design is becoming the standard

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

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

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

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

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

Risk assessment depends on the use case

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

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

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

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

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

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

August 2026 is approaching…

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

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

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

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.