| ▲ | singpolyma3 2 hours ago |
| I mostly like this article but > Those who refuse to use an LLM will fall behind because they won't be able to produce as much Seems like a silly and needlessly aggressive take. Fall behind what? Able to produce "as much" what? I've never been evaluated on volume in my life. Nor have co workers who were severely "behind" ever feared for their jobs. |
|
| ▲ | marginalia_nu an hour ago | parent | next [-] |
| Just about every professional coding job I've ever had has had programmers eager to code more, complaining about how much rigmarole there is around making changes, complaining about constant meetings and endless bureaucracy around change management and requirements. Meanwhile business mostly saw programmer velocity and output as a problem and a business risk, as they struggled to keep up with the rate of change and kept stepping on the brakes. Like realistically even without LLMs I output probably around 10x as much code working alone, self-employed with zero meetings or bureaucracy, than I've ever done as a professional programmer. My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content. |
| |
| ▲ | WJW 2 minutes ago | parent | next [-] | | > My output sometimes rivals that of entire teams' I've been part of That's not very hard with many of the teams I've seen, with or without LLMs. Though the old adage of "If you want to go fast, go alone. If you want to go far, go together" still applies. | |
| ▲ | skydhash 22 minutes ago | parent | prev [-] | | > My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content. The fact is that often I code less than most of my peers. Because I prefer spending some time to design suitable data structures/algorithms for the problem at hand. I don't aim for perfection, just that it align with the business domain (and/or the interface) so that future works are proportional with the scope of change requests. This has reflected in small commits because the fundamental core of the business domain rarely changes (when they do, we have bigger problems than my writing speed). So I've never seen the need to increase my writing speed, because there's never any need to do so. What I'd like to increase is the speed the Product team get back to me with answers to my questions. Because that's often the real bottleneck. |
|
|
| ▲ | stickfigure 15 minutes ago | parent | prev | next [-] |
| > Fall behind what? Able to produce "as much" what? Customer meaningful features that move the needle on the business. I think this is strictly true. And not because LLMs can write code faster. I think it's true even if you're still writing most of your code by hand and using the LLM as an assistant. My anecdotal but decades-long observation is that most of the time=cost of a project comes not from writing code, but from dealing with "issues". Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours. LLMs excel at this kind of thing, freeing you up to spend most of your time working on business logic. This has certainly been my experience. |
|
| ▲ | Krssst 2 hours ago | parent | prev | next [-] |
| Yes, I dislike this kind of take so much. It keeps being repeated as a truthism and a way of putting down people that don't do what the speaker wants. It's fine to disagree, but there's no need to get such a threatening tone. A lot of tech jobs seem to be only about sheer output volume, with quality (maintenability, availability, security, generally understanding what the thing is doing) not mattering much. In that case sure, LLM all the way and whatever happens happens. But not all jobs are like that. |
| |
| ▲ | inglor_cz an hour ago | parent [-] | | My experience with regard to quality is quite the opposite. With LLM at my disposal, I had the time- and effort-budget to expand test suites considerably, I was even able to attack a somewhat thorny question of reproducible builds on MSVC, which is not exactly friendly towards determinism. These tasks would take me personally so much time that I would have to set them aside, at the cost of output quality. | | |
| ▲ | saghm 7 minutes ago | parent [-] | | Sure, but this is not at all uniform in how people use these tools any more than there was uniformity in how people balanced quality and speed before LLMs entered the picture. There was already a lot of variety in how some developers moved fast and broke things, others moved slow and fixed things, some would prototype new crazy ideas and others would spent time on the long tail of getting something from working adequately to being robust and polished. This isn't to say that LLMs aren't impactful, but that there's an argument for viewing them less as being a fundamental shift in how our profession works and more as another tool we can use to pursue essentially the same goals more efficiently than before. Like any other tool that's worth having, they can do things our existing tools couldn't do as well, or else we wouldn't have added it to our toolbox, but you still need to be able to recognize when to use it and when not to (and potentially how to use it when you do). I think that part of why these tools are so polarizing is that there was already some assymetry in how much longer it takes to clean up things than to create things that need to be cleaned up, so a new tool that makes everyone more productive has a lot of potential to exacerbate the existing imbalance. To make up some numbers for illustrative purposes, if someone introduced four new flaky tests in the time it took to fully diagnose and clean up one, and then LLMs came and made everybody twice as productive, now in the same amount of time someone might introduce eight flaky tests while you fixed two, so you're falling behind twice as fast. Unless the productivity gain disproportionately speeds up the people working on making things more robust and polished (which I find dubious; if anything I think the opposite seems more likely) or LLMs suddenly make everyone who didn't care about quality when rushing things out take it more seriously (which seems even more dubious), then LLMs don't improve the situation for people who already felt that the balance was slanted too heavily towards speed over quality. |
|
|
|
| ▲ | zdragnar an hour ago | parent | prev | next [-] |
| This is very much an N=1 anecdote from a friend, but his manager has basically doubled velocity expectations for the team at his company over the last year. Everyone has to use Claude code because that's the only model they're allowed to use, and not using it means not hitting the arbitrary expectations. Conversely, the company I am at has no such expectations, and we've got a legacy code base that LLMs aren't very handy in anyway. |
| |
| ▲ | CamperBob2 an hour ago | parent [-] | | we've got a legacy code base that LLMs aren't very handy in anyway So do I. What I'm finding is that they are now. I've spent the last week tracking down bugs using Fable that have gone undiagnosed for several years. And this is a damned obscure legacy code base that runs on a proprietary 8051 variant. Guaranteed to be nothing like it in-distribution. |
|
|
| ▲ | GolfPopper 20 minutes ago | parent | prev | next [-] |
| Those who do not transform themselves into paperclip maximizers will become paperclips. |
|
| ▲ | jonas21 17 minutes ago | parent | prev | next [-] |
| We have general expectations on the velocity an engineer should be able to work at. If it took someone 5 weeks to deliver the exact same thing another engineer could deliver in 1 week, that would be considered "falling behind" at most places. Would you disagree? The notion of falling behind because you refuse to adopt an advance in the field seems both uncontroversial and not aggressive at all to me. |
|
| ▲ | rnewme 27 minutes ago | parent | prev | next [-] |
| Those times are passing and you'll sooner or later meet with new reality. |
|
| ▲ | bitwize 12 minutes ago | parent | prev | next [-] |
| No, he is correct. LLMs have much larger working memories for the kind of details you work with in programming tasks. You are at an objective cognitive deficit by not taking advantage of this. Everybody knows what he means by left behind. When you program, you do so with a goal in mind, and you will not be able to reach that goal as quickly without LLMs. You will be outcompeted by those who use them, and this means that opportunities to contribute professionally, in open source, etc. will be closed to you. This is the future. Adapt or die. |
| |
| ▲ | rdpsentinel598 2 minutes ago | parent | next [-] | | The reality is that everyone will be replaced by a cheaper alternative someday, with LLMs or not. If you depend on LLMs more and more to do your work and the costs of keeping your tokens increases, your 'left behind' co-workers will still be fine. | |
| ▲ | liveoneggs 9 minutes ago | parent | prev [-] | | I use the 1M token opus claude for two days to build a dashboard and it forgets how to run the build script it wrote at the start of the project. Man can it put together a react app lickety split, though |
|
|
| ▲ | greenavocado 41 minutes ago | parent | prev [-] |
| 127. A technological advance that appears not to threaten freedom often turns out to threaten it very seriously later on. For example, consider motorized transport. A walking man formerly could go where he pleased, go at his own pace without observing any traffic regulations, and was independent of technological support-systems. When motor vehicles were introduced they appeared to increase man’s freedom. They took no freedom away from the walking man, no one had to have an automobile if he didn’t want one, and anyone who did choose to buy an automobile could travel much faster and farther than a walking man. But the introduction of motorized transport soon changed society in such a way as to restrict greatly man’s freedom of locomotion. When automobiles became numerous, it became necessary to regulate their use extensively. In a car, especially in densely populated areas, one cannot just go where one likes at one’s own pace one’s movement is governed by the flow of traffic and by various traffic laws. One is tied down by various obligations: license requirements, driver test, renewing registration, insurance, maintenance required for safety, monthly payments on purchase price. Moreover, the use of motorized transport is no longer optional. Since the introduction of motorized transport the arrangement of our cities has changed in such a way that the majority of people no longer live within walking distance of their place of employment, shopping areas and recreational opportunities, so that they HAVE TO depend on the automobile for transportation. Or else they must use public transportation, in which case they have even less control over their own movement than when driving a car. Even the walker’s freedom is now greatly restricted. In the city he continually has to stop to wait for traffic lights that are designed mainly to serve auto traffic. In the country, motor traffic makes it dangerous and unpleasant to walk along the highway. (Note this important point that we have just illustrated with the case of motorized transport: When a new item of technology is introduced as an option that an individual can accept or not as he chooses, it does not necessarily REMAIN optional. In many cases the new technology changes society in such a way that people eventually find themselves FORCED to use it.)
Ted explained this clearly https://www.washingtonpost.com/wp-srv/national/longterm/unab... |