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

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

Research, plan, execute

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

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

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

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

Engineering is now becoming even more necessary…

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

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

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

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

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

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

… and engineers are now more orchestrators than code writers

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

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

Zvonimir, interestingly, had a take about exactly that:

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

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

Want to hear more? Check out the video.

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

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

At CTO Craft Con, Dr. Catherine Hicks (founder of Catharsis Consulting and researcher on open-science work involving 15,000+ developers) argued that most engineering measurement failures aren’t really data problems.

No matter how much dashboards you vibe-code (we all do that nowadays, don’t we?), the problem is theoretical: understanding what causal model your metrics are actually testing.

Are you building spike lines?

Hicks opened with a historical detour that turned out to be her sharpest part of the argument. Probably a bit brutal from today’s point of view, but early electricity measurement looked straightforward: count the deaths, count the lumens, measure the hours of labor saved.

Why the number of deaths? Those numbers made sense relative to what came before. Gas infrastructure occasionally caused sidewalks to explode. Zero to ten electrocution deaths in a neighborhood looked different once you remembered that twenty people you knew had died from the sidewalk going up.

Measurement always encodes a comparison, and if you do not make that comparison explicit, your metric will mislead you.

The more cutting example was the spike line. In early U.S. rural electrification, large power companies would create something called a spike line. It’s a single wire that ran through a region, sometimes connected to nothing more useful than a light in a shed, in order to legally claim the territory and block rural co-ops from building real infrastructure. The federal government that was measuring electrification by the presence of a line wasn’t measuring access but the exact opposite.

Hicks argued that engineering organizations are building spike lines right now, and mostly do not know it.

Measurement failures usually come back to theory failures.

The loudest thing (on Slack) might not be the most important

A change theory, in her framing, is a causal model: if I give engineers more ramp time on this language, they will engage differently with these processes, and that will produce a business outcome. Everyone operates inside such models, but most teams never make them explicit.

The result is that they default to measuring what is visible, what is fast to collect, or what is loudest on Slack. None of those is necessarily connected to the outcome they care about.

On AI specifically, she identified three recurring failure modes:

1. Treating developers as interchangeable units producing identical work, when they’re actually using AI in highly individual contexts.
2. Reading early spikes in code volume as a stable signal, when research on open-source repositories shows those spikes often normalize into different patterns within weeks.
3. Measuring only at the individual level while ignoring the interaction between the tool, the team, the task, the project goals, and organizational culture – a system Hicks said has too many interaction terms for any person to hold at once.

Her response to that complexity was deliberate: stop trying to measure everything.

Your job is not to measure everything that’s happening. What you really need to do is think about what in your organization are the key signals to measure if they give you two things.

Those two things are levers, predictors of large behavioral patterns, or blockers you can actually remove, and shared outcomes you can hold the organization accountable to over time.

Correlation between learning culture and team effectiveness

Hicks drew on her own research to illustrate what a well-theorized lever looks like.

In a 2024 study of over 3,000 working developers, her team tested whether learning culture could reduce the identity threat that developers report feeling from AI. Teams with strong learning cultures, defined as believing they have organizational support to learn, and rejecting fixed-mindset assumptions about what makes someone technically capable, cut their AI-related identity threat by 50% or more. She has since replicated the correlation between learning culture and team effectiveness across multiple engineering organizations, and found that reaching the highest effectiveness tier requires clearing a threshold of learning culture, not just improving incrementally.

The practical upshot for leaders: if you want to measure whether your AI investment is working, you probably should not start with token consumption or PR velocity. You should ask whether developers believe their organization treats learning as legitimate work.

What if your metrics are broken?

On the question of what to actually do when you realize your metrics are broken, Hicks was direct. Describe how you got there. Find the argument you lost, or the organizational story that made a bad measure feel safe to commit to. Then build a change theory first, and derive the measures from that, not the other way around.

She closed with a framing that captured her broader position: you are not trying to map every variable in a complex system. You are trying to create enough shared understanding that people will tell you what is actually happening.

You will become the person who can hear what is really happening. You will be the person who will start to hear: I think we’re measuring spike lines over here.

That, she argued, is more useful than any dashboard.

The post Tokens and PR velocity won’t tell you if your AI investment is paying off appeared first on ShiftMag.

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

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

PRISM uses AI token activity to estimate energy use and emissions

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

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

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

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

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

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

From idea to IDE

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

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

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

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

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

How red was that prompt?

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

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

Nayan continued to explain the colors:

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

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

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

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

