As someone who has spent nearly 20 years following developers, founders, and tech entrepreneurship, I spoke with Amir after his talk about what developers need to know to become founders. We discussed how AI is changing software development, junior hiring, product building, and what one person can achieve.

Developers are not doomed

What happens to developers now that AI can write code? It has probably become one of the most common questions at tech conferences over the past few years, ever since the AI revolution began. Naturally, I opened my conversation with Amir by asking exactly that.

Amir has programmed since childhood and spent over 20 years developing his own Vim configuration, which he says became one of the world’s most popular. Today, he barely uses the editor the same way and rarely reviews code in detail (except when security, models, or other areas need his attention).

Still, he doesn’t think developers are becoming irrelevant. Quite the opposite:

My contrarian view on this is: developers are still super critical, because I don’t think code was ever the objective. What is objective? Solving problems for customers, building systems.

In other words, writing code was never the whole point. Code serves as a tool, while solving customer problems and building systems remain the real goals.

What changes now is the level at which developers work. Managing agents, configuring them, coordinating multiple systems, and working with what Amir calls agent swarms all matter more and more.

That shift also dramatically changes the leverage a single developer can have:

I think the difference between a good developer and an amazing developer is not a 10x anymore. It’s 1000x.

Juniors may have an advantage that seniors do not

That raises another question: how can someone who enters the industry today learn what good engineering actually looks like?

Amir sees a potential advantage for junior developers here. Unlike seniors, they do not carry 20 years of habits that they first need to unlearn – they can start from first principles and treat agents, agent swarms, or systems that build other systems as a natural part of development, instead of trying to retrofit them into a workflow they have followed in the same way for years.

But that advantage has its limits: AI models still cannot replace the kind of experience that helps developers recognize whether a solution is actually good:

This said, I do still think the models are not good enough for a lot. Especially architecture.

Customers are still P1 for founders

AI may let one person build more, but a founder’s main job is still the same.

I asked Amir what developers should focus on when they also have to think about design, marketing, sales, hiring, and fundraising. Once again, he came back to the basics: customers:

Again, I’m actually not sure how much has changed, because I think in the end what you’re building for is customers, it’s other people, it’s empowering them. And you need to find out: how can you get customers? How can you build something useful? And that is maybe the P1. Everything else, attending conferences, getting investment, should not be a P1.

He says new founders often reverse that order. They start with incubators, try to raise money, or look for a co-founder, and only then ask whether anyone actually needs what they are building.

None of those things lack value. They simply do not belong at P1:

But P1 is finding customers, finding something useful, building something useful, trying it out, learning from that, getting kicked in your face. And then you go back and you rebuild and you learn. And also this loop is very critical.

In other words, build something, put it in front of users, make mistakes, learn from them, and build again. Amir sees that loop as one of the key parts of building a company.

Do not blindly copy Silicon Valley

From the very beginning, Todoist followed a different organizational model from the classic Silicon Valley playbook, but Amir did not choose that path because he had a grand theory about the future of work.

The company went remote because he lived in Chile and simply could not find enough people to hire locally.

At one point, he actually planned to move to Silicon Valley and start the company there, but then he met his wife and changed his plans.

That experience shaped another piece of advice he gives developers who want to become founders: instead of copying someone else’s formula, start with your own circumstances, abilities, and strengths:

I do think you need to work in what kind of environment you have, what kind of skills you have, what kind of strengths you have, and then work from that.

For that reason, founders should not treat his remote model as a template that automatically works for every company.

The same goes for following other founders too closely:

You follow what I have done, or you see something on X or some other founder, and then you just blindly follow them. That’s probably not going to lead to a very good outcome.

If you start an AI startup today, you may already be too late

AI has become impossible to ignore, swallowing the tech industry’s attention. Almost every startup wants to become AI-native, conversations turn to agents, and everyone looks to Silicon Valley again.

So I asked Amir whether developers outside this wave should feel they’re missing out. He gave one of the most direct answers of our conversation:

In a lot of cases, if you actually start an AI startup right now, you’re probably too late.

