gjadi

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".

Except that zip does not preserve permissions.

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.

Well, it does tell us something if they limit screen time like they limit sugar but don't limit book time.

I'm sure almost no family have an upper limit on book time.

Thus aiming for screens the replace books is a bad aim.

It depends on their sleep habit, work-life requirements and compensation when they need to be on-call.

When you get a fatter check because your code break, the incentives are not in favor of good code.

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.

“The doers are the major thinkers. The people that really create the things that change this industry are both the thinker and doer in one person.”

Steve Jobs

Now, what are doers in the age of LLM is another question.

Because people only quote it partially.

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%.

The maintainer explained the reasoning for closing the issue quite well in a comment.

There is always more money elsewhere.

But once you have a home, enough to raise your family and save for later, when is enough enough?

And is the work fun? Fulfilling?

Money is a mean to an end.

Sure you can aim to earn enough to get FIRE asap. In my case, I aim for FIRE in the next 40y while maxing my fun in the meantime :)

Not everyone is motivated by the highest wage they can get.

Good enough can be good enough and then aim for fun/interesting/challenging/fulfilling work instead of a fatter check.

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.

This.

For me, navigating with shortcuts feels like I can keep my inner monologue, it is part of it, maybe because I can spell it?

Dunno, but reaching for the mouse and navigating around breaks that, even if it can be more convenient for some actions.

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".

Interesting argument.

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.

It's ego won't get in the way but it's lack of intelligence will.

Whereas a junior might be reluctant at first, but if they are smart they will learn and get better.

So maybe LLM are better than not-so-smart people, but you usually try to avoid hiring those people in the first place.

It's like pot.

Back in the day, it was much less concentrated and less dangerous than what you can get today.

It's much easier to forbid something to a subset of the population than to the population at large.

Imho it's because you worked before asking the LLM for input, thus you already have information and an opinion about what the code should look like. You can recognize good suggestions and quickly discard bad ones.

It's like reading, for better learning and understanding, it is advised that you think and question the text before reading it, and then again after just skimming it.

Whereas if you ask first for the answer, you are less prepared for the topic, is harder to form a different opinion.

It's my perception.

Have this shortcomings of llms been addressed by better models or by better integration with other tools? Like, are they better at coding because the models are truly better or because the agentic loops are better designed?

I agree with the excel thing. Not with thinking it can't happen with vibecoded python.

I think handling sensitive data should be done by professional. A lawyer handles contracts, a doctor handles health issue and a programmer handles data manipulation through programs. This doesn't remove risk of errors completely, but it reduces it significantly.

In my home, it's me who's impacted if I screw up a fix in my plumbing, but I won't try to do it at work or in my child's school.

I don't care if my doctor vibe codes an app to manipulate their holidays pictures, I care if they do it to manipulate my health or personal data.

Sure, but then I rely on an actual expert.

My issue is, LLM fooled me more than a couple of times with stupid but difficult to notice bugs. At that point, I have hard time to trust them (but keep trying with some stuff).

If I asked someone for something and found out several time that the individual is failing, then I'll just stop working with them.

Edit: and to avoid with just anthropomorphizing LLM too much, the moment I notice a tool I use bug to point to losing data for example, I reconsider real hard before I use it again or not.

But with a software bug, the error becomes rapidly widespread and systematic, whereas human error are often not. Doing wrong with a couple of prescription because the doc worked for 12+ hrs is different from systematically doing wrong on a significant number of prescriptions until someone double check the results.

IME I don't learn by reading or watching, only by wrestling with a problem. ATM, I will only do it if the problem does not feel worth learning about (like jenkinsfile, gradle scripting).

But yes, the bench result will tell something true.

Ok. I also have the intuition that more tests and formal specifications can help there.

So far, my biggest issue is, when the code produced is incorrect, with a subtle bug, then I just feel I have wasted time to prompt for something I should have written because now I have to understand it deeply to debug it.

If the test infrastructure is sound, then maybe there is a gain after all even if the code is wrong.

I don't want my doctor to vibe script some conversion only to realize weeks or months later it made a subtle error in my prescription. I want both of them to have enough fund to hire someone to do it properly. But wanting is not enough unfortunately...

When you don't know the answer to a question you ask an LLM, do you verify it or do you trust it?

Like, if it tells you merge sort is better on that particular problem, do you trust it or do you go through an analysis to confirm it really is?

I have a hard time trusting what I don't understand. And even more so if I realize later I've been fooled. Note that it's the same with human though. I think I only trust technical decision I don't understand when I deem the risk of being wrong low enough. Overwise I'll invest in learning and understanding enough to trust the answer.

As if reading books was enough to make you an author.