The impact is awareness, not less AI use

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

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

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

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

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

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

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

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

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

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

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

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

Our Shift CTO Craft Dinner format is built on candor, rather than slides or sponsor pitches. It’s just a group of senior engineering leaders talking about what’s actually happening in their organizations. At our Toronto dinner held on the outskirts of the CTO Craft conference, the theme was AI adoption in engineering

Within the first 5 minutes it was clear we’d spend the evening confirming one uncomfortable truth, similar to the one we heard earlier this spring in London: nobody has truly yet figured it out.

Note: We’ll try to figure it out at our Shift developer conference in September on the beautiful Croatian coast – tickets are on sale!

The free-for-all is over

Two years ago, the mandate was simple: spend on AI, no questions asked. That era is over.

What’s replaced it is a harder conversation, one several participants had clearly been having with their CFOs. The question has shifted from are you using AI to what are you getting for it?

The need for an ROI hasn’t changed. If anything, that window of just spending freely is dwindling. For larger organizations, the expectation is return within 12 months, or sooner.

The challenge, as one participant put it, is that the I in ROI is completely unmanaged. Engineering capacity used to mean headcount, something finance could model. Now it means tokens, and nobody controls how many tokens any individual engineer burns on a given day.

The CFO has no control once they’ve signed the contract over what the actual investment is going to be. And if you can’t tell me the investment, what does projected return even mean?

Several people around the table had run into the same wall: organizations that bought the tools, signed the contracts, and then realized there’s no financial model inside the company to manage what comes next. The comparison kept coming up: early cloud adoption, FinOps before FinOps existed. We’re in that same window. Costs are still a fantasy, usage is still undefined, and the metrics to measure it haven’t been invented yet.

One participant’s take: pushing for ROI too hard right now might mean measuring the wrong things entirely. The smarter move is to establish a baseline first.

I think eventually it will get to a more predictable state where we can say, approximately this many tokens leads to this much feature value. But I don’t think we can predict that yet.

The more pragmatic response, shared by more than one team: stop the free-for-all, start standardizing. This doesn’t mean we’re telling people to use AI less, but nudging from “use everything” to “use the same things, smarter.”

What you’re actually hiring for now

The hiring discussion exposed a split in how people in the room think about what an engineer actually is.

One participant drew a clean line between two different roles that often get conflated: the AI engineer who ships product, and the engineer who owns system design. Language doesn’t matter anymore: Python, Go, Rust, Node. But system design hasn’t changed. Someone still has to think about availability, budgets, and the architectural decisions that AI can’t make for you.

The new software engineer is a product leader. Someone thinking about what the product is, not just how it works. But we still need technical people who think about the design. Those are two different things.

On the interview side, the consensus leaned toward keeping technical fundamentals, but with caveats. One team hadn’t changed their process yet, still testing for systematic thinking, for the ability to break down ambiguous problems. Others were actively rethinking it. The most interesting take came from someone who’d shifted their interviews toward code review rather than coding, precisely because that’s what engineers actually do now.

I changed our interview process to focus on code review, because that’s what we’re actually doing. And implementation is now AI-assisted, however you choose to use your agents.

If your team can generate code faster than it can review it, you have a bottleneck. The constraint is human judgment, not output.

Team reactions and ‘recalibration moments’

Across the table, nobody described a team that was uniformly enthusiastic or uniformly resistant. The reality was messier.

One leader talked about late adopters at his company who finally jumped in after being gently pushed, then hit what he called “recalibration moments“: realizing that whole categories of work that used to take days now take hours, and having to rethink how their schedule works.

Another described something more complicated: an engineer who is highly productive with AI, genuinely good at using it, but also deeply skeptical of AI-generated output.

There’s one person who’s really good at using AI, very productive, but also highly sensitive to anything AI has produced. “This is written by AI.” “Okay, but is it good?” “Yes, it’s good. But it’s written by AI.”

The concern about AI making people stop thinking came up more than once. The counterargument wasn’t a dismissal. It was a reframe: this is a management problem, not a technology problem. The tools make it easy to be lazy. The job of a leader is to make laziness not worth it.

You can choose to make something fast and long and not that good. Or you can use it to iterate and really drill it down to something short. We can all write really long letters now. Whether we should is a different question.

One company ran an anonymous survey and found 90% of engineers at that organization actually want to use AI, higher than expected. What surprised him wasn’t the enthusiasm but what came next: questions about performance management, about promotion criteria, about how individual contribution gets recognized when anyone can now generate code. The adoption had outrun the enablement.