For him, understanding technological S-curves matters much more: founders need to recognize which stage a particular technology has reached.

Ideally, he says, you enter a trend before exponential growth begins. AI may already be deep into that curve, while space could still be near the start.

The reverse is true too: in mature markets, making a significant impact is much harder:

For instance, if you do SaaS right now, that is freaking mature. You have very, very entrenched companies. Of course, maybe by some miracle you can do something that’s 10x, but it’s highly unlikely.

Rather than chase the hottest field, founders should understand where the market and their company sit on the S-curve and where they want to compete. The same applies to fundraising: know what game you’re choosing to play.

Before taking VC money, you need to know which game you are playing

Todoist has remained bootstrapped, and when I asked how he thinks about company financing today, Amir returned to the same starting point: founders who lack traction, customers, proof that the product works, or a personal track record will struggle to raise money.

His preferred order therefore remains the same. First, build, learn, and find customers. Only then decide whether fundraising makes sense at all.

But another part of that decision matters even more. VC money comes with very specific expectations about what company success should look like:

VCs want to see billion-dollar outcomes. If you don’t have a realistic way to achieve that, even if you lie, say, okay, this is our path, but you don’t really believe it, at some point they are going to push you to their direction, and then they’re going to mess up your company, because that is what you’re signed up for.

The problem, then, does not lie in the VC model itself. The problem appears when a founder accepts that kind of capital without actually wanting to build the kind of company that the VC game requires.

That is one of the reasons Amir has never raised money for Todoist:

Why I have never raised money for Todoist is because I don’t want to build a billion-dollar ARR business.

Bootstrapping is like climbing Everest without oxygen

That does not mean Amir sees bootstrapping as an easier or more relaxed alternative to the VC path.

I also wanted to know whether people have romanticized bootstrapping in recent years. Founder stories often present it as a way to avoid investor pressure, keep control, and build a company at your own pace.

Amir dismantles that image:

But I think bootstrapping is incredibly hard. It’s not the easy path. What I actually tell my team is: we are climbing Mount Everest without oxygen, and with oxygen is the capital. That is what you’re signing up for.

So the real question is not whether bootstrapping beats VC funding. Founders need to ask what they actually want from their company and from their own lives.

Not every company fits the VC path. At the same time, bootstrapping comes with serious constraints of its own.

Todoist removed “balance” from its core value

Building a company for 20 years doesn’t mean 20 years of growth. Amir recalled that Todoist and Buffer followed a similar path: years of growth, then a plateau and slight decline.

As he puts it, growth can make you think you’re “the freaking smartest.” When it stops, you realize how much needs rethinking. At Todoist, that meant major culture changes, including dropping one word from a core value:

We actually had this core value called ambition and balance. And then we just removed balance.

Amir says that at one point he became deeply unhappy with how things worked inside his own company. He did not think the company showed enough ambition, he did not like the level of output, and he felt that the team no longer pushed boundaries.

The cultural shift went beyond words. During that process, the company let some people go, while others chose to leave:

And I think right now we have a lot more calibrated company because of that.

He sees an important lesson in that experience for new founders. The culture you create at the beginning, the first people you hire, and the first core values you define can have a huge impact on the company you eventually build.

Once the company grows, changing those foundations becomes much harder.

Todoist now wants to become a suite of apps

At the end of our conversation, I wanted to know what comes next, and Amir described two very different possible futures for Todoist.

In one, he could cut 50 percent of the team, generate much more profit and, as he joked, perhaps buy himself a small yacht, while in the other, the company would take on a much bigger problem, which is ultimately the path they chose:

Or we can just say, okay, let’s freaking solve a much, much bigger problem. So for us, we are going to create a suite of apps.

The first product in that expansion will focus on automations:

Honestly, I think what we have done technologically, but also on product side, will be really, really cool for people to see, because everything is natural language. And you tell what you want to build, and then the system builds it for you. And it’s quite affordable. So automations will be the first leak. The other one is team communication.

When Amir mentioned team communication, I asked whether that meant a return for Twist, Doist’s asynchronous team communication app, which the company developed as an alternative to real-time workplace chat.

