The analogy doesn't work here ... In your scenario they are ok with using the bolt as long as the Chinese company promises to remove deliberate defects - which is of course absurd ... AND contradictory.
My comment was trying to suggest that some of these types of searches would allow you to link resources or works together because of how tightly coupled they'd be when you produced vectors from the metadata.
If product->quality_x, I'm okay with employee->?quality_x — but not with either employee->quality_x or employer->!quality_x. A better thing to remember is that people have themselves to feed. Of those 100k engineers, how many can say "no, you don't, Satya, ain't no besmirching my code with slop"?
Lots of interesting ways to spin this. I was in a computer science course in the late 90s and we were not allowed to use the C++ standard library because it made you a "lazy programmer" according to the instructor. I'm not sure if I agree with that, but the way that I look at it is that computer science all about abstraction, and it seems to me that AI, generative pair programming, vibe coding or what ever you want to call it is just another level of abstraction. I think what is probably more important is to learn what are and are not good programming and project structures and use AI to abstract the boilerplate,. scaffolding, etc so that you can avoid foot guns early on in your development cycle.
The counterargument here is that there is a distinction between an arbitrary line in the sand (C++ stdlb is bad) and using a text-generating machine to perform work for you, beginning to end. You are correct that as a responsibly used tool, LLMs offer exceptional utility and value. Though keep in sight the laziness of humans who focus on the immediate end result over the long-term consequences.
It's the difference between the employee who copy-pastes all of their email bodies from ChatGPT versus the one who writes a full draft themselves and then asks an LLM for constructive feedback. One develops skills while the other atrophies.
That's why it's so important to teach how to use them properly instead of demonizing them. Let's be realistic, they are not going to disappear and students and workers are not stopping using them.
Uh, correct me if I'm wrong, but aren't bash and GNU tools ALSO code? They're ROCK SOLID, battle tested, well understood APIs for performimg actions, including running other CLIs, and any OTHER code it's written. It makes the the MOST sense for the agent to live at that level!
This was my first thought as well, I found the examples of `ls` and `grep` amusing in this context.
I think the author's point is: instead of exposing `grep`/`head`/`awk` as their own distinct tools, expose a single tool for writing the language. They chose Python but one could just as easily choose bash.
I think the point is being able revert to the initial state, and to have a single step between the initial state and final state. It’s hard to rollback a series of tool calls, and your search for a solution continues at every step. With a “code only” agent, the goal is to get to the final state in a single step, and you can keep reverting state and modifying the code until you get there. You can’t do that with a series of tool calls.
reply