I think this is a really sober comment. There are lots of knock-on effects of this claim, even if it's not true which are consequential. The fact that a spokesperson for the US government is going out of their way to comment is concerning.
It's especially sad because on of the things those LLMs are best, almost purpose built for is to tell those students which books to go open, where to find nuggets people haven't bumped into for years, to make cross-connections that would take a PhD a decade to find.
My bona-fides here amount to little more than being a big time reader of non-fiction. But IMO, there's a nice synthesis here. Rather than going long rounds of asking LLMs about a subject, I usually end up asking it for book recommendations. It's much better than a google search and you can push it into some deep corners if you go past the surface level recs.
You can get quite specific. You can find texts you wouldn't discover unless you spent years studying the topic. Often these are completely approachable and give interesting perspectives they just get buried behind a wall of syllabi and listicles.
This is how I ended up reading Thompson's 'The Making of the English Working Class' and Graves' 'Goodbye to all That' among others.
Yeah, this is very much one of those stories where people from many different perspectives or chopping it up on a plate and ripping it through a straw.
I think the important lesson is to use clear eyes to evaluate what the rewrite buys you. I was on a team that rewrote a native code app in C#. We also had access to early cloud tech in the Azure stack, what is called queue now and then was called service bus.
These two technologies combined greatly simplified this specific product making it far easier to maintain. Performance on these services was not important so native code was carrying a lot of penalties without the benefits.
Having a well documented messenger like service bus with great SLAs removed several tools we had needed in the old implementation.
We were able to leverage the tests form the original product to define success and tmthus were able to solve a lot of the edge cases in the new code w before we even shipped.
However, the old code was perfectly fine code. If new technologies had not provided significant simplification of the service architecture, a rewrite would've been foolish. And without the very good previously existing tests, we would've run into a lot of issues as we released.
What do your tests look like. Because rewriting by hand and rewriting via AI have the same load bearing on whether or not your tests cover your scenarios and your integrations well.
Because there is more value in understanding someone else's ideas than as some kind of cultural favor? East Asians built empires, invented and discovered incredible things. They have developed elaborate artistic, musical and familial traditions. All of that is of course related to their cosmological ideas. If you could, why wouldn't you understand ideas that were integral to so much human activity? And if they fail to understand your culture in the same regard, that just puts you at an advantage.
In the words of my old man, "I'm not telling you what I know, cause then you'll know what I know plus what you know and then you'll know more than me!"
I don't think the intent of Robert Pirsig's work was to outline a git gud strategy cloaked in chillness. The book is heavily inspired by Eugen Herrigel's Zen in the Art of Archery which is explicitly not about trying to get good at something.
Both books highlight the value of dissolving conscious aim in favor of experience something. Pirsig's point isn't, you gotta act like a noob and then you can be good at maintaining motorcycles. His point was that there is a joy in losing yourself in these things that have to be done. If you are rushing to get it done or focusing too much on the end state, you will lose the joy and this thing will become a chore.
He does make the connection that years of doing things this way will lend you a kind of skill. And he connects the ideas to the Western concept of gumption which is a kind of motivation or persistence but again the book's core is not, lose yourself and you will get good. It's more like that a Western obsession with accomplishment can rob you of the joy that can come from engaging with activities for their own sake and not pushing through them just to get them done.
We're approaching the definition of magic here aren't we. And I think this is what really divides this discussion. There is one set of people who insist that things must be explainable. And if something is explainable, it yields to science and is no longer magic.
On the other side, you have people who insist that there are things which do not yield to science. So whether they admit it or not, they insist upon the existence of magic.
In fact, the definition of magic might as well be, that which does not yield to explanation. The only question once you believe in magic is, what alternative epistemology do you accept? Scripture? Tradition? Divine revelation?
But the sensation in a sense is a lie. Cold strictly speaking isn't real. And for much of human existence we spoke of it as if it was a substance due exactly to this specific sensatation.
I would caution outright categorizing this as paranoia stemming from a mental illness. The problem with delusional paranoia and justifiable paranoia is that clinically they can present the same.
> Just keep in mind all the dangerous people who these groups investigated that they did nothing about that went on to do bad stuff.
There are numerous people that America's intelligence agencies have intimidated, harassed and yes drugged for similar reasons.
OP, I hope you have been seen by a mental healthcare professional. They can help you determine the nature of these experiences. I hope you have extensively documented these experiences. Sharing that documentation with your family or others who you know to be sober in judgement is probably the only mechanism you have to distinguish if your experiences are based in reality.
LLMs have single handedly turned the hardest part of this job into entire job. The hardest part of this job is troubleshooting, maintaining and developing on top of an unfamiliar code base. That's not a new experience for anyone who has lived the production code life. One of the first production engineers I was tutored under used to love to say, "the code should tell you a story."
I love C. I came up on C. But C does not tell you a story. It tells you about the machine. It tells you how to keep the machine happy. It tells you how to translate problems into machine operations. It is hard to read. It takes serious effort to discern its intent.
I think any time you believe the codebase you're developing will have to be frequently modified by people unfamiliar with it, you should reach for a language which is both limiting and expressive. That is, the language states the code intent plainly in terms of the problem language and it allows a limited number of ways to do that. C#, Java (Kotlin) and maybe Python would be big votes from me.
And FYI, I came up on C. One of the first senior engineers I was tutored by in this biz loved to say, good code will tell you a story.
When you're living with a large, long lived codebase, essenti
I guess I'm very confused as to why just throwing an LLM at a problem like this is interesting. I can see how the LLM is great at decomposing user requests into commands. I had great success with this on a personal assistant project I helped prototype. The LLM did a great job of understanding user intent and even extracting parameters regarding the requested task.
But it seems pretty obvious to me that after decomposition and parameterization, coordination of a complex task would much better be handled by a classical AI algorithm like a planner. After all, even humans don't put into words every individual action which makes up a complex task. We do this more while first learning a task but if we had to do it for everything, we'd go insane.
https://twitter.com/DevlprSchmevlpr