When I’m using AI for coding, I find myself constantly making little risk assessments about whether to trust the AI, how much to trust it, and how much work I need to put into the verification of the results. And the more experience I get with using AI, the more honed and intuitive these assessments become.
For a system that has such high cost (to the environment, to the vendor, to the end user in the form of subscription), that's a damningly low level of reliability.
If my traditional code editor's code completion feature is even 0.001% unreliable – say it emits a name that just isn't in my code base – that feature is broken and needs to be fixed. If I have to start doubting whether the feature works every time I use it, that's not an acceptable tool to rely on.
Why would we accept far worse reliability in a tool that consumes gargantuan amounts of power, water, political effort, and comes with a high subscription fee?
Revenue going up, hiring going down, layoffs every quarter and a big push for everyone to use AI. But at the same time basically no real success story from all this increased AI usage. Probably just me, but I just don’t get it.
No, you've got it: Revenue increases, short term, when personnel costs are cut, through layoffs and hiring freezes.
The story told (“workers must return to the office to sit on teleconference all day” prompting more of them to quit, or “your job can be done by robots”, or whatever) only needs to make enough sense that the stock holders are satisfied the executives have a sane explanation for sudden loss of workers. Otherwise it might look like the executives are panicking!
Stop trying to trap people inside “the app”. If “the app” is designed to keep people inside and not visit other sites, that's a reader-hostile pattern and a publisher-hostile pattern.
The founding model of using Reddit is “the front page of the internet”. That requires that the rest of the internet is still there, not that the rest of the internet gets sucked into Reddit.
Now we are beginning to see agents: systems that aspire to greater autonomy and can work in “teams” or use tools to accomplish complex tasks.
Given that an “agent” can be assigned work and carry it out autonomously: no, we are not yet seeing any agents. Every one of these bots requires close attention by a human to weed out the huge quantity of mistakes it generates. That's not an “agent” by any useful definition:
Both Anthropic and OpenAI, for example, prescribe active human supervision to minimise errors and risks.
Right. So, it's a bot which even the vendor recommends you don't leave it to work autonomously. Not an agent.
In other news: “self driving” that requires continuous human monitoring and intervention, by multiple humans per vehicle, is not self driving.
Just because the hype marketing of tech corporations bleats a term into the media, does not mean they've got anything that actually does what they say it does.
Except worse: Confluence tries insanely hard to prevent anyone actually getting at the document source code. So you are expected to use the godawful interactive web editor to make any changes.
Despite their great value to society, open source projects are frequently understaffed and underresourced.
That’s why GitHub has been advocating for a stronger focus on supporting, rather than regulating, open source projects.
What nice sentiments. Perhaps you, GitHub, could start by insisting that Microsoft cease the un-attributed, non-consensual shovelling of open-source software into their LLM training maw. And turn off the LLM that they're attempting to unilaterally sell based on all that uncompensated labour.
Or is your platitude of “supporting open source projects” fall short of actually respecting what we want and need?
a marketing term that is used to sprinkle some magic fairy dust that brings the venture capital dollars.
Like “metaverse” before it. And “blockchain” before that.
Whatever magic phrase will unlock the purse strings of those who control the money, know nothing about where to invest it, and expect unreasonable monopoly returns.
As others have said: the content is likely to be only of historical interest, because the fields they describe have progressed in understanding a great deal in the intervening decades. As a result, many, many historical books are of effectively negligible interest today.
With that said, historical interest can sometimes be a lot: and those two seem to be from institutions which did seminal work (Rand Corporation, for example).
Magit, which is the best Git porcelain around. Git, because it has an unparalleled free-software ecosystem of developer tools that work with it.
Why is Git's free-software ecosystem so much better than all the other VCSen?
Largely because of marketing (the maker of Linux made this! hey look, GitHub!), but also because it has a solid internal data model that quickly proved to experts that it is fast and flexible and reliable.
Git's command-line interface is atrocious compared to contemporary DVCSen. This was seen originally as no problem because Git developers intentionally released it as the “plumbing” for a VCS, intending that other motivated projects would create various VCS “porcelain” for various user audiences. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain The interface with sensible operations and coherent interface language, resides in that “porcelain”, which the Git developers explicitly said they were not focussed on creating.
But, of course, the “plumbing” command line interface itself immediately became the primary way people were told to use Git, and the “porcelain” applications had much slower development and nowhere near the universal recognition of Git. So either people didn't learn Git (learning only a couple of operations in a web app, for example), or to learn Git they were required to use the dreadful user-hostile default “plumbing” commands. It became cemented as the primary way to learn Git for many years.
I was a holdout with Bazaar VCS for quite a while, because its command-line interface dealt in coherent user-facing language and consistent commands and options. It was deliberately designed to first have a good command-line UI, and make a solid DVCS under that. Which it did, quite well; but it was no match for the market forces behind Git.
Well, eventually I found that Magit is the best porcelain for Git, and now I have my favourite VCS.
Maybe closed source organizations are more willing to accept slop code that is bad but can barely work versus open source which won’t?
Because most software is internal to the organisation (therefore closed by definition) and never gets compared or used outside that organisation: Yes, I think that when that software barely works, it is taken as good enough and there's no incentive to put more effort to improve it.
My past year (and more) of programming business-internal applications have been characterised by upper management imperatives to “use Generative AI, and we expect that to make you nerd faster” without any effort spent to figure out whether there is any net improvement in the result.
Certainly there's no effort spent to determine whether it's a net drain on our time and on the quality of the result. Which everyone on our teams can see is the case. But we are pressured to continue using it anyway.
Please either update the post with the URL that gets around this login-wall; or, remove the post because the article is not on the public web.