Even Google itself is now just asking AI. Usually the AI summary Google returns is more useful than the links. I get really annoyed when I query something and no AI summary is given as the links it returns these days are trash.
It’s interesting that people claimed the exact same thing when computers were being introduced to the work place int the 80s and 90s. Lots of papers showing how productivity didn’t go up at all and using a paper and pen seems to be just as efficient as using a PC.
Even in the 19th century, when electricity became widely available, there was no productivity gain for 30 years at least. This is a well understood phenomenon.
Ah you must be referring to this off the cuff comment by Robert Solow in a book review: "You can see the computer age everywhere but in the productivity statistics" (1987)
It's an interesting question and very much not resolved. It indeed led to a flurry of studies in the 1990s, and more recently to several updates and meta-analyses.
The problem of "does computer technology investment causes increased productivity" is an interesting issue in economics and statistics. It is far from clear that the (immense) investment in computers over the past several decades has caused a corresponding excess growth in productivity.
Some of the literature published after 2015 that I have read on this topic:
"Information technology (IT) productivity paradox in the 21st century"
> Thus we are still unable to confirm or reject the existence of an IT
productivity paradox
"Benchmarking the IT productivity paradox: Recent evidence from the manufacturing sector"
(This one was published in 2006 but I find it relevant because it does a very well scoped analysis in manufacturing firms thus addressing the oft-mentioned argument that computer technology may leverage task productivity in a way that is hard to measure in aggregate)
> However, many scholars from both sides of the IT paradox debate agree that difficulty still exists in specifying how to assess the IT contribution, and the availability of reliable data sets
> Regardless of the final decision to differentiate or conform, our results make a compelling argument that more spending does not necessarily mean better IT productivity.
"Lessons from three decades of IT productivity research: towards a better understanding of IT‑induced productivity effects"
(This is one of the most inclined to disagree with the existence of the paradox, and still very cautious in the language used for writing the conclusion, e.g.:)
> But to not at least consider the ongoing technological change as an important determinant of the deceleration in productivity growth seems ill-advised."
(This I'm quoting from the submitted manuscript. I haven't gotten around to reading the published version yet, but:)
> Since the size of the effect helps make the right decision in business-related investments, our result of ICT elasticity being very close to zero with values, about 0.3% for productivity and no effect on profitability, supports the argument that there are better forms of investment to be made
Without tools LLMs can do nothing more than emit text. You are probably assuming a harness is provided to the LLM with shell access but that is absolutely not necessary for LLM usage depending on the use case. For interesting stuff, you do want to provide some tools, but nothing with the power of a terminal if you are worried about security. A MCP server is perfect to securely provide the LLM with some controlled power exactly because it can do nothing at all other than call tools that go through the MCP server and can therefore be scrutinized, audited and ensure credentials are not visible to the LLM.
They have a UI which is pretty good! That explains why JS , they can run that in Electron and in TUI. I only use the UI now since it is do damn useful with its management of worktrees and multiple sessions, including ones running remotely via ssh devcontainers.
I would think that with agentic coding they’d be able to have a shared core and an interface native to the system, I.e. not react in the terminal and a swift or C# front end for the desktop app
They have a feature where they open a browser right in the app for Claude to use! They also use browser rendering for displaying various graphical formats. For once an Electron app that can actually justify shipping a whole browser in it.
Bob also knows how to quickly check things with a little bash scripting and tests. Can quickly switch branches to confirm regressions and consult documentation if something requires more information. His twin can also quickly scan for all the common security vulnerabilities in any code, and will do it without complaining as many times as you want him to.
I’ve come to trust Bob with code more than any human.
Yep! We run security reviews on our pull requests now and are shocked at how it stops a lot of vulnerabilities being shipped. We've had a couple of high score CVEs from the before-LLM times, and when the AI reviews the code that introduced the CVEs, it easily picks them up. We had 2 humans reviewing every PR, and both missed the issues. It's far too easy to miss security issues when you manually review them, but LLMs are exceptionally good at finding them. Unfortunately for me, I admit, I just can't get myself to push code anymore without an LLM checking my work (or writing much of it when I'm at work, I try to write code by hand in my own time to make sure I don't rust away, but at work there's no way to justify doing it the "slow" way anymore).
You just misinterpreted what NSArray is. It’s not an immutable type, it’s a read-only type. As others already mentioned that’s different things. If you have a read-only variable and exclusive access to it, then you can rely on immutability as well. This is what Rust has, for example. Many languages use this definition as well as it’s much more useful than having some sort of pure immutable type guarantee (which some languages do have with const).
Another language that uses this is Kotlin: List is a read-only type. MutableList is a subtype of List. You can get a “const” List by only keeping a reference to the value via a List binding. This can be worked around via casting and reflection, but even in Haskell you can do unsafe things that mutate a immutable value, so I don’t think that undermines the idea.
reply