3 ms·
Maybe, but that's a bet I'm willing to take. Here's the rub: if my competitors are going to realize "massive productivity gains," where are those gains actuall
by gavinhoward 4y ago
Maybe, but that's a bet I'm willing to take.
Here's the rub: if my competitors are going to realize "massive productivity gains," where are those gains actually coming from?
Are they coming from the time it takes to type? No, because typing is a small portion of the time we spend as programmers.
Are the gains coming from the time spent on design and architecture? Maybe, but that means my software will have better architecture, and I will have better velocity in the long run. (I have real-world experience with this, by the way; it takes me, on average, less than an hour to fix bugs in my bc nowadays. Architecture matters for long-term velocity.)
Are the gains coming from the time squashing bugs? No, this is where AI would decrease productivity because you have to carefully review outputs to ensure there are not any bugs.
In essence, the productivity gains will only happen the less that my competitors actually review and clean up the code from these tools. The less they do that, the lower the quality. The lower the quality, the slower their long-term velocity will be.
"A little bit of slope makes up for a lot of y-intercept." [1]
[1]: https://gist.github.com/gtallen1187/e83ed02eac6cc8d7e185 https://gist.github.com/gtallen1187/e83ed02eac6cc8d7e185
- jmfldn 4y agoHonestly I wish you well in this approach, I just worry that ignoring this completely may be too costly. I'm just advocating a very cautious middle path. For now, these tools are just code helpers to me (and right now I barely use them for that), but the moment I sense a genuine advantage to using them in my job, and I don't think it undermines my engineering, I think I'll have to engage further. Undermining for me means, reducing software quality, reliability, my own understanding. To the extent that I can work faster though, and even improve on those metrics, so much the better. The semi-near future to me (5-10 years?) , breathless hype-aside, looks like one where quite a lot of coding is automated with machines able to range over whole codebases and build higher level models of the software, and then getting into architectural system-design suggestions. I also see them linking up with company docs to build up a model of the whole domain. This doesn't need AGI, it's just an extension of what we have now, and I can't see it being anything other than a game changer. Forget ChatGPT, imagine your own private LLM, trained on your code and business, with all the weird glitches these prototypes have currently largely gone. You, the expert architect, are still needed, but you've now added a superpower to your tool chain.
- gavinhoward 4y agoFair enough. > This doesn't need AGI This is where we disagree. Code is so complex that I believe, strongly, that anything less than AGI will not be good enough. Notice I said "good enough". Sure, something less might be able to do something, but not good enough to make it a part of my toolkit. Also, code is Turing-complete. These LLM's are not Turing-complete. How could something that is not Turing-complete hope to "understand" (for some definition) something that is?
- jmfldn 4y agoI sort of agree with you in the most extreme case, ie "computers taking our jobs" means AGI. I'm not even sure that LLMs take you to AGI fwiw. Obviously we also need to define what we mean by AGI too. Anyway, all of that aside my point is this. AGI-aside, the current tools, scaled up and improved, will have a big impact on productivity eventually. When I think of the toil so much development involves now, especially for your average mid-level engineer, a lot of that could easily be eliminated. That's a lot of man hours right there. I can also see it as a knowledge base on steroids. Large orgs are so hampered by fragmented docs, misalignment etc, that this could really help to build business and domain insights. I see any number of transformative business /dev products to start appearing soon. The level of investment, and the technical progress, make this inevitable.
- fl7305 4y ago> These LLM's are not Turing-complete. Aren't they? I view them as "language processors", that execute one token (instruction) at a time, and use the token window as their working memory. Sure, they have a limit to their instruction count (8k/32) before stopping. The working memory is small, but 8k tokens goes a lot longer than 8 kB. I've seen you state in other comments that LLM's cannot reason. I used to think so too until a couple of weeks ago. But I had to change my mind. They're not just fancy autocomplete tools any more. They exhibit intelligence in that they can understand a given problem statement, reason about it, and make predictions and recommendations.
- gavinhoward 4y ago