Fortunately, there was no production incident; most issues were detected during internal testing. It is always better to learn on someone else’s mistakes, this article will help you learn on mine.

The architecture in place

The service orchestrates WhatsApp campaign delivery through an asynchronous, scheduler-driven pipeline. Campaign destinations enter the system via an API and are persisted to MS SQL Server. Two background schedulers handle the processing. The first retrieves unscored destinations, invokes a scoring service to evaluate delivery priority, and assigns each destination to a bulk: either appending to an existing one or creating a new bulk when capacity is reached.

The second scheduler manages the delivery lifecycle: it polls the external Bulk Scheduling System for status updates, submits ready bulks for sending, and coordinates priority by pausing lower-scored bulks while higher-priority ones are in flight. MS SQL serves as the central state store, maintaining campaign metadata, bulk assignments, and processing status throughout the pipeline.

Insert record in batches

When you expect a heavy load, don’t insert data one by one. We learned this when a client started sending their campaign as separate HTTP requests—one message per request, all belonging to the same campaign. Our controller accepted a list of messages, but a single-element list is still a list, right? The service started returning HTTP 500 errors due to waiting too long for an available database connection.

We solved this by introducing Kafka as a buffer between the API and the database. Incoming requests get published to a topic and then consumed in batches, enabling batch inserts into the database. A nice bonus came from how Kafka handles partitioning: by setting the message key properly, we ensured that all requests for the same campaign land in the same partition—and get processed together.

Of course, the implementation should still handle lists properly. One caveat: Hibernate does support batch inserts (feel free to check), but not when you use an IDENTITY primary key generation strategy. With IDENTITY, the database generates the ID on each insert.

To get true batching, we bypassed Hibernate and used plain JDBC.

override fun submitCampaign(campaignRequest: CampaignRequest) {
    val message = campaignRequest.messages[0].message
    val campaignId = campaignRequest.parameters.campaignId ?: "no-campaign-id"
    val topicKey = "${message.channelId}-${message.from}" +
                   "-${campaignRequest.parameters.templateName}-$campaignId"
    val messageBatches = campaignRequest.messages.chunked(maxMessagesPerBatch)

    messageBatches.forEach { batch ->
        val batchRequest = CampaignRequest(
            messages = batch,
            parameters = campaignRequest.parameters
        )
        campaignRequestProducer.send(ProducerRecord(TOPIC_NAME, topicKey, batchRequest))
    }
}

@KafkaListener(
    topics = [TOPIC_NAME],
    containerFactory = KafkaConsumerConfiguration.BATCH_LISTENER_FACTORY_BEAN
)
@Timed
fun processRequests(
    records: List<ConsumerRecord<String, CampaignRequest>>,
    ack: Acknowledgment
) {
    val groupedByCampaign = records.groupBy { it.key() }

    for ((_, recordsGroup) in groupedByCampaign) {
        val campaign = findOrCreateCampaign(...)
        val destinations = recordsGroup.flatMap { it.value().messages }.mapToDestinations(campaign)
        storeCampaignDestinations(destinations)
    }

    ack.acknowledge()
}

@Transactional
override fun batchInsert(destinations: List<CampaignDestination>) {
    if (destinations.isEmpty()) return

    val sql = """
        INSERT INTO cds.campaign_destination
            (campaign_id, destination, external_message_id, content, failover)
        VALUES
            (?, ?, ?, ?, ?)
    """.trimIndent()

    jdbcTemplate.batchUpdate(sql, destinations, destinations.size) { ps, dest ->
        ps.setLong(1, dest.campaign.id)
        ps.setString(2, dest.destination)
        ps.setString(3, dest.externalMessageId)
        ps.setString(4, dest.content)
        ps.setString(5, dest.failover)
    }
}

Now Kafka took the big chunk of stress, the database can easily handle the load.

Too complex queries

A query that’s too complex can take too long to execute, especially without proper indexes. Think about what data you already have in the application and use it to simplify things. In our case, we needed to find bulks that still had space for more recipients. The original query joined the destinations table to count how many each bulk contained, filtered by several conditions, and used a HAVING clause to check capacity.

@Query("""
    SELECT cb, COUNT(cd) FROM CampaignBulk cb
    LEFT JOIN CampaignDestination cd ON cd.campaignBulk = cb
    WHERE cb.campaign = :campaign AND cb.priority IN (:priorities) AND cb.waitUntil > :nowWithBuffer AND cb.bulkStatus = 'CREATED'
    GROUP BY cb
    HAVING COUNT(cd) < :maxBulkSize
""")
fun findNotFullAndNotExpiredBulks(campaign: Campaign, priorities: Set<BulkPriority>, maxBulkSize: Int, nowWithBuffer: Instant): List<BulkWithCount>

