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.

Lovable lets people describe the software they want to build in plain in natural language, and then the platform creates it. It handles security, builds complete solutions, and lets users add artificial intelligence to their applications.

Essentially, it helps people build entire apps, and company founders, small businesses, and large corporations all use it.

This is how Anton Osika, co-founder of Lovable, described his platform. Users create over a million apps on it every week, and these apps attract around 700 million monthly visits.

It sounds like a true paradise for non-technical people who want to build products and scale their businesses, but I wanted to know what value Lovable brings to developers, who make up 20% of the user base. I found my answers at this year’s Raise Summit in Paris, during the fireside chat between Osika and Mark Cuban, the investor and serial entrepreneur.

1. For a quick project start

Cuban highlighted that one of Lovable’s greatest strengths is how it helps people become entrepreneurs:

We all have ideas, right? But taking the first step is usually the hardest part.

The platform’s creator strongly agreed. He explained that although people initially viewed Lovable as a software engineer (or even as competition), they eventually came to see it as an AI co-founder and partner:

When you start a company, the hard part is not just building the software. You also have to register the business, handle banking, set up payment systems, and organize operations.

As he explained, users now build their businesses by talking to the platform and giving it prompts like:

• “I am launching my business. What is the next step?”
• “How do I set up global payments?”
• “How do I get customers?”
• “How do I build internal systems?”

At the very start of product development, Lovable significantly shortens the path from an idea to the first prototype.

This is especially true for developers who know what they want to build but do not want to waste time starting from scratch or dealing with complex business steps. Previously, they had to hire an accountant, a lawyer, or a consultant for these tasks.

2. For MVP and idea validation

For developers working on new products, Lovable serves as an MVP machine. It helps them test whether an idea has market value before they invest serious time in fully custom development.

According to Osika, if you are close to a problem and understand it well, you are often the best person to know what solution to build. He said that building this kind of solution used to be hard because it required too many resources:

Today, you can build a large part of it on your own. That is what I generally recommend. We recently conducted a survey of 10,000 of our users, and about 80% of them are building something they plan to monetize at some point.

Osika also pointed out that many people who successfully monetize their products have a decade or more of professional experience. They combine their expertise with Lovable to build products that attract actual users.

In this case, Lovable serves as a validation tool. This means you first create a working version, then measure market interest, and only then expand the product.

3. For internal tools

Lovable is not just for robust, new applications, it also works well for internal tools, especially when teams need a quick tool for operational processes.

As an example, Anton mentioned Nursa, a US company that allowed its employees to use Lovable for various needs, ranging from marketing to administrative processes.

The results were highly cost-effective:

They have already replaced more than ten software subscriptions that they used to pay for, and they estimate they will save about a million dollars a year.

This example shows that founders can use Lovable to quickly assemble small tools that cut costs and replace multiple separate SaaS solutions.

This way, they save both time and money, and they can focus on their core business.

4. For integrations and business infrastructure

Cuban noted that integrating AI into large companies is often much more complicated than people expect:

We see companies like Microsoft hiring thousands of engineers to implement AI solutions.

Therefore, in addition to building apps, Lovable allows users to integrate these tools into their business infrastructure.

This enables developers to connect the product to databases, internal tools, ERP systems, and other existing company systems much faster, without tedious manual work or complex initial setups.

He observed:

One of the major challenges is connecting to existing systems: ERP systems, internal databases, and current software tools.

To solve this, Lovable enables secure and controlled connections, which allows companies to use AI effectively.

For developers, this matters because it allows them to look beyond the frontend and quickly extend the application’s reach into actual business processes.

In other words, Lovable helps them work more efficiently, not just in building products, but also in fitting them into a broader technical and business ecosystem.

5. For analytics, reporting, and decision-making

Finally, Lovable helps build a layer that connects business data with the tools teams use for strategy, finance, and operational planning.

Instead of lengthy development from scratch, developers can deliver tools that help the team find answers faster and make data-driven decisions.

Cuban described this through his own use of an AI agent:

I ask it: “How fast are we growing in a specific segment?” “Which countries should we consider for a new office?”

This application is important for developers because it shows that Lovable can serve as the foundation for tools that are not just visually functional, but also business-relevant.