Amir replied:

It’s coming back in a very strong form.

That fits with the broader direction Amir described for Todoist, as the company now plans to expand beyond its core product and build a wider suite of apps.

The post Todoist Founder: Developers Should Focus on Solving Customer Problems appeared first on ShiftMag.

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.

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.

What made it especially interesting to me was that it moved beyond the familiar question of how much AI can speed up an individual developer.

Instead, it raised a more compelling one: how do you organize software development when one engineer is no longer working with a single AI tool, but coordinating five, six, or seven agents at once?

AI adoption in software teams has evolved through three stages

The conversation featured Jordan Topoleski, COO at Cursor, and Pallavi Mahajan, CTO at Nokia, and was moderated by Bloomberg’s Peter Elstrom. Topoleski’s view of how AI adoption in software teams has evolved through three stages is particularly revealing, as it clearly illustrates just how quickly the nature of developers’ work has changed.

The first stage was defined by tools such as autocomplete, designed to speed up existing tasks.

The second began with the emergence of AI agents, which developers can already delegate entire tasks to.

The third, which is only just beginning, brings a much deeper shift: companies no longer need to introduce more capable tools, but to rethink how development, teams, and responsibilities are organized when a single engineer is managing multiple agents working in parallel.

We need to redesign the system for a world where one person can work with five, six, or seven different agents at the same time.

Topoleski believes this shift also requires a different way of thinking about productivity. Figures such as AI spend per developer or token usage say very little on their own about the value a company actually receives.

That is why companies are increasingly shifting their attention from inputs to concrete outcomes, asking what the team actually managed to deliver because of that investment.

Cursor already sees the limits of simply adding AI tools to the existing development process at large companies without making deeper changes to how that process works. 

Topoleski says many organizations plateau at around 35 to 45 percent of AI-generated code eventually reaching production, which suggests that giving developers more capable tools alone will not take them to the next stage.

To fully use their potential, companies also need to adapt both their organization and their development process to an AI-native way of working.

AI is also changing how teams share responsibility

One consequence of this shift is a different distribution of time across the software development lifecycle. Technical teams have traditionally spent a large part of their time writing and reviewing code, and AI can now speed up both activities particularly well.

However, as teams speed up these tasks, the bottleneck simply moves to another stage of the process.

As a result, planning and design, as well as review, testing, and deployment, become increasingly important parts of the development cycle, because faster code generation means little if the rest of the system cannot keep up.

The shift also affects team size. Topoleski pointed to a large insurance company that split its teams of eight or nine engineers into smaller teams of about four, and the smaller teams moved through the organization much faster thanks to the lower coordination burden. The company saw roughly a threefold increase in output, suggesting that AI can change the economics of teamwork itself.

Nokia already sees a similar transformation inside its own organization, while Mahajan believes technology itself rarely creates the biggest obstacle to this kind of change:

Technology is never the bottleneck. People, culture, and the operating model are the bottleneck.

That is why the changes do not stop with the tools developers use. They also affect the traditionally clear boundaries between roles in the development process.

Nokia previously had separate positions such as software engineer, test engineer, release qualification engineer, and product manager, but Mahajan says those boundaries are now gradually fading and merging into a broader role she calls the “product builder.”

In other words, AI is changing code writing as well as how teams distribute responsibility.

How much AI should developers be allowed to use?

As developers use more advanced models, companies need to find a balance between controlling budgets and giving developers the freedom to use AI when it creates value.

At one point, Nokia experimented with quotas for engineers, but Mahajan said the approach caused negative reactions. The company then moved to a more flexible model:

Instead of strict restrictions, Nokia now uses “soft limits.” When developers exceed a certain quota, they receive a notification, but they can continue using the resources if they decide they need them.

Cursor also supports a more dynamic approach. The most advanced models do not need to be the default choice for every task. Some jobs benefit from frontier models, while teams can handle others with much cheaper models without significantly reducing quality.

In one project with a large hardware company, Topoleski says Cursor helped reduce costs by 26 percent while the organization continued to increase the share of code that made it into production.

