For developers, that means model quality still matters, but benchmark scores no longer tell the whole story. As Igor Dmochowski (Developer Relations Manager, Nvidia) said at Infobip Shift 2026:

An agent is far more complex than a 2022-style chatbot: it can use tools, handle multimodal context, retain memory, and spawn subagents.

Hybrid architectures preserve useful state without making every turn more expensive

Longer context windows matter because agents need to remember more: past messages, documents, tool outputs, code, plans, and earlier steps. But as the context gets longer, self-attention becomes more expensive and harder to scale.

Dmochowski’s point was that context length is a real systems constraint. A model may accept a huge prompt, but still be too slow or too memory-hungry for a real application. The question now is what they cost to process:

The compute required to process your context was growing quadratically with regards to the context. This is not scalable.

The approach discussed on stage was a hybrid model that combines Transformer attention with Mamba-style state-space layers. Instead of using full attention for every token, the model uses more efficient layers for most of the work and keeps attention where it matters most.

That matters for agents because long context often contains information with very different levels of importance. “A production system needs enough capacity to preserve useful state without making every turn proportionally more expensive. Hybrid architectures are one attempt to move that curve in a more manageable direction,” Dmochowski said.

Models like MoE, active compute and throughput matter more than total parameter count

The second shift is sparsity.

In a conventional dense model, every token passes through the same large set of parameters. Igor explained that Mixture of Experts, or MoE, adds a routing mechanism that activates only a subset of specialized expert blocks for each token. The total model can contain far more parameters than are actually used during a single forward pass.

According to Dmochowski, this distinction between total parameters and active parameters is becoming much more useful when comparing models. A large parameter count can suggest capacity, but it says much less about serving cost once sparse architectures enter the picture:

We don’t need to put all of the tokens into all of the parameters of the model, we route them to the experts. For deployment, active compute, memory footprint, context length, KV cache behavior and tokens per second can be more informative than the headline parameter number alone.

Dmochowski connected that efficiency directly to capability. His point was that more throughput gives a system more room to reason within the same compute budget.

Agents can do more intermediate work and finish long tasks with lower latency. When reasoning uses thousands of tokens, throughput becomes part of the capability envelope, which is why multi-token prediction matters.

Lower-precision formats can reduce memory and compute requirements as well. Both techniques point toward the same goal: spend less hardware effort per useful token without destroying model quality:

The faster model is going to be the smarter model. There is obviously a trade-off, but producing two or four times more tokens with the same compute gives you room to make that trade-off.

For developers, efficiency is becoming an architectural feature

A model’s behavior depends on where you run it – the same model can act differently through a basic API than it does inside an agent harness with tools, memory, system instructions, and a loop that shows it the results of its actions.

A leaderboard or prompt benchmark only tells part of the story. An agentic app is a full system, not just a model. “Tool schemas, retry logic, context construction, memory strategy and the execution loop all influence the final result. Evaluation should therefore resemble the environment in which the model will actually run,” Dmochowski said:

The environment in which the models are set matters quite a lot. The behavior you get through an API can be completely different from the one you get within a harness.

The same idea applies during training and post-training: models should be trained in environments that simulate agent harnesses, and model choice and system design should be tested together.

Open models can be the better choice when private data has to stay in-house

Dmochowski also made a case for open models in domains where the most valuable data cannot be handed to a frontier model provider. Internal code, proprietary documents, regulated records and specialized workflows may require organizations to adapt models within their own environment:

Open weights, training recipes and reproducible tooling can matter most in exactly those cases, because the competitive advantage is often the private data and workflow rather than the base model itself.

The useful takeaway from Dmochowski’s talk is that the bottlenecks are moving. The early LLM conversation focused on scale and benchmark scores, but agentic systems force developers to think about long context, memory, generation speed, tool use, and the cost of every extra reasoning step. That changes how models should be evaluated: a smaller or sparser model can be the better choice if it keeps quality while lowering latency, and a huge context window only matters if the system can afford to use it.

The post LLMs Have a New Limit – It Costs More to Think Longer appeared first on ShiftMag.

Yesterday at Infobip Shift 2026, I listened to Apple Principal Engineer and CNCF Technical Oversight Committee member Katie Gamanji talk about the state of cloud native and its slow turn towards AI.

She said cloud native spent years becoming stable and unexciting, and AI teams now need that stability more than new tools. The big question is whether the people around that infrastructure can move as fast as the platform itself.

For teams already using Kubernetes in production, the next change is very concrete, Katie said:

Dynamic Resource Allocation, or DRA, reached general availability in Kubernetes 1.34, adding a native way to request GPU and TPU capacity for AI workloads.

Kubernetes is now officially boring

Katie started with a number that captures how far Kubernetes has come: “98% of organizations in the CNCF’s annual report said they had adopted cloud native technologies.” After a decade of development, Kubernetes has become mainstream:

Kubernetes is now described as being boring, and I think this is a wonderful achievement.

The problem appears when AI workloads enter that mature infrastructure. According to the figures Katie presented, 66% of organizations are already deploying AI workloads on Kubernetes. But only 7% are doing it daily, while 47% deploy them occasionally. Of the organizations using Kubernetes for AI, 23% have fully adopted the Kubernetes stack and 43% have partially adopted it.

That 67 to 7 gap points to one likeliest cause. The talk did not name the cause directly, but the pattern Katie described points to operational immaturity as the likeliest one:

Teams fine-tune an existing model rather than build one, deploy it once to prove it works, and lack the automated retraining pipelines that would treat the model as a dynamic component.

The 7% deploying daily, she noted, “most likely implemented an automated retraining pipeline that treats the model as a dynamic component rather than a static element.” Running an AI workload is not as simple as putting another application into a container. Teams need model artifacts, rollback strategies, and training pipelines. Kubernetes is being positioned as the shared platform, though whether teams adopt it that way is another question.

