Enterprises are increasingly investing copious amounts of cash in AI without a lot to show for it. This could be, in part, because the wrong people are leading the change.

As I’ve argued before⁠, AI isn’t likely to eliminate developers so much as change what we need from them. For example, we keep asking whether junior developers are needed in a world where large language models can write code faster and cheaper. What this overlooks is the reality that these younger developers and their relative inexperience may be exactly what we need to rewrite the rules of software development.

This thought hit me while reading James Governor’s riff on something Ben Griffiths⁠ wrote about our industry’s habit of confusing age with authority. Griffiths remembered sitting through a conference talk in which a speaker tried to shame a young audience for not recognizing some of the older men who had shaped computing. The irony, Ben noted, was that many of those “old men” had done their world-changing work when they were younger than the people being lectured. Bill Joy wrote vi when he was 22, John Carmack created Doom at 23, Linus Torvalds launched Linux at 22, etc. Many of our industry’s titans made their biggest contributions before they had decades of experience.

The point isn’t that young people are smarter. They’re not. The point isn’t that the key to AI success is to ignore more experienced developers. That’s dumb. Rather, it’s a suggestion that Griffiths’ larger point is right: At the beginning of big shifts, experience can be a mixed blessing. It can help you see risk, but it can also make you overconfident in old ways. The most successful enterprises will find ways to balance youthful innovation with experienced guardrails.

The factory doesn’t redesign itself

Zara Zhang recently pointed to Paul David’s classic 1990 paper, “The Dynamo and the Computer,”⁠ as a way to understand why so many companies have “adopted” AI without much to show for it. David’s argument, simplified, is that electricity didn’t immediately transform factories. For a long time, factories simply swapped out the central steam engine for an electric motor while keeping the same layout, the same workflows, and the same assumptions.

Electricity was new, but we largely stifled its potential by force-fitting it into old factory systems.

The big productivity gains came later, when factories stopped treating electricity as a cleaner steam engine and started redesigning work around smaller motors distributed throughout the factory. Once each machine could have its own motor, the factory no longer had to organize itself around a single driveshaft. Work could instead be reorganized around the flow of production.

That’s a decent description of where many enterprises are with AI. Enterprises today are buying copilot licenses by the thousands, wiring agents into existing applications, etc., and then wondering why the results are so uneven, as I’ve written⁠. This is the equivalent of swapping the steam engine for an electric one and declaring that the AI modernization work is done. It’s not. Not even close.

The real payoff won’t come from asking AI to write the same tickets a bit faster. It will instead come from changing how teams define work and how (and what) developers build. The “factory” has to change.

So here’s the uncomfortable question: Who is most likely to build the new factory?

Experience cuts both ways

There’s an obvious danger in romanticizing youth. Plenty of bad software has been written by people with unlimited confidence and limited context. Enterprises need software that works, yes, but “works” also means it complies, scales, respects security boundaries, and more.

This is where experienced developers matter. A lot.

As I pointed out recently, the agent era makes engineering judgment more important than ever. After all, AI makes it easier to generate code, but easier code generation can become easier technical debt generation. Hence, the limiting factor becomes less of “Can we create something?” and more of “Can we create the right thing, in the right place, with the right constraints?” Taste is required, in other words.

Senior engineers are often better at seeing those constraints because their experience gives them “taste.” They know why the weird validation rule exists, and they remember the customer who depended on the undocumented behavior. They understand why a simple schema change can turn into a multi-week migration.

But experience also has a shadow side, because it can make the current process feel inevitable. A senior engineer may see an AI assistant as a faster autocomplete because that’s the easiest way to fit AI into their existing mental model. A junior developer, less invested in the old workflow, may ask the more interesting questions: Why are we doing this ticket at all? Why isn’t the spec executable? Why can’t the agent generate the test harness first?

It’s not that the more experienced developers don’t know these questions. Rather, they may simply not have the energy to rage against the machine, as it were.

The value of inexperience

The worst way to use junior developers in the AI era is to treat them as cheaper versions of senior developers. That was always a bad idea, but AI makes it worse. If the job is “take this ticket, generate some code, and send it to a senior person for review,” the junior developer becomes a human wrapper around a coding assistant. That helps no one. The junior doesn’t learn much, the senior gets buried in review, and the enterprise ends up with more code, which, as I’ve said, is hardly a good thing.

Instead, junior developers should be given room to explore new workflows, with just enough oversight from experienced colleagues. That might mean giving these newer developers interesting questions to answer, such as:

• How would we redesign onboarding if every internal API had an AI-readable contract and examples that actually worked?
• How would we change code review if the agent produced a change summary, test evidence, dependency risk, and rollback plan with every pull request?
• How would we build features if product requirements were written as executable acceptance tests rather than vague prose?
• How would we reduce toil if agents could safely perform routine migrations, dependency updates, or incident triage within clearly defined boundaries?