We’re applying AI adoption rapidly, but we haven’t updated the career pathway or rethought the competency matrix. They have every right to ask those questions.

The feature debt problem nobody wants to talk about

AI makes it cheap to write code. That is not the same as it being cheap to ship it, or to maintain it. One participant put it cleanly: cognitive debt is the new technical debt.

The room had seen the same pattern: teams adding features at a pace that would have been impossible two years ago, now dealing with the maintenance overhead that comes with it. Legacy code that was already hard to understand is now harder, because the people who wrote it aren’t being careful. They’re being fast. And internal tools that were never meant to be permanent are now permanent because someone shipped them with three prompts.

Those processes, build or buy, is this worth maintaining long term, were there for a reason. But if you can spin something up in an afternoon, it’s easy to skip them. The problem comes later.

One participant’s response: write whatever you want, but writing it doesn’t mean you’re shipping it. Code is cheap, but launching it isn’t. Keeping that distinction alive in a team is harder than it sounds when management is celebrating every PR.

The concept of a dedicated “technical health team” came up as a structural answer: engineers who ship features and engineers who delete or refactor them, treated as equally valuable work. Getting buy-in for that from a business incentivized by velocity is the actual challenge.

Who should be shipping PRs?

The most spirited part of the dinner: if AI makes it easy for anyone to write code, should product managers be shipping PRs?

The room was divided. Not on the possibility (everyone agreed the tools make it technically feasible) but on whether it’s the right thing to optimize for.

One participant pushed back hard on the narrative of non-engineers shipping to production as a win:

If you’re effectively making engineers into code review monitors, protecting the company from PRs they didn’t write, while the PM gets the credit for shipping, check in on your engineers’ mental health.

Others were more pragmatic. Enabling non-engineers to contribute on smaller, lower-risk tasks reduces the feedback loop for everyone. Designers who can write a component to spec without waiting for an engineer. Product managers who can fix a copy bug without opening a Jira ticket. That has value, as long as the guardrails are right.

The self-driving car analogy landed well: an average AI-assisted non-engineer is probably better than an average unassisted one. But nobody’s comparing them to the engineers who spent years developing the expertise. The comparison only makes sense within a specific complexity range.

If a feature is 80% engineering and 20% product thinking, an engineer can do it. If it’s the reverse, maybe a PM can handle it. What I think is actually happening is that we’re becoming value creators who pick up whatever slice of the work makes sense, regardless of title.

The harder structural question got no clean answer: if anyone can ship, whose job is it to hold everything together? Several people in the room said the only realistic response is radical team autonomy: small groups of three to five people who own their own decisions, with management’s job shifting to alignment rather than gatekeeping.

Code review is the bottleneck. AI might fix it.

One participant had been thinking about this from a CI/CD angle: the problem isn’t that teams can’t generate code, it’s that they can’t review it fast enough. Human review is now the bottleneck, and the solution isn’t more reviewers. It’s smarter triage.

His team had been experimenting with confidence scoring on PRs: using AI to assess the risk of a change and surface only the parts that actually need human eyes. A 15,000-line PR with three lines that need human review isn’t a 15,000-line review problem. It’s a three-line problem, if you can trust the rest.

I honestly think you can have a fifteen thousand line PR and say, I need a human to review these three lines. Everything else here is fine. I don’t know how to do that yet, but I know it has to happen.

The deeper point was about abstraction layers. We don’t read assembly, we trust compilers. The question is whether you can build enough validation infrastructure, feature flags, observability, acceptance tests, mutation testing, to make a similar trust relationship work with AI-generated code.

Nobody in the room claimed they’d solved it. Several said they were pushing as hard as they could in that direction.

One practical suggestion that came out of this: invest in evals now, not later. The cost of building AI features isn’t the hard part. The cost of verification is. If you build a solid eval suite today, you can swap providers, survive model deprecations, or move to open source without starting from scratch.

The cost of building isn’t as high. The cost of verification is high. When the vendor you’re partnering with changes their model, which they do often, you just run that suite of evals and you’re okay.

The vendor you’re betting on

What happens when Anthropic or OpenAI raises prices, goes down, or gets disrupted?

One participant said it plainly: her entire company has a single point of failure on Anthropic. Engineering understands single points of failure. The people in marketing and finance building on top of Claude do not.

So many teams outside engineering are building things, and I don’t think they truly understand what’s underneath it. If all of a sudden we can’t get inference, what happens to marketing? What happens to finance? They’re gonna call engineering.