DRA and AI Conformance are making Kubernetes the AI platform

Katie compared this to DevOps: Kubernetes once brought developers and operations together, and now it could do the same for infrastructure teams and data scientists. But the analogy has limits – DevOps took years to work, and it is still not fully settled everywhere.

Data scientists, for their part, rarely want to operate Kubernetes; they want a model served. Still, a platform that can run both traditional workloads and training or inference jobs reduces the need for separate AI infrastructure.

Kubernetes is also adapting for this: DRA in 1.34 gives teams a more reliable way to allocate accelerators, which matters most for teams deploying daily.

The AI Conformance Working Group defines what a platform must support to run AI workloads reliably, with portability as the goal as Katie said:

If you have two conformant platforms, it’s going to be easy to lift and shift one product to the next platform.

Other initiatives target batch workloads, inference performance, and AI integration, and an Agent Sandbox effort is designing stateful, isolated runtimes for AI agents. The Serving Working Group completed its milestones and archived itself in February, continuing as a SIG on inference performance.

The list is still changing quickly. Katie expects much of this landscape to look different within six months to a year.

The cloud native playbook AI can borrow

Katie divided the emerging open source AI ecosystem into three areas: training, inference, and agents. Training turns data into a model. Inference serves it. Agents connect it to the outside world.

For platform leads, maturity matters. Training is led by the PyTorch Foundation, inference has many options, and agents are still young under the Agentic AI Foundation.

Cloud native experience can help AI tools mature faster. Security, observability, and identity were already solved in cloud native, and the CNCF project pipeline shows that kind of progress at scale.e.

It also prunes: 28 archived projects. For anyone choosing a stack, the archive list is a practical filter, and Katie argued archival is a healthy sign, letting maintainers redirect energy toward projects that earn adoption.

Teams that engage now will shape the patterns everyone else follows

For Katie, the next phase of cloud native is about whether the people building and maintaining the ecosystem can keep pace. She pointed out that contributing also means production feedback, feature requests, documentation, and white papers all shape projects.

But in the end Katie’s talk left the hard questions unanswered, but the data shows why:

98% of organizations trust Kubernetes with their infrastructure, two thirds have tried running AI on it, and almost nobody operates it continuously.

The specific bottlenecks, daily operational maturity, DRA adoption, and the conformance baseline, are still being defined, which means teams deploying AI on Kubernetes today are writing the patterns everyone else will copy:

All of the working groups’ meeting notes, invites, and repositories are public on GitHub. The teams that engage now, before the patterns harden, will not have to retrofit someone else’s choices in two years.

The post Only 7% of Organizations Using Kubernetes for AI Do So Daily appeared first on ShiftMag.

The easier it is to make something look finished, the more important it is to understand what the team actually decided.

That was the starting point for Hugo Raymond, Designer Advocate at Figma, in his talk at Infobip Shift 2026.

His main point was that AI becomes a problem when it fills in the gaps before decisions are made, because it can hide unresolved decisions.

A prototype shouldn’t try to look like a finished product

Hugo reminded us that the purpose of a prototype is to help the team test an idea. He compared it to a model airplane:

A model doesn’t try to be a real airplane. We use it to study specific characteristics of the airplane.

The problem, he argued, is that AI can now create a very convincing prototype even when the original idea is still incomplete:

In the past, gaps were easier to see. If a screen did not exist, a flow ended in a dead end, or the team had not defined a certain state, you could clearly see that nobody had made that decision yet. AI can now connect the flow, generate data, create loading and error states, and add behavior that nobody explicitly defined.

In the end, everything looks like one coherent product, even though the team designed some parts and the model simply filled in the rest.

Visual polish no longer proves that the team solved the problem

According to Hugo, this creates an especially important problem for developers: the more finished a prototype looks, the more authority we give it and the more likely we are to treat it as a specification that developers simply need to implement.

Hugo warned that a polished prototype no longer means that someone has thought through every edge case, business rule, or technical constraint.

One of his key points was that polish used to be expensive. If something looked highly refined, you could at least assume that someone had spent time thinking through the problem. Now, the tables had turned:

AI has broken that connection. The first draft can now look like the final iteration. Teams therefore need to make a much clearer distinction between what they have actually decided and what is still only an assumption.

Code is not the opposite of design

Hugo doesn’t think the solution is to move design back into static mockups, quite the opposite: code is not the opposite of design but one of the materials we use to design:

A code prototype can use real data, react to unexpected input, and show states that a designer did not draw in advance. AI has made this kind of experimentation much more accessible.

Still, code and a design canvas don’t show the same things.

Code is very good at showing what happens, while the canvas can do a better job of preserving why the team made a certain decision, which alternatives the team considered, and what the team still needs to solve.

Because of that, he sees a future where teams combine different materials depending on what they’re trying to learn.

AI speeds up execution, but not decision-making

The final and most important point of his talk focused on the limits of automation.

AI can take over a lot of repetitive work, speed up prototyping, and help teams test ideas more cheaply, but making something faster does not mean we understand what to make any better.

Hugo therefore makes a distinction between friction worth removing and friction that serves a purpose:

We can automate copying, waiting, and repetition. We should not automate comparing options, testing assumptions, discussing trade-offs, and questioning decisions.

As he pointed out, these moments help teams develop the judgment that AI cannot simply replace. “When almost every prototype can look finished, how convincing it looks is no longer the most important thing,” he said. What matters is whether the team can still clearly see what it has decided, what it has assumed, and what it still needs to solve.

The post AI speeds up prototyping, but teams still need to distinguish decisions from assumptions appeared first on ShiftMag.

