That's just completely false but ok. There's even a EU regulation to ensure the exact opposite: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=legissum...

To build frontier models you need VC money. There’s no VC money because VC believe that there is no market for a ‘EU Champion’.

There’s no market for a EU champion because internal EU market is not big enough for VC returns. Why invest in EU champion when the US champion is guaranteed to have better returns ?

And there’s no public alternative to VC either because that’s national level and national investment in EU doesnt cross national boundaries

Mistral actions reflect this, they need returns and they target the market where they can be competitive, which is the scraps the US labs cannot address. This is not enough to fund frontier lab research

Also the legal context on regulations is quite different from the US. In the US you can have unlimited damage, that is not the case in the EU, where regulation penalty can never as a matter of principle put the existence of the company in danger, and thus the application of the regulations is always a matter of negociation with the government. You don't have to respect everything all at once, size of the company and ability to actually implement the regulations are taken into account, which means that sartups are usually excempt.

It is also quite sad that the western NGOs, which all have their own very functional and heavily subsidised delivery channels, keep it to themselves, instead of making it available to the general public and businesses of the countries. Their monopolies on efficient import is weird and counter productive.

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.