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.

That seems fine to me. I’ve never cared about permissions in a zip. Zip these days is primarily for exchanging a directory as a single file to another person. Permissions wouldn’t work across computers anyway.

If you want a faithful archive of the data then a tar archive or disk image is what you want.

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.

That's a fair question, and looking at my post I now realize I have two independent points:

1. A proof mindset is really hard to learn.

2. Writing theorem definitions can be hard, but writing a proof can be even harder. So, if you could write just the definitions, and let an LLM handle all the tactics and steps, you could use more advanced techniques than just a SAT solver.

So I guess LLMs only marginally help with (1), but they could potentially be a big help for (2), especially with more tedious steps. It would also allow one to use first order logic, and not just propositional logic (or dependant types if you're into that).

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.

This is only true if you aren’t internally mirroring those packages.

Most places I’ve worked have Artifactory or something like it sitting between you and actual PyPI/npm/etc. As long as someone has pulled that version at some point before the internet goes out, it’ll continue to work after.

And this is exactly why we see noise on HN/Reddit when a supply-chain cyberattack breaks out, but no breach is ever reported. Enterprises are protected by internal mirroring.

Is there any package manager incapable of working offline?

> Is there any package manager incapable of working offline?

I think you've identified the problem here: package management and package distribution are two different problems. Both tools have possibilities for exploits, but if they are separate tools then the surface area is smaller.

I'm thinking that the package distribution tool maintains a local system cache of packages, using keys/webrings/whatever to verify provenance, while the package management tool allows pinning, minver/maxver, etc.

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

Well was Jobs a "doer"? Did he get his hands dirty on the code? Or did he use his employees how we would like to use LLMs?

> Well was Jobs a "doer"?

Jobs' talent was that he was an incredibly talented salesman.

Salespeople sell things that already exist. If you can envision new things that would sell well, that's a bit more than sales talent

> Salespeople sell things that already exist. If you can envision new things that would sell well, that's a bit more than sales talent

A lot of gadgets that were claimed by Steve Jobs to have been envisioned by Apple (or rather: by him) - as I wrote: Steve Jobs was an exceptional salesman - already existed before, just in a way that had a little bit more rough edges. These did not sell so well, because the companies did not have a marketing department that made people believe that what they sell is the next big thing.

Have you ever heard of Steve Jobs?

That wasn't too hard for him given he was also an incredibly talented market opportunity spotter and product leader.

Why do people write such nonsense?

Jobs envisioned the iPad and iPhone. Did he do the physical work? No. But he created direction.

Everyone around him at that time has commented on this. Are you going to claim they’re all lying?

> Jobs envisioned the iPad and iPhone. [...] Everyone around him at that time has commented on this. Are you going to claim they’re all lying?

I don't claim that they are all lying, but I do claim that quite some people fell for Apple's marketing (as I wrote: "Jobs' talent was that he was an incredibly talented salesman.").

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.