imilev

This is cool af.

yes i think everyone is waiting to see that ;d, i've been on qwen for the last year and a half now.

Great article, I think the most important aspect from it is the auto-routing. As humans laziness is in our nature, so having to think if the model is capable enough is not something that most ppl will do - resulting in trying out smaller models which failed our task and then just giving up and running on the bigger model all the time.

Interested to dive deeper on the upfront design discussion. Have you found these to more often then not translate into the real product.

In my experience at the begining of the full agentic coding loop in our company we were more hands on with the codebase and had better judgement over the plans. Now it is quite often that the inital plan after executed needs more refinement and that made the plan review somewhat obsolete for us.

I hope that some of the executives out there will read the list. I know they won't spend the time to read the full blog, but at least the headers should be enough

I see, I misinterpret what you are saying. I think manually written code is thing of the past. There will be need for it from time to time but we are going to operate at an even higher abstraction than we do now.

Same is for things like asembly there are still people who need to edit that, but most of us are working with the higher-level programming languages.

I disagree tbh, the prototype is not the product not just because of technical abilities but also because of product expertese in a topic.

If it was otherwise outsourcing companies would've dominated the market for a long time, but it is with the exp from clients and many users that you get to build a great product.

It takes a lot of time to understand what is the pain of the user, in many cases we know what the problem is but we have not time to think of a good solution to it.

I think we have played this game long time ago. If products were a question of a single request then outsourcing companies would dominate over product ones.

I think a lot of product development happens in the itearations after the intial prototype/MVP and so on. It is not only the technical aspect to it, you need to spend time on a problem deeply understand what are the root causes of pains and address them in your product, both from UX and also from technical perspective.

People were able to "prompt" a product even before to an outsourcing company, but they'd rather pay the fee to a product company because of the expertese they have gained through out the years and all the users they've spoken to.

What happens when shit hits the fan in my exp is that I have to crack open the codebase and debug some portion of it, so I can explain it to myself in order to be able to explain what is wrong to the LLM.

Otherwise what I have found is that the LLM will add a new if statement which will handle the newly discovered issue and you start stacking them ifs. As the article mentions LLM's unlike humans aren't lazy, they will copy, paste add patches for every issue, why bother think and understand root cause :d.

So as part of our review we have a rule against that as well.

Cannot believe I needed a VPN to the US, to open this from Switzerland...

At least give me the article ffs.

Awesome article, I feel a lot of people have also forgotten that good projects take iteration not 100 new features. To get few features to an excelent state it requires multilpe iterations at multiple stages. 1) The developer who does a task validates that their thinking was the correct one, they see how they changes impact the system, is it scalable? Does it need to be scalable? While you are working and thinking on it you get more and more context which simply wasn't there at the begining. 2) A feature done once (even after my perfect ClaudeCode plan) is not done forever, people will want to make it better/faster/smoother/etc. But instead of taking the time to analyze and perfect it we go onto the next feature, and if we have to iterate on the current one, we don't iterate we redo...

Really like the article I think it is awesome, and I strongly believe AI for coding will stay, but I also beleive that we need to still have a strong understanding of why we are building things and what they look like.