I feel this. I've had a few tasks now where in honest retrospect I find myself asking "did that really speed me up". Its a bit demoralising cause not only do you waste time, you have a worse mental model of the resulting code and feel less sense of ownership over the result.
Brainstorming, ideation and small, well defined tasks where I can quickly vet the solution : these feel like the sweet spot for current frontier model capabilities.
(Unless you are pumping out some sloppy React SPA that you don't care about anything except get it working as fast as possible - fine, get Claude code to one shot it)
I've found a pretty good speed up just letting Claude Code run with a custom prompt to gather the context (relevant files, types, etc..) for the task then having it put together a document with that context.
It takes all of five minutes to have it run and at the end I can review it, if it's small ask it to execute, and if it actually requires me to work it myself well now I have a reference with line numbers, some comments on how the system appears to work, what the intent is, areas of interest, etc..
I also rely heavily on the sequential thinking MCP server to give it more structure.
Edit:
I will say because I think it's important I've been a senior dev for a while now, a lot of my job _is_ reviewing other people's pull requests. I don't find it hard or tedious at all.
Honestly it's a lot easier to review a few small "PRs" as the agent works than some of the giant PRs I'd get from team members before.
> I've been a senior dev for a while now, a lot of my job _is_ reviewing other people's pull requests
I kind of hate that I'm saying this, but I'm sort of similar and one thing I really like is having zero guilt about trashing the LLM's code. So often people are submitting something and the code is OK but just pervasively not quite how I like it. Some staff will engage in micro arguments about things rather than just doing them how I want and it's just tiring. Then LLMs are really good at explaining why they did stuff (or simulating that) as well. LLMs will enthusiastically redo something and then help adjust their own AGENTS.md file to align better in the future.
if the benefit is less than 2x then we're talking about AI assisted coding as being a very, very expensive IntelliSense. 1.x improvement just isn't much. My mind goes back to that study showing engineers claimed a 20% improvement and measured 20% reduction in productivity -- this is all encouraging me to just keep using traditional tools.
The only AI-assisted software work I've seen actually have a benefit is the way my coworker use Supermaven, where it's basically Intellisense but suggesting filling in the function parameters for you as well. He'll type `MergeEx` and it will not just suggest `MergeExample(` as Intellisense would have done, but also suggest `MergeExample(oldExample, newExample, mergeOptions)` based on the variable names in scope at the moment and which ones line up with the types. Then he presses Tab and moves on, saving 10-15 seconds of typing. Repeat that multiple times through the day and it might be a 10% improvement, with no time lost on fiddling with prompts to get the AI to correct its mistakes. (Here, if the suggestion is wrong, he just ignores it and keeps typing, and the second he types a character that wasn't the next one in the suggestion it goes away and a new suggestion might be calculated, but the cognitive load in ignoring the incorrect suggestion is minimal).
I've found it to be insanely productive when doing framework-based web development (currently working with Django), I would say it's an easy 5-10x improvement in productivity there, but I still need to keep a somewhat close eye on it. It's not nearly as productive in my home grown stuff, it can be kind of annoying actually.
I recently made the shift to graphene from iOS and am mostly enjoying it.
The user profiles was slow to set up and not having shared filesystem between the user profiles creates friction. But I love that I can effectively sandbox my work apps, sandbox the Zuck apps etc, with different VPN profiles for each user.
Getting a burner google account (for gplay services) is a PITA if you are determined to get a clean slate from Googles tracking. Gplay is the only safe way to get certain apps at the moment, and make certain apps pass the device integrity checks.
I suspect one of the biggest barriers to mass adoption will be the fact that tap to pay doesn't work. IIUC apple/google pay are generally considered a privacy and security improvement over physical cards, since you don't give every merchant your actual card number.
Overall love the project and really nice to see such high quality open source software.
> The user profiles was slow to set up and not having shared filesystem between the user profiles creates friction. But I love that I can effectively sandbox my work apps, sandbox the Zuck apps etc, with different VPN profiles for each user.
It's worth noting this is a standard Android feature along with work profiles and Private Space which are nested in another user. Private Space has built-in sharing functionality and work profiles can have it via the management app.
GrapheneOS enhances user profiles and Private Space but doesn't add the baseline features.
> I suspect one of the biggest barriers to mass adoption will be the fact that tap to pay doesn't work. IIUC apple/google pay are generally considered a privacy and security improvement over physical cards, since you don't give every merchant your actual card number.
Curve Pay, PayPal tap-to-pay and a bunch of European banks provide tap-to-pay support. Google Pay doesn't allow GrapheneOS but works on it on a technical level so if it was tricked into believing it was an old stock OS device, it would work, but that's not something feasible to keep working as they don't want to allow it.
PayPal's tap-to-pay availability is currently very limited and is likely still only in Europe. Curve Pay is in all of the UK and European Economic Region. I don't know how many countries have options for tap-to-pay via banking apps without Google Pay, but it's definitely available in most of Europe.
Yeah, worlds slowest and most in-efficient write-only database. And as soon as you need to interact with goods or services in the real world, then you still need trust anyway.
All these people harping on about: "Bro I just need to move my money without trusting anyone!, I just need a trust-less way to send currency bro!"
Trust is a good thing! Banks and financial middlemen aren't the devil. Look at how many TPS the visa network can do thanks to trust.
If it weren't for some minimum of social/institutional trust the whole of society would collapse anyway and your digital coins would finally converge to their true value (zero - or actually negative once you add in the externalities).
Fuck google for this. Awful decision. Guaranteed to be abused when Google or government despots decide that certain apps (or developers) aren't aligned with their interests.
Feeling very frustrated with the way the internet is going lately. This plus OSA + chat control. And compounded by the imperative for AI companies to keep hoovering up any and all data they can get their hands on, wiring it into "agentic" workflows and such.
You mean the guy that bans people from twitter for disagreeing with him? And has made a chatbot that spouts right-wing conspiracies in the name of being "anti-woke"?
I wish people would stop parroting the view that LLMs are lossy compression.
There is kind of a vague sense in which this metaphor holds, but there is a much more interesting and rigorous fact about LLMs which is that they are also _lossless_ compression algorithms.
There are at least two senses in which this is true:
1. You can use an LLM to losslessly compress any piece of text at a cost that approaches the log-likelihood of that text under the model, using arithmetic coding. A sender and receiver both need a copy of the LLM weights.
2. You can use an LLM plus SGD (I.e the training code) as an lossless compression algorithm, where the communication cost is area under the training curve (and the model weights don’t count towards description length!) see: Jack Rae “compression for AGI”
There is an excellent talk by Jack Rae called “compression for AGI”, where he shows (what I believe to be) a little known connection between transformers and compression;
In one view, you can view LLMs as SOTA lossless compression algorithms, where the number of weights don’t count towards the description length. Sounds crazy but it’s true.
A transformer that doesn't hallucinate (or knows what is a hallucination) would be the ultimate compression algorithm. But right now that isn't a solved problem, and it leaves the output of LLMs too untrustworthy to use over what are colloquially known as compression algorithms.
Outside a few weird online bubbles and pockets of the US, hardly anyone disputes the claim you are objecting to.