The problem? A join on an unindexed column, filters without indexes, a COUNT, and a HAVING clause. Combined, it was too much for the database. The query took ages and locks escalated to entire tables. It quickly turned out that we already knew the destination count during processing. So we denormalized: we added a destinationCount column to the CampaignBulk table and updated it whenever destinations were added. The new query and supporting index look like this:

@Query("""
    SELECT cb FROM CampaignBulk cb
    WHERE cb.campaign = :campaign
      AND cb.priority IN (:priorities)
      AND cb.waitUntil > :nowWithBuffer
      AND cb.bulkStatus = 'CREATED'
      AND cb.destinationCount < :maxBulkSize
""")
fun findNotFullAndNotExpiredBulks(
    campaign: Campaign,
    priorities: Set<BulkPriority>,
    maxBulkSize: Int,
    nowWithBuffer: Instant
): List<CampaignBulk>

CREATE NONCLUSTERED INDEX idx_campaign_bulk_count_filter
ON cds.campaign_bulk(campaign_id, bulk_status, destination_count)
INCLUDE (id, priority, wait_until, bss_bulk_id, api_key_id, creation_date, last_status_change_date);

After these changes, the query performs well.

Concurrency: when more isn’t always better

We all want to process data as fast as possible. Especially in the world of virtual threads; you can spin up thousands of them and feel good about how concurrent your application is. But the database doesn’t share that enthusiasm. Under the hood, you have a limited Hikari connection pool. Run too many concurrent operations and your queries start timing out. Worse, when multiple threads hit the same table and the same dataset, you’re heading straight for lock contention.

Here are a few things to consider when you need to control concurrency.

Use shedlock

ShedLock is a library that ensures scheduled tasks run only once across multiple application instances. It works by creating a lock record in a shared storage—typically a database table—before executing a task. When a scheduler triggers, it tries to acquire the lock by inserting or updating a row. If another instance already holds the lock, the task is skipped.

The lock is released after execution or after a configured timeout, preventing deadlocks if an instance crashes mid-task. In our case, we wanted to avoid the same campaign being processed by a couple of instances at the same time.

Shedlock helps a lot here. Feel free to check the full ShedLock documentation.

val config = LockConfiguration(
    Instant.now(),
    LOCK_NAME_FOR_PROCESS_CAMPAIGNS + campaign.id,
    Duration.ofMinutes(5),
    Duration.ZERO
)

val lock = lockProvider.lock(config)

if (lock.isPresent) {
    try {
        singleCampaignService.processSingleCampaign(campaign)
    } finally {
        lock.get().unlock()
    }
}

Limit your concurrency with a semaphore

A Semaphore lets you limit how many threads can execute a block of code at the same time. In our case, each scheduler iteration could potentially process dozens of campaigns in parallel; especially with virtual threads, where spawning new threads is cheap. But each campaign processing involves multiple database operations: reads, updates, and inserts. Letting all of them run at once would exhaust the connection pool and trigger lock contention.

We introduced a Semaphore with a fixed number of permits to cap the number of campaigns processed concurrently. Before processing a campaign, a thread must acquire a permit. If all permits are taken, the thread waits, but with virtual threads, this isn’t a problem.

When a virtual thread blocks, it gets unmounted from its carrier thread, freeing it to run other virtual threads. So waiting for a permit doesn’t waste OS resources like it would with traditional platform threads. Once processing is done, the permit is released.

This keeps database load predictable and prevents the connection pool from becoming a bottleneck.

private val semaphore = Semaphore(10)
private val executor = Executors.newVirtualThreadPerTaskExecutor()

fun processCampaigns() {
    val campaigns = campaignRepository.findAllToProcess()

    campaigns.forEach { campaign ->
        executor.submit {
            semaphore.acquire()
            try {
                processSingleCampaign(campaign)
            } finally {
                semaphore.release()
            }
        }
    }
}

Use query hints

When multiple threads query the same table, the database decides how to handle locking. Sometimes those defaults work against you in different ways. Locks escalate, threads wait on each other, or worse, deadlocks occur. SQL Server lets you guide this behavior with query hints. Here are the ones we found useful:

• UPDLOCK – reserves update locks on selected rows, so other threads can’t select the same rows for processing.
• READPAST – skips rows that are already locked by other threads instead of waiting for them to be released.
• ROWLOCK – suggests that SQL Server use fine-grained row-level locks instead of page or table locks.
• NOLOCK – reads rows without acquiring shared locks, allowing it to read data that other transactions are currently modifying. This means it won’t block writers and won’t be blocked by them but it can return dirty data that might be rolled back, or even read the same row twice or skip rows entirely if data is being moved during the scan.

Think about your access patterns. Are multiple threads competing for the same rows? Are you okay with skipping locked data or reading uncommitted changes? The right combination of hints depends on your specific use case but knowing they exist can save you from mysterious slowdowns and deadlocks.

