pull down to refresh
63 sats \ 11 replies \ @SimpleStacker 4 Sep \ on: Brian Armstrong says about 40% of Coinbase’s daily code is AI-generated AI
If you've used an ai integrated IDE I don't think you'd find this surprising. A lot of code is boilerplate, and the AI lets you easily autocomplete all that boilerplate
reply
I think <tab>-<complete> style AI coding is actually sustainable and can yield great results. Its really uncanny when you start making a change in something like Cursor and AI picks up on your intent and suddenly starts making suggested edits that are all coherent to your intention.
I think vibe / prompt coding can be useful for getting 0.0.1 version bootstrapped and immediately functional, however has very very low percentage of being sustainable after a few versions.
For an existing project, new features can be vibe-coded into existence, but then it needs to quickly transition to <tab-complete> (ai assisted) to actually work as an integrated component long term.
Basically (as you've said), we have 2 differing styles of AI-coding currently happening, but we haven't yet developed the best practices methodology on when/where to use each.
reply
So we've come to basically 3 variations:
- AI-assisted completion
- AI-assisted coding (you're more likely to understand what you're coding here)
- Vibe coding
I fully agree that completion is sustainable and the second variation, assisted coding, isn't much different from someone doing C&P from stackexchange, perhaps even a little more advanced even, so that's manageable; but it could still be debt, especially when refactoring. I must admit that I really like the "let's discuss this code" use-case. This is much better than having to browse reference sites and a great improvement when you're learning (which you always are.)
Vibe coding currently isn't practical for anything past prototyping and those are throwaway prototypes at that. Anything complex that for example needs concurrency control is in my experience until now problematic for LLMs, including Claude 3.7 and 4, and Qwen3 coder. I think this is also risky with #2.
reply
I think vibe coding has its use cases. As a teacher, I've always wanted to come up with these little interactive examples. Vibe coding makes it way faster to do that. In fact, that single page static website I mentioned was exactly such a use case. But you're right, for larger projects it's nowhere near "there" yet.
I've only really tried vibe coding (from scratch) once, and it actually worked pretty well. But it was a single page static site, no database or complicated state management needed.
I use the <tab>-<complete> version of AI assisted coding all the time now though, and it's hit or miss. I do think it's pretty impressive how it picks up my intent sometimes. At other times, I roll my eyes and wonder what it's thinking.
reply
That's basically my point. Depending on how Brian Armstrong was measuring it, it may or may not be accurate to say that 40% of the code was "made by AI". It was made by humans, except the AI just assisted with the typing of what the human was gonna type anyway
reply
I think he's in desperate need for attention and he's mostly just babbling, especially since quality > source. But I agree with you that:
the AI just assisted with the typing of what the human was gonna type anyway
if that's the case then fine, but then why is AI-generated code a metric at all? The only correct metric for this is imho: problems solved per day without regressions.
reply
Never used it. Thanks for clearing that up.
reply
I agree. But very often code that matters and separates a good codebase from a crappy codebase are the ones least likely to be in a training dataset (hence, AI output).
Besides, new and better languages, design patterns, libraries are coming out everyday, along with breaking API changes of existing contracts. So the implications for AI generated codes?
reply