The counterpoint was that competition will keep pricing in check. Open source models are no longer years behind; they’re a couple of versions back at most. You can’t double your prices when customers have alternatives. But the lock-in concern isn’t really about the model itself. It’s about everything built around it. Skills, tooling, internal workflows — those are much harder to migrate than a model endpoint.

The practical advice: build internal UI wrappers over generic model APIs now, before your teams are locked into specific product interfaces. It’s cheap to do, and it means you can swap the model underneath without rebuilding the interface your teams depend on.

What’s next? Let’s talk about it at Shift

These reflections, reactions and conversations were part of just one of our Shift CTO dinners that we’re organizing as a lead up to our Shift engineering and AI conference in September. All of our dinner participants have been invited – and so are you!

We’re also planning some Engineering leadership programming, but will be talking about topics just like the ones in this article – building AI native engineering teams, growing your developer career, scaling systems – across the conference agenda. I’d love for you to join us – get your tickets and see you in Zadar!

The dinner was held under Chatham House rules. Quotes are used without attribution.

The post CTOs Agree: Cognitive Debt Is the New Technical Debt appeared first on ShiftMag.

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

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

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

Burn, baby, burn

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

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

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

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

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

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

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

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

What about controling the PR size?

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

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

Different approaches to reduce human review burden

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

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

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

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

Writing code is no longer a bottleneck

Poletto said in closing:

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

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

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

We played “Truth or Dare” with developers again, truth only, with no option to dodge the answer by doing push-ups.

Developers from different parts of the industry spoke about how they survive tight deadlines, tension inside engineering teams, and the subtle, protective lies they use to get through the week.

There’s a pressure to sound confident

In engineering teams, pressure, shifting priorities, and the need to move quickly shape communication. In that environment, “truth” is more about signaling confidence, alignment, and forward progress than precision.

Weekly meetings, fast delivery cycles, and constantly changing priorities push developers to learn that how they communicate can matter as much as the work itself.

That is why we asked how developers manage expectations. The phrase “it will be done” often appears early, sometimes before anyone fully understands the scope of the task. Under pressure, estimates tend to be optimistic, and reality usually forces adjustments as the work moves forward.

At the same time, developers handle that pressure in different ways – some narrow their focus and push through tight deadlines, while others start by asking whether those deadlines even make sense.

The truth about deadlines

Deadlines sound like a nightmare for an engineering mind, so we asked our developers how they deal with them.

Some described how short deadlines increase focus and force prioritization. Others questioned whether extreme deadlines reflect process problems rather than urgency.

Hrvoje Rančić, Senior Software Engineer, described how constant pressure can indicate systemic misalignment rather than effective planning:

I realized that deadlines can sometimes be a mechanism of manipulation. If there are too many short deadlines, something is wrong in the process. Either people are making unrealistic promises, expectations are unrealistic, or there is poor communication between product and engineering.

At the same time, other participants admitted that deadlines can help with focus and discipline, but only when they are based on a realistic scope of work, not on constant escalation of pressure.

The point is not that deadlines are bad, but that misaligned and unrealistic deadlines often point to deeper organizational issues.

Engineering is often about people, not just code

The stereotype of the isolated, antisocial engineer still exists, even though modern software development is highly collaborative. That misconception often clashes with the reality of teamwork, where communication, negotiation, and constant alignment are a key part of the job.

Kristina Valjak, Engineering Lead, summarized it:

Some people think engineers are introverts who don’t socialize, who sit in basements and stare at screens all day. Maybe it’s true that we’re not social enough, but in reality, everyone is smart.

The irony is that engineering work is rarely isolated. Most of the tension developers describe does not come from code, but from coordination between them, the product teams, and management.

How developers smooth over the truth at work

Developers often tell small, strategic lies to keep work flowing smoothly. These are not dramatic deceptions, but everyday adjustments such as overconfidence in estimates, downplaying uncertainty, or agreeing in meetings while problems are resolved in the background.

Emin Mulaimović, Junior AI Engineer, reflected on this broader communication culture, recalling an anecdote from his first job:

At my first job they told me not to say I was happy at work, so I kept complaining all the time. I think that’s the only lie I tell. I don’t tell them how much fun I actually have working there and how much I enjoy the job.

In another example, a developer described solving an issue during a break and returning to the meeting without interrupting the flow of discussion. In other cases, developers admitted to deliberately inflating estimates or simplifying status reports to avoid unnecessary tension.