As Anton Osika said, “access to core data is one of the key ways we unlock the value of artificial intelligence.” This is exactly what gives developers the power to build reliable tools for analysis, forecasting, and decision support.

And here’s my two cents…

Ultimately, this fireside chat left me with a clear realization: using Lovable will not make everyone a developer, let alone a good one. But developers who embrace it can become significantly more effective. They build faster, work smarter, and spend less time on repetitive tasks.

As Anton Osika pointed out, only about a fifth of the platform’s users possess a technical background. Yet, these individuals know exactly how to leverage the tool to their advantage.

This marks the true shift in our industry. We are not witnessing the end of software engineers, but rather the rise of creators who understand the core problem deeply enough to build solutions in record time.

The post Lovable’s Co-Founder on Why Developers Use a Platform Made for Non-Technical Users appeared first on ShiftMag.

Join us on the beautiful Croatian coast

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

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

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

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

AI accelerates multi-platform development

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

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

AI is nothing without people!

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

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

Professional growth is impossible without enthusiasm

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

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

Shift conference as an opportunity to expand knowledge

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

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

Much more than just code!

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

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

Sneak peek of the Shift talk

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

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

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

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

Trisha Gee has spent over two decades in software development, from startups to global enterprises – equally at home discussing DORA metrics and SPACE frameworks as business outcomes and organizational design.

At Devoxx UK, she gave a talk about how software engineering principles stay the same regardless of what tooling era you are in.

I wanted to understand what that means right now when AI is writing a significant portion of the code.

AI exposes the weakest link, not just the fastest path

Trisha frames AI as an amplifier, not a solution. When I asked what that looks like beyond demos, she put it simply: it exposes the problems that were already there, the ones you didn’t know you had.

The most common thing I saw (I was working at Gradle, so we dealt with a lot of build tooling) was more code, more tests, and tests taking longer. The continuous delivery pipeline took a lot of pressure.

The broader pattern she describes is straightforward but easy to miss when you are excited about shipping faster. “Whichever part of your system is the weakest, it’s going to expose that part,” she said.

Reframing it this way, while most conversations about AI adoption focus on what gets faster, Trisha highlights what deteriorates first.

When code gets cheap, everything else gets expensive

When I asked Trisha where teams should focus once code generation becomes cheap, her answer was everywhere.

What she means is that optimizing the writing of code without understanding the surrounding system does not move the needle.

It’s not about one thing which is going to fix one problem, it’s about really understanding the whole system, it’s about understanding even the whole organization, the whole enterprise. Where does IT and technology and software fit into that? What are you really trying to deliver? What is the business benefit?

She described this as working across two ends of the process. On the input side, teams need to get better at questioning requirements before writing anything. On the output side, they need to look at build pipelines, test parallelism, flaky tests, and DORA metrics.

“If you can measure those things (your DORA metrics, build times, whether delivered requirements actually give users value) you can start to see which parts of the process are working and which need attention,” Trisha explained.

Measuring the wrong things optimizes the wrong things

She also makes a sharp point about measurement and optimization.

If you measure lines of code for productivity, you’ll get more lines of code. But really productivity is not just about what we call these activity metrics. It’s not just lines of code. It’s not just pull requests, merges, features delivered.

The thing teams consistently miss is the full arc of delivery.

Developer experience and productivity is the whole piece. Did it get out to the user? Did it meet the user’s needs? Is the user paying for more of our stuff? Is the business getting what they need from what the developers are doing? What you’re measuring there impacts what you’re going to optimize.

That last line is worth sitting with. If your productivity metrics stop at pull requests merged, you are optimizing for pull requests merged.

The SPACE framework and why three metrics beat one

When I asked Trisha what teams should measure, she pointed to the SPACE framework. SPACE stands for satisfaction, performance, activity, communication and collaboration, and efficiency and flow.

DORA metrics, which most teams are more familiar with, are a subset of it. Her recommendation is to pick metrics from three different dimensions rather than relying on a single category. The reasoning is that single-category metrics tend to be easy to game without improving anything real.

So yes, you can write more code, but no, you didn’t do what the business wanted.

She also brought up Fred Brooks and communication overhead as something the industry consistently underweights. The harder metrics to capture, like satisfaction and flow, are often more revealing than the activity metrics that dashboards make easy to track.

