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.

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.