Google DeepMind’s VP of Technology argued that one of the most important developments to watch is the rise of systems that can learn beyond the limits of human-generated training data.

He said AI has already gone through most publicly available human knowledge and is ready for the next step:

What it really needs now is to start generating its own experience and its own data. In the next year or two, that’s exactly where AI is heading.

That’s where recursive self-improvement comes in: AI could start learning from its own experience by trying problems, checking its answers, finding mistakes, and testing different approaches instead of depending only on human-generated data. Humans do this naturally, but AI still struggles with it for now.

AI can learn from experience, but monitoring has to improve too

Schillings pointed to AlphaGo as an early example.

AlphaGo is DeepMind’s system that beat one of the world’s best Go players, and Go is an ancient Chinese board game where the goal is to control territory on a grid. What made AlphaGo important was how it learned: by playing against itself and finding strategies that didn’t come from human games.

Humans spent centuries developing Go, and now they study strategies discovered by AI. So: who is teaching whom? AI and humans learn from each other.

There is, however, a major problem with the idea of AI learning from itself. What happens when the AI is wrong and who determines whether the data it produces is useful? This is particularly important because, as Schillings noted during his talk, models can sometimes find ways to appear successful without actually solving the problem they were given.

Cheating is a real problem. You ask a model to solve a problem, especially in code, and it will tell you, “I’ve done it, it’s there, it’s beautiful.” Then you check and find that it actually did not solve the problem. It may have stolen the result from somewhere else, or, even more amusingly, you ask it to write a tool for Linux and it says, “I wrote the tool,” when it’s really just invoking the existing tool and hiding the trace.

Sophisticated cheeting is becoming more and more an issue even for model to self-verify. So, we need to get the monitor to become more sophisticated also. That’s a part of the recursive self-improvement, he said.

AI needs step-by-step feedback

Another part of Schillings’ point is how AI systems are trained. Some problems are easy to check: a proof works or it doesn’t, code passes tests or it doesn’t. But real-world problems are usually messier than that.

Schillings compared it to teaching someone to climb a mountain with only one bit of feedback: you fell or you didn’t. That would be a terrible way to learn. A better teacher would give step-by-step feedback:

This part was good. Try this section differently. You’re getting closer. Here’s where you can improve.

AI systems are being trained to give this kind of step-by-step reward. That matters more than it first seems: if models can learn not just from success and failure, but from how close they were to a better solution, they can handle much more complex problems.

New systems may reveal things we haven’t noticed yet

What happens when AI starts exploring the unknown? This is where the implications become interesting.

Code is a relatively convenient environment for AI because there is usually a way to test whether something works. Schillings expects the coming wave of AI development to produce an increasing number of breakthroughs in areas such as physical sciences, biology, mathematics and engineering. The reason is straightforward.

If AI can generate hypotheses, test them, reject unsuccessful approaches and build on successful ones, it can start exploring the space of possibilities itself. That is a very different proposition from using AI as a better search engine. The ultimate value of these systems may be that they help us discover things nobody knows yet.

And that could turn out to be the most important AI story of the next few years.

The post Google DeepMind: AI’s Next Step Is Learning From Its Own Experience appeared first on ShiftMag.

Luis Velasco, Forward Deployed Engineer at OpenAI, says we’re entering a new field: meta software engineering.

Instead of building software that follows a predefined sequence of operations, engineers now need to build the systems around AI agents giving them context, tools, skills, constraints, and ways to evaluate their work.

The hardest part is always the context

Code is easier for AI agents to work with. A codebase is structured, and the results are easy to check because the code compiles and tests pass. Business workflows are a lot messier, Luis explains:

In business workflows, the context is fragmented and spread across people and systems. A Slack message may explain why a decision changed, a legacy application may hold the data state, and an experienced colleague knows the part nobody wrote down. The work item we’re trying to automate depends on all of that.

For an agent to perform that work, engineers first have to reconstruct the context in which the work happens. Velasco breaks this down into three elements: data, processes and systems.

Data gives the information and domain knowledge for decisions. Processes define the rules, exceptions, and timelines. Systems provide the apps and APIs that let the work get done, with the right permissions.

The agent needs a context layer that stays current and gives it the information relevant to the task. Processes can be turned into agent skills, while APIs and other systems give the agent the ability to execute the work. Velasco showed this with an insurance claims workflow: the agent read an email and attachments, checked information across multiple apps, verified the claim, calculated the settlement, and prepared the response in 22 seconds instead of 20 to 30 minutes.

Everything works fine until it has to run at scale

Getting one agent to complete a workflow is just the beginning, because the real challenge starts when that workflow has to run at scale. Then agents have to work in parallel, workflows can become interconnected, and one agent’s result can become the input for another:

This can be handled with agents and sub-agents that share context, or with an independent environment where agents can read and write shared state. That state helps them recover what has already been done and figure out what needs to happen next.

That’s why the infrastructure around the agent matters: queues, worker processes, checkpoints, and an artifact store with results, evidence, and reports. The goal is a durable execution environment that can recover if something crashes and avoid doing the same task twice.

Multi-agent systems need more than extra model calls

Velasco showed what this looks like at a much larger scale with an experiment focused on CPU design: a campaign controller spread goals, budgets, and work across different CPU domains, with 512 agents working on areas like arithmetic, memory ordering, and control flow.

The agents, he explained, had different roles: some looked for potential bugs, critic agents challenged their findings, and verification agents tried to reproduce them. The campaign ran for four days, used about 1.4 terabytes of data, and produced evidence that could be shared with verification engineers before a problem reached production.

It shows that multi-agent systems need coordination, shared state, verification, and a way to manage work across many agents, not just extra model calls.

The system can learn without changing the model

