You mean you rewrote the nginx test suite with smaller leaner tests ? How did you bootstrap that ? How do you know the leaner tests are equivalent to the real ones ?
Basically I use these "kits" to prove that the behavior is working as expected with mocked data/ interfaces and then only after these kits pass I'll run the real test suite files as confirmation. So these let you iterate a lot faster than the official test suite because it is very slow.
These are bootstrapped from the real tests.
The other commenter was being a bit dismissive but this is the kind of thing I'm taking away as a real useful pattern to do verification of behavior at scale.
Mistral is against these EU regulations. I bought a printed version of the AI act, it's 600 pages of absolute nonsense, with 5 mandatory committees on national, eu, company level; 12 steps 6 months processes to release a new features; daily reporting obligations to yet another committee. It's just not possible to release software with the regulations as they are written.
I do some work in Africa and that's not what i've seen. The NGOs have their own separate supply chains and are quite resistant to corrupt officials and local criminals. The problem with NGOs is that they're mostly regular business masquerading as 'aid' and out competing local businesses who dont have access to their infrastructure and subsidies. There's actually much more demand for NGOs from the West than from their recipients. African governments are trying to clamp down on NGOs, but there's a lot of pressure from the west for the status quo.
I help a good friend run a small business in Africa, and this story is exactly why, every time I go visit, I fill my luggage with stuff she needs. Laptops, car engine turbos, espresso machines, fryers, bottles of shampoo, printers, anything. The cheapest and most reliable way to deliver things there is to take a plane yourself and carry the things with you. This whole mess is why, despite being a poor continent, the price of goods is actually much higher than in rich developed countries, which puts a huge brake on the development of the countries.
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.
The NGO delivery channels are privileged because they are charitable. That's why they get to bypass the country's restrictions. You can't open that channel up, the country would object at humanitarian exemptions being used as a backdoor for commercial imports.
What I mean is that they should use the standard commercial channels and use their economical and political channels to make sure they work well so that everyone would profit from having working import systems.
The result of this might be NGO money being used to fund inefficiency or even corruption. By maintaining their own channels, the NGOs can be more certain their funds are being used responsibly. It's possible otherwise local government would take it upon themselves to try to bleed these western NGOs.
If you read the article you would know that the problem wasn't finding the money to pay import duties (or the delivermen), the problem was not being allowed to give them the money in the first place and the sheer informality of the logistics infrastructure.
> 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
For every dozen people mailing in a laptop, there'll be someone mailing in guns. They don't want that liability. It would damage their ability to do what they do.
I think the best place to put barriers in place is at the mcp / tool layer. The email inbox mcp should have guardrails to prevent damage. Those guardrails could be fine grained permissions, but could also be an adversarial model dedicated to prevent misuse.
That's the point of the loop, (the prompt is in another comment) start with a fresh context at every step, read the whole code base, and do one thing at a time.
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 architectural patterns are similar in go. The part of the prompt that contains the refactoring concerns that I wanted to fix are specific to this go project. You can very well add what you just explained and not only will it follow it, it will cleanup the parts when it isn't done. You don't need to fully explain the concept as it probably nows them well, just mentionning the concept you want to fix is enough.
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
> …You don't need to fully explain the
> concept as it probably nows them well…
Unsurprisingly, many would disagree [1]…
> 1 Establish a Clear Vision
…
You have experienced the world, and you want to work together with a system that has no experience in this world you live in. Every decision in your project that you don’t take and document will be taken for you by the AI…
Unfortunately not, it's private company code. But I can share the prompt I used for the refactoring:
- 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"'
The TASKS.md file will be created and filled by the model. The prompt needs to be run repeatedly in a loop until it decides there's nothing to be done anymore.
reply