The business outcomes she keeps returning to are specific: “You need to measure, did it do what you wanted it to do? Did it get out to the user in time? Did they start spending more money with us? Did it fix your retention problem?”

Those are the things which matter much more to the business.

What to fix before adopting AI

I wondered what teams need to get right before AI tooling can actually help them. Trisha’s first answer was essentially: stop adopting AI the way you have adopted everything else.

We generally get requirements, write the code, chuck it out there, and then you’re kind of done. That’s not how it should work.

What she advocates for instead is applying the scientific method to engineering decisions, which sounds obvious but rarely happens in real life.

Have a hypothesis, do your investigation, measure the results, have a conclusion. Generally speaking, we have not been great at that in our industry.

Applied to AI adoption specifically, that means being precise about what you are actually trying to achieve. What are we trying to achieve with AI? Do we want to deliver more features more quickly to the customer or do we want to perhaps deliver higher quality features? Because those two things are not necessarily the same thing Trisha concluded.

Therefore the practical instruction she gives is to run short experiments, measure one change at a time, and iterate. But have a hypothesis, figure out how to measure it, measure it, get feedback, and iterate over that.

The post Trisha Gee: AI Won’t Fix Your Broken Pipeline – It Will Break It Faster appeared first on ShiftMag.

When incidents hit production systems, engineers rarely stay inside one tool for long, jumping from logs to dashboards to runbooks, trying to reconstruct what is actually happening.

Talking to other builders, it seemed like almost everybody faces this context-switching problem.

Rocío Bayon (Product Manager) and Sebastian Villanelo (Sr. Forward Deployed Engineer) from PagerDuty think MCP is how you fix it.

PagerDuty built their MCP to cut context switching

Rocío explained that their MCP is solving the issue of context switching:

When an incident hits, the engineer has to go between 5 to 10 different tools to understand what’s happening.

That’s the real problem they’re trying to solve.

PagerDuty’s framing of MCP was interesting: neither Rocío nor Sebastian described MCP as just another integration layer. They framed it as connective tissue that gathers logs, alerts, runbooks, and incident context into a single workflow.

What the MCP does, it brings all that context into one platform where engineers are usually already working.

Most engineering organizations already have enormous amounts of observability data. The real problem is that it is scattered across systems, and engineers end up reconstructing operational context manually during incidents.

Retrieve what you need, nothing more

Sebastian framed the problem as signal retrieval. Rather than feeding the model more information, the goal is pulling the relevant operational state around a specific incident.

If you have the right parameters or the queries and all this stuff, you will retrieve the exact information that you need.

That means narrowing context around the actual incident window. When an incident hits, it retrieves information around that time only, Sebastian explained.

That also changes how they think about efficiency, reducing context switching directly affects operational speed, token usage, and cost.

You will see that information only with one call. And that saves a lot of tokens and time. That’s money and time.

AI helps but engineers still decide

Still, both of them were careful not to frame AI as autonomous incident management.

Rocío repeatedly emphasized that MCP and AI systems are primarily helping with context gathering and operational visibility, while engineers remain responsible for the high-risk decisions:

The AI is helping you, but the engineer is the one who is assessing and making decisions where there’s a high risk.

That human layer is intentional. PagerDuty’s broader vision seems less about replacing on-call engineers and more about reducing the operational overhead surrounding incidents. Their MCP systems help gather information, surface relationships between systems, and accelerate investigation workflows, but humans still decide what actually happens next.

Rocío also mentioned that their SRE agent is designed to support larger incident workflows beyond information retrieval:

It can also help you trigger those incident workflows. So it can help you resolve the incident. And it learns as it goes.

“MCP – the connective tissue between tools”

I asked Rocío and Sebastian, how does MCP fit into the tools they already use without becoming just another silo.

And both of them clearly framed MCP as anti-silo infrastructure since it brings everything to one place. Rocío called MCP “the connective tissue between all these different tools.”

That framing probably captures the broader architectural challenge better than anything else in the interview.

Modern incident response already spans dozens of systems: observability platforms, deployment pipelines, CI/CD tooling, ticketing systems, infrastructure management, and communication layers.

AI systems inherit that fragmentation unless something explicitly connects operational state.