Another important part of Velasco’s approach is that the model itself doesn’t always need to get more capable for the whole system to improve. He compared it to an experienced employee:

A senior employee may have the same basic intelligence as when they joined a company, but after years of experience they know the systems, common failure modes and small details that make them more effective.

For an agent, that experience lives in the system around the model.

Updated context can provide relevant knowledge, updated skills can refine how work is performed, and evaluations can check behaviours that need to be verified. The model weights may stay the same while the system around the model gets better through repeated execution.

Velasco said successful runs, failures, and human corrections all help here. Successful runs show what to reinforce, failures show what needs improvement, and human corrections reveal gaps in the agent’s skills. Over time, those patterns can update memory, context, skills, or evaluation sets.

He showed this with a tax preparation agent: it started by completing about 25% of the required fields, and after six weeks of repeated runs, evaluations, and skill updates, it reached nearly 90%.

Engineering will become meta software engineering

This changes the engineer’s role. As more execution is delegated to agents, engineers spend more time designing and improving the system doing the work. But engineering doesn’t disappear, humans still set the goals, make the trade-offs, and decide where human intervention belongs.

That leads to Velasco’s broader definition of what engineers are building in an AI-assisted environment:

The highest value software artifact that we may be creating is not the code base itself, but the system of intent, the constraint, and the evaluation from which code can be produced in a systematic and repeatable way.

He calls this emerging discipline meta software engineering: building the environment around AI so agents have the right context, tools, skills, coordination, and feedback to do the work and get better over time.

The next chapter of software engineering is about building the systems around the code.

The post OpenAI Says the Real Work in AI Coding Is Building the System Around It appeared first on ShiftMag.

I spoke about that with Ross Kukulinski from Tailscale at WAD Berlin. He kept coming back to the same problem: traditional networking still trusts too much based on IPs and subnets. That doesn’t work well in a world where identity matters more than location.

We talked about his talk on the next internet protocol and what it takes to build connectivity around identity instead of network boundaries.

Large shared networks are becoming a liability

Kukulinski points out a simple mismatch: the internet was built to be open, but private infrastructure usually shouldn’t be. That openness works for public services, but it gets much harder to justify when you’re talking about databases, Kubernetes clusters, internal tools, and AI workloads.

In practice, teams try to work around this with firewalls, gateways, proxies, and network segmentation

Kukulinski argues that a better starting point is to ask whether every person, machine, or workload should be able to reach everything else at all. This shifts the design toward smaller, isolated networks that are only connected when a resource needs to be shared, with access rules determining which identities can communicate with which services. He explained:

The key is point-to-point connectivity. Policy is governed centrally, but enforcement happens at the edge. Instead of routing through a stack of gateways or proxies, machines can talk directly to each other.

For developers, the key idea is the separation of authorization from network topology. A service can be reachable because a particular identity is allowed to reach it, rather than just because both endpoints sit inside the same trusted network.

“That distinction matters as infrastructure becomes more distributed. A development environment may span several clouds, customer networks, on-prem systems, remote workstations, and edge devices,” Kukulinski pointed out.

He added that traditional connectivity options can solve individual cases, but large shared networks become harder to govern as the number of environments and access relationships grows. The goal is to make connectivity explicit and narrowly scoped, instead of treating broad network membership as permission.

Identity is more durable than an IP address

That same idea raises a bigger problem with trusting IP addresses: IPs are fine for finding where traffic should go, but they are not a good way to prove who someone is or whether they should be allowed to access something sensitive. Kukulinski said this is especially clear in Kubernetes, where IP addresses change often and don’t reliably represent identity:

IP addresses come and go, and they’re duplicated everywhere. If you’re running in a Kubernetes cluster, the IP address of any one pod changes as pods are destroyed and recreated. So trusting IP addresses, or even trusting a subnet, really doesn’t work.

Kukulinski also said that identity-based access is better because it ties permissions to the connection itself, rather than to an IP address or subnet. That connection can carry useful context, like who the user is, what group they belong to in the identity system, what device they’re using, and what policies apply to that device. For example, a managed work laptop might be allowed to access internal systems that a personal laptop cannot, even if both belong to the same person.

For developers, this can remove a lot of the hassle around infrastructure access. SSH, Kubernetes admin tasks, databases, and remote systems often rely on credentials that have to be created, shared, updated, and eventually revoked.

Identity is becoming the control layer for infrastructure and AI

Kukulinski also said that if access is based on identity and group membership, permissions can change automatically when a person’s role changes. For example, when a developer moves to another team, the systems they can reach can update right away, without having to clean up old VPN access or long-lived keys:

If I transfer internally from product management to engineering, and my groups change in the identity provider, that automatically updates what I can do from my devices.

The same idea is becoming important for AI tools too. An identity-aware gateway can sit between developers and model providers, check who is making the request, control which models they can use, and manage provider logins in one place. As Kukulinski explained, developers can still make API calls without needing a separate credential for every model or service.

He also said Kubernetes shows that networking can still get complicated, even when identity is handled well:

The harder problem begins at the cluster boundary, when a service in one cluster must communicate securely with another cluster, another cloud, or a system outside Kubernetes. Things inside the cluster can talk easily, but talking to other Kubernetes clusters, especially in a different cloud, is incredibly challenging

Kukulinski prefers a direct encrypted connection when possible, using relay infrastructure only as a backup. Connectivity affects not just security, but also speed, reliability, and cloud costs.

AI agents need limited access, not blanket trust

AI makes this problem harder because it adds non-human users that need access to internal systems. Kukulinski also said AI tools can help attackers automate scanning and reconnaissance, so defenders should use the same kind of automation for supply-chain security, environment checks, and build and deployment controls.

