Yup, the unpredicable nature of their unreliability is what makes it very tiresome to work with LLMs sometimes.
With people, you kinda learn their strength and weakness.
With LLMs I haven't yet.
You can't talk about delegation without talking about what and who you're delegating.
Delegating a demo or an exploration to a junior is fine if you can help them with feedbacks and make them grow and the business is not on the line.
Delegating a critical development to a senior engineer you've vetted on previous delivery is fine too.
Delegating a critical development to a junior is a recipe for disaster.
Now, I'm still trying to figure out what I can fully delegate to an agent and what I can't.
Right now, LLM feel like a senior on technical stuff and a junior on decision/taste. One thing is sure, I can't delegate a critical development to it, not without review. For that review, I need programming skills.
Maybe in the future that won't be the case, but I am not seeing that right now. (Using Claude code)
Interesting as I reach a similar pov. I just started with experimenting with the following workflow with Claude Code:
- get a plan for whatever I want to do, iterating in plan mode until I am satisfied with the solution
- before execution, I mark each phase that I want to do/learn about with /tutor-mode
Tutor-mode is a SKILL I made to have the LLM guide and teach through questions and hints.
So I delegate completely the boilerplate/build system/CI and switch to manual+aided by AI for specific implementation part of the code.
I also keep a final validation step to me because I've experimented a few too many "sorry I told you I passed the test suite and I did, but the build failed and I didn't told you".
How is getting proof one doesn't understand going to help build safer system?
I want to believe formal methods can help, not because one doesn't have to think about it, but because the time freed from writing code can be spent on thinking on systems, architecture and proofs.
Vendoring means you don't have to fetch the internet for every build, that you can work offline, that you're not at the mercy of the oh-so-close-99.999 availability, that it will keep on working in 10 years, and probably other advantages.
If your tooling can pull a dependency from the internet, it could certainly check if more recent version from a vendored one is available.
> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
IMHO, the real problem is that they create an even greater dissonance between online life and IRL.
Think about dating apps, pictures could be fake, and now words exchanged can be fake too.
You thought you were arguing with a gentle and smart colleague by chat and mails, too bad, when you meet then at a conference or at a restaurant you find them very unpleasant.
My gut feeling is that, without wrestling with data structures at least once (e.g. during a course), then that knowledge about complexity will be cargo cult.
When it comes to fundamentals, I think it's still worth the investment.
To paraphrase, "months of prompting can save weeks of learning".
But isn't the corrections of those errors that are valuable to society and get us a job?
People can tell they found a bug or give a description about what they want from a software, yet it requires skills to fix the bugs and to build software. Though LLMs can speedup the process, expert human judgment is still required.