These are not toy problems. They’re not “junior work.” They’re exactly the sort of process redesign that enterprises need but generally avoid because everyone is too busy running on the existing hamster wheel.

Finding the balance

So what should engineering leaders do? First, stop treating AI adoption as an individual productivity contest. We seem to be moving quickly away from the idea that “lots of tokens” equals “great engineer,” but the fact that we even flirted with it is damning. I love how Santiago Valdarrama eviscerates this vanity metric: “Measuring AI productivity in number of lines written is a stupid mistake. One day, everyone will have always been against this.” Instead we should be asking questions like, “What part of our software delivery process no longer makes sense?” AI’s biggest gains will come when we change how we specify, test, review, and ship software.

Second, mix up your AI workflow teams. No, not committees or PowerPoint-producing centers of excellence. I’m talking about combining two or three newer developers who are already fluent in AI-native tools with two or three senior engineers who understand production, security, architecture, and organizational constraints. Then give them a real workflow to redesign, such as dependency upgrades or test creation.

Third, make the senior engineer’s job less about saying no and more about defining the guardrails within which others can say yes. I’ve argued that golden paths are key to using AI effectively. Good senior engineers should define the paved roads: approved patterns, test requirements, observability standards, etc. Then let junior developers and agents move quickly inside those boundaries.

Fourth, reward deletion. This may be the most important point. Going back to the factory electricity metaphor, we’ll fail with AI modernization if we simply add AI without removing outdated processes.

Bring everyone to the table

The future of software development won’t belong to the young. It won’t belong to the old, either. It will belong to teams that combine the talents of both.

Newer developers often bring impatience. They’re less likely to accept the existing workflow as sacred. They’re more likely to try weird tools, compose them in unexpected ways, and wonder why enterprise software development feels like a ritualized exercise in waiting for permission.

Experienced developers bring judgment. They know that software has users, auditors, attackers, budgets, latency, history, and consequences. They know that the right answer is often boring, and boring is good.

Enterprises need both. They need the developer who asks why the factory is still organized around the old drive shaft, and they need the developer who knows which machines will kill someone if moved casually. In sum, every development team needs people who know why the old system exists… as well as those who don’t.

MUNICH — Amid trans-Atlantic political and trade tensions, digital sovereignty — once a relatively niche concern — has jumped to the top of the agenda for European organizations wary of their reliance on US technology suppliers.

For many, including European Union policy makers, increased use of open source software is a key part of the answer, offering an alternative to proprietary platforms from a handful of large US vendors.

That’s the view of Frank Karlitschek, CEO of Nextcloud, the German software vendor that bills itself as an open-source alternative to software suites from the likes of Microsoft and Google. 

Nextcloud

Karlitschek founded the company in 2016, forking OwnCloud’s open-source file-sharing software. Since then, Nextcloud has expanded its products to include a range of productivity and collaboration tools that organizations can install and run on their own servers or access via cloud providers. 

More recently, Nextcloud helped develop the Euro-Office application suite, which launched last week as an open source alternative to Microsoft Office and others, and continues to build out its Nextcloud Hub with AI assistant and agent features. The company now says revenues are growing at between 50% to 100% year over year.

Computerworld spoke to Karlitschek at Nextcloud Summit about momentum around digital sovereignty, the European Commission’s Tech Sovereignty Package proposals, and how Nextcloud hopes to evolve in the coming years.

The following interview was edited for length and clarity.

When Nextcloud launched, there was a big push in Europe away from on-premise software towards US cloud providers. How have attitudes towards open source and awareness of alternatives providers changed since then? “I’ve been doing open source since the ‘90s; at the time it was mostly for a nerdy audience — a very small group of people who really care about software and being in control. The sovereignty part was always there. It’s the core idea behind open source that you can understand what the software is doing, you can deploy it wherever you want, you can study it and change it, and so on. 

“At the time, it was very niche, and since then it’s really growing and growing. There are certain points in time that really accelerated the growth; something like the Snowden revelations, for example, or the whole discussion about GDPR and certain legislation. And then, of course, the current geopolitical situation.  

“I personally find it interesting that it grew from something that is just interesting for software developers, and now it’s on the geopolitical stage. I have meetings with big politicians who really care about it now, and I personally find it interesting that it’s increasingly understood by — I wouldn’t say the mainstream, but more and more people.

“At the beginning of Nextcloud, we mostly talked with IT managers looking for a solution; they care about how it works, the price and other things. But now we are also talking with the C-level people. It’s part of an overall strategy of a company, to say, ‘Hey, we need to look into the dependencies, we want to have a solution that fits into the strategy of the company.’

“In the past, it was like a commodity – it’s just some software, who cares? Now, it’s really part of the company strategy. That’s really interesting.”