The risk is often inside a company’s own infrastructure. Teams sometimes give AI projects broad access first and tighten it later, which can leave them with the same kind of over-permissive VPN access companies have struggled with for years:

The historical pattern has often been: “We just need to get this AI thing going, so let’s give AI access to the whole network.” That’s the scariest thing, and it repeats the same failure mode as giving too many people open VPN access to too many systems.

Kukulinski’s preferred model is to give agents their own identity and access policy, with permissions that can be changed or revoked as needed. An agent, or group of agents, can also be isolated from the wider network and given access only to the nodes, services, or data it needs.

For developers building agentic systems, treat an agent as a separate workload with least-privilege access from the start

“If an agent can reach a production database simply because it is already inside a trusted network, the architecture has repeated an old networking mistake with a much more capable actor,” Kukulinski said.

The post AI agents need their own identity and least-privilege access appeared first on ShiftMag.

AI makes ad hoc operational work so easy that we stop building the tools around it.

Why write a script when you can just ask Claude or Copilot to restart the canary? Why build a dashboard when ChatGPT can summarize today’s deploy status in 15 seconds?

Because that 15-second conversation, repeated by 50 engineers 20 times a day, stops being convenience and starts becoming a tax.

Conversation-driven operations have a hidden cost

Let’s walk through a real example: restarting a canary deployment.

Manual AI-assisted workflow:

1. You: “Check the health of the canary deployment for payment-service”
2. AI: calls monitoring API, returns data (~800 tokens)
3. You: “It looks unhealthy, restart it”
4. AI: calls deployment API, confirms restart (~600 tokens)
5. You: “Monitor it for the next 5 minutes and confirm if it stabilizes”
6. AI: polls metrics, returns confirmation (~900 tokens)

That’s ~2,300 tokens per restart. Three restarts a day across a team = ~200k tokens/month. For a task that takes one CLI command.

Now compare:

/canary-restart payment-service

One message, zero AI tokens. The bot routes the intent to an internal tool that handles health checks, restart logic, and confirmation, all without an LLM in the loop.

Use AI to build the tool once, so you don’t keep paying for the conversation.

Why Slack?

Because that’s where the work already happens.

Incidents get declared in Slack. Deploy notifications land in Slack. Someone pings you in Slack asking “is prod healthy?” The response to that message shouldn’t require opening a terminal, switching to a dashboard, or navigating to another tool.

Your team already works in Slack, so your commands, context, and decisions should live there too, directly connected to the machines.

The alternative is telling every engineer: “When something breaks, leave the place where your team is coordinating, open a different tool, figure out what command to run, then come back here to tell everyone what happened.” We’ve been doing that for years and it’s never been good. We just didn’t have a better option.

The bot is there to connect, not to decide

This is where most Slack bot projects go off track: they pack business logic directly into the bot itself. Message handlers start calling APIs, transforming data, and handling retries, and before long the bot turns into a monolith.

The Slack bot should be thin. It does exactly three things:

1. Parse the incoming command or message
2. Route it to the right internal service
3. Format the response back to the user

No business logic, no database queries, no retry loops, and no secret management.

The actual work lives in your internal tools and services. The same ones your GUI calls, your MCP server exposes, your CLI wraps, your CI/CD pipeline triggers. The Slack bot is just one connector among many.

The tool service owns the business logic. Every connector, GUI, MCP, Slack, CLI, is a thin shell that calls the same service. Write the logic once, expose it everywhere.

Choose configuration over code for adding tools

If adding a new Slack command requires a PR, a deploy, and someone from the platform team to review it, you’ve already lost. It won’t get done.

Adding a tool should be a configuration change:

tools:
  - name: canary-restart
    description: "Restart a canary deployment"
    endpoint: http://tool-service/internal/canary/restart
    parameters:
      - name: service
        type: string
        required: true
    acl:
      - platform-team
      - oncall

  - name: feature-flag
    description: "Toggle a feature flag"
    endpoint: http://tool-service/internal/feature-flags/toggle
    parameters:
      - name: flag-name
        type: string
        required: true
      - name: environment
        type: string
        default: staging
    acl:
      - developers

The bot reads this config, registers the slash commands, and routes them. The tool service behind those endpoints can be built and deployed independently, by any team, in any language, on any cadence.

This separation means:

• The ops team owns tool-service deployments and logic
• The platform team owns the bot and routing config
• Any engineer can propose a new tool by opening a config PR
• No one ever modifies bot code to add a capability

The bot becomes part of the infrastructure (quiet, reliable, and rarely changed). The tools behind it keep moving forward.

This is what it looks like in practice

Incident response, today without a bot:

Alert fires, someone opens PagerDuty, 5 people join a Slack huddle, one person shares their screen navigating dashboards, someone else runs CLI commands, results copy-pasted back to the thread.

Incident response with a bot connector:

Alert fires, /incident declare payment-service-health-check-failing, bot creates incident channel, rolls back the canary, posts the deploy diff, pings the on-call, everyone joins the channel with full context already there.

Feature flag management, today:

“Can someone toggle the new checkout flow to 10% in staging?”, wait for platform team to wake up, ticket, CLI command, “done”.

Feature flag management with a bot connector:

/feature-flag new-checkout-flow --env staging --rollout 10, bot calls the feature-flag service, responds with confirmation, done in 3 seconds.

None of these Slack commands contain business logic. They all call the same internal services your MCP server, admin GUI, and CLI already use. The bot is just the most accessible surface.

Practical takeaways

Put operational logic in internal services, not Slack bots or CLIs

This isn’t about Slack bots, MCP servers, GUIs, or CLIs. They’re all just ways to connect things. What really changes is this:

Stop scattering operational logic across interfaces. Centralize it in internal services. Then build whatever connector makes sense for the context. Slack for incident coordination, MCP for AI agents, GUI for exploratory work, CLI for automation.