Engineers trust systems that behave predictably

Sebastian mentioned that teams often react very differently to MCP systems. Some embrace them immediately while others remain skeptical, especially around security and predictability. For him, trust improves once systems consistently produce expected outcomes:

When a person or a teammate says “ah, I’m retrieving what I’m expecting to retrieve”, that will help them to trust it.

A lot of AI tooling discussions still focus on model capability, reasoning quality, or benchmark performance. But operational systems are usually adopted much more pragmatically. Engineers trust systems that behave predictably, retrieve the right operational context, and fit into workflows they already rely on.

The post When systems go down, devs still juggle 10 tabs. PagerDuty says MCP fixes that appeared first on ShiftMag.

When humans maintained the GraalVM native image reflection metadata repository, coverage sat at just 14%. Tests were often stubs that technically compiled but covered nothing meaningful, nobody wanted to write them for someone else’s code, and the results showed.

At Devoxx UK, Vojin Jovanovic (Principal Researcher, Oracle Labs) and Mihailo Markovic (Software Engineer, Oracle), presented how they replaced that process with an autonomous AI agent pipeline.

The result is 90% dynamic access coverage across more than 1,000 JVM libraries, roughly 2 billion tokens spent, and a GitHub repository generating thousands of commits per week – while Vojin was at a hotel the night before the conference.

The problem with GraalVM reflection

GraalVM Native Image takes a Java application, performs static analysis, and AOT compiles it into a single binary. The benefits are significant: startup roughly 10x faster than a standard JVM, dramatically lower memory footprint.

But static analysis has a fundamental limitation: when a method calls Class.forName(“Foo”) with a dynamic argument, the analyser cannot determine at compile time what class will be needed. Reflection calls break the closed-world assumption.

The solution is reachability metadata – a JSON file that tells the native image compiler which classes, methods, and fields need to be accessible at runtime. Writing this metadata requires running tests that exercise all the relevant code paths.

For a library like Hibernate Core, that means covering 264 individual reflection call sites. For Tomcat, 205. Across the JVM ecosystem, the number is enormous, and until recently, it was almost entirely a manual process that humans were not doing well.

Start simple, then add feedback

The first approach was straightforward: give an LLM the library source code, tell it to generate comprehensive Java tests, collect the metadata via a JVMTI agent.

The results were not impressive – 5.7% coverage for logback, 2.9% for H2. Vojin noted how this doesn’t feel like AGI.

The shift came from adding GraalVM’s static analysis directly to the agent’s context. Instead of asking the LLM to guess which code paths matter, the pipeline runs a static analysis pass that identifies every dynamic access call site (the exact class, method, and line number) and feeds that report directly to the agent. With this addition, logback coverage jumped to 97%, H2 to 84.3%, in five iterations.

The next layer was JaCoCo integration. After each generation round, the pipeline correlates coverage data with the remaining uncovered call sites and feeds only the uncovered ones back into the next iteration. The agent knows exactly what it hit and what it missed. Vojin noted:

We always create a checkpoint in those systems so we can go back to it if something goes wrong. And in these LLM-driven workflows, something is always going wrong.

With this feedback loop: logback reached 100%, H2 reached 96.1%.

Coverage sometimes still isn’t enough

For larger, more complex libraries (Guava, Tomcat, MongoDB) even the feedback loop left gaps. The team added a third technique: PGO (Profile-Guided Optimization) profiling from GraalVM’s Graal compiler. The profiler samples execution and produces a call trace, which can be correlated with static analysis to identify exactly where a test nearly reached a reflection call but diverged.

The profiling feedback tells the agent not just what’s uncovered, but where in the call stack a test went in the wrong direction and what it would need to do differently. Results: Guava went from 50% to 72%, Tomcat from 45% to 83%, MongoDB reached 100%.

The feedback also tells the agent (and the engineers) why certain calls cannot be covered: a security service only available on Java 6, a cleaner class incompatible with the current JVM. “If you cannot reach it, tell us why,” the prompt instructs, and the agent does.

Cost, agents and model selection

Codex was the first agent framework the team tried. For logback (a library with 33 dynamic access calls) Codex spent $35:

If we’re spending $35 per library for a thousand libraries, we’re not replacing humans.

