First, I’m sorry. I attribute LLM use when I had only suspicions about it. And this is on me. If you weren’t using LLM for the message, this is on me.
This is where the open spec tries to help/solve […]
I’m interested in open spec since reading your article. I wasn’t aware before. […]
This is a derivate methodology from the SpecKit (which is a piece of crap, stay away from it). It helps to certain points, but this is still bandaid in it. Not a real solution.
It depends what you think is large enough. I work in microservices where the effort […]
Looks like we work in very different kind of projects. I’m used to jump into garbage projects to fix it. Often the projects that other people tried to make something new and fumbled so hard that the company owner had to buy my labour and knowledge to fix the shit.
Yet, microservice is the point were LLMs fails the most. Not having the full context of other services and without the good test case for it, the product will be fated to fail. So I think you may not have a full cycle on the software development, the green field is always easy, and this wasn’t never the problem.
Look on the history, the first months of a product is always the most productive (way before any LLM would ever exist), the real issues appears years in the development, when the cumulative decisions start to group and becames a problem, where every new change breaks other. The technical debt that I spoke in the article.
This isn’t on the first week of the project, this is years in it.
In short, microservice is already a bad design for most of products, very few products require to be microservices, and combined with the LLM lack of view on the product as a whole makes this even worse. So I would suggest you to validate your own assumptions on the topic.
There is a good chance that you are either not fully validating, or not seeing the product as a whole.
Wrong, from the experiments on the academia, […]
I challenge this notion. I have real, measurable productivity gains of 20-30% which […]
But I think you missed my larger point, which was that the developers […]
That’s very funny. The same academic research who found out that the usage of LLM delayed the deliverables in ~19% had a section where the developers using the tool thought (wrongly) that they were ~25% faster.
You are only proving the paper.
Regarding the idea, I’ll think about it (like I always do), but making shorter text will not make my style. When I’m reading blogs I’m looking for the similar size text, this usually fits in the commute time, have a deeper conversation/meaning.
Again, thanks for reading.





Better, probably not. And I’ll give you one example. In a codebase there was an issue with Auth, after few runs of the LLM, the best suggestion resulted in 30~40% of change in the Auth workflow.
Took me a couple hours to figure out that the problem was a misconfiguration key (
camelCasetosnake_casein the vault store). Fixing this on the store (not on the code) fixed the Auth workflow.This two hours were the cognitive debt. And keep in mind, I’m familiar with this part of the code. A Mechanical Parrot happy-trigger boyz would accept the change in the codebase as an attempt to fix it.
So, mechanical parrot can help? Sure. But better than people, probably not. At least not yet, not with the current set of tool, not with the promise of fully solving it.
This is badly wrong. The same node can point to multiple places depending on the
Kfactor on this. And this isn’t even theTapplied to it. So, the same node can infer multiple different others. This is the nature of the probabilistic of LLM.