I think you are putting the cart before the horse: the code was written intentionally, i.e. someone first had a thought, and then fleshed it out in the code (and maybe had forgotten all about it the minute later).
When LLM generates code, it also has a "thought process" of sorts. But it's very different from the one humans use. An LLM generating code may pretend to have a thought process similar to humans (when asked to elaborate on the reasons the code is this way or the other), but, fundamentally, it's going to be a lie, because the real reasons this LLM created the code in a particular way is very different, and is very hard to grasp for a human, even if they are familiar with the problem (there were some attempts at explaining LLMs "thinking" that would end up looking like heatmaps and other weird things that are useful for debugging them).
Imagine that instead of a stack trace, the program you are debugging spits out only the memory dump with values in registers etc. (the gibberish-looking part of the coredump file). You'd be in a similar situation receiving the "true" explanation from an LLM generating your code.
My very recent story with libvirt and secureboot resulted in blanket disabling of secureboot as part of the preparation for creation of VMs.
The reason: the VM refuses to boot when provided with an ISO (via virtual CDROM) with a meaningless error (permission denied: go figure out what permission and why was it denied and by whom).
Secureboot is meaningless / useless for most people running VMs, be it on own or rented hardware. It takes some pain and extra work to get it to work sometimes, and a huge amount of work to get it to work always. I doubt anyone was dedicated enough to get it to work always. So, I believe you are right. This is extremely unlikely to be a problem for anyone running Linux VMs, and the more VMs they need to run, the less likely it is a problem.
Oh, I've worked in more than a dozen of software companies. When it comes to planning activities and setting goals, I've rarely seen a lot of sense.
I mean, we are in the industry where it used to be a standard practice, not so long ago, to deliver daily reports about one's activities while "planking", or throwing a beach ball to another person doing some silly acrobatics...
It should come as no surprise that there's no rigorous assessment protocol for these kinds of things anywhere. Retrospectively, I will admit, that enormous amount of effort and resources are wasted due to bad planning. But it's still not done.
I can imagine that with the field becoming more competitive, eventually, the industry specialists will come together and try to address the problem, but so far and for so long the resources just kept flowing in, the huge waste wasn't really a problem.
A lot of programmers naively believe that tests prove that the program works... Even though this has been repeated over and over again: tests can only prove that the program isn't broken in some specific way.
When there's a person in the loop, you know that the program was written intentionally. It can still be wrong, but if you were to ask the author why they wrote this or another part of the program, they'd have an explanation ready. When you interact with LLM, it can generate an explanation, but, fundamentally, it doesn't work in the same way the flesh-and-blood programmer does. It doesn't really have an explanation. LLM can be right 99 times out of 100, where a human undertaking the same task might be right only 90 times out of 100, but the inability to find that 1 wrong case is scary.
LLMs and live programmers make mistakes in different ways. You, the tester, can re-trace the thought process of a live programmer and detect errors where your outcomes don't match the outcomes produced by another programmer. You, however, cannot have the same though process as an LLM... that's physically impossible. So, once it's wrong, you are on a wild goose hunt after the error.
Not the author, but as someone who frequently has to answer this question, I'll chip in:
A mistake is a mistake, whether you have a way to reproduce it right now or not. It's pretty much a given that whatever means you have right now to reproduce the problem will evolve and broaden the scope. Also, if you haven't found a way to reproduce the problem, it doesn't mean it doesn't exist: it takes a lot more effort to prove that it's impossible to reproduce than to simply not being able to reproduce the problem.
Here's about the Israeli PM, and why he's allowed not to wear a tie:
> One day, Netanyahu shows up to the Knesset not wearing a tie. The speaker then reminds him about the decorum, to which Netanyahu replies that the queen of England allowed him not to wear one. The speaker then inquires about the circumstances, to which Netanyahu replies that he didn't wear a tie to Buckingham either, and that the queen told him "perhaps back in Israel, you might not wear a tie, but you must remember to wear one here."
In other words, Netanyahu is, by no means an example of what anyone would consider to be "classy". He's not the worst example, but he certainly fits the stereotype of obnoxious, loud, poorly dressed and otherwise poorly mannered.
> No, I don't think so, why would it?
Absolutely. It's kind of ridiculous to watch a typical Israeli recruit struggle with it. There's a practical reason for it: you have to speak clearly when you are on comms, and nobody can you see swing your hands to explain yourself. But, military being military, this is just a rule that's applied to everyone. Another reason is that you have to stand at attention ("amod be dom matuakh") when you are talking to an officer. Again, this applies to basic training ("tironut") only, since during your regular service you rarely stand at attention in general, let alone when talking to an officer.
Well, I lived in Petakh Tikva and met some people who lived there before 1948. There are still some patches of land (eg. behind Belinson) that used to be in Turkish possession, then were bought by Keren Kayemet le-Israel, and then kinda went nowhere. That one looks like it used to be an... orange orchard (is it what it's called? the orange tree plantation?). Anyways, growing oranges was a very common agricultural activity in that general area. Not really done by the nomads. There's also a park, if you go from Ramat Gan around Bney Brak in the direction of Petakh Tikva, and it has an old mill that used to belong to some Arab family (that whole place used to be an Arab village before 1948). Now it's a museum of sorts.
Petakh Tikva is also commonly called "Em ha-Moshavot" (mother of settlements) because it was one of the first, if not the first settlement by Jewish immigrants. It was very much the pilot in terms of how Jews were trying to get a hold of any plot of land they could and entrench there, including the tactics I described earlier. Of course, this wasn't the only tactics, and it wasn't necessary hostile to the locals. Another tactics that is well-known around that time is called "homah u-migdal" (wall and tower), which refers to the fact that having a wall and a tower was a necessary prerequisite for a place to be considered a settlement (for the purpose of drawing maps), and so Jews, esp. the Solel-Boneh (a well-known today construction company) would invest into building these sorts of "settlements" to claim more territory.
I'm not saying that the expulsion of Arab fellakhin from their peasant jobs was the reason for the confrontation. But it certainly contributed. And it certainly happened. While even to this day there are nomadic tribes in Israel and the occupied territories, none of them are Arabic (they are Bedouin). There are plenty of Arabic agricultural communities, and many of them can be traced back more than a hundred years. For instance, the Jaffa Oranges you might associate today with Israel (they are a popular export good and found in a lot of Western supermarkets) were actually bread by Arab farmers living around Jaffa (south of modern day Tel Aviv).
> jobs programs and helicopter money where people get paid to do nothing to keep the economy humming.
The article addresses your concerns already. I know it's long, but you could probably skip a few paragraphs in the middle and start here:
> Piketty, no conservative, has argued that UBI fails to address root structural problems: “unequal access to education and health, low-paying and low-productivity jobs, malfunctioning markets, corruption, and regressive tax systems.” David Shor’s polling data bears this out from the other direction: UBI is unpopular with American voters; a federal jobs guarantee has legs. People don’t want a check. They want work. They want purpose.
But this doesn't summarize the argument, it's just where you need to start reading.
If I try to summarize the argument, it says that jobs are a bargaining chip in the hands of laborers (the largest fraction of our society). Currently, they use it to secure certain freedoms and benefits. If, however, they no longer have jobs, whoever gets the role of distributor of the wealth produced by the AI will not be compelled to distribute it fairly... well, the whole concept of fairness will have to be reinvented (because, roughly, now we base fairness on individual's contribution, but that's not going to work anymore). But, most likely, it will lead to a dictatorship of those with access to AI over those who have none.
* * *
Here's my (unrelated to the article) historical parallel. In the beginning of the 20th century when Jews started campaigning for bringing more Jews into Turkish, then British Palestine, the process often went like this: Jewish community or a wealthy individual buys a plot of land from a Turk owner. Turks never worked that land themselves, and used to hire local Arabs to do the agricultural labor. Jews would not rehire Arabs after acquisition, instead, they used the newly bought land to create jobs for more Jewish immigrants.
This greatly contributed to the animosity between Jews and Arabs in Palestine because even though initially Arabs would be paid off to "go someplace else" after the land purchase, realistically, there was no other place for them to go to. Which led to spreading poverty, which led to sporadic attacks on new land owners. Which led to retaliation... and well, the conflict never really went away, didn't it?
This just might happen on a much larger scale in countries like the US, if suddenly a large fraction of population finds itself powerless and being unable to influence the decisions of the government.
The goal of having a job isn't happiness. At least not immediately. The goal is to have something to bargain with: employees offer labor, employers buy it. If employees don't deliver, they get fired, if employers don't deliver, employees leave / strike. This is what keeps system in a semblance of balance. But once would-be employees can be employees no more, they have no way of influencing any aspect of their governance. Not economical, not political, not military, not ethical.
In other words, people need jobs to try to secure their place in the world on multiple levels. It's not about socializing at work, at least, that factor is absolutely not a priority.
Well, it's the same problem with all sorts of free-market capitalism and derivatives. They all believe there's infinite "somewhere else" that resources can come from, or the customers, or the funding etc. But reality is very much finite. And so instead of the theoretical equilibrium we get monopolies and collusion to manipulate markets.
The article, actually, addresses your claims:
> The optimists will tell you this is just productivity gains. The economy has absorbed automation before; agricultural employment collapsed from ninety percent of the American workforce to two percent and civilization continued. David Autor at MIT has shown that roughly sixty percent of today’s jobs didn’t exist in 1940. New technologies create new categories of work. True. But there’s a difference between an observation about the past and a law of nature, and the optimists consistently confuse the two. The agricultural transition took a hundred and forty years. Carl Benedikt Frey at Oxford has documented that the Industrial Revolution took seventy years before wages and employment recovered for the workers it displaced. In the interim, wages stagnated, the labor share of income collapsed, profits surged, inequality skyrocketed, and the political consequences included the Chartist movement and widespread social upheaval. As Frey puts it: “Most economists will acknowledge that technological progress can cause some adjustment problems in the short run. What is rarely noted is that the short run can be a lifetime.”
So, the author believes that the problem with your reasoning that it will take a long time for the niches you are talking about to be filled (lifetime, maybe more), meanwhile things will look quite bad for most those involved.
I am even less optimistic than the author. The new aspect of this workforce displacement is the centralization. Of course, previous advances in automation also caused a degree of centralization, but AI is posed to become super-centralized if you will. There will be just a handful of suppliers and nobody will be able to challenge them, similar to situation we have with microprocessors today. Needless to say this is absolutely not a healthy situation for the world's economy.
Well, where I work, "automation" is part of my job title. And if I ever even suggest that I've done some work outside of the tasks assigned to me that has something to do with my job, I'd be sent into disciplinary hearing. Any work I do for the company must be sanctioned by my boss, otherwise it's treated as dereliction of duty (under the pretext, that I should've been using that time to work on my tasks given me by my boss, or, if I had no such tasks, I should've informed my boss about the situation).
And, in my specific case, my boss is not very good at programming, and doesn't like anything I do on that count. So, anything I've done so far was mired in pointless PR reviews and discussions, stalled for many months or simply never made it after more than a year of PRs waiting. Ironically, my boss had to order the cancellation of some CI tests because he didn't accept my PR fixing those tests. And it's been like that for something like three years now.
I wish this situation was exceptional, but it happened more than once, and, by far, I'm not the only one experiencing this. That's what I mean by "initiative is punishable."
It was drilled into me since childhood that speaking with your hands is lacking "class". On a conscious level, I know not to judge people by something as superficial, but on subconscious level, if someone is swinging their hands in the air while talking to me: I don't want to talk to them. It's the same with being loud, or using stop words etc.
I haven't been to Italy, but this was a huge deal for me living in Israel. In Israel, it's a substantial cultural divide between descendants of Arab countries refugees and those coming from Europe. It's generally seen as "proper" to not use your hands. In the military, especially in basic training, that would probably send you doing pushups.
I live in the Netherlands for about five years now. To be honest, I didn't notice people talking with their hands... well, outside of the Middle East or North African immigrants. Also, I don't really have Dutch friends to the point that we'd spend enough time together for me to notice how and if they use their hands during a conversation. In more formal context, I don't see the Dutch doing that.
I absolutely don't see these as benefits... Living in the Netherlands, apartments owners typically have to pay "VVE" (service fee for the ongoing upkeep of the building where your apartment is), while house owners typically pay out of their pocket for any repairs they have to do.
This was my first time living in a house as opposed to an apartment. It's been three years of bitter regret, and I'm very eager to sell the damn thing and leave the nightmare behind. In the last three years, I had to re-paint the roof, replace the garden fence and a bunch of related stuff in the garden, replace the water boiler. I had to climb on the roof of the house to rake the leaves at least twice a year (not expensive, just scary). I had to repaint areas of the house because the previous owner did a crappy job painting them.
But, most importantly, it's a piece of junk. It's a typical front brick wall with the rest of the house made of wood covered in dry wall. Its foundation is going to skew and sink because... that's the general condition of everything in the Netherlands: the ground water is too close to the surface, so the foundation is too shallow. I can't hang anything heavy on the wall because the wall can't support it. Every wall is crooked and bent and so is the ceiling, so, for example, it's not possible to put a curtain railing on the ceiling...
Everything is made of perishable materials which will last five to ten years tops, and then everything needs to be torn down and redone. Looking at how my neighbors are spending their lives on the hamster wheel of infinite repairs... I want absolutely none of this. Some people enjoy sinking their time and finances into this black hole, but I'd rather just buy hard drugs for the same price all the way until I die. It's just an arduous and unrewarding toil.
I think sleep serves multiple functions. For example, anyone who works out in any-what systematic way knows that sleep is essential for muscle grow. You can't skip on sleep if you want to get fitter. And this probably has very little to do with the more sophisticated functionality of the brain, rather it allows for some process in muscle tissue to happen.
So, whether the LLM "dies" in any sense may or may not be important for what "sleep" is defined to be in this article. It's quite possible that sleep also affects endocrine system in animals or hormones etc... and that's what's causing death, not necessarily anything to do with how brain functions.
* "Corporate hackers" is a... not a very common thing. In the corporate world most programmers do what they are told to do and nothing more. Initiative is punishable.
* API wrappers aren't actually good. Not to mention that the API itself is very poor. JIRA has a tradition of arbitrary changing things, especially removing things, or not exposing the useful functionality. It's not a well-designed or well-executed product.
* AI is too immature and too non-deterministic to be useful for most of the things you want from a bug tracker. Also, for most companies, it's going to be too expensive to do it this way.
* QA is usually an afterthought, unless... we are talking about budget cuts and cutting corners, then it's left, right and center. Most companies see QA as a liability. They don't see it as producing value. They just have to pretend to have QA so that they can tell their customer they have it. When it comes to making QA do meaningful things, that require hiring good engineers, allocating development time, allocating compute resources... well, good luck with all that! Most QA I've seen, especially in international huge corporations was all for show, to produce appearance of work while following the same, mostly useless and mostly manual process.
I had a bunch of ideas about how QA can be made more efficient, both in terms of resource use and in terms of problem space it tries to address. Doing things like RCA automation or exploratory dynamic* testing... and after trying to see if any of such ideas would have any luck of becoming an actual successful product, I realized that nobody wants to improve QA. If a product made the "certification" (the ability to claim to have tested the product) cheaper, then it could be viable... but this is neither the direction I wanted to go, nor is it really all that feasible to improve a bug tracker in this direction.
----
* What I mean by exploratory testing is a sort of "fuzzing", however one that's more structured. Fuzzing, typically, is applied to the input, which then tries to explore all possible ways through the program under test. Exploratory testing is a test made up of modules that can be combined to produce longer tests. This addresses the problem of difficult to reach "corner" cases in the program, also the problem of reaching code paths that aren't directly (or at all) dependent on input.
While NaCL and Silverlight were both alternatives to Flash...
All these people in comments beating their chests about how WebAssembly is totally good for everything you can imagine, and there's not a single browser game that is not a tic-tac-toe level.
Please, read what you quoted to the end. The answer is right there.
Anyways. Here are examples to the contrary: cars and driving. Somehow, collectively, we realized that driving requires learning the tools to a minimal proficiency level. This doesn't prevent anyone from driving a car w/o a license (a document certifying one's learned the tools), but it puts the blame for a certain category of accidents on the driver, thus making it unnecessary to demand absolute road safety from car manufacturers.
What if we treated computers more like cars? Perhaps, in a situation like this, products s.a. VSCode wouldn't even exist in the same way how there aren't cars that don't come equipped with safety belts?
Right now, parent suggests, metaphorically, to equip cars with a system that plans the route in advance, has a required number of passengers for each planned trip and won't even open the doors unless the car reaches its destination. This is what "explicit permission system" is to a computer user lucky enough to have avoided most of the MS / Google / Apple and Co products.
Before I say anything: I don't use VSCode and have no intention of doing so. Most of my experience is gained vicariously, through working with or helping someone else who does.
I use Emacs for my day-to-day stuff. I don't think Emacs extensions are more secure by design. Pretty sure that, if I wanted to, I could craft an extension that does bad things. I'm not sure how hard it would've been to sneak it past MELPA or (is there really anything else people are using these days? Used to be Marmalade, but I think it's gone), but, it's people, and people make mistakes, so, there's some % chance that a bad extension can be inserted there. Such security problems happen to a lesser extent (if at all?) in the Emacs world because of the size of the user base. It's simply impractical to target a small community, as it's always a numbers game.
Very unwillingly, and with a lot of contempt, I use Android, where this "explicit permissions system" you speak of exists. There are many reasons to hate Android, and the "explicit permissions system" is a prominent member in that collective.
Companies like MS, Google etc. always default to this way of solving their security issues: by restricting their users from doing useful things. They model their users as a herd of brainless lemmings who must be herded with an iron fist in order for them not to plunge to their deaths (yes, I know, real-life lemmings don't do that, but we all know the metaphor). And this tactics is so common that the MS-lemmings learn to yearn for it.
The solution I want to see to this and similar problems is two-fold:
1. Users learn to use their tools.
2. Users learn to treat important information on their computers in a more defensive way, if they open the door for outside, potentially bad, software providers.
This is, of course, a pie in the sky sort of wish... But, imagine it was achievable, wouldn't the world be a better place? Now, I believe it's possible to approach these goals gradually, and it would still be better than a system imposed by the software provider that prevents users from doing useful things.
For example, Emacs has a mechanism to prompt users when attempting to use a particular functionality. Some of it is because the functionality can be surprising for the novice, some of it is because it could be dangerous from the security standpoint. So, in principle, VSCode could do that too. Eg. a user would have to interactively grant its extensions permissions to call whatever functionality within the editor, while some "dangerous" functionality would have to be removed from the JavaScript runtime available to VSCode and only made available in this interactive way (eg. when JavaScript code in VSCode extensions wants to call exec() or similar, it would have to call an overloaded exec() provided by VSCode, that would inform the user that such-and-such extension wishes to run such-and-such command, and that it needs their permission to do it).
I used Prolog twice in production, but none of them were what I'd expect to be the "typical" uses.
1. I used GoLog (a Prolog interpreted in Go) for defining some functional tests in the project where the testing infrastructure was otherwise written in Go.
2. I used Prolog (SWI) to write a parser for Thrift (both the definition and binary format) simply because I needed one, and Prolog was convenient.
What I expect people who use Prolog for the stuff it's really good at is databases that encode some complicated business or legal processes. I.e. databases with many complex constraints that have to all somehow come together to produce a solution set. Prolog would also be a good language to encode / query graph databases. So, whatever you can think of being a good match for a graph database would also work well with Prolog.
There are also (even more niche) Prolog derivatives, eg. Ciao or Mercury, that are... well, decent all-purpose languages. You can just use them in the same context where you'd use Python or Haskell respectively. The implementations are pretty solid in terms of performance and correctness... so, if you like the approach, then why not?
Out of things listed there, I see some as positives rather than negatives, but, specifically, wanted to reflect on:
> No non-developer UI for project managers to see or comment on issues.
Strategically, I'd prefer this over anything that offers non-developer UI. My experience with any tool that offers non-developer UI for developer-related activities was overall infuriatingly negative (think Jenkins, JIRA, Github and the likes etc.) Because these UIs will usually expose the underlying functionality in a bad way that will create pathologically bad practices that will require the developers to accommodate the lowest common denominator.
Here's one example: Github or GitLab PR management interface. Before this became "standard practice", PRs used to be deal with from the interface to Git chosen by the developer. It allowed more freedom of editing and communication, but, most importantly, it didn't lock the developers into a few selected choices of reconciling the new changes with the existing code.
GitLab, for example, doesn't even offer the only good way to do that: there's no way, using GitLab interface to rebase the suggested changes on the target branch. All the options it offers in UI are wrong. And yet, companies, like the one I work for, make it a corporate policy to work exclusively through this garbage UI because they make their OPs / IT teams design workflows around it.
As an aside: if a project manager cannot use Git, they shouldn't be a project manager. There are some job requirements that one must meet in order to hold a job, and using the most popular VCS should be one of them. This is just as true as it is true for developers: if they don't know / can't use Git, they shouldn't be in that role. The manager's ineptitude shouldn't be an excuse to make / adopt cruddy software.
When LLM generates code, it also has a "thought process" of sorts. But it's very different from the one humans use. An LLM generating code may pretend to have a thought process similar to humans (when asked to elaborate on the reasons the code is this way or the other), but, fundamentally, it's going to be a lie, because the real reasons this LLM created the code in a particular way is very different, and is very hard to grasp for a human, even if they are familiar with the problem (there were some attempts at explaining LLMs "thinking" that would end up looking like heatmaps and other weird things that are useful for debugging them).
Imagine that instead of a stack trace, the program you are debugging spits out only the memory dump with values in registers etc. (the gibberish-looking part of the coredump file). You'd be in a similar situation receiving the "true" explanation from an LLM generating your code.