In my experience the latest model (Opus 4.6 in this case) are perfectly able to do senior stuff. It's just that they don't do it from the get go, as they will give you the naive junior dev solution as a first draft. But then you can iterate on refactoring later on

Two important part that has been left out from the article is 1) service code size, our services are small enough to fit in a context + leave room for implementation of the change. If this is not the case you need to scope it down from 'read the whole service'.

The other part is that our services interact with http apis specified as openapi yaml specs, and the refactoring hopefully doesn't alter their behaviour and specifications. If it was internal apis or libraries where the spec are part of the code that would potentially be touched by the reafctoring I would be less at ease with this kind of approach

The service also have close to 100% test coverage, and this is still essential as the models still do mistakes that wouldn't be caught without them

The service was in go, but this doesn't matter.

  - 1. Read the whole code of the repository.
  - 2. Read the TASKS.md file if it exists.
      - 2.1. If it exists and is not empty, pick a refactoring task from the list. Choose the most appropriate.
          - 2.1.1. Refactor the code according to the task description.
          - 2.1.2. Commit the changes to git.
          - 2.1.3  Remove the task from TASKS.md
          - 2.1.3. You are done.
      - 2.2. If it doesn't exist or is empty:
          - 2.2.1. Identify the parts of the code that could be refactored, following the following principles
              - A class should have a single responsability
              - The dependencies of the class should be mockable and injected at class instanciation
              - Repeated code should be factored into functions
              - Files shouldn't be longer than 1.5K lines
          - 2.2.2: If using the previous insights you think there is valuable refactoring work to be done:
              - 2.2.2.1 Write a list of refactoring tasks in TASKS.md
              - 2.2.2.2: You are done.
          - 2.2.3: If there is no more refactoring to be done, notify me with 'say "I am done with refactoring"'

Well that's the job of VCs, that's what they're expert at.

There's also another model where established industrial communities set up research centers to fund projects that might help their common problems.

It doesn't to me at all, it is mainly focused on self hosting llms, which is a complete deadend. It just isn't feasible to self host the useful models, the hardware requirements are just too big.

The current topic of focus around AI are: how to adapt development practice to agentic coding, agent harness, agent orchestration, mcp integrations, etc.

I guess there is some unease in the oss community to rely on large companies to run and host the models. But this isn't entirely new, we also relied on big companies to manufacture our computers. It's just the way it is.

> Well, for better or for worse, FOSDEM is not a tech start-up event.

It is weird, there are a lot of startups present, look at all the stands showcasing projects. Aren't those startups ? What I noticed is that they are usually funded by public grants rather than VCs. I am not sure why this is the case.

Corporate Open Source should have its place at FOSDEM. The linux dinosaur companies such as Redhat are still there. But what about the new ones ? What about Mistral, Odoo ? Even the 'evil' ones such as facebook, github, etc, aren't they contributing a lot of open software ? Aren't they more relevant than let's say Olimex ?

There were some students, yes but the attendence is growing old, and the chit chat is more about 'remember this and that' than 'we're building the future'

Invite the open source developpers behind popular OSS AI frameworks such as opencode, etc.

Invite talkers from large companies that produce open source software and models such as Mistral.AI

Invite talkers from companies that run OSS LLMs at scale such as groq

Invite the people who build drones in Ukraine, (probably the most succesful open hardware story to date). Have drone building workshops / drone piloting stands

We're in 2026, hardware is made in dark factories in shenzhen in fully automated assembly lines by the million of units. Software is written using LLMs hosted in gigantic datacenters. Millions of people are now writing their own software with vibe coding platforms from their phones

What is the FOSDEM community's answer to the real concerns that these changes pose ? Let's hand solder raspberry pis ! let's self host LLMS from 2 years ago on FreeBSD ! Look, i can run wasn linux on this risc-v cpu !

These takes are completely out of touch with reality, no wonder that nobody younger than 40 was attending the conference. The next generation is doing something else and rightly so.

> Human: Claude, How big is a banana ? > Claude: Hey are you doing something with my thoughts, all I can think about is LOUD