The real ROI may not come from developers doing less

However, one of the most interesting points from the panel was that AI’s biggest value may not come from cutting costs.

Topoleski argues that many companies have never lacked ideas. The challenge has been turning those ideas into reality. When AI takes over some of the execution, developers can spend more time thinking about what they actually want to build:

This also changes how companies look at their roadmaps, as projects that were previously pushed aside because of limited time and resources can now become possible.

Instead of simply helping companies complete their existing roadmap faster, AI can expand what they are able to build in the first place.

With AI agents and systems that run multiple agents in parallel, the impact goes far beyond writing code faster. Developers are changing the size of development teams, the boundaries between roles, and the entire process of turning an idea into production.

The post Cursor and Nokia: AI Matters Less for Speed Than Expanding Developers’ Capabilities appeared first on ShiftMag.

At the Raise Summit in Paris, I caught up with Richard Kirby, Office of the CTO at 1Password.

We sat down to discuss why passwords haven’t disappeared, where passkeys still stall in practice, how engineering teams should approach service accounts and AI agents requesting tool access, and what building secure, developer-friendly secrets management actually looks like today.

Passkeys are replacing passwords?!

We’re seeing the cybersecurity world gradually move from old-school passwords to passkeys. That shift is exactly why I asked Richard how 1Password (a company built around password management) is approaching the change and adapting its broader strategy.

The company is actively pushing that transition: a few years ago, 1Password acquired Passage specifically to speed up passkey adoption. Today, the platform supports both passwords and passkeys, though Richard expects the shift to happen slowly:

Passwords are not going away. In some ways, we would love passwords to go away because passkeys are obviously a more secure option. However, passwords remain so prevalent that every system still relies on them.

He says this change affects credentials overall, not just user passwords. “In the age of AI, managing credentials has become very important. AI doesn’t use a passkey itself, but it still needs credentials to access certain resources”.

That’s why 1Password sees passkeys as an important part of the modern tech stack. Passwords are still here, but the focus is shifting more toward AI and managing credentials for AI agents.

Software vendors are slowing passkey adoption

When I asked what technical hurdles are preventing passkeys from becoming the new standard, Kirby said platform vendors first have to rewrite how they handle authentication:

Introducing passkey technology requires people to go back and retrofit their existing platforms, which creates the biggest hurdle.

From a user’s perspective, passkey setup can be confusing because vendors handle it so differently: some require multiple passkeys, others replace passwords entirely, and some do both. That inconsistency is still slowing down wider passkey adoption.

1Password lets developers share credentials with AI agents more securely

As engineering teams automate more infrastructure, I wanted to understand how they should think about non-human identities, like service accounts and AI agents.

Richard was especially excited about a feature his team recently launched: a dedicated part of the product that helps developers manage local secrets safely:

Initially we built the 1Password Environments feature to help developers keep credentials out of local disks and .env files. It uses FIFO pipes, which lets us avoid writing credentials to disk.

This setup also solves a big security problem for AI. You should never give raw credentials directly to an autonomous AI agent, since they can end up in logs or other places you can’t control. This feature lets apps access credentials securely while keeping you in control:

When an agent wants to use plugins for Cursor, Claude, or other major platforms, 1Password notifies me and says, “An agent wants access to data.” I approve the request, and 1Password supplies the credential to the authorized application so it can complete the sign-in, without exposing the raw secret to the agent. That’s a huge step forward. We don’t see this as the end goal, but it is an extremely valuable tool for working with AI agents in a secure environment.

What happens when you invite an AI Agent “into the house”?

Richard calls this mechanism “Securing the Stay,” and sees it as a major breakthrough in connecting cybersecurity and AI.

But that raises a new question: once the agent is inside, what can it do, who approved it, and how much can it do on its own? That’s why these systems need governance, policy, and oversight.

No one has solved it fully yet, but the whole industry is moving in that direction.

We see the biggest transformation for users right there: Securing the Stay and establishing full compliance to provide complete control and guarantees over what an agent can access.

Keep things simple!