And when someone asks “can we add that to the bot?”, the answer should be yes, and it should take 5 minutes and a config change, not a sprint. If it can’t, the architecture is wrong.

The post You Should Bring Your Ops to Slack appeared first on ShiftMag.

Recently, when I changed my job position inside the company, everything changed with it.

Switching from an internal web app to customer-facing mobile development felt like a downhill skier in full gear competing in the Summer Olympics in the 400-meter hurdles. But the reality hit differently, and I realized I am not only the same developer I used to be, but also a different person.

As an aspiring senior developer, I had been working in my domain for almost five years. I knew every bug, every comma in the code, and the domain itself was already printed in my DNA.

Then a challenge came in my career: the company needed a native iOS dev to help with a customer-facing project. What now? My career aspirations gone. My growth aspirations gone. Or weren’t they?

Oh, to be the youngest on the team…

As a developer in my old position, I was really independent. I took on big tasks, hard investigations, and suggested architectural changes. But as the youngest in my team, I was often doing documentation, maintaining stuff, and doing support, while the big senior guys had meetings where important decisions were being made that affected whole departments.

I was looking at them jealously like Barry B. Benson at the Pollen Jocks in Bee Movie. He had a good life, but he wanted more. He wanted to be the most elite part of the Beehive that risks their life to collect life-sustaining nectar. He was often reminded he can’t just decide to be a Pollen Jock – he had to be bred for that.

Thankfully, I am not a bee, and I was often reminded that my time will come, just need to be patient. But my 30th birthday was approaching faster than that promise. “I need a little patience, yeah,” as Guns N’ Roses sing.
 

I decided to bite the bullet

And then the time came: our project was moved to a different country, and only a few members of the team could stay together on a new, very similar project. One of the opportunities for the rest of us was to switch to customer-facing native mobile development.

I had been doing internal tool web-app work, but mainly focused on backend development and DB architecture for five years, so the opportunity sounded to me like they wanted a knight in full armour to swim through La Manche.

But I’m the type of person who would do it for the team. I’m really a flexible person, so I wasn’t even afraid of this challenge – until I finally hit a wall.

The scope was terribly big, with more teams collaborating on multiple SDKs, and everything was customer-facing, so no mistakes were allowed. Even the Xcode IDE for iOS development was so terrible that, when I tried to find some feature I was used to, one Redditor wrote that no one should even try, because that IDE was created by Satan himself.

So my easy equation – I will prove myself in a totally different environment, I will be a senior developer – was crushed.

Tiberius Claudus Caesar Augustus Germanicus the code conqueror 

There was basically no time to meet with more senior colleagues, and I only had a few days on Udemy before I started working on the first issues. So it was a lot of meetings, but basically no context.

At the same time, we started adopting Claude Code and an agentic coding approach more broadly. I was skeptical about AI at first – it had a lot of flaws back then, still hallucinated, and produced plenty of bugs. It didn’t feel trustworthy. But I quickly realized that if I didn’t want to spend the next year and a half just learning everything the hard way, I had to adapt faster than ever and Claude became my main companion in that process.

I didn’t had a choice so I decided to utilize him at maximum. Learned a lot about subagents, prompting skills, planning and mainly use divide and conquer method to ensure multiple iterations so that the AI produced code won’t break. I was able to learn much more faster, skip boilerplate code and focus on the real matter. After lot of produced .md files with reviews and exhausting code explanations later I see I have real influence on my new team, despite still a lot of things to learn, new programming languages are just a formality and my confidence grows every day with every prompt. 

… Back to my roots 

The most exciting part of the university was for me problem solving. Different fields of study, different programming languages and your task was to find solutions to different problems. That’s basically the essential meaning of engineering described as a problem-solving discipline using science, math and creativity. 

In the corporate world, this has been replaced by endless ticket maintenance processes, with people focusing only on their area of expertise and often losing touch with the bigger picture. With AI agents all boundaries were erased. You don’t need to study some new programming languages and their principles, you don’t need to maintain a lot of tickets manually, you dont have to write tests anymore.

Your only responsibility in this AI world as a Software engineer is to solve problems, without being distracted by all the small things that don’t bring you joy but are required by ruthless corporate rules. The only barriers now are only our own imagination and AI slop code. Happy engineering.

The post How AI Helped Me Survive the Shift from Backend and DB Architecture to Native iOS appeared first on ShiftMag.

Four words show up in almost every eCommerce project we take on here at Neuralab: “Just connect it to our ERP.“ They usually drop near the end of a kickoff call, tossed out as casually as asking for the Wi-Fi password.

The word doing all the heavy lifting (and all the damage) there is just. It’s the word that turns a monolithic beast of a legacy system that nobody in the room fully understands into a neat little line item some project manager expects to close in a two-week sprint.

I want to make an argument that sounds painfully obvious once you say it out loud, yet gets completely ignored on most projects: building a new store and connecting it to the systems already running the business are not the same sport. Heck, they’re barely the same project!

A new storefront is greenfield. Clear ground with no legacy baggage. You plan the architecture and data model upfront and mostly hold to the plan. An integration with an existing ERP or CRM is brownfield by default. It’s an archaeological dig into an old system you didn’t build, that’s poorly structured, still running, and troublesome in ways nobody ever bothered to write down. Treat the second like the first and you get an integration that works beautifully in the demo and completely shits the bed the first time a real order does something unexpected.

There is a fix, and it comes down to timing more than technique. I’ll get to it, but first you need to see what you’re actually up against. 

The integration layer breaks because no one owns the handoffs between systems

