4 ms·

This seems to romanticize the past. I've been doing this for 40 years and I don't see that much has changed. I would code even if I didn't get paid for it. T

This seems to romanticize the past. I've been doing this for 40 years and I don't see that much has changed. I would code even if I didn't get paid for it. That said I've always seen writing code as a means to an end. I use GenAI every day to write code, and it brings pure joy when there's boiler plate that I don't need to write so I can focus on the fun stuff. There is zero value in me writing yet another Python argparse routine. I've done it and I've learn everything I'm ever going to learn about it. Let me get on to the stuff that I don't know how to do.

spockz 1y ago
Okay I get the desire of not wanting to do repetitive stuff. It appears doing this with an llm scratches your itch. Before the same - focusing on the intrinsic complexity instead of the accidental - could be achieved by using libraries, toolkits, frameworks, better compiler (plugins), or “better” languages. What plagues me about LLMs is that all that generated code is still around in the project making reviews harder as well s understanding the whole program source. What is in there that makes you prefer this mechanism instead of the abstractions that have been increasingly available since forever?
- seer 1y ago
  Isn't this compiled languages vs writing pure machine code argument all over again? The compiler produces a metric shit ton of code that I don't see when I'm writing C++ code. And don't get me started on TypeScript/Clojure - the amount of code that gets written underneath is mindbogglingly staggering, yet I don't see it, for me the code is "clean". And I'm old enough to remember the tail end of the MachineCode -> CompiledCode transition, and have certainly lived through CompiledCode -> InterpretedCode -> TranspiledCode ones. There were certainly people who knew the ins and outs of the underlying technology who produced some stunningly fast and beautiful code, but the march of progress was inevitable and they were gradually driven to obscurity. This recent LLM step just feels like more of the same. *I* know how to write an optimized routine that the LLM will stumble to do cleanly, but back in the day lots of assembler wizards were doing some crazy stuff, stuff that I admired but didn't have the time to replicate. I imagine in the next 10-20 years we will have Devs that _only_ know English, are trained in classical logic and have flame wars about what code exactly would their tools generate given various sentence invocations. And people would benchmark and investigate the way we currently do about JIT compilation and CPU caching - very few know how it actually works but the rest don't have to, as long as the machine produces the results we want. Just one more step on the abstraction ladder. The "Mars" trilogy by Kim Stanley Robinson had very cool extrapolations where this all could lead, technologically, politically, social and morally. LLMs didn't exists when he was writing it, but he predicted it anyway.
  - pseudalopex 1y ago
    A stronger plausible interpretation of their comment is understanding meant evaluating correctness. Not performance. Higher level languages did not hinder evaluating correctness. Formal languages exist because natural languages are ambiguous inevitably.
    - spockz 1y ago
      Exactly, understanding correctness of the code. But also understanding of a codebase what its purpose is and what it should be doing. Add to that how the codebase is layed out. By adding more cruft the details fade away in the background making it harder to understand the Crux of the application. Measuring performance is relatively easy regardless of whether the code was generated by AI or not.
  - jimbokun 1y ago
    You don't have to review the compiler output because it's deterministic, thoroughly tested, predictable, consistent and reliable. You have to review all the LLM output carefully because it could decide to bullshit anything at any given time so you must always be on high alert.
    - seer 1y ago
      Ha! That’s what is actually happening under the hood, but is definitely not the experience of using it. If you are not into CS or you haven’t coded in the abstraction below, it can be very tough to figure out what exactly is going on, and reactions to your high level code become random. A lot of people (me included) would have a model of what is going on when I wrote some particular code, but sometimes the compiler just doesn’t do what you think it would do - the jit will not run, some data would not be mapped in the correct format, and your code will magically not do what you wanted it to. Things do “stabilise” - before TypeScript there was a slew of transpiled languages and with some of them you really had nasty bugs that you didn’t know how they are being triggered. With ruby, there was so many memory leaks that you just gave up and periodically restarted the whole thing cause there was no chance of figuring it out. Yes things were “deterministic” but sometimes less so and we built patterns and processes around that uncertainty. We still do for a lot of things. While things are very very different, the emotion of “reigning in” an agent gone off the rails feels kinda familiar, on a superficial level.