This behavior is not so much about deception as it is about reducing “noise” in systems that are already complex enough.

Want to hear more? Check out the video.

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

The post The Small Lies Developers Tell to Keep Work Moving appeared first on ShiftMag.

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

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

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

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

The acceleration is accelerating

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

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

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

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

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

Give AI more power and it gets proportionally smarter

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

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

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

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

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

The more capability, the more risks

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

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

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

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

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

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

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

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

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

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

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

Why not just build custom MCP servers?

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

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

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

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

Infobip’s answer was no.

The OpenAPI connection

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

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

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

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

How the framework works

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

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

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

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

Not every endpoint should become a tool

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

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

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

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

Naming, descriptions, and making agents actually use your tools

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

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

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

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

Solving authentication without reinventing it

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

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

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

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

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

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

Building on a moving train

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

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

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

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

The demo

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

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

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

The post Your API Is Already a Hidden MCP Server, You Just Need to Discover It appeared first on ShiftMag.

I spend most of my time maintaining our companies internal developer portal (IDP), known internally as Kazhoon (which is built on Backstage). Like any developer portal, it provides a lot of features built by a wide range of engineering teams.

Beyond my core team of maintainers, there are about 50 other contributors across the company who regularly develop their own plugins and features. All of these engineers push code to a single, giant monorepo.

As you can imagine, there are going to be a lot of challenges with this kind of setup. In this guide, I’m going to focus on solving one of them.

The Multi-Contributor Challenge

When contributors are working on some feature, before merging, they would like to test it out, usually in a staging/testing environment. A small team working on a project has no issues here. They will just internally coordinate who gets to deploy at what time. But when you have 5 teams simultaneously working on different features, you will get conflicts.

Our solution initially was to tell people to merge their “feature” branch into a “dev” branch that in theory should contain the features of all the other contributors as well. We would then deploy just this “dev” branch. In practice, however, we were still getting conflicts, just this time in a different place.

Contributors would have issues merging their changes into the dev branch due to several reasons. Sometimes the dev branch was outdated, missing the latest changes from the master branch. Sometimes the contributors branch was not up-to-date.

Sometimes someone doesn’t merge cleanly, which causes frustration to all the other people wanting to merge as well. Every few weeks we had to create a new “dev” branch from scratch because it just became impossible to fix the problems with the old one.

So how do we solve this problem? The answer came to me while experimenting with Kubernetes. I was in the process of migrating one of our projects from a traditional “Docker on a VM” setup into Kubernetes. The project in question, as you might guess, is Kazhoon, our internal developer portal (IDP). 

Before explaining the solution, it helps to first understand how we deploy applications to Kubernetes.

How do we deploy to Kubernetes

Apart from having standard Kubernetes clusters, Infobip also leverages ArgoCD. A continuous delivery/deployment tool that sits between developers and Kubernetes. It uses GitOps principles to continuously sync infrastructure configuration stored in a Git repository with the actual cluster state.

This way, developers don’t need to directly interact with a Kubernetes cluster but instead just tweak and update the files in git and ArgoCD will make sure the changes get reflected in the actual Kubernetes cluster.

Also, it gives us a nice UI to monitor the changes.

So how do we deploy?

Well…, let’s say we want to deploy a “simple” application. In this case it is our IDP Kazhoon. Keep in mind that our app has do be dockerized for it to be deployed to Kubernetes.

P.S. The files below are created in a separate git repository that is linked with our ArgoCD application. For more information check out ArgoCD docs. Parts of the files have also been cut out for clarity.

We will first create a file which describes how our application should be deployed. Important parts have comments.

apiVersion: apps/v1
kind: Deployment # Type of resource in Kubernetes that manages our pods (aka. instances)
metadata:
  name: backstage-deployment # Name of the resources
  namespace: infobip-kazhoon
spec:
  replicas: 2 # Number of pods to create/manage
  selector:
    matchLabels:
      app: backstage-deployment
  template: # this is where we describe each deployment of our application
    metadata:
      labels:
        app: backstage-deployment
    spec:
      imagePullSecrets:
        - name: image-pull-secret
      containers:
        - name: backstage-deployment
          image: docker.domain.com/infobip-backstage:1.175.9 # dockerized image on internal artifact repository.
          imagePullPolicy: IfNotPresent # Yes, Kubernetes will cache your images, so if it already existed, it will reuse it based on the name/version.
          ports:
            - name: http # new port called "http"
              containerPort: 7007 # port where our application is listening
          envFrom:
            - configMapRef:
                name: backstage-config # Environment variables defined in a separate file
            - secretRef:
                name: backstage-secrets #  Secret Environment variable defined in a separate file
          resources: # We don't need to provision VMs for our application, we just tell Kubernetes how "heavy" our app is and Kubernetes will make sure to give us enough power.
            requests:
              cpu: "1"
              memory: "1Gi"
            limits:
              cpu: "1"
              memory: "1Gi"