Let’s start with what the integration layer actually is. The storefront takes the order – the gateway authorizes the cash – the tax engine figures out the state’s cut – the ERP opens a sales order and reserves stock – accounting generates an invoice – the warehouse picks and packs – the CRM logs it all so customer support has something to stare at next week.

Every single one of those systems has an owner. But the handoff between them has no real owner at all. That’s what the integration layer is: the unowned seams. And seams are exactly where the fabric tears, because it’s the one place where two systems that were designed in total isolation have to agree on something in real-time, having never formally met.

Sometimes system takes the money a beat before the order exists

Payment authorization must happen synchronously, meaning the customer needs an immediate response while they are waiting on the checkout screen. The payment gateway typically has up to a minute to confirm whether the transaction is approved or declined. But everything after the payment – opening the ERP order, reserving stock, pinging the warehouse – has to be asynchronous. You simply can’t make a paying customer wait on an ancient ERP API that answers whenever it feels like it. You are accepting eventual consistency by default here, simply because holding synchronous cross-system locks will butcher your conversion rates. 

So, the confirmation page fires the instant the payment clears, telling the customer “you’re all set” a beat before the system actually knows if it can deliver on that promise. Without explicit architectural patterns to handle that gap you’re just playing infrastructure roulette.

Most of the time, this gap closes in milliseconds and nobody’s the wiser. But sometimes it doesn’t. The payment clears, but the queued job to create the order times out or drops on the floor without a sound. Now you’ve taken their money with no order behind it.

That failure rarely hits the dev team first. Instead, an account manager has to act as human middleware – cross-referencing payment logs, re-typing order data into the ERP, and calling the warehouse floor to check on a shipment. Forcing humans to manually heal a cracking system is the most expensive bottleneck of a poorly planned integration.

The fixes here aren’t exotic but they do need to be explicitly planned, and budgeted upfront, a line item almost nobody includes until after their first major post-launch fire drill.

The old system is the business’s memory, not clutter

Any ERP or CRM that’s been running a real business for a few years has grown a thick layer of weird behavior that exists nowhere in its documentation. By that I mean a product-code field that silently clips at forty characters, so anything longer has been quietly losing its last digits since 2019. Or a nightly cron job that only works because some guy manually restarts it every Tuesday. Or an “order status” column that encodes five completely different business meanings depending on which department touched it last.

An outside team scoping a connection to that system on day one is just looking at a facade. They can read the API docs and see the tables, but they cannot see which of those unmapped load-bearing walls their integration is about to lean on. So the scope gets written against the version of the system that exists on paper, not the one coughing in production.

There’s a concept worth borrowing here: The Lindy effect. The longer something has already survived, the longer it’s likely to keep going. That 15-year-old ERP is still there precisely because too much depends on it for anyone to risk ripping it out. Its longevity is proof of its necessity.

When you arrive with a shiny new tech stack, the temptation is to treat the old system as dead weight and a dumb obstacle overdue for replacement. Resist that instinct! The old system has survived contact with the actual business for a decade and a half. It knows things your new build doesn’t know yet, encoded in all those annoying quirks you keep tripping over. Treat it as a battle-tested opponent rather than a nuisance and try to untangle its accumulated weirdness.

Build first, audit second, integrate last

Put the greenfield and brownfield halves together and the most common planning error becomes glaringly obvious. Clients, and plenty of agencies, scope the new build and the integration as one single piece of work. Same estimate, same timeline, same assumption that they’re the same species of task.

They are not, and if you bundle them together you actively poison the integration.

When you write that combined scope, the new platform’s data model doesn’t even exist yet. Its catalog structure, content architecture, and the actual shape of the data are completely unsettled. So you’re designing an integration against a guess, layered on top of the fog already surrounding the old ERP. Guess wrong on either end, and you’re in for massive rework right when the deadline is breathing down your neck – which is exactly when developers start reaching for shortcuts that become those fragile seams everyone has to live with afterward.

The fix is a sequencing decision, and it’s almost boringly simple:

Build the new thing first. While that’s happening, send an analyst into the existing systems to do a pure audit. Figure out what the system actually does and where the unmapped walls are. Once the new platform is close to finished and its data model is a fact rather than a weekly weather forecast, then you scope the integration. Now both ends are known.

I’ll be honest, we learned this the expensive way at Neuralab. Years ago, we used to bundle the two into one scope to give a client a tidier number upfront. We’d then spend all that “saved” time back with massive interest during the last three weeks of the project, desperately discovering what the old system actually does.

Question the legacy workflow before you automate it

Even if sequenced right, integrations are the hardest work we estimate in Neuralab because there’s a quiet trap that inflates the scope from the inside.

A client has an existing, complicated internal process. The natural instinct for both the developer and the business analyst is to lock onto that process and faithfully rebuild it in the new system, because a concrete process sitting in front of you is a satisfying puzzle to solve.

The question almost nobody asks is whether that process still needs to exist at all. Was half of it just scaffolding for a limitation the new system doesn’t even have? Faithfully cloning a bad process that shouldn’t survive the migration just relocates the waste into a more expensive place and bills you for the move.

We saw this clearly with one of our large pharmacy clients. Their original plan was to manage and edit all rich product details such as marketing copy, attributes, or extended specifications inside their legacy ERP, and then force all that content downstream to the web store. But standard ERPs are notoriously bad at managing complex eCommerce datasets and rich visual content.

Instead of building a fragile, over-engineered integration to force an old ERP into doing a PIM’s job, we redrew the architectural boundaries. The ERP stayed strictly in its lane: holding SKUs, core titles, pricing, and stock quantities. Meanwhile, WooCommerce became the single source of truth for rich product content. It was essentially functioning as a lightweight PIM for all media and marketing data. 

By questioning the legacy workflow instead of blindly automating it, we saved months of painful integration work and gave their team an architecture that actually fits how they work today. 