The alternative was P, a minimal agent that starts with a 200-token context describing basic file operations and bash execution. Same results, roughly 10x cheaper and the lesson is straightforward:

Simple task, use a simple agent. You already give it a lot of rules, a lot of context, and you’ve grounded it enough so it can perform on the level of these big agents.

On model selection, the team compared GPT 5.5 against several open-source alternatives – GLM, Kimi K2, DeepSeek, Gemma. GPT 5.5 consistently outperformed them on coverage. The counterintuitive finding was this: a more expensive model that makes the right decision in one shot can cost less overall than a cheaper model that wastes tokens going in the wrong direction.

The architecture that lets it run without you

The pipeline now operates as a third-generation system. When a user opens an issue requesting a library, the agent fetches the issue, runs the generation workflow, verifies the output, creates a pull request, reviews it, and merges or escalates to human review – automatically. The “human intervention” label on GitHub still exists, but its queue has shrunk dramatically.

Documentation, not smarter prompting, was what made the difference.

Vojin outlined what he calls the key context layers:

• raison d’être (why does this project exist, in two sentences),
• state of direction (where the architecture stands today),
• functional specification (how the system behaves),
• architectural specification (how it is built),
• decision records (what major choices were made and why), and
• comprehensive logs that serve as checkpoints for recovery.

When you do all of these things, it takes almost a few days for a very big project. You will reduce your work by 50%, 60%, 70%.

The payoff is that agents with this context can diagnose failures, trace them through logs, and fix the underlying system, not just the immediate problem.

The RAID system (an automated issue-resolution agent) was built in four prompts on a Sunday morning. It sweeps human intervention tickets, classifies them, performs deep analysis using the project logs, and either opens a GitHub issue for humans or attempts a fix in a forked branch with review. Jovanovic added:

Never work on the problem, always work on the system. You never go and fix a ticket. You always go fix the rules.

Where things stand

The repository currently supports 1,021 libraries. Without five large Hibernate libraries that predate the automated pipeline, dynamic access coverage across the ecosystem is 90%.

The GitHub repository has accumulated roughly 2,977 branches. In the week before Devoxx, it logged approximately 8,000-9,000 commits, with agents committing every few minutes around the clock.

Total cost for the project: approximately $1,700 in API tokens, plus personal compute on Jovanovic’s home desktop, running around the clock because the Oracle compliance process for cloud infrastructure takes time. The key point is simple:

Start with neural, simplest thing, get results, and then slowly chop off things and put them into algorithms, because they are much cheaper and faster.

We caught Vojin Jovanovic for a few more questions!

After the talk, we sat down with Vojin for a few minutes to ask him a couple more questions.

You tested over 1,000 libraries. What broke first when you tried to scale?

Vojin: Basically everything broke. We had mostly infrastructure issues, all kinds of GitHub failures. When you build a system at this scale, you need to assume that everything will fail and needs to recover. We broke GitHub rate limits. My machine was broken because it was running so many things. The key takeaway is that you need to build a system in a way that you can always continue. When things fail, you always checkpoint and continue from a checkpoint. We do work in sizable chunks, and when something fails, you just restart the chunk.

Is just asking the LLM enough?

Vojin: If you had asked me four weeks ago, I would say no. Now I would say you need to know how to ask it, and it will be enough. I was like, “GitHub is failing with a 504, abstract away all GitHub calls and retry.” It did it in two minutes. With today’s models, it’s a matter of minutes, not hours.

What did you learn about the trade-off between cost, speed, and coverage?

Vojin: I haven’t seen a situation when doing something with an LLM is more expensive than doing that by a human typing on the keyboard. Build a system that uses the most efficient LLM for the job — you’re going to get far and not cost much money at all.

When does using multiple agents make sense?

Vojin: Where I use it is for decisions and research. I use Claude Opus 4.7, Gemini 3.1, and GPT 5.5. I ask them all, let them discuss, and I discuss together with them. Each brings something to the table. Before, it was always Claude who was the smartest. Now GPT 5.5 is second and close to the first. Things are changing. The most important bit is getting the system designed right. Once you do that, coding, I don’t care who does it.

The post Teaching AI Agents to Test 1,000 Java Libraries – and Letting Them Run While You Sleep appeared first on ShiftMag.