We also need some sort of internal load balancer for our pods to be able to connect to them. We need to create a Kubernetes Service. 

apiVersion: v1
kind: Service # Type of Kubernetes resource that acts as an internal load balancer. It also allows other resources to communicate with out pods
metadata:
  name: backstage-service
  namespace: infobip-kazhoon
spec:
  selector:
    app: backstage-deployment # We tell the service which pods it should find
  ports:
    - name: http #  we define a new port 
      port: 80 # this port gets opened on the Service 
      targetPort: http # resolves to the 7007 port of our pods (check the ports defined in the Deployment snippet)

As a last step we also want to allow for people outside the Kubernetes cluster to connect to our application. We need an Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress # Type of Kubernetes resource that allows us to expose our internal network to the outside. In Infobip we use Haproxy for this.
metadata:
  name: backstage-ingress
  namespace: infobip-kazhoon
  annotations:
    iks-external-dns.k8s.infobip.com/hostname: infobip-kazhoon-iot1.domain.com # special Infobip annotations that create a DNS record for our network
    cert-manager.io/common-name: infobip-kazhoon-iot1.domain.com # used for TLS
    cert-manager.io/cluster-issuer: vault-issuer # TLS
spec:
  rules:
    - host: infobip-kazhoon-iot1.domain.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: backstage-service
                port:
                  number: 80
  tls:
    - hosts:
        - infobip-kazhoon-iot1.domain.com
      secretName: minimal-ingress-cert # stores the certificate in this certificate resource

Once we create all the files, we push them to our git repository and hit “Sync” on ArgoCD. If we did everything okay we should see something like this:

Since this is a simplified “network” view we don’t see all resources (config files, certificates, etc…). The pods/instances on our right are the result of our “Deployment” resource which is not visible here.

As you can see, with just a handful of files we managed to completely skip VM provisioning as well as avoid the need to click through yet another UI just to deploy.

And then, it clicked

Kubernetes wasn’t just solving our infrastructure problems. Its design made it possible to solve the contributor problem I described at the beginning.

Instead of coordinating deployments, managing shared environments, or deciding who gets to test changes and when, we could let the platform do the work for us.

Everything could be automated.
Every change could have its own environment.
No coordination required.

The solution?

Ephemeral Environments

Whenever a contributor opens a new pull request, we can create an ephemeral (temporary) environment specifically for that branch, using the steps described in the example above.

We deploy the contributor’s branch to this environment and provide a unique link where they can test their changes.

This approach means contributors don’t need to think about deployment at all – everything happens automatically.

Each temporary environment is fully isolated from the others. The only shared component is the database, which could be further improved by switching to an in-memory solution.

Each environment has its own ingress, ensuring that every contributor receives a dedicated URL for their branch.

Because of this, we can eliminate the need for a separate dev branch and deploy feature branches directly.

How it works?

Step 1: Pull Request Hooks

Initially a contributor will just write some code, test it locally, and when happy, open up a pull request. This is where most developers would usually deploy to some IO environment that is close to a production setup for additional testing.

Instead of having to worry about the deployment, a Bitbucket webhook which listens to the PR_OPENED event will trigger a Jenkins job. The same Jenkins job that is used to build the main Kazhoon application. This is done to prevent duplication of jenkins groovy code as well as archetypes, which I will explain later. Simple hook below.

Notice the additional hook at the top. This is the main hook used for the app. It triggers the same Jenkins jobs but under different conditions (PUSH_EVENT – when code is pushed).

All of this can also be achieved on Github as well, using workflows.

Step 2: The main Jenkins Job

Apart from the main logic for building Kazhoon and pushing a docker image (standard for most Infobip apps), we additionally need the setup for Kubernetes. Keep in mind that the Jenkins job runs every time new code gets pushed. We need a way to detect which code change is linked to a PR. In other words: Does the branch that is currently being built have an open PR linked to it?

Initially we figured we could just use the build parameter PR_ID as seen on the image above. This was working okay for testing, but then a problem appeared. How do we detect code changes? After all, we would like the most recent code to be deployed and not just the one that existed when we opened up the PR.