hinkley 1y ago
I've seen a lot change. I used to have a seemingly bottomless list of things we are doing wrong and about half of them have dropped off in the last twenty years. Did they all turn out as well as we hoped they would? No. I don't think a single one did. We are half-assing a lot of things that we used to laugh off entirely. In most of these cases some is better than none, but could be a lot better. What I worry about is that my list has gotten shorter not because everything is as it should be but because I have slowed down. Quite a lot of things on that list were of the "The future is here but it's not evenly distributed" sort. XP was about a bunch of relatively simple actions that were force multipliers with a small multiple on them. What was important was that they composed. So the benefit of doing eight of them was more than twice the benefit of doing four. Which means there's a lot of headroom still from adding a few more things.
mattikl 1y ago
That's certainly a more positive way to look at this. Working software has always relied on having people who grok the code, and this happens by spending a lot of time thinking about the code while writing it. And it's undocumented, because the nature of it is something you cannot really document. If AI is writing all the code, how do we keep the quality good? It's so obvious with the current GenAI tools that they're getting great at producing code, but they don't really understand the code. We don't really know how this story unfolds, so it's good to keep a positive mindset.
imiric 1y ago
Code generation tools of today are pretty good at writing the boring boilerplate. I think the author is aware of this. But what happens when they get really good at generating the not-so-boring bits? They're much better at this than they were a year or two ago, so it's not unthinkable that they will continue to improve. I'm a firm "AI" skeptic, and don't buy into the hype. It's clear that the brute force approach of throwing more data and compute at the problem has reached diminishing returns. And yet there is ample room for improvement by applying solid engineering alone. Most of what we've seen in the past year is based on this: MCP, "agents", "skills", etc. > I would code even if I didn't get paid for it. That's great, but once the market value of your work diminishes, it's no longer a career—it's a hobby. Which doesn't mean there won't be demand for artisanal programming, but it won't power the world anymore. It will be a niche skill we rely on for very specific tasks, while our jobs will be relegated to steer and assist the "AI" into producing reliable software. At least in the short-term. It's doubtful whether the current path will get us to a place where these tools are fully self-sufficient, and it's arguable whether that's something worth aiming for anyway. This is the bleak present and future the article is talking about. Being an assistant to code generation tools is far removed from the practice of programming. I personally find it tedious, unengaging, and extremely boring. There's little joy in the experience beyond ending up with a working product. The road to get there is not a journey of discovery, serendipity, learning, and dopamine hits. It is a slog of writing software specs, juggling contextual information and prompts, and coaxing a human facsimile into producing working software by using natural language. I dislike every part of this process. This is not the type of work that inspired me to do this professionally. Sure, every job has tasks we sometimes don't enjoy. But once you remove programming from the equation, there's not much joy in it left for me.
- doug_durham 1y ago
  I'm not particularly worried about being automated out of a job. I use the cutting edge tools for my work and they are getting incrementally better. It feels like we are plateauing. I can see a world where the LLM isn't writing code end-to-end. Instead it is writing chunks of code that I integrate. That may be more efficient than me writing out a 10,000 sentence English spec document. That allows me to express my value-add more effectively than I could otherwise. I think OP is projecting the bleak end of the possible outcomes. I don't see that happening.
jimbokun 1y ago
What if your boss says you'll be fired if you don't use the LLM for the "fun stuff" too?

spockz 1y ago

Okay I get the desire of not wanting to do repetitive stuff. It appears doing this with an llm scratches your itch. Before the same - focusing on the intrinsic complexity instead of the accidental - could be achieved by using libraries, toolkits, frameworks, better compiler (plugins), or “better” languages. What plagues me about LLMs is that all that generated code is still around in the project making reviews harder as well s understanding the whole program source. What is in there that makes you prefer this mechanism instead of the abstractions that have been increasingly available since forever?

seer 1y ago
Isn't this compiled languages vs writing pure machine code argument all over again? The compiler produces a metric shit ton of code that I don't see when I'm writing C++ code. And don't get me started on TypeScript/Clojure - the amount of code that gets written underneath is mindbogglingly staggering, yet I don't see it, for me the code is "clean". And I'm old enough to remember the tail end of the MachineCode -> CompiledCode transition, and have certainly lived through CompiledCode -> InterpretedCode -> TranspiledCode ones. There were certainly people who knew the ins and outs of the underlying technology who produced some stunningly fast and beautiful code, but the march of progress was inevitable and they were gradually driven to obscurity. This recent LLM step just feels like more of the same. *I* know how to write an optimized routine that the LLM will stumble to do cleanly, but back in the day lots of assembler wizards were doing some crazy stuff, stuff that I admired but didn't have the time to replicate. I imagine in the next 10-20 years we will have Devs that _only_ know English, are trained in classical logic and have flame wars about what code exactly would their tools generate given various sentence invocations. And people would benchmark and investigate the way we currently do about JIT compilation and CPU caching - very few know how it actually works but the rest don't have to, as long as the machine produces the results we want. Just one more step on the abstraction ladder. The "Mars" trilogy by Kim Stanley Robinson had very cool extrapolations where this all could lead, technologically, politically, social and morally. LLMs didn't exists when he was writing it, but he predicted it anyway.
- pseudalopex 1y ago
  A stronger plausible interpretation of their comment is understanding meant evaluating correctness. Not performance. Higher level languages did not hinder evaluating correctness. Formal languages exist because natural languages are ambiguous inevitably.
  - spockz 1y ago
    Exactly, understanding correctness of the code. But also understanding of a codebase what its purpose is and what it should be doing. Add to that how the codebase is layed out. By adding more cruft the details fade away in the background making it harder to understand the Crux of the application. Measuring performance is relatively easy regardless of whether the code was generated by AI or not.