There’s been a lot of interest around digital sovereignty over the past couple of years. To what degree is this translating into action, with organizations migrating away from US cloud providers? “The interest is gigantic. Everybody’s talking about it, we have so many contacts and people coming to us. Not everybody is doing it — a lot of people are just exploring and seeing what the options are. 

“Obviously, we hope that this will translate into actions in a few months. At the moment, it’s a lot of talking and exploring the options. As a company, we are also growing a lot in customer base.  But the interest in this space is even bigger; we see it as the beginning of a funnel.

‘In defense we see a lot of interest, then also everything around education is very important for us, then other regulated markets like the healthcare, for example. Finance is an interesting one.”

A lot of the conversations around digital sovereignty are tied to the current geopolitical situation and even the US administration. Do you see demand for sovereign technology as a structural change or are some organizations holding back to see how the situation improves in the future? “I see it as a long-term trend. If you look at the IT budgets and projects in the ‘90s, it was some something unimportant. It was, of course, important that the printer works and the fax machine works, but it was not definitely not strategic for the company. 

“And then in 2000, the whole cloud trend came up, and there was the big hope that this will save money. It was always the narrative with cloud computing that you can just outsource it and save money and it’s great. 

“Nowadays, people realize that it’s not something that you can just ignore. I wouldn’t say that everything comes back on premise, but people care about it now. They understand it’s not just a commodity, like water, or electricity that comes out of the wall and you don’t care what’s behind it. People realize that it’s something that has an impact on the future of an organization, from a vendor lock-in perspective, from a cost perspective, from an industry espionage perspective, and competitiveness. With open source, you’re more flexible. So, I think the trend that this is all more strategic and important for the future, this will go on.”

The European Commission recently published its Tech Sovereignty Package, including its open source strategy. Are these proposals sufficient to address the concern around digital sovereignty and support the open source ecosystem in Europe?

“It’s great, I really like it. I was actually surprised they listened so well. But now the real challenge is to actually do it; this still needs to happen. The description of the problem and a possible solution, this is all very good. I’m surprised, I’m happy about it, but to put this into actually binding law, this still needs happen.”

Would you like to see any changes to the current proposals before they’re gets passed into legislation? “At the moment, they have these four different risk levels, and the most critical one — No. 4 — is one where they accept only open source and European solutions. This is the highest risk level, but this is only for 1% of the market. I hope that it’s better understood that more than 1% should care about this more.

“If you have something which is completely not critical, maybe doesn’t possess any personal data at all — sure, it’s totally fine [to use non-EU suppliers]. But if you have GDPR requirements, espionage protection, no vendor lock-in, and so on, then there should be more of that [the highest requirement level].”

US firms have attempted to address European customers’ concerns in different ways, with sovereign marketed cloud services and joint ventures with European providers. Microsoft 365 Local is designed to run on premise. Where do you draw the line between what’s actually a sovereign solution and what some call ‘sovereignty washing? “Sovereignty has different dimensions, of course. But if you look at the problem of the CLOUD Act alone, which gives foreign agencies full access to the data here, then the whole idea that it’s enough to have European data centers — that’s not enough. It’s clearly written in the CLOUD Act, that even with [European] data centers, or subsidiaries, it still applies.  

“Microsoft tries to find a solution there with its Delos idea; a company that is owned by SAP — a German company — and Microsoft delivers only the software. But even then, you have this dependency, because software needs updates and software security updates. And if they’re not available, or if someone puts a backdoor into the software, which is possible, then you still have a problem. 

“So, they’re trying really, really hard to find a way around the problem, but it’s not easy for them.”

To look ahead a bit in terms of the product strategy, there were announcements for Nextcloud Hub this week around AI agents, and the program to work with independent software vendors. What do these say about Nextcloud’s future? “The overall product strategy will not change so much; it’s about having state-of-the-art collaboration software — but with a lot more control, security and safety — that’s open source and independent where you host it. So this will always stay, but of course, there’s some additional factors that come into play now, like the AI impact that we see and want to leverage with our agent strategy. 

“We’ve had this for one and a half years already, but we are expanding that. In the future, you might still use an interface in a classic way that you open documents and type in text and so on. But there are also a lot of operations that can be automated in the future with AI. And this is something we really invest a lot into. 

“Another aspect of AI is how easy it is to build custom software around it. The coding models are getting better all the time, which means there will be more and more custom business software. This is what we want to capture with our ISV program. Software development will become easier, but you don’t want to deploy just random software in your company, you want to have something that is tested, certified and secured, and that somebody’s accountable for it. This can be something we can provide at Nextcloud.”

Editor’s note: NextCloud paid for Matthew Finnegan’s travel and hotel costs for NextCloud Summit 2026, but had no editorial role in the creation of this story.