Øredev 2026: What Have We Inherited?

Øredev is turning 20 this year, and the theme for the three days in Malmö is Legacy. The opening framed it as one question per day. Wednesday: what have we inherited? Thursday: what should we continue, and what should we end? Friday: what will others inherit from us?

This was my first Øredev, and the theme runs through pretty much everything. They definitely have a style. Between sessions, there was always something going on: a Brazilian drumming band, an ambient DJ with live visuals, and jugglers, both of them on unicycles. The breaks felt like part of the program, and the hallway track was busy. My conversations there went from platform engineering and why the platform matters even more with AI, to observability and OpenTelemetry.

I wasn’t the only newcomer. The organisers asked the room to stand up if it was their first Øredev, and a lot of people did. Then they asked who had been to all 20. A handful stood up, to a well-deserved “whoa” from the rest of us. Each morning started with an icebreaker. On day one, we told a neighbour something we’d inherited. On day two, the question was which piece of tech we should retire.

I always enjoy conferences that take me outside my usual topics, and Øredev did. AI was still everywhere, but the conversations kept coming back to problems we’ve had for years: platforms that aren’t ready, bottlenecks that move instead of disappearing, and systems full of decisions nobody remembers making. Agents inherit all of that, and now they can create more of it, faster.

A legacy can start with one talk

The opening keynote was a good fit for the theme. Emil Eifrem, co-founder and CEO of Neo4j, first talked about Neo4j on the Øredev stage 19 years ago and came back to tell the story of what happened next. As he put it, if it weren’t for Øredev, Neo4j wouldn’t exist.

It started in the early 2000s, when half of Emil’s engineers spent most of their time fighting the database. So they decided to build a database for connected data. How hard can it be? He was clear that they had no idea, or they would never have done it. The name got a lot of laughs. Neo means new, and Emil loves The Matrix, but neo.com cost $2,000, “about $1,900 more than we had”, while neo4j.com cost $9.

Neo4j nearly didn’t make it. In March 2009, everything was agreed with their first investors, the train tickets to Stockholm were booked and the champagne was ordered. At 9 a.m. the call came: the partner championing the deal had resigned over the weekend, and the firm was walking away. Neo4j had 18,000 kronor in the bank and a week until payroll. Within that week, the whole team was out doing plain Java consulting, Emil had sold the invoices to a factoring firm, and salaries were paid. It’s rare to hear a founder be this open about how close they came to failing.

My talk

Later in the morning I gave “Rethinking Observability as a Platform Product”. It’s an argument I’ve been taking on the road for a while now: we’ve spent too long treating observability as a tooling problem. What most organisations need is a shared foundation, built into the platform, that developers can use without becoming observability experts. OpenTelemetry is that foundation, and the same structured, correlated telemetry works for engineers and agents. It turned out to be a recurring theme over the three days.

The talk seemed to resonate. Afterwards, several people came up to tell me they liked it and had learned something, which is a great feeling. Jessica, who is Swedish, told me later that Swedish audiences can be hard to read: few reactions during the session and rarely any questions in the room, but people come up afterwards. Which is exactly what happened. Good to know for next time. The slides are here (PDF).

Golden paths for humans and agents

After lunch, I stayed in the same room for my fellow CNCF Ambassador Jessica Andersson and “Practical guide to agent native platforms”. Jessica organises the Cloud Native Gothenburg community group, so if you have a talk you want to give there, go find her.

She opened with public GitHub data showing more than three times as many issues created and pull requests merged in Q3 2026 as a year earlier. The bottleneck is moving from writing code to deciding what to build and to reviewing and shipping it. She argued that internal developer platforms have become the foundation for succeeding with AI. LLMs are stochastic by design, so left alone, agents will fragment your codebase, and she’d rather run 1,000 applications that look exactly the same than 12 unique ones. The users of the platform are now developers, citizen developers in finance or sales who build software for their own work, and agents working for both.

I was surprised when Jessica asked who had a platform in their organisation and not that many hands went up. Even fewer stayed up when she asked who had a good one. We’re discussing how to make platforms agent-ready while plenty of organisations are still working out how to make them developer-ready.

She showed two patterns live. One was deterministic guardrails: linters that run as a hook every time the agent saves a file, so it gets a clear yes or no straight away instead of after a full CI run. The other was a small Golden Path CLI with search and lookup commands, so the agent pulls in only the part of the golden path it needs, when it needs it. In the demo, Claude built an app that let the audience vote between cat pictures and technically bad jokes. The jokes won. When she asked for confetti from a CDN, the linter fired, and Claude looked up the golden path article on third-party assets and fixed it.

Her closing advice: everything the agent uses must also work for humans. If your agent provider goes down during a production incident, you still need to be able to fix things yourself.