At the MCP Dev Summit North America earlier this month, I was listening to Meghana Somasundara, (Agentic AI Lead, Uber), and Rush Tehrani (Senior Engineering Manager leading the Agentic AI Platform, Uber) talk about what they’re building.

By their account, more than 90% of Uber’s 5.000+ engineers already use AI monthly for agentic workflows. They also have over 1.500 monthly active agents internally, running more than 60.000 executions per week.

What stood out to me was Meghana’s framing of the real risk: not deliberate misuse, but an agent causing serious damage by accident, faster than any human could react:

It takes us humans a lot more effort to break things. But with agents, it’s a lot faster, a lot quicker, and the blast radius is a lot higher.

What problems did Uber face when scaling AI?

Meghana and Rush’s talk focused on three problems that nearly made those numbers impossible to reach. The first was the lack of a shared way of building.

When agent adoption spreads organically across a large engineering organization, teams tend to build independently. At Uber Technologies, with over 10.000 internal services, that meant dozens of teams were building MCP servers and custom integrations on their own, without shared standards, central oversight, and any real way to reuse what others had already built.

The result was predictable: duplicated work, and a growing stack of systems that only the original team really understood, as Meghana Somasundara explains:

The simple truth was, if you can’t manage the development lifecycle, you just can’t trust it in production.

When agents start making decisions across systems, inconsistent implementations stop being a minor issue but they become harder to track, debug and even harder to trust.

The second problem included security. Agents operating across a complex service landscape could unknowingly call endpoints they shouldn’t, expose sensitive data, or trigger operations nobody intended. Add third-party MCP servers into the mix (Uber uses many external systems) and the governance problem scales quickly.

They needed full visibility into call patterns: who was accessing what data, under what conditions, and what happened when things went wrong. Without that, running agents in production at scale becomes a trust problem.

Finding the right tool quickly became the third problem, Rush asked himself:

How does an agent or the engineer building it actually find the right one?

Not just any MCP server, but one that’s reliable, performs well, and doesn’t quietly degrade everything built on top of it.

When discovery is left unmanaged, agents default to whatever is most visible rather than what actually works best. At smaller scale, that’s an annoyance, but across thousands of services, it becomes a systemic quality problem.

How Uber addressed these challenges

Uber’s answer to all three problems was a centralized MCP gateway and registry.

Meghana describes it as a central control plane that turns Uber’s endpoints into MCP tools, with service owners deciding what gets exposed and how it’s defined.

Every change flows through pull requests, passes security scans before deployment, and is continuously monitored in production, while a central registry (acting as the single source of truth) removes duplication and enforces tighter scrutiny on third-party MCPs.

In their no-code Agent Builder, as Rush explained, engineers can pre-select specific tools from an MCP server so the model doesn’t have to decide which one to use, and they can also lock down parameters so the agent doesn’t have to infer them at runtime, ultimately reducing the number of decisions and things that can go wrong.

Getting the infrastructure right shows up in adoption: their coding agent Minions generates about 1.800 code changes weekly and is used by 95% of Uber engineers, but that’s the output, not the real lesson.

On the roadmap are evaluation metrics in the registry to help teams spot reliable servers before committing, and “skills”, reusable MCP patterns with built-in A/B testing that bake evaluation into how knowledge is shared.  

Does any of this apply if you’re not Uber?   

Uber operates at a scale most engineering teams never see (10.000+ services in play) but while the complexity is extreme, the underlying failure patterns Meghana and Rush describe aren’t unique to them.  

Teams often end up building the same integrations in parallel, with governance only becoming a priority after something breaks, and discovery treated as an afterthought. These problems appear well before reaching 1.500 agents – once multiple teams start using the same MCP infrastructure without a shared layer.

The Uber model won’t translate directly to smaller organisations. But if you’re already running MCP servers across more than two teams and nobody owns discoverability or access control yet, that gap could surface soon. 

The post Uber Shares What Happens When 1.500 AI Agents Hit Production appeared first on ShiftMag.

Why would you, as a developer, fly halfway around the world to hear something you could Google in minutes?

“Because there’s more to it than just getting plain information,” says Mark Hazell, organiser of Devoxx UK and co-founder of Voxxed.

