←back to thread

108 points bertman | 1 comments | | HN request time: 0.279s | source
Show context
ebiester ◴[] No.43821540[source]
First, I think it's fair to say that today, an LLM cannot replace a programmer fully.

However, I have two counters:

- First, the rational argument right now is that one person and money spent toward LLMs can replace three - or more - programmers total. This is the argument with a three year bound. The current technology will improve and developers will learn how to use it to its potential.

- Second, the optimistic argument is that a combination of the LLM model with larger context windows and other supporting technology around it will allow it to emulate a theory of mind that is similar to the average programmer. Consider Go or Chess - we didn't think computers had the theory of mind to be better than a human, but it found other ways. For humans, Naur's advice stands. We cannot assume that this is true if there are tools with different strengths and weaknesses than humans.

replies(2): >>43821634 #>>43822188 #
rowanseymour ◴[] No.43822188[source]
If you forced me to put a number on how much more productive having copilot makes me I think I would say < 5%, so I'm struggling to see how anyone can just assert that "the rational argument right now" is that I can be 200% more productive.

Maybe as a senior dev working on a large complex established project I don't benefit from LLMs as much as others because as I and the project mature.. productivity becomes less and less correlated with lines of code, and more about the ability to comprehend the bigger picture and how different components interact... things that even LLMs with bigger context aren't good at.

replies(3): >>43822711 #>>43824435 #>>43824786 #
1. ebiester ◴[] No.43824786[source]
I don't think about it in lines of code, but let me say that there are some efficiencies being left on the table.

It helps because I am quicker to run to a script to automate a process instead of handling it manually, because I can bang it out in 15 minutes rather than an hour.

I am more likely to try a quick prototype of a refactor because I can throw it at the idea and just see what it looks like in ten minutes. If it has good testing and I tell it not to change, it can do a reasonable job getting 80% done and I can think through it.

It generates mock data quicker than I can, and can write good enough tests through chat. I can throw it to legacy code and it does a good job writing characterization tests and sometimes catches things I don't.

Sometimes, when I'm tired, I can throw easy tasks at it that require minimal thought and can get through "it would be nice if" issues.

It's not great at writing documentation, but it's pretty good at taking a slack chat and writing up a howto that I won't have the time or motivation to do.

All of those are small, but they definitely add up.

That's today and being compared to 5% improvement. I think the real improvements come as we learn more.