Why AI-Native Software Delivery Needs More Than a Better Model
AI tools work. Adoption is above 80%. And yet measurable business value remains stubbornly low. The bottleneck is not the model — it's the software delivery system around it.

AI tools work. Adoption is above 80%. And yet measurable business value remains stubbornly low. The bottleneck is not the model — it's the software delivery system around it.

Evaluating agentic systems is a multi-dimensional challenge that requires a multi-layered framework. A robust evaluation system must verify both functional and non-functional requirements. The system should verify whether an agent is fulfilling its core objectives, while performing efficiently, safely and with low latency. Furthermore, the system must account for scalability while ensuring the agent's underlying reasoning remains transparent and traceable. Those different evaluation layers allow, to evaluate the model both from the technical and strategic business perspectives.

A monthly reading roundup - no chasing every model, no top-50 lists, no marketing. One thread running through it all: the best model on the planet can be switched off on a Friday afternoon, so the real asset is what you build around it. You lease the model, but the process is yours.

Depending on the team and project, developers may work from well-defined requirements or help shape solutions from the ground up. In developer tooling, the latter tends to happen particularly often. We spoke with Karol Skóra about what surprised him most after moving from backend development into tooling and why communication may be just as important as technical expertise.

Most developers build software for a specific customer. Tomasz Godzik works in a very different environment. As one of the engineers behind Scala open-source projects such as Metals and the Scala 3 compiler, his users can be anyone - from developers inside large organizations to contributors on the other side of the world. We talked about open source, development tooling, AI, and the kind of mindset required to solve problems that often have no documented solution.

Interview with Krzysztof Romanowski, Head of Development Productivity at VirtusLab Software engineering loves process, structure, best practices, and architectural purity. Tooling engineering often lives somewhere else entirely - in edge cases, uncomfortable tradeoffs, and systems that only work because somebody deeply understands how they break. We sat down with Krzysztof Romanowski to talk about why tooling engineers often think very differently from the rest of the industry.

A slightly unsettling realization hit us at VirtusLab not long ago - our collective list of starred GitHub repositories had quietly ballooned into something that could generously be called "a problem." Instead of pretending it wasn't happening, we decided to lean into it: every two weeks, we pick a trending open-source project, pull the hood off, and tell you what we find underneath. We focus on fresh, relatively unknown repos - not the usual suspects that everybody and their tech newsletter already covered (because let's be honest, you don't need us for that).

Interview with Jerzy Muller, Scala Evangelist & Dev Tooling Expert at VirtusLab Sometimes Google returns zero results. That’s usually where tooling engineers begin their work. In large-scale engineering organizations, their job is to make impossible systems work together and keep thousands of developers unblocked when everything starts breaking at scale. We sat down with Jerzy Müller, Scala Evangelist and Dev Tooling Expert at VirtusLab, to talk about what this work actually looks like behind the scenes.

As AI tools take over more and more of the actual coding work, a new question emerges: who's watching what they do? Visdom Governance is a tool designed to bring that control back. Krzysztof Grajek, Principal Software Developer at SoftwareMill and the lead engineer behind Visdom Governance, talks about why the rise of AI-generated code demands a completely new approach to trust, auditability, and documentation.

This is post #3 in The Agent-Ready SDLC series. In post #1 we laid out the Ferrari-in-a-Fiat-500 problem - the engine is great, the chassis isn't. In post #2 we covered the first bottleneck: context. Now we're at the second bottleneck - the one that sits between your agent and reality.

As AI accelerates code generation, many teams are discovering that speed gains often come with hidden costs in review, validation, and complexity. We sat down with Krzysztof Romanowski to unpack what’s really happening inside modern engineering organizations.

As developer experience (DX) becomes a competitive advantage, many organizations are investing in internal platforms and tooling. However, building and maintaining DX capabilities in-house is costly and complex. This raises a key question: when should organizations manage developer productivity internally, and when is it more effective to engage external partners?