Process data in batches

Even with ROWLOCK hints, SQL Server can escalate locks. When a single transaction acquires too many row locks on one table, SQL Server may convert them into a table lock for efficiency. This is called lock escalation, and when it happens, your “harmless” operation suddenly blocks everyone else.

We learned this the hard way. Our scoring scheduler fetched all unscored destinations for a campaign in a single query, which sometimes includes tens of thousands of rows. With UPDLOCK to prevent other threads from picking them up, SQL Server decided it was cheaper to lock the entire table. Suddenly, other threads couldn’t read or write to the destinations table at all. The whole pipeline stalled, waiting for one greedy query to finish.

The fix was simple: fetch in batches. Instead of selecting all unscored destinations, we now use TOP(n) and iterate until there’s nothing left to process.

SELECT TOP(400) cd.*
FROM cds.campaign_destination cd WITH (UPDLOCK, READPAST, ROWLOCK)
WHERE cd.campaign_id = :campaignId
  AND cd.bulk_id IS NULL
  AND cd.id <= :maxId

Each batch locks only a few hundred rows, commits, and moves on. This keeps the lock count well below the escalation threshold and lets other threads continue their work.

For more details on lock escalation, see Microsoft’s Troubleshooting explanation.

Final thoughts

The database is not an implementation detail you can ignore. I hope these lessons save you some debugging time.

Have you faced similar challenges? I’m curious how others handle these problems.

The post How Convenient JPA Defaults Broke Our Kotlin Microservice appeared first on ShiftMag.

What’s the worst type of project?

Sure, the term “worst” means different things to different people, but most of the engineers agree: the worst types of projects are the ones that aren’t set up well by humans, not the ones that have big technical requirements. And, as you can probably guess, human-designed flaws are much more creative.

For example, one engineer highlighted that the worst project for him was working with family members who were not familiar with software development at all, affecting expectations, realisations and everything in between.

Another situation was a client project that took four months, with progress going smooth up until the last month. Nikola Buhiniček, Engineering Manager, said:

The client changed the scope significantly without much warning. We had to abandon a lot of the work we’d already done and come up with new features and opportunities. It felt like compressing two and a half months of work into one month before the deadline.

Another type of projects that drive engineers crazy are legacy code projects without real instructions on how to approach them, as explained by Edvin Teskeredžić, Senior AI Software Engineer:

We had this old legacy project, basically 10-year-old code which needed to be maintained. It was also all internal libraries but there was no documentation. The documentation simply lived in the heads of senior engineers, so you had to kind of figure it out yourself, and you couldn’t Google it because it was all internal libraries.

What’s the best, then?

In contrast, the best projects tend to be tied to others as well, only this time it’s about great teams and good colleagues. For some engineers, the best projects are those where leadership has a clear vision and that vision is clearly shown to the teams.

Other engineeers, such as Filip Bolčić, Full-Stack Engineer, highlighted teamwork as the best part of the projects they’ve worked on. For example:

Everybody’s insight was really valuable, and I had a great mentor from whom I learned a lot. It was just a really meaningful project for us, we felt really good working on it.

On the other hand, Nikola noted that sometimes, the best projects are the most challenging ones. He explained the process of adding the automations feature to Productive was one of the more challenging and interesting ones he worked on:

It was such a different feature from what we used to do, and I was given the opportunity to build it. In the end it was one of the best features we have. The usage is growing up from month to month. I’m really happy that it was something that I built like two years ago, and it’s still growing so fast.

It all comes down to the human factor

The hardest thing to fix as an engineer might not even be software-related, according to Hrvoje Rančić, Senior Software Engineer:

My posture. I had really terrible back pain from sitting too much during the COVID era. I think this is a very dangerous job because it involves a lot of sitting, and sitting is the new smoking, so I encourage everyone to move more if you’re a software engineer.

Ergonomics aside, Software Engineer Emin Mulaimović said that some of the biggest recent challenges he had were related to LLM’s:

We had this unstable LLM prompt which basically means you ask the same question and it gives different answers, and the answers are not marginally different. To fix that you just need to rephrase the question over and over and over again until it worked. And then when it worked you didn’t learn anything, you didn’t have fun fixing it, you’re just glad it’s over. Some bugs are fun to fix; this one wasn’t.

On the other end of the spectrum, the toughness of a task comes down to a personal mistake by the engineer themselves, and there’s rarely anything you can do but to fix it. That’s exactly what happened to Filip:

I remember working on a really big-scale production application and accidentally just deleting a lot of important stuff from the database. I was really young in my career and I remember being really stressed out about this, but the project manager protected me and we were able to restore a backup of this database, so in the end everything was good, but it was really stressful for me.

And to further drive the point home, sometimes the fix isn’t even tough, but so time-consuming you think you’re going crazy, as evidenced by Olga Koroleva, Engineering Manager:

I made a bug in the code where entries to the database were written wrong, and I had to manually fix thousands of them. After that, I always double-checked and triple-checked everything.

Make sure to check out the entirety of the video to find more about the best and worst projects, and the challenges of software development!

Special thanks to our engineering colleagues at Infobip, Nikola Buhiniček (Engineering Manager, Productive) and Filip Bolčić, (Full-Stack Engineer, Ars Futura).

The post Developers are the reason behind best (and worst) parts of software development appeared first on ShiftMag.

In a recent conversation with a few Infobip engineers, we asked whether that promise holds up in practice – and the answer was clear: AI can generate code fast, but it still cannot understand the problem, define the boundaries, or own the consequences.

That part remains the developer’s job.

AI should be a tool for accelerating clearly defined tasks

Better context and clearer specifications make useful, maintainable, and secure output far more likely. As Zvonimir Petković, Staff Engineer, explained:

The quality of the code ultimately depends on the context given to the GenAI agent and the model underneath. The software engineer is still the one writing the specifications, and the better the specification and context, the better the code produced.

To maintain quality, he says, we need to isolate the code into smaller segments and check each one. Effective work with coding agents is less about one large prompt and more about small, controlled iterations.

That may mean changing the architecture, refactoring a component, or requesting a more precise implementation of a single interface. František Lučivjanský, Senior Principal Engineer, described a similar workflow:

I work with AI in smaller chunks. I give it a small part, review the result, and steer the agent: “This is not correct; do it this way.” I may also define the architecture differently – for example, by asking it to refactor one part first. These slow iterations help me maintain the same quality I would achieve manually.

Working in smaller chunks helps developers preserve a mental model of the system and review decisions while the code is still easy to change. AI serves as a tool for accelerating clearly defined tasks.

AI doesn’t create technical debt, people do

Faster code generation naturally raises questions about technical debt. Teams have more code to understand, test, and maintain, but AI did not create technical debt. Debt grows from deadlines, trade-offs, and decisions that prioritize short-term delivery over long-term maintainability.

For Tvrtko Ivasić, Application Security Intern, the answer is not to relax established controls, but to reinforce them:

We should preserve the standards established in the past: the security pillars, the SDLC pipeline, code review, SAST, and the rest of the process. If anything, the bar should be even higher because the code is now generated by AI rather than written by an engineer.

AI-generated code should go through the same SDLC as human-written code: code review, automated tests, SAST, and dependency checks.

František Lučivjanský notes that agents don’t remove the pressures behind technical debt, but they can help manage it more deliberately. They can also spot duplication, suggest refactors, write tests, or explain legacy code, but the value still depends on the engineer reviewing the output.

Vibe coding might evolve into agent engineering

Vibe coding may be enough for a hobby project or proof of concept, but problems begin when the same workflow reaches production without additional controls. Engineers may not need to write or memorize every line, but they still need to understand the architecture, system boundaries, scalability, and failure modes, enough to delegate implementation without delegating responsibility.

Asked whether vibe coding is a sustainable approach to software development or merely a short-term productivity boost, Zvonimir argued that it is likely to evolve:

Vibe coding is not just a short-term boost or a passing trend. “Dark factories” may represent the ultimate direction, with workflows that incorporate vibe coding and require us to look at the code less and less. I think it will evolve into agent engineering, and that is how software will be built in the future.

Companies that adopt this workflow may ship faster without sacrificing quality, spending less time on routine code and more on specifications, architecture, evaluation, and automated controls. The key is to understand where vibe coding creates speed, where it introduces risk, and how AI agents fit into proven software engineering principles – because responsibility for what reaches production remains unchanged.

Special thanks to our engineering colleagues from Infobip, the publisher of ShiftMag!

The post AI Helps Ship Faster, But It Doesn’t Do the Thinking appeared first on ShiftMag.

Ahead of the Infobip Shift Conference in Zadar this September (for which you get a special discount as a ShiftMag reader), we spoke with Amir, who will be one of the speakers. Reflecting on Doist’s longevity, he said, “We’ve always thought in decades, not quarters.”

While many Todoist competitors raised big funding rounds and grew too fast before being acquired or shutting down, Doist chose a slower, steadier path focused on product and users – and it paid off.

Remote work needs to be sustainable, not glamorous

Doist has also been remote-first from the start and is often cited as an early example of remote work at scale.

They have spoken often about job satisfaction, mental health and wellbeing, but he says Doist hasn’t “solved” mental health in remote work. Instead, the company is structured to make people less likely to feel isolated or overworked, or to struggle quietly.

Furthermore, Amir explained:

Remote work offers freedom, but it can also blur boundaries and create loneliness. So we focus on making it sustainable, not on making it glamorous. We’re remote-first, not nomad-first: people can work from anywhere, but we encourage them to build roots near friends, family, and community.