- jimbokun 1y ago
  You don't have to review the compiler output because it's deterministic, thoroughly tested, predictable, consistent and reliable. You have to review all the LLM output carefully because it could decide to bullshit anything at any given time so you must always be on high alert.
  - seer 1y ago
    Ha! That’s what is actually happening under the hood, but is definitely not the experience of using it. If you are not into CS or you haven’t coded in the abstraction below, it can be very tough to figure out what exactly is going on, and reactions to your high level code become random. A lot of people (me included) would have a model of what is going on when I wrote some particular code, but sometimes the compiler just doesn’t do what you think it would do - the jit will not run, some data would not be mapped in the correct format, and your code will magically not do what you wanted it to. Things do “stabilise” - before TypeScript there was a slew of transpiled languages and with some of them you really had nasty bugs that you didn’t know how they are being triggered. With ruby, there was so many memory leaks that you just gave up and periodically restarted the whole thing cause there was no chance of figuring it out. Yes things were “deterministic” but sometimes less so and we built patterns and processes around that uncertainty. We still do for a lot of things. While things are very very different, the emotion of “reigning in” an agent gone off the rails feels kinda familiar, on a superficial level.

hinkley 1y ago

I've seen a lot change. I used to have a seemingly bottomless list of things we are doing wrong and about half of them have dropped off in the last twenty years. Did they all turn out as well as we hoped they would? No. I don't think a single one did. We are half-assing a lot of things that we used to laugh off entirely. In most of these cases some is better than none, but could be a lot better. What I worry about is that my list has gotten shorter not because everything is as it should be but because I have slowed down. Quite a lot of things on that list were of the "The future is here but it's not evenly distributed" sort. XP was about a bunch of relatively simple actions that were force multipliers with a small multiple on them. What was important was that they composed. So the benefit of doing eight of them was more than twice the benefit of doing four. Which means there's a lot of headroom still from adding a few more things.

mattikl 1y ago

That's certainly a more positive way to look at this. Working software has always relied on having people who grok the code, and this happens by spending a lot of time thinking about the code while writing it. And it's undocumented, because the nature of it is something you cannot really document. If AI is writing all the code, how do we keep the quality good? It's so obvious with the current GenAI tools that they're getting great at producing code, but they don't really understand the code. We don't really know how this story unfolds, so it's good to keep a positive mindset.

imiric 1y ago

Code generation tools of today are pretty good at writing the boring boilerplate. I think the author is aware of this. But what happens when they get really good at generating the not-so-boring bits? They're much better at this than they were a year or two ago, so it's not unthinkable that they will continue to improve. I'm a firm "AI" skeptic, and don't buy into the hype. It's clear that the brute force approach of throwing more data and compute at the problem has reached diminishing returns. And yet there is ample room for improvement by applying solid engineering alone. Most of what we've seen in the past year is based on this: MCP, "agents", "skills", etc. > I would code even if I didn't get paid for it. That's great, but once the market value of your work diminishes, it's no longer a career—it's a hobby. Which doesn't mean there won't be demand for artisanal programming, but it won't power the world anymore. It will be a niche skill we rely on for very specific tasks, while our jobs will be relegated to steer and assist the "AI" into producing reliable software. At least in the short-term. It's doubtful whether the current path will get us to a place where these tools are fully self-sufficient, and it's arguable whether that's something worth aiming for anyway. This is the bleak present and future the article is talking about. Being an assistant to code generation tools is far removed from the practice of programming. I personally find it tedious, unengaging, and extremely boring. There's little joy in the experience beyond ending up with a working product. The road to get there is not a journey of discovery, serendipity, learning, and dopamine hits. It is a slog of writing software specs, juggling contextual information and prompts, and coaxing a human facsimile into producing working software by using natural language. I dislike every part of this process. This is not the type of work that inspired me to do this professionally. Sure, every job has tasks we sometimes don't enjoy. But once you remove programming from the equation, there's not much joy in it left for me.

doug_durham 1y ago
I'm not particularly worried about being automated out of a job. I use the cutting edge tools for my work and they are getting incrementally better. It feels like we are plateauing. I can see a world where the LLM isn't writing code end-to-end. Instead it is writing chunks of code that I integrate. That may be more efficient than me writing out a 10,000 sentence English spec document. That allows me to express my value-add more effectively than I could otherwise. I think OP is projecting the bleak end of the possible outcomes. I don't see that happening.

jimbokun 1y ago

What if your boss says you'll be fired if you don't use the LLM for the "fun stuff" too?