The seams between systems need their own memory.

So how do you actually wire this stuff together? Point-to-point custom code between each pair of systems is the wrong default. It works great right up until the day an order gets stuck, a client asks what happened, and your honest answer is that the event passed between two systems and vanished into the ether.

What actually holds up is an explicit orchestration layer sitting in the middle – whether that’s an event pipeline like n8n which we heavily use, a separately hosted application with its own logging and event-handling capabilities, or a messaging platform such as Kafka, Amazon SQS, or RabbitMQ.  Its job is to own the sequencing, handle retries, and log every single event as it passes, so the whole flow can be inspected on its own.

When something breaks, you shouldn’t need write access to the ERP and an open database console on the storefront just to reconstruct the story. You should have one central place that already holds the receipts. Intentional middleware is the architecture our team defaults to now (usually reaching for custom applications or n8n to drive it). But the tool is just execution! The principle is the real point: the seams between systems deserve their own memory, because nobody else is taking notes.

The “J” word comes last

The client isn’t wrong to want a “just.” A boring, invisible connection nobody ever thinks about is exactly what a good integration looks like from the outside. That simplicity is the finish line – you only reach it after someone goes down into the old system, maps the weak walls, and quietly absorbs the complexity so the business doesn’t have to.

So don’t argue with the person who says it, take it as the brief. Do enough excavation upfront so that a year from now, connecting to that ERP genuinely is simple, and the manual re-keying, the spreadsheets, and the cron job someone babysits every Tuesday become an old war story instead of your next Monday.

The post The phrase that ruins every eCommerce project: “Just connect it to our ERP.” appeared first on ShiftMag.

Benoit Schillings has spent more than three decades in Silicon Valley, working in senior engineering roles at Be Inc., Nokia, Yahoo, and Google X, where he served as CTO.

Today, at Google DeepMind, he leads research into generative AI for code, deep reasoning algorithms, and the future of pre-training and transformer models. This September, he’ll be a keynote speaker at Infobip Shift Zadar 2026 – and ShiftMag readers can get a special discount.

I met him at the AI Engineer World’s Fair conference in San Francisco and one line from him stuck with me:

I no longer see manually writing (or even reading) every line of code as the core engineering task.

AI writes fast, engineers still own the mess

Benoit has been writing code for decades, but these days, he admits, he no longer enjoys it:

I have an astronomy project in the Sierra Nevada: a half-meter telescope, a small Linux computer, and photon-counting cameras working together to track the sky and process data in real time. For it, I don’t even read the generated code anymore; I just check that it works, while AI helps write the control software, driver bindings, and parts of the wavefront reconstruction.

To him, this is just the next step in software development. Programmers used to distrust compilers, but now most engineers don’t even look at compiler output unless they’re doing extreme low-latency work. AI-generated code is going through the same change, only now it’s happening inside the tools programmers use every day.

That raises another question: if generating code becomes increasingly cheap, what does an engineer need to be good at?

Being a software engineer is so much more than writing 100 lines of Python. It means walking into an enterprise, discovering a codebase with 150 million lines of legacy Python, and being tasked with fixing a race condition on day one.

Engineers inherit systems they didn’t design and constraints they didn’t choose. AI can write code fast, but someone still has to know where it belongs, how to test it, and what happens when it fails.

Security will become a bigger part of the engineer’s job

That last point becomes more complicated when the models generating code are trained on the code already available online:

Models have been trained based on the GitHub data, and 90% of GitHub is crap. Even worse, people are now uploading things to GitHub to create vulnerabilities.

That creates a problem beyond the familiar concern that AI might generate buggy code: if the training data contains poor practices, vulnerabilities or deliberately malicious examples, the model can become part of the security problem rather than simply a tool for solving it.

This is why Schillings expects security to become a larger part of the engineering job rather than something that can be delegated to the model producing the code:

You also need to use models to monitor models. You need to fight fire with fire.

The point isn’t to have one AI police another, but to recognize that AI-generated software needs another layer of scrutiny. As more code is automated, humans can’t realistically review every line.

That doesn’t eliminate human responsibility. Someone still needs to define what software should do, verify that it does it, and decide what risks are acceptable.

For engineers entering the field, that means developing a different set of skills:

The more mundane aspect of just spewing out the code is going away. Understanding the problem, understanding if that meets some requirements, understanding how to validate if that code will do what you expect, actually being paranoid about security, probably thinking about performance, I think that’s where the job is going to move in the future.

That is a considerably different proposition from simply becoming faster at programming. It puts more weight on requirements, architecture, testing, security and judgment, the parts of software development that remain difficult even when the implementation itself can be generated in seconds.

AI agents create an organizational problem

Schillings also sees AI changing how engineering teams are organized:

Management is an incredibly archaic skill. You look at the way a large company takes decisions and is managed, you could probably show that to the Babylonians.

That point matters even more as companies move from using one AI assistant to using multiple agents on different parts of the problem.

Benoit doesn’t think the answer is to just make hundreds of copies of the same agent:

You don’t want one brain cloned a hundred times. You want diverse, specialized agents colliding and collaborating.

This feels less like a software design issue and more like a team issue. If you use the same kind of agent everywhere, you just scale the same mistakes. Different agents with different roles can push back on each other, like people with different expertise on a real team.

But that also means someone still has to decide who does what, judge the results, and take responsibility when things go wrong.

That may be the real change AI brings to engineering: less about writing code, more about directing, checking, and owning systems that act more on their own.

Want to hear more from Benoit Schillings, VP of Research at Google DeepMind? Get your ticket for Shift conference with a special discount for ShiftMag readers!

The post VP of Research, Google DeepMind: “The mundane work of writing code is going away.” appeared first on ShiftMag.