For Amir, people simply do their best work when they have good lives. Simple as it may be, it’s also something that goes completely over the heads of many companies, especially fast-growing startups in the “AI hustle” era.

Building software isn’t enough anymore

A quick Google or LinkedIn search tells you all you need to know about the state of productivity apps and software in 2026. The marketplaces are flooded with AI tools and wrapper apps, creating a greater need for quick success than just a few years before, and a “closing window” dynamic where developers must achieve massive scale in months or disappear.

Amir tells us that, despite this, many of the fundamentals still matter:

Are you solving a real customer pain point in a 10x way? Is your solution differentiated? Do you have strong marketing and a memorable brand?

Continuing, Amir says that the bar to create has dropped dramatically, but the quality bar has risen just as much. To succeed now, one needs to build something far better than what was required when Amir was starting out. Concluding, Amir says that you “need to be incredible at many things, such as design, marketing and sales, not just software.”

Engineering still matters in 2026

Doist emphasizes deliberate decision-making, and that same approach shapes its engineering culture. For Amir, “engineering culture at Doist” means:

Making clear technical choices and trade-offs that help us serve users, move faster with confidence, and build durable foundations. It’s about thoughtful preparation, strong ownership, high-quality systems, and focusing on the technical work that matters most (not chasing everything at once).

Speaking of engineering, Amir’s talk at Infobip Shift will be watched by engineers and leaders in the space, many of whom are building products themselves. To them, he says that the engineering mindset is still incredibly useful for building and scaling companies, and that engineering still matters a lot in 2026.

Make sure to reserve your ticket with a special discount for ShiftMag readers!

The post Doist CEO: ‘The bar to create has dropped, but the quality bar has risen’ appeared first on ShiftMag.

But what does that career structure actually look like?

To answer that, we explored publicly available discussions on platforms like Reddit and Dev.to, connected common patterns, and compiled a clear overview of the Google engineering ladder.

What the Google engineering ladder looks like

Public sources generally describe Google’s engineering levels like this:

At the early stages, engineers typically focus on learning, delivering well-scoped tasks, and becoming independent in familiar problem spaces. In contrast, at higher levels, the emphasis shifts toward technical strategy, cross-team collaboration, and creating impact that extends far beyond individual contributions.

Google rewards increased scope, greater leverage, and sustained impact over time

A common misconception is that more years of experience automatically lead to higher levels. However, reality is more nuanced. Instead, Google evaluates engineers based on scope, impact, and influence.

At lower levels, engineers are expected to:

• Learn systems quickly and effectively
• Deliver tasks with appropriate guidance
• Collaborate closely with teammates
• Build strong technical independence over time

As engineers progress to mid-level roles, expectations expand. They are expected to:

• Lead complex projects from start to finish
• Make sound technical decisions under uncertainty
• Navigate ambiguous requirements
• Take ownership of systems or features
• Communicate effectively across teams and functions

Meanwhile, at higher levels, the focus shifts again. Engineers are expected to:

• Influence multiple teams and stakeholders
• Understand organizational and technical context broadly
• Define or shape technical direction
• Solve systemic rather than isolated problems
• Multiply impact through others
• Act as anchors for large-scale initiatives

Senior vs. staff

The transition from Senior to Staff is often considered one of the most significant jumps in the entire ladder.

A Senior Engineer typically:

• Works independently on complex problems
• Leads major features or components
• Understands architecture and trade-offs
• Mentors other engineers
• Delivers impact primarily within a single team or domain

Senior Engineer is a strong individual contributor whose influence remains largely within a defined area.

However, a Staff Engineer operates differently.

A Staff Engineer:

• Focuses on the broader system, not just one team
• Connects multiple teams and initiatives
• Identifies and resolves systemic issues
• Drives cross-organizational projects
• Aligns people, processes, and architecture
• Produces impact that extends beyond direct output

Therefore, the shift is not about doing more work. Instead, it is about expanding influence and creating long-term, scalable impact across systems and teams.

Outcomes matter more than job titles

Google’s leveling decisions are usually shaped by three major factors.

1. Interview Performance

During interviews, candidates are evaluated on:

• Technical depth
• Problem-solving ability
• Analytical thinking
• Role-specific knowledge
• Leadership signals

However, strong coding skills alone are not enough. Candidates must demonstrate they can think like engineers who design and maintain large-scale systems.

2. Previous Experience and Projects

Experience matters, but it is not the only factor.

More importantly, Google looks at:

• What you actually delivered
• The impact of your work
• The complexity of your projects
• Whether you led meaningful initiatives
• Evidence of ownership and responsibility

3. Skill Set and Ability to Create Impact

In addition, Google values engineers who can:

• Learn quickly in new environments
• Make informed risk assessments
• Operate effectively under ambiguity
• Communicate clearly and consistently
• Influence others through credibility and mentorship
• Take responsibility beyond formal assignments

As a result, seniority reflects not only technical ability but also influence and leadership without authority.

How much do Google engineers earn?

Based on public reports, approximate annual compensation ranges often look like this:

For L9 and above, public data is limited, and discussions tend to focus more on rarity and impact than exact numbers.

Overall compensation depends on several factors

It is important to remember that these figures are estimates based on public sources, not official salary disclosures. Actual compensation varies depending on:

• Location
• Level
• Base salary
• Bonuses
• Equity (stock grants)
• Performance
• Team and product area

For this reason, professionals in Big Tech usually refer to total compensation (TC) rather than base salary alone.

What is above L6?

As engineers advance beyond Staff level, their responsibilities become increasingly strategic.

L7: Senior Staff

At this stage, engineers influence multiple teams and broader domains. Rather than solving isolated problems, they help shape how entire groups of teams operate.

L8: Principal Engineer

Principal Engineers define technical direction across large areas of the organization. This role requires long-term thinking, strong systems design skills, and the ability to align complex technical decisions.

L9+: Distinguished Engineer, Fellow, Senior Fellow

Only a very small number of engineers reach these levels. Their influence can extend across:

• Entire organizations
• The company as a whole
• The broader tech industry

At this stage, the focus shifts from implementation to shaping the future direction of large-scale systems and platforms.

What is Google Career Dreamer?

Google Career Dreamer is a career exploration and guidance tool designed to help users better understand their skills and career options.

It helps users:

• Identify transferable skills
• Define their professional identity
• Explore potential career paths
• Prepare for career transitions

Main Features

1. Career Identity Statement
This feature helps users summarize their professional profile for use in resumes, LinkedIn, portfolios, and introductions.

2. Explore Career Possibilities
It suggests roles aligned with a user’s experience and skills.

3. Relevant Jobs Near You
Users can discover job opportunities that match both profile and location.

4. Gemini Support
The tool also integrates AI support for:

• Cover letters
• Resume improvements
• Career planning

In conclusion, the Google career ladder is not defined by a single dimension but by the scale of problems you solve, your influence across teams, your ability to handle ambiguity, your leadership without authority, and the multiplier effect of your work.

The post Google Careeer Ladder for Engineers Explained appeared first on ShiftMag.

The question is how that response gets requested. 

The agent ran. It checked the queue, detected the anomaly, made the call. Then it produced a tidy summary (decision, rationale, confidence score) and delivered it to the person who was watching. 

That’s the happy path. The fact of the matter is that most runs aren’t that clean.  

One failure, a dozen scenarios

Each of the cases listed below is a version of the same failure: the agent did its job, but the result didn’t reach the right person:

• The agent hit a step it couldn’t resolve and stopped, waiting for an approval that nobody saw.  
• A decision came back ambiguous and needed a human call, but there was no way to surface that to the right person in time.  
• An edge case surfaced mid-run that the original prompt didn’t account for, and the agent had no way to escalate it. By the time anyone noticed, the context was stale. 
• The colleague who needs to act on the decision wasn’t in the thread. The on-call engineer isn’t watching the terminal.  
• The automated pipeline that ran at 3am had no audience.  

The agent’s output is readable, but it’s trapped in the interface that produced it: visible to whoever happened to be present, invisible to everyone else. 

Connecting the agent to a messaging channel doesn’t solve the problem entirely, but it does extend the reach of its output beyond the interface it ran in.  

Tool count is an architectural decision 

The practical question is how to do it properly. Most messaging MCP servers are built for full-featured channel integrations: scheduling, logs, template management, bulk sending. That’s useful if you need it. But for an agent that just needs to notify someone or request a human decision, you’re loading a lot of tools into the model’s context that have nothing to do with the task. 

Every tool you expose to an LLM costs more than the API rate card suggests. The tool’s schema, name, description, parameters, gets injected into the model’s context on every invocation. A server with 27 tools loads 27 definitions into every request. The model them has to reason over all of them. 

That’s not always a problem. If your agent needs scheduling, delivery logs, carrier-level capability checks, or template management, a full-featured channel server earns its footprint, and it’s typically the most common go-to use case for messaging MCP servers. 

But if the agent just needs to notify someone, you’re paying a context tax on 26 tools you didn’t ask for. 

This is the argument behind deliberately minimal MCP servers: for simple use cases, smaller is also more accurate, not just cheaper.  

What “minimal” could look like in practice 

When Infobip talked to developers using its MCP ecosystem, a pattern emerged: some of them weren’t reaching for the full feature set. They had a pipeline, an agent, and a need to notify someone (sometimes to attach a screenshot while at it).

