It's happened to me recently, I've relied so much on LLMs for coding and after hours of spinning the wheel, I realized, it has no idea, when it fixes something it's mostly a guess, most I've the time we're just debugging by adding logging statements and the code we've created looks crap and is mostly wrong, full of fluff, or hard to understand.
I've been coding without my LLM for 2 hours and it's just more productive...yes it's good for getting things "working" but yeah, we still need to think and understand to solve harder problems.
My initial impressions blew me away because generating new things is a lot simpler than fixing old things, yes it's still useful, but only when you know what you're doing in the first place.
> the code we've created looks crap and is mostly wrong, full of fluff, or hard to understand
I don't disagree in general but I've had a lot of success asking the LLMs to specifically fix these things and make things more maintainable when specifically prompted to do so. I agree debugging and getting things working it often needs supervision, guidance and advice. And architecture it often gets a little wrong and needs nudges to see the light.
I'm not great at this stuff and I got tired of reviewing things and generating suggestions to improve implementations (it seemed to be repetitive a lot) but I am having good results with my latest project using simulated ecosystems with adversarial sub-projects. So there's the core project I care about with a maintainer agent/persona, an extension with an extension developer agent/persona (the extensions provide common features built upon the core with the perspective of being a third-party developer), and an application developer that uses both the core and extensions. I have them all write reports about challenges and reviewing the sub-projects they consume, complaining about awkwardness and ways the other parties could be improved. Then the "owner" of each component reviews the feedback to develop plans for me to evaluate and approve. Very often the "user" components end up complaining about complexity and inconsistency. The "owner" developers tend to add a lot multiple ways of doing things when asked for new features until specifically prompted to review their own code to reduce redundancy, streamline use and improve maintainability. But they will do it when prompted and I've been pretty happy with the code and documentation it's generating.
It's not the article is about though, you're doing all this "engineering" to have success with the "AI". You're not really "depending on it", which is more in the spirit of the article and what I found myself starting to do. At some point you think , I'll either do it myself, or use "AI", at which point you will start to become dependent on it.
Ah I see what you mean. I interpret "depending on it" to have shifted. I want to depend on a particular project for my work, and if it happened to exist on github, I would have just used that. But it doesn't exist so I have created a fake github "community" to develop the part that I will depend on and I don't want to think about a lot of the API design for things I haven't thought about yet, I just want it to work and be ergonomic.
But my point remains specifically about the crappy code AI writes. In my experience, it will clean it up if you tell it to. There's the simple angle of complexity and it does an okay job with that. But there's the API design side also and that's what the second part is about. LLM will just add dumb ass hacks all over the place when a new feature is needed and that leads to a huge confusing integration mess. Whereas with this setup when I want to build an extension the API has been mostly worked out and when I want to build an application the API has mostly been worked out. That's the way it would work if I ran into a project on github I wanted to depend on.