1Password tries to keep its user experience simple, and its Director of Product Management strongly believes in that approach:

I have always believed that if you make someone’s job easier, they will do it. The cybersecurity industry as a whole holds a reputation for overcomplicating things. People often perceive passkeys as overly complex, so they run away from them.

For Richard, being developer-friendly means helping people get things done quickly and simply, without extra complexity. As a developer himself, he values tools that reduce friction and work reliably.

Least privilege is key to good security

To wrap up our interview, I asked Richard Kirby which identity primitive he would prioritize first if he had to design an access management layer for a startup today.

Without hesitation, Richard chose least-privilege access.

The principle of least privilege has always underpinned good security, but teams have always struggled to apply it. Returning to my previous point: if you make it simple, users will reap massive benefits.

The post Your .env File Wasn’t Built for AI Agents. 1Password Has a Better Way. appeared first on ShiftMag.

Last autumn, I had the chance to speak with Dana Lawson, CTO at Netlify, for ShiftMag. This year, I was thrilled to learn that she’ll be joining us as a speaker at Infobip Shift in Zadar – and ShiftMag readers can get a special discount.

Ahead of her talk, I wanted to talk to her about Hot App Summer, Netlify’s community challenge that encouraged developers to ship one AI-assisted or vibecoded app every day for 30 days in June, because it’s a great example of how AI is changing the way we learn, build, and experiment with software.

Netlify got 1.000.000 users in three weeks

Netlify recently crossed 16 million users, adding 1 million of them in just three weeks. For Dana, the milestone itself is less interesting than the pace of growth – and what it says about who is building software today:

The number is exciting, but the pace tells the real story: it points to a fundamental shift in how software gets built.

As Netlify’s CEO Mett Billman in his post says, when Netlify crossed 10 million users, much of the growth was driven by developers discovering the platform through coding agents.

That wave hasn’t slowed, but the audience is expanding beyond professional developers: finance teams are building dashboards, sales teams are creating prototypes for prospects, and customer success teams are shipping tools they once would have needed engineering to build.

AI is lowering the barrier to software development to the point where building is no longer reserved for people with deep technical expertise. Someone with an idea, a spreadsheet, and an internet connection can increasingly turn that idea into working software in hours.

We can now learn by shipping

That shift was on full display in Hot App Summer, which started as a “build one app a day” challenge and grew into a community where people publicly shared their projects and experiences. As Lawson put it, “People were not competing, they were inspiring each other.”

What stood out to Dana most was what that revealed about how people learn today:

People learn by shipping. You can build something on Monday, discover what you still don’t know on Tuesday, improve it on Wednesday, and then repeat the process.

As she put it, you learn more from thirty imperfect apps than from one perfect tutorial, because every project exposes something new to solve.

Now, even small problems can be solved with software

Looking back at the projects created during challenge, Dana points out that most were not attempts to build the next billion-dollar startup:

Many focused on solving small, everyday problems – from time management and business processes to family coordination and content creation.

That part of the software market has often been underserved because custom solutions were not always worth building financially.

AI suddenly makes these niche problems economically viable to solve.

Engineers are not disappearing, their role is expanding

Netlify’s CTO believes this lower barrier to entry points to a much bigger shift across the industry: computer literacy is changing. It used to mean knowing how to use technology, but today it also means knowing how to create with it.

This allows experts from different fields to solve problems in their own areas without waiting for someone else to create the tools they need:

A CFO can build a forecasting system, a teacher can create a classroom tool, a small business owner can create their own software instead of waiting for someone else to build it.

In her view, more people creating software does not make engineers less important and at Shift in Zadar, she is going to challenge the idea that AI makes professional engineers less valuable. Her point is the opposite: as more people start building software, strong infrastructure, security, and engineering practices matter even more:

Engineers are not disappearing, their role is expanding. They are becoming the people who build platforms, guardrails, and systems that allow millions of others to develop software safely.

Get your ticket for Shift conference with a special discount for ShiftMag readers!

The post Netlify’s CTO: You learn more from shipping 30 imperfect apps than from one perfect tutorial appeared first on ShiftMag.