An evening at the city hall

The speakers ended the first day at Malmö’s city hall, where the vice chair of the city council welcomed us on behalf of Malmö, wearing the city’s chain of office. It’s quite a room, with gilded ceilings, chandeliers and centuries of portraits on the walls.

How does it feel to write software now?

Clive Thompson opened day two. He has spent 30 years writing about developers for the New York Times Magazine and Wired, and his keynote asked how all this feels to the people doing the work.

Developers have always told him they love the sorcery of coding and the loop of frustration followed by joy when a bug finally gives in. Now the work is a conversation with agents, and he’d collected CLAUDE.md files to prove it. His favourite line: “Pushing code that fails pytest is unacceptable and embarrassing.”

He also had numbers for the bottleneck Jessica described the day before. Data from Jellyfish covering about 300 million work events shows more commits and pull requests, but epics closing only 1 or 2 percent faster. The time saved writing code gets eaten by judging it, and a system that’s right most of the time is the hardest one to keep watching. Senior developers told him they worry about losing their Fingerspitzengefühl, like a Tesla driver whose skills have faded right before the car hands back the wheel in a crisis.

Every jump in abstraction has met the same fear, and Dijkstra once called students who’d learned BASIC “mentally mutilated beyond hope of regeneration”. In his view, those fears were mostly overblown. Where he does see damage is early-career jobs in AI-exposed fields, down about 19 percent in the Stanford Digital Economy Lab research he cited, which leaves an open question about where the next generation of seniors comes from.

His comparison with earlier technology shifts was the part I liked most. When something gets cheaper and easier, we tend to do much more of it, and his example was light: as it got cheaper, we ended up using far more of it. Maybe software works the same way. If writing code gets cheaper, we might build a lot more of it, with developers spending their time on something different from today. To me that sounds more like a huge opportunity than the end of the profession.

He closed on the idea that the technical skills we thought were the hardest may be the easiest to automate, and what’s left is the tacit work of understanding people and what they need. Developers are the first profession going through this at scale, so what we figure out now will show the way for everyone else.

Reinventing the dev team

Hannah Foxwell, co-founder of BIMP, picked up where Clive left off. He’d looked at individuals. She looked at teams, because the team is the unit of delivery, and built the talk on three anchors that hold however good the agents get: build something worth building, speed requires safety, and people matter.

Eighteen months earlier, she’d said on a podcast that every team has a backlog of two to three years. Since then she has seen teams run out. In February, she and her co-founder built the MVP for BIMP, a supply chain security platform, by lunch on day one. A few weeks later she took it to KubeCon in Amsterdam, came back with a waiting list, and threw the prototype away. Some of the people on that list were banks, so the next chapter was a full re-architecture for resilience and security, with only two new features shipped.

On her trash list: the team of six to eight developers, the six-month roadmap, two-week sprints and mandatory code review for every change. Instead, review the spec the agent works from, and make the author own the generated code all the way to production.

Code review is the part I keep thinking about. For now, we’re automating more of it, using LLM-as-a-judge and other checks on the less critical paths. If a change meets the requirements you’ve defined and scores well against a clear definition of what good looks like, it might be a candidate for auto-approval or even auto-merge. I’d want that scoring done by a different model than the one that wrote the code, so it isn’t grading its own work.

Like Jessica, Hannah sees platform engineering turning into agent enablement, with platform teams curating the skills and APIs that coding agents use. And people still matter: you need at least four people for a sustainable on-call rotation, which puts a floor on how small a team can get. Her guess at the next bottleneck is how fast your customers can absorb change.

A thousand services on OpenTelemetry at Volvo Cars

After lunch I picked the session closest to my own work. Christian Fredriksson and Henrik Lindström moved Volvo Cars’ connected car cloud to OpenTelemetry: about 1,000 services, 15,000 pods and 30 teams, more than 90 percent of it Java and Spring Boot. They started with no traces, 10 TB of unstructured logs a day, and Splunk as their single most expensive system.

Their rule was zero code changes for the service teams. They used Micrometer with the OpenTelemetry bridge, added through the shared platform parent and libraries almost every service already used, so teams picked it up in normal dependency updates. That’s a platform move as much as an observability one. When nobody in the room had used exemplars, Christian said, “Cool, you’re all going to learn something.”

Then they let an agent read the telemetry. With the signals correlated through trace IDs and exemplars, an agent with the official MCP servers and a few short internal skills answers “what are the RED metrics for the weather API?” in about 17 seconds. It found a real bug at a 0.007 percent error rate, a timestamp parser that broke when the provider trimmed the fractional seconds from nine digits to six. Nobody would have prioritised that from a dashboard.