Some things just can’t be replicated online

Conferences feel like one of the few places where simply showing up still counts. In a way, they’re a throwback, a reminder that not all value happens behind a screen.

And that’s precisely what makes them stand out: remote work offers undeniable flexibility, but it often fragments our attention. It’s hard to find real focus, especially if you’re trying to keep a healthy work-life balance. At a conference, that changes, as Mark points out.

Simply not being distracted by incoming mail or slack messages is worth its weight in gold in terms of the knowledge you take away.

The person next to you might be facing the same problem, or they might have already solved it. That kind of closeness makes learning immediate, practical, and way faster than online.

Many people tell me they watch a session on-demand from Devoxx UK and wish they could be in the room so they can chat with others who are facing similar challenges or are even further along in finding solutions.

But conferences are expensive…

Let’s face it: conferences aren’t cheap. Between tickets, flights, and hotels, the costs add up fast. And with companies tightening budgets and cutting back on travel, that expense really matters. If you don’t get real value in return, it can quickly feel like a waste of both time and money.

Mark doesn’t deny it. Instead, he reframes the question: if you take your team to the right conference, you’ll see a strong return.

The keyword here is well-chosen:

I do think it’s key to research up front and find the conference that accelerates learning and problem solving in ways truly relevant to those attending. That way, instead of weeks of trial and error, your team can spend a day or two at the conference and return with practical techniques, ideas, and tooling suggestions that boost productivity and quality.

Picking the right conference is all about fit. How long will your team be out? Is the ticket worth it? Will they meet people facing similar challenges? That’s where the real value is, says Mark. Plan ahead, and early bird tickets, flights, and hotels cost a lot less than last-minute bookings.

Big stages or small communities?

It might seem that large flagship conferences have the upper hand with bigger budgets, bigger names, and more production. And in some cases, that’s true, Mark admits: “If a conference is run by a large company with deep pockets, it can be more financially resilient.”

But that’s not the model Devoxx relies on, its strength comes from the community: they rely on a big team who volunteer their time and help them pull together all of the content, shape how the event looks and feels, and execute it on the ground.

In fact, many of today’s most respected conferences began as small, grassroots initiatives, including Devoxx itself, which grew from the London Java Community.

And for Mark, the real distinction isn’t size – it’s about quality and intent:

Whatever the size of the event, the content has to stay balanced and neutral. Without that, scale doesn’t mean much.

When people feel welcome, real connections follow

Modern conferences sit at the intersection of learning, hiring, and business. Sponsorships and recruitment are part of the reality, especially in expensive cities like London. But Mark doesn’t see it as a trade-off between developers and companies:

I prefer the notion of weaving strands together to create a fabric that everyone is part of.

That means creating an environment where attendees benefit from sponsors being present and sponsors benefit from genuine interaction with the community.

That same philosophy extends to how Devoxx grows by creating real opportunities for first-time speakers, helping them gain experience and build confidence. Many return to mentor the next group, creating a self-sustaining cycle that supports the broader developer community.

When there’s no barrier, people talk more freely, ask more questions, and connect naturally, Mark says.

Our philosophy is to create an environment where everyone is equal (sorry speakers, that means no private room out back to go hang out in), everyone is welcome and everyone is respected. This is noticeable and means the event has this really special, open vibe to it.

As Mark puts it, when people feel welcome and respected, they talk, share, and enjoy themselves, and meaningful connections naturally follow. “Sure, we do stuff like hosting evening socials, a party, a pub quiz,” he says, “but it’s really the collective buy-in from everyone to welcome and respect each other that makes all the difference.”

ShiftMag is recognized as a friend of the Devoxx UK conference.

The post Tech Conferences Aren’t Dead. But Why We Go Is Changing. appeared first on ShiftMag.

How are CTOs feeling about AI?

According to Andy Skipper, founder of CTO Craft, they’re experiencing fear, uncertainty, and doubt.

And if the technical leaders of companies are feeling that way, what can the rest of us expect? Certainly, we dream of productivity boosts and an AI El Dorado – but that’s not the reality.

That’s why we sat down with Skipper to talk about how CTOs should manage expectations for AI, and how to navigate the hype versus reality.

Stakeholders and investors are watching CTOs closely, and the pressure is rising

