zlacker

>>tablet+(OP)
Can we get a video of a workday conducted by these people?

Unless there's a significant sense of what people are working on, and how LLMs are helping -- there's no point engaging -- there's no detail here.

Sure, if your job is to turn out tweaks to a wordpress theme, presumably that's now 10x faster. If its to work on a new in-house electric motor in C for some machine, presumably that's almost entirely unaffected.

No doubt junior web programmers working on a task backlog, specifically designed for being easy for juniors, are loving LLMs.

I use LLMs all the time, but each non-trivial programming project that has to move out of draft-stage needs rewriting. In several cases, to such a degree that the LLM was a net impediment.

>>mjburg+q4
I have done everything from architecture design for a DSP (Qualcomm), to training models that render photos on Pixel phones, to redoing Instagrams comments ranking system. I can't imaging doing anything without LLMs today, they would have made me much more productive at all of those things, whether it be Verilog, C++, python, ML, etc. I use them constantly now.

>>mgracz+M9
I use LLMs frequently also. But my point is, with respect to the scepticism from some engineers -- that we need to know what people are working on.

You list what look like quite greenfield projects, very self-contained, and very data science oriented. These are quite significantly uncharacteristic of software engineering in the large. They have nothing to do with interacting systems each with 100,000s lines of code.

Software engineers working on large systems (eg., many micro-services, data integration layers, etc.) are working on very different problems. Debugging a microservice system isn't something an LLM can do -- it has no ability, e.g., to trace a request through various apis from, eg., a front-end into a backend layer, into some db, to be transfered to some other db etc.

This was all common enough stuff for software engineers 20 years ago, and was part of some of my first jobs.

A very large amount of this pollyanna-LLM view, which isnt by jnr software engineers, is by data scientists who are extremely unfamiliar with software engineering.

>>mjburg+7b
Hmm how did you get that from what I listed?

Every codebase I listed was over 10 years old and had millions of lines of code. Instagram is probably the world's largest and most used python codebase, and the camera software I worked on was 13 years old and had millions of lines of c++ and Java. I haven't worked on many self contained things in my career.

LLMs can help with these things if you know how to use them.

>>mgracz+Nc
OK, great. All I'm saying is until we really have videos (or equivalent empirical analysis) of these use cases, it's hard to assess these claims.

Jobs comprise different tasks, some more amenable to LLMs than others. My view is that where scepticism exists amongst professional senior engineers, its probably well-founded and grounded in the kinds of tasks that they are engaged with.

I'd imagine everyone in the debate is using LLMs to some degree; and that it's mostly about what productivity factor we imagine exists.

>>mjburg+0g
Developers who are productive with these tools are not going to waste time on that.

They are busy doing their work and prefer their competitors (other developers) to not use these tools.

>>johnb2+0M
The article you’re replying to is just one of many examples of people who profess to be productive with these tools, but are spending significant time and energy attempting to convince skeptics to use them.

>>sarche+pS
For this article he took the time explain how it makes him more productive. What more do you expect? Why are you entitled to any more than that?

>>johnb2+hV
I’m not entitled to anything but what you said in the previous post is clearly not the least bit true.