- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
As we continue developing our software, we accumulate a growing amount of technical debt just to keep the system running. But I believe we are on the brink of an even larger issue. Cognitive debt.
Hope you enjoy this reading, all feedback is welcome.



Wooow, this message is as long as my post, love it!
This is where the open spec tries to help/solve. But this is a bandaid. Without a lot of hand-holding the models will make shity decisions/code. And this is cumulative, the more you try to steer the wheel, the worse it gets. I can specify details, but a 3 years old project is in this shape, and no amount of LLM will solve/help.
I understand this point, but it’s flaky at best. To be honest, with a large enough project a decision will take longer, if not impossible in a LLM driven codebase. It will be years to debugging, breaking down and rebuilding to even get close. Or spend the paycheck of 5 engineers annually for a single migration.
And this considers the the current LLM are heavily subsided.
Wrong, from the experiments on the academia, we get the fact that engineers with AI are often slower, because the problem was never in the code, code is the tool, it was the acquiring the right data, model and get the knowledge of the product to make the changes needed.
I try to keep around 1.5k to 2k words a week. It’s not always the case, some weeks I’m somewhat more inspired, sometimes I need some refinement, but this is a personal view, I want the reader to have a “conversation” with the author. This is the type of metaphor I try to use.
Either way, thanks for reading.
Ps.: Do you always use LLMs to write your messages? I would love to read your own words. Don’t be the meat proxy for the LLM.
I almost never use AI to write my words. And when I do, it’s heavily hand edited. Every single word of my above comment was hand written. No AI was used to summarize or reply to your post. I did use fair fewer profanities than my usual style (which helps a reader hear the human behind the words) because I didn’t want to come across as aggressive or insulting, especially with English not being your first language, I erred on the side of caution.
I’m interested in open spec since reading your article. I wasn’t aware before. It might be helpful to my efforts. In all cases when we run into a decision point or problem, we update the documentation first, and then implement.
It depends what you think is large enough. I work in microservices where the effort is far beyond simple Python scripts at which LLMs excel, but not at the level of a full product. Our process is not nearly so messy. But it does require a lot of up front work, and a lot of intermediary steps to make sure that every problem, every judgment call however big or small is formally documented into the spec.
I challenge this notion. I have real, measurable productivity gains of 20-30% which is double what I expected. I believe the key factors are experienced developers and critical thinking, but I’m aware of that research and it doesn’t align with my experience, so there is some difference at play. I’ve seen many examples of it going wrong, but with caution and skepticism, we are finding success that defies that research.
But I think you missed my larger point, which was that the developers grow and become more capable in general, where even with our system, the AI can only grow more capable within one particular project and you’re largely starting from scratch on the next.
I applaude your commitment. I can’t do that. I’m always afraid I won’t have anything worth saying on a regular schedule. That said, the current document is not a conversation but a lecture. Splitting it up allows a reader to say, “interesting, tell me more about this.”
Again, all human words. No ai involved. Probably you’ll find some typos if you look. No matter how hard I edit, I always do. Good luck. Hope to read more from you.
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 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.
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.
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.