[jeffreyrogers]

I think some people are drawn to technical careers because they like details and others are drawn to them because they like systems (now people are drawn for money too, but I'm talking about people who are more technically oriented). My theory is that if you are a systems person you find using LLMs fun and fulfilling and if you are a details person you find that they are the opposite. I have an acquaintance who is fairly well known for some of the work he did in computer vision (pre-neural net/deep learning), he's a details guy, and he was telling me how software is boring now because when he was young they were still figuring out how to do tons of things for the first time and now most software is just putting things together that we already know how to do. LLMs seem to be continuing this trend.

[cryptopian]

I enjoy software more out of a love of maths than a love of technology. My favourite class of problems are the times I can boil a problem down to a simple equation without even touching a keyboard, and I seem to be one of the few people who enjoy algorithmic design. So for me, churning out a script using an LLM hits the same part of my brain as randomly inserting numbers into a sudoku until the app tells me I have the right answer.

[alberto-m]

> My theory is that if you are a systems person you find using LLMs fun and fulfilling and if you are a details person you find that they are the opposite.

There was echoed by Andrej Karpathy: “LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building.”

[hnarayanan]

This is the take on this entire thread that I resonate with the most.

As a systems person, I do not know how to share with a details person how the combination of some magically conjured (and sometimes inscrutable) building blocks can still take us to interesting and joyful end results.

[never_inline]

What if I am a quality person and I am disappointed because LLMs are squandering any remaining commitment to quality in favor of quantity and speed in certain environments?

[jillesvangurp]

Then you might want to spend more time on the quality of your guard rails. It's the best way to ensure LLMs produce higher quality output. To get the best results, you need to get systematic about enforcing what you want. Guardrails are one of the tools for doing that.

A lot of developers are acting like passive bystanders here. You can take a more active role in the whole process, including doing quality assurance and correcting LLMs when needed. And like it or not, QA is actually still part of your job. A lot of developers never liked doing QA. The good news is that you can make the LLM do most of that. But it helps if you are a bit opinionated about how to do QA. Again, guardrails.

For example, if you care about performance, get systematic about performance testing and tell the LLM to find and fix your performance bottlenecks. I did that with a Go server a few months ago. It was functionally correct but it had a few bottlenecks. So, I generated a benchmark and then made the LLM suggest and implement solutions for all these bottlenecks. Once it had the benchmark, it got good at testing and validating its own solutions. After a few iterations, I had very decent throughput.