Many CTOs, Skipper notes, are navigating intense pressure from non-technical stakeholders and investors alike, especially with the massive resources being invested in AI and LLM technologies.

He’s a bit careful about this:

AI is not going to reduce costs or increase productivity in the way some non-technical people think just yet. It’s getting there, but it’s not there yet.

At the same time, Skipper points out a surprising upside: AI is giving engineering leaders a chance to reconnect with the code and architecture without writing all the code themselves:

One of the things you have to accept as an engineering leader is that you are going to get further away from the code the more senior you become. AI gives people an opportunity to get back to architecture and development work, even if they aren’t coding themselves.

CTO role can be isolating

When Skipper became a CTO for the first time, he quickly realized just how isolating the role could be. There was nowhere for tech leaders to share challenges, get support, or navigate the non-technical side of the job.

That gap inspired him to start CTO Craft, now a community helping senior engineering leaders navigate team dynamics, strategy, and AI.

When I was a CTO for the first time, I didn’t have somebody who I could talk to about the issues I was seeing or compare notes with people who had similar challenges. That’s what CTO Craft is all about – helping people understand where the challenges come from and understand they’re not alone in having those challenges.

As a coach and mentor, Andy works closely with CTOs around the world, helping them deal with issues like burnout, communication with nontechnical stakeholders, and, lately, how to adapt in the AI era.

The most common CTO mistake? Always chasing the newest technologies

Many first-time CTOs struggle with burnout, overextending themselves to shield teams from stress, and balancing hands-on coding with high-level responsibilities. He explains:

A lot of the people that I work with directly are suffering from burnout. First time CTOs commonly miss out self-preservation. And usually that’s a combination of too much expectation of their own energy levels, their own abilities, backlogs…

And after overextending themselves, first-time CTOs often make another common mistake: chasing the newest technologies. While adopting the latest tools and frameworks can seem exciting, Skipper warns that it’s not always the best choice for fast-moving teams trying to scale.

“Using bleeding-edge tech can slow you down, make systems harder to maintain, and even complicate hiring because the talent pool for newer technologies might be limited,” he explains.

As a coach, Skipper says these are just some of the recurring challenges he sees among engineering leaders, alongside a range of other operational and people-related issues.

Engineering skills alone won’t make you a CTO

For aspiring engineering leaders, Skipper highlights that growing into a successful CTO requires more than technical excellence: commercial understanding, communication, coaching, and vision-setting are just as crucial:

The difference between a good engineering manager and a great CTO is understanding how technology drives business success, while still inspiring and guiding your teams.

But technical and business skills are only part of the picture. Motivation and team management are equally critical. Skipper stresses that not everyone is motivated by the same things, and leaders need to understand individual drivers:

Having a vision in the first place is very important. But when it comes to actually bringing individuals along on the journey, they all need to be worked with differently. You can’t just set it and expect everyone to be motivated.

He also warns against a common mistake among CTOs: trying to shield their teams from the challenges of a pivot or rapid change. While the instinct is understandable, it often backfires and drains the leader’s emotional energy. Instead, transparency and realistic communication are key:

Being transparent, being realistic, measuring your words, not being super negative about everything, but still being realistic, I think all these things are really important.

The need for a support network, not another tech stack

Skipper believes resilience and peer support are crucial for engineering leaders navigating the complexity of the CTO role. Sharing experiences and learning from others can help leaders realize they’re not alone when facing difficult decisions.

Looking ahead, however, he admits that the pace of technological change makes it hard to predict what the role will look like in the future.

Five years from now, I honestly have no idea what the role of a CTO will look like. The way we build software is already changing rapidly, especially with AI. But the fundamentals like setting a vision, communicating it clearly, and connecting technology with business outcomes, will always remain essential.

For Skipper, that uncertainty makes peer support crucial: it helps leaders adapt, learn, and navigate a fast-changing profession.

Ultimately, he believes the most important skill for CTOs is the ability to keep learning and tackle challenges without going it alone.

*Infobip, the global communications API leader that launched ShiftMag, was an Event Partner at CTO Craft 2026.

The post CTOs Face Pressure to Deliver AI Gains, but Productivity Isn’t There Yet appeared first on ShiftMag.