Sadly, the PR_ID parameter does not exist on regular code changes. We could create another hook using the PR_SOURCE_RESCOPED event, but that would mean that we will have duplicate Jenkins jobs. One for the newly added hook and one for the original “main” hook that always gets triggered when we push code. We need a different solution.

Luckily, it is possible to call APIs through Jenkins, so what we can do is call the Bitbucket API, check if the branch currently being built has an open pull request, and if so, initiate the Kubernetes setup. This logic can be done on the initial pull request open event as well as subsequent code change triggers. Here is how that would look like. Example written in a Jenkinsfile using scripted pipeline syntax.

def findPrForSourceBranch(sourceBranch) {
    withCredentials([string(credentialsId: globconst.GIT_HTTPS_TAG_TOKEN, variable: 'GIT_TOKEN')]) {
        def response = httpRequest(
            url: "${globconst.BITBUCKET_API_URL}projects/IAF/repos/infobip-backstage/pull-requests?state=OPEN&at=refs/heads/${sourceBranch}&direction=OUTGOING",
            httpMode: 'GET',
            contentType: 'APPLICATION_JSON',
            customHeaders: [[name: 'Authorization', value: "Bearer ${GIT_TOKEN}"]],
            validResponseCodes: '200'
        )
        def prList = new groovy.json.JsonSlurper().parseText(response.content)
        if (prList.size > 0) {
            return prList.values[0].id
        }
        return null
    }
}
node('infobip-docker-nodejs:v20-dev') {
    LoadJenkinsPipelineLibrary(this)
    if (!env.PR_ID && env.BRANCH_NAME && env.BRANCH_NAME != 'master') {
        def prId = findPrForSourceBranch(env.BRANCH_NAME)
        if (prId) {
            env.PR_ID = prId
            echo "Found PR_ID=${prId} for branch ${env.BRANCH_NAME}"
        } else {
            echo "No PR found for branch ${env.BRANCH_NAME}"
        }
    }

In the later stages we can just check for the env.PR_ID. If it exists then there is a PR linked to the branch. Here is how that would look like:

Stages:

1. Clone Kubernetes config repository which is linked to the ArgoCD application
2. Generate Kubernetes files from template – make sure we sanitize the values
3. Push to git
4. Trigger sync on ArgoCD and leave comment in PR with link to new deployment.

def K8S_CONFIG_REPO = 'ssh://git-instance.com:7999/project-name/infobip-kazhoon.git'
def K8S_CONFIG_BRANCH = 'master'
def K8S_CONFIG_TARGET_DIR = 'k8s-config-repo'
def featureName = env.BRANCH_NAME.toLowerCase().replaceAll(/[^a-z0-9_-]/, "-") ?: 'feature-preview'
def k8sSafeName = env.BRANCH_NAME.toLowerCase().replaceAll(/[^a-z0-9-]/, "-").take(40).replaceAll(/-+$/, "") // Kubernetes name limit
def dnsSafeName = k8sSafeName.take(24).replaceAll(/-+$/, "") // DNS name limit eg. infobip-kazhoon-iot1-feature-verylongbr.domain.com

stage('Clone Kubernetes Config Repo') {
	// A neat trick to skip jenkins stages. Left out in later stages for brevity
    if (!env.PR_ID) { 
        Utils.markStageSkippedForConditional(STAGE_NAME)
        return
    }
	// Clone the kubernetes repository where we put our initial files for deployment.
    sshagent(credentials: [GIT_CREDENTIALS]) {
        globlib.git.checkout(gitUrl: K8S_CONFIG_REPO, gitBranch: K8S_CONFIG_BRANCH, targetDir: K8S_CONFIG_TARGET_DIR)
    }
}

stage('Generate Kubernetes Files from Template') {
    def featurePath = "${K8S_CONFIG_TARGET_DIR}/feature/${featureName}"
    // Copy and customize template. The template looks similar to the 3 files we created for the deployment just with some parts containing placeholders instead of fixed values.
    sh """
        mkdir -p ${featurePath}
        cp -r ${K8S_CONFIG_TARGET_DIR}/feature/template/* ${featurePath}/

        # Replace placeholders in template
        for f in ${featurePath}/deployment.yaml ${featurePath}/service.yaml ${featurePath}/ingress.yaml; do
            sed -i -e "s|{{IMAGE_TAG}}|${dockerLabel}|" \
                -e "s|{{K8S_SAFE_IMAGE_TAG}}|${k8sSafeName}|" \
                -e "s|{{DNS_NAME}}|${dnsSafeName}|" \"\$f"
        done
    """
}

stage('Push Kubernetes Resources to Git') { 
    dir("${K8S_CONFIG_TARGET_DIR}") {
        sshagent(credentials: [GIT_CREDENTIALS]) {
            sh """
                git config user.email "infobip-ci@infobip.com"
                git config user.name "Infobip CI (Jenkins)"
                git add .
				// We don't want the script to fail if there are no changes
                if ! git diff --cached --quiet; then
                    git commit -m 'added feature ${featureName}'
                    git push -u origin ${K8S_CONFIG_BRANCH}
                else
                    echo 'No changes to commit'
                fi
            """
        }
    }
}

stage('Trigger Sync on ArgoCD') {
    withCredentials([string(credentialsId: 'kazhoon_argocd_bearer_token', variable: 'BEARER_TOKEN')]) {
        def response = httpRequest(
            url: "https://argo-instance.com/api/v1/applications/infobip-kazhoon-iot1/sync",
            httpMode: 'POST',
            contentType: 'APPLICATION_JSON',
            customHeaders: [[name: 'Authorization', value: "Bearer ${BEARER_TOKEN}"]],
            validResponseCodes: '200'
        )
    }
	// Utility function for posting comments to Bitbucket PR.
    postPrComment(env.PR_ID, "finish", """ Your **feature environment** is live!
    ![party](https://media2.giphy.com/media/v1.Y2lkPTc5MGI3NjExcjFyczl4anFvZXYzNGY1aGM2amIyZTk5Y3B6ZWJ4dHM1Y2ExamptYSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/a0h7sAqON67nO/giphy.gif)
     Access it here: [Preview URL](https://infobip-kazhoon-iot1-${dnsSafeName}.domain.com)
     Note that it might take a few minutes for the DNS to propagate and the service to become fully operational.
     If you encounter any issues, please contact [#kazhoon_contributors](https://infobip-support.slack.com/archives/C098ETXLL2U) on slack.""")
}

Step 3: Cleanup

After the PR is merged, the letfover deployment is automatically cleaned up using a separate webhook and Jenkins pipeline which I won’t go into detail for this blog post.

In short, when a PR is merged or deleted, a Jenkinsfile.cleanup  pipeline is executed to remove all previously created resources and trigger a sync in Argo CD.

The same Jenkinsfile.cleanup pipeline also runs periodically to remove stale resources from old PRs, helping avoid unnecessary infrastructure and electricity usage.

Conclusion

Kubernetes and Argo CD allowed us to significantly improve the developer experience for everyone contributing to Kazhoon. By adopting a GitOps-driven approach, we eliminated the need to interact with a UI and, with it, the mental overhead of figuring out how and where to test changes. The entire deployment process is now fully abstracted away from contributors.

The original “dev” branch which was a major source of confusion and friction no longer exists. Developers work exclusively on their feature branches, each with its own isolated, production-like environment.

This setup also removed a large portion of our support overhead. Everything is automatic, predictable, and clearly communicated directly through pull request comments, allowing contributors to focus on what actually matters: building features.

Resources & Shout-outs

Special shout-out to Matej Kern and his team for helping me throughout the entire process. From explaining Kubernetes concepts to setting up the infrastructure behind everything described in this post. This project would not have been possible without their support and guidance.

A huge shout-out as well to the maintainers and contributors behind these amazing projects and resources that made this workflow possible:

• Kubernetes
• Argo CD
• Backstage, where I got the inspiration from
• The cloud-native computing foundation

Hope you enjoyed this blog post. It’s my first official one (and definitely not the last). There’s a lot I didn’t manage to include, because it would’ve ended up being a whole novel, so if you have any questions or thoughts, I’m always happy to chat. Feel free to message me on X.

The post Solving the Multi-Contributor Challenge with Kubernetes and Ephemeral Environments appeared first on ShiftMag.

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

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

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

Developers should adopt AI gradually

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

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

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

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

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

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

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

In his view, neither approach is correct.

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

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

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

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

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

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

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

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

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

AI will reshape roles in tech companies

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

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

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

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

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

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

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

AI agents are still nothing without people

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

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

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

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

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

There are fewer junior developers, but they are still valuable

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

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

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

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

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

Experienced developers face an identity crisis because of AI

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

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

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

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

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

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

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

The future is uncertain but exciting

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

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

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

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

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

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