The Infobip Message MCP server is a direct response to that feedback: one or two tools covering SMS, RCS, and Viber, with support for images where the channel allows for it.  

There’s something worth noting in that design choice. The broader Infobip MCP ecosystem includes channel-specific servers with rich feature sets: the RCS server has 27 tools, WhatsApp has 18. The Message server sits deliberately at the opposite end and caters to use cases that only require low footprint.  

It’s not a replacement for the channel-specific servers, but a different tool for a different job. The agent can then send a notification across three different channels from a single tool call. 

The pattern behind the product 

Out of this integration comes an interesting trade-off to consider: how does the minimal-footprint pattern hold up as agents get more capable? 

Agents take on more complex workflows. The instinct is to give them more tools, more context, more capability, and more surface area. But since the relationship between tool count and agent performance is not linear, past a certain point, more tools will always mean more ambiguity about what to call, more opportunity for hallucinated parameters, more tokens spent on reasoning over options rather than executing. 

For narrow, high-frequency actions (notifications and alerts being the clearest example), there’s a real case for purpose-built tools that do one thing and declare that scope clearly. Not every agent capability needs the full API surface. 

Whether that principle scales to more complex tasks, and whether the industry converges on a layered tool architecture rather than a flat one, is still an open question.  

But for now, for the specific problem of “my agent needs to reach a human,” starting minimal and adding surface area only when the use case demands it seems like a more defensible approach.   

The post Human Decisions Are The Real Bottleneck Of Agent Design appeared first on ShiftMag.

Eoin, who now works independently across software architecture, green software, and engineering, has spent decades around large systems.

The failures he keeps seeing are rarely exotic. They begin with something mundane, an environmental detail nobody verified, a technology nobody fully understood, or a second order effect nobody expected until the system was already live.

That is why, for him, architecture is less about drawing clean systems on paper and more about surfacing the assumptions production will eventually expose.

Production is where the assumptions become visible

When I asked Eoin where failures come from, he resisted the temptation to separate elegant design from messy execution. He argued, the system that matters is the one that ships, and the one that ships is full of assumptions.

Ultimately the problem is always the design or actually, not even the design but what ends up in production…

This means that diagram may look reasonable, the architecture review may pass and the slide deck may even sound convincing. Production is where the assumptions become visible. Experience changes what people notice, Eoin put this bluntly:

The older and more cynical you get, the more questions you ask.

Seniority, at least in architecture, often means noticing the missing question before the missing answer turns into an incident. The same logic applies to coupled systems. A component can behave well on its own and still create trouble once the rest of the system starts reacting to it.

If one component slows down dramatically, the others (if tightly bound to it) probably slow down dramatically as well. It’s only when it actually happens that everyone realises everything else slows down in lockstep, because they hadn’t realised how coupled together they were.

That is the kind of failure teams usually understand only after the fact. The system behaves as designed, then fails as a whole because the interactions were never really understood as interactions.

Architecture is never just about structure

That distinction matters most where recovery is expensive. Financial infrastructure, healthcare, industrial control, and similar environments do not get the luxury of treating failure as a learning exercise.

We’re much less enthusiastic about moving fast, breaking things and fixing forwards actually because if we do break something in a mission critical system it has a really serious side effect.

In those environments, speed only helps when recovery is cheap. If rollback is hard, repair is slow, or the impact is irreversible, then fast delivery stops being a virtue and starts becoming a liability.

That is why architecture is never just about structure, but about consequences. A design that looks efficient in a presentation can become expensive in the real world the moment its assumptions meet a system that cannot absorb mistakes.

Writing the scenario forces the hidden question into the open

Eoin made the same argument in his Devoxx talk by describing a scene almost every engineer will recognise.

A stakeholder asks for something scalable, cost effective, secure, and easy to use. The architect comes back with containerised microservices, lower storage costs, forced password changes, and a task oriented interface. The stakeholder says it sounds good, while still not really understanding what was asked or what was decided.

That gap between what was asked and what was understood is exactly what architectural scenarios are designed to close.

A scenario takes a vague wish and turns it into something concrete. Not “the system should be scalable” but what happens when 5,000 users connect at the same time and the primary database fails at 7pm during peak load. Not “the app should be secure” but what happens when a decryption key needs to be recovered after an incident. The value of that exercise is not subtle.

There’s nothing like writing a scenario to reveal what you don’t know about your own system.

That is why scenarios matter, Eoin believes. They do not make uncertainty disappear, but they do force it into view.

He described six practical uses for scenarios. Teams use them to:

• decide what to build
• compare design options
• drive research
• assess design choices more broadly
• explain existing system behaviour to people who need to understand it without getting lost in technical detail
• surface the questions that should have been asked much earlier

The point is not documentation for its own sake though, but to make the system legible before production does the explanation instead.