Their three takeaways were store it, structure it and instruct it. Keep all signals in open backends, put the same identity and trace ID on every signal, and write your internal knowledge into skills. This is why I keep arguing that observability belongs in the platform. Volvo didn’t ask a thousand service owners to figure it out on their own. They built the foundation once, made adoption part of normal dependency updates, and now have telemetry that engineers and agents can both work with. It’s also a good example of why we build Dash0, where I work. If running your own observability stack isn’t a differentiator for you, you don’t have to build it yourself.

Decluttering your repository

Milena Fluck and Andy Schmidt took a different approach to legacy, borrowing ideas from professional home organisers to clean up repositories. One piece of advice I liked was to watch which structure your AI chooses to follow. Agents don’t know which parts of a repo are good practice and which are historical accidents, and they’ll happily build on both.

How does it end?

Joe Macleod closed day two with “Endineering”. After years of building products, he started asking how they end. We split the product lifecycle into onboarding, usage and offboarding, and put almost all our effort into the first two. At the end, the customer is often left on their own. Polaroid tells a great story at the start, but to close your account, you send them an email. Dropbox tells you a file is “deleted everywhere”, and Joe wondered where everywhere is.

He connected it to productivity as well. Xerox promised the paperless office, and we ended up with far more paper. Vibe coding is mass production of software, and turning software off is getting more expensive. He cited estimates, attributed to an AI lab, of 4 to 8 percent of the initial build to shut down a traditional product and 12 to 22 percent for an AI product. With new EU product liability rules that, as he put it, make software makers responsible for up to 25 years, he doesn’t think piecemeal compliance will hold up.

His ask for the audience was to bring one question to the next product meeting: how does it end?

Building what others inherit

Friday opened with Jutta Eckstein, founder of the Agile Sustainability Initiative, and “Building our Legacy – One Decision at a Time”. She separated legacy, the outdated system nobody manages to get rid of (she still gets offers for Smalltalk projects), from heritage, the part society chooses to keep. Systems leave traces either way, like a patient registration form that rejected last names shorter than three characters, or phones replaced because the software stopped being supported.

Most of her practices were old principles: KISS, YAGNI, “make it work, make it right, make it fast”, no CV-driven systems, and build less. Removing features nobody uses might be the hardest part, and it’s pretty much where Joe left off the evening before. She also suggested sustainability toggles, which work like permission toggles but switch off heavy features for slow connections or old hardware, and asking in retrospectives what would change if the planet were a stakeholder.

She ended with the question for the day: we all stand on the shoulders of giants, so what kind of shoulders are we providing?

A concerto for Java and AI

Thomas Vitale’s “Concerto for Java and AI – Building Production-Ready LLM Applications” was one of my favourite sessions. He composed music for an action scene while explaining decision models, embedding models and tools. Thomas, author of “Cloud Native Spring in Action”, composes film music as a hobby, and he built a Spring Boot app for his composition notes. He started from the problem rather than the technology: having to pick a category for every note broke his flow. His fix was a decision model, part of a Spring AI release candidate that came out the day before, with work he’d contributed himself.

The decision model answers typed questions with probabilities and a confidence score in well under 100 milliseconds, and when the scores are too close, the app asks the user to decide. The same model runs his guardrails, three questions in parallel for on-topic, prompt injection and creative work, so the assistant declined both a pineapple pizza recipe and a request to write song lyrics. Everything ran locally on Ollama, with OpenTelemetry for observability.

Embeddings gave him search by meaning, so “sad” finds the melancholic chord progressions, and tools let the assistant play chords and search his instrument libraries. At the end, the room voted for an action scene, and he composed and performed the score live from the plan his assistant suggested. His answer to the day’s question: creativity is what makes us human, and if we focus on that, we’ll have a good future.

Wrapping up

The three daily questions are a good way to look back. Many of the problems we discussed existed long before agents: platforms that aren’t ready, telemetry without structure, repos nobody dares to clean up, and products nobody planned an ending for. Agents inherit all of that, and now we’re asking them to move faster.

Volvo showed what’s possible when the foundation is there: an agent found a bug nobody would have thought to look for. I find that just as interesting a use of AI as generating code.

I’d continue building platforms as products, with paved paths that work for humans and agents, and rethink some of the processes we’ve built around software, from how we review code to the features nobody uses anymore. I also liked Clive’s argument that cheaper software probably means we’ll build a lot more of it. Together with Thomas’s point about creativity, it’s a more optimistic picture of where our work is heading.

Jutta put it best: we all stand on the shoulders of giants, so what kind of shoulders are we providing?

Thanks to the Øredev team for a great first Øredev, to everyone who came to my talk, and to everyone I met in the hallways.