If offline mode has only been demonstrated and never truly tested against the live system, the scenario is where that becomes obvious. If a recovery flow exists mainly in a vendor demo, the scenario turns the demo into a question rather than a conclusion.

The simplest useful habit is still discipline

Eoin’s most practical advice was also the least glamorous:

Make architectural decisions intentionally, and write them down.

This means recording the assumptions built into it, the trade offs it accepts, and the implications that follow.

ADRs, or architecture decision records, are not a new idea. Eoin said he was already writing them as a graduate in the 1990s, and even then they were not common practice. The fact that the advice is old does not make it less relevant. If anything, the opposite is true.

AI tooling is generating code faster than teams can inspect the assumptions that end up inside it. Requirements are still vague. Stakeholders still do not always understand the technical response and decisions are still too often left implicit.

The result is more software with more hidden assumptions inside it.

That is where architecture really begins, in the part of the work that makes those assumptions visible before production has to do it for you.

The post Why Good Architecture Still Fails in Production appeared first on ShiftMag.

Join us on the beautiful Croatian coast

Speaking of sneak peeks, reading this article makes you eligible for a discount on Infobip Shift tickets. You’re welcome.

To kick things off, I had the opportunity and pleasure to talk with one of this year’s speakers,Teresa Wu. In addition to her work as the VP Engineer at JPMorgan Chase, Teresa is also a Google Developer Expert (GDE), an accomplished public speaker and mentor.

She has worked with many talented developers on various apps and projects over the years, and she enjoys exploring the world of multi-platform development, the fun of continuous delivery, and following a product from development to release.

Her experience makes her the ideal person to talk to about today’s tech landscape, especially in the era of AI. So we did just that, and also talked about the perspective of an experienced mentor and public speaker. Teresa also shared some hints of her upcoming talk at Shift!

AI accelerates multi-platform development

Throughout her career, Teresa has worked in front-end development, cloud technologies, and multi-platform products.
Currently, she is most inspired by multi-platform development, which she finds very exciting because, by using a single codebase combined with AI-powered automation, we can significantly speed up code generation and easily adapt user interfaces for iOS, Android, and web platforms:

In this way, traditional barriers between platforms are removed and the time needed to bring a product to market is significantly reduced. This allows engineering teams to overcome technical limitations and fully focus on rapidly delivering value to end users.

AI is nothing without people!

When asked how she sees the impact of artificial intelligence on the daily work of software engineers, Wu notes that AI is constantly evolving, creating a kind of feedback loop in which what we build today becomes training data for tomorrow’s systems:

AI frees us from routine and repetitive tasks, but it still relies on people when it comes to defining rules, guiding processes, and creating new patterns of thinking. That is exactly where human creativity, experience, and judgment remain irreplaceable.

Professional growth is impossible without enthusiasm

As a mentor and experienced public speaker, Teresa believes that sustainable professional development is almost impossible without genuine interest in what you do. That’s why she tries to find technology or projects that truly interest her, whether within her job or outside of it, and to find personal motivation in them:

For me, public speaking is not just an opportunity to present knowledge; it is a way to explore new ideas and build a network of friends and professional contacts. When you align your learning with what truly drives you, professional growth becomes a natural and fulfilling consequence.

Shift conference as an opportunity to expand knowledge

For Wu, this will be the first time speaking at (or visiting) Infobip Shift. She decided to participate because the event brilliantly combines cutting-edge technologies and a vibrant community of experts, and is especially looking forward to the unique atmosphere of a large tech festival in Zadar.

In addition, the opportunity to explore a beautiful destination while connecting with a global network of developers represents the perfect personal motivation for gaining new ideas and inspiration.

Much more than just code!

As she points out, Teresa’s main goal is to gain a new perspective on how engineering teams use AI-based automation:

Beyond technical talks, I place great value on people and conversations. What I especially appreciate about Shift is that it’s not just about code, but about the unique energy of thousands of developers trying together to understand what the future brings. I want to bring that inspiration into my everyday work as well.

Sneak peek of the Shift talk

Without revealing too many details, I asked Teresa to hint at the topic of her talk and what can attendees expect to learn or take away from it:

• Problem: Engineers responsible for software releases spend up to 40% of their time on manual processes and overly large change packages.
• AI-driven transformation: Moving from simple code-writing assistance to an autonomous “Release Pilot.”
• Data-driven decisions: Replacing subjective “go/no-go” decisions with an AI index that evaluates stability signals and system observability.
• Implementation plan: A 90-day migration path that significantly reduces manual work and enables faster, more efficient software delivery.

Want to hear Teresa live? Purchase your Shift ticket and use code MAG15 for a discount!

The post Great Developers Are Curious, Creative, and Ready for AI appeared first on ShiftMag.

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 spite 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 spite line. In early U.S. rural electrification, large power companies would create something called a spite 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 spite 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 spite 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.