9 ms·

> And when I ask them about it, they answer something like "oh but programming is the boring part, now I can focus on the problem solving" or something like tha

by svara 9mo ago

> And when I ask them about it, they answer something like "oh but programming is the boring part, now I can focus on the problem solving" or something like that, even though that's precisely what they delegate to the AI. This I think I can explain, because I'm one of these people. I'm not a programmer professionally for the most part, but have been programming for decades. AI coding allows me to build tools that solve real world problems for me much faster. At the same time, I can still take pride and find intellectual challenges in producing a high quality design and in implementing interesting ideas that improve things in the real world. As an example, I've been working on an app to rapidly create Anki flashcards from Kindle clippings. I simply wouldn't have done this over the limited holiday time if not for AI tools, and I do feel that the high level decisions of how this should work were intellectual interesting. That said, I do feel for the people who really enjoyed the act of coding line by line. That's just not me.

omnicognate 9mo ago
> coding line by line This phrase betrays a profoundly different view of coding to that of most people I know who actively enjoy doing it. Even when it comes to the typing it's debatable whether I do that "line by line", but typing out the code is a very small part of the process. The majority of my programming work, even on small personal projects, is coming up with ideas and solving problems rather than writing lines of code. In my case, I prefer to do most of it away from the keyboard. If AI were a thing that could reliably pluck the abstract ideas from my head and turn them into the corresponding lines of code, i.e. automate the "line by line" part, I would use it enthusiastically. It is not.
- noduerme 9mo ago
  It's not the typing, obviously, you're right. I think the parent is talking about it being an "intellectual exercise" to organize their thoughts about what they wanted to see as a result, whereas we who enjoy programming enjoy the exercise of breaking down thoughts into logical and algorithmic segments, such that no edge cases are left behind, and such that we think through the client's requirements much more thoroughly than they thought through them themselves. A physician might take joy in finding and fixing a human or animal malady. A roofer might take joy in replacing a roof tile, or a whole roof. But what job besides coding offers you the chance to read through the entire business structure of.. a lawyer, a doctor, a roofing company, a bakery.. and then decide how to turn their business into (a) a forward-facing, customer-friendly website, and (b) a lean data-gathering machine and (c) a software suite and hosting infrastructure and custom databases tailored to their exact needs, after you've gleaned those needs from reading all their financials and everything they've ever put out into the world? The joy of writing code is turning abstract ideas into solid, useful things. Whether you do most of it in your head or not, when you sit down to write you will find you know how you want to treat bills - is it an object under payroll or clients or employees or is it a separate system? LLMs suck at conceptualizing schema (and so do pseudocoders and vibe coders). Our job is turning business models into schemata and then coding the fuck out of them into something original, beautiful, and useful. Let them have their fun. They will tire of their plastic toy lawnmowers, and the tools they use won't replace actual thought. The sad thing is: They'll never learn how to think.
  - svara 9mo ago
    > The sad thing is: They'll never learn how to think. Drawing a sense of superiority out of personal choices or preferences is a really unfortunate human trait; particularly so in this case since it prevents you from seeing developments around you with clarity.
    - globnomulous 9mo ago
      I agree with the person you're answering. LLM-assisted coding is like reading a foreign language with a facing translation: most students who do this will make the mistake of thinking they've translated and understood the original text. They haven't. People are abysmal at maintaining an accurate mental accounting of attribution, authorship, and ownership.
      - grim_io 9mo ago
        Why is it so hard for people to understand or appreciate the higher layers of abstraction, that lie above their preferred layers of comfort? Think back on assembly programmers scoffing at c programmers. Same arguments, probably same outcomes.
        globnomulous 9mo ago
        I disagree. When you add an abstraction layer, the user of that layer continues to write code. That's not the case when people rely heavily on LLMs. They're at best reading and tweaking the model's output. That's not the only way to use an LLM. One can instead write a piece of code and then ask the tool for analysis, but that's not the scenario that people like me are criticizing or concerned about -- and it's not how most people imagine LLMs will be used in the future, if models and tools continue to improve. People are predicting that the models will write the software. That's what people like me and the person I agreed with are criticizing and concerned about. I'm uncomfortable with the idea not because it's outside of my area of comfort but because people don't understand code they read the way they understand code they write. Writing the code familiarizes the writer with the problem space (the pitfalls, for instance). When you haven't written it, and you've instead just read it, then you haven't worked through the problems. You don't know the problem space or the reasons for the choices that the author made. To put this another way: you can learn to read a language or understand it by ear without learning to speak it. The skills are related, but they're separate. In turn, people acquire and develop the skills they practice: you don't learn to speak by reading. Junior engineers and young people who learn to code with AI, and don't write code themselves, will learn, in essence, how to read but not how to write or 'speak;' they'll learn how to talk to the AI models, and maybe how to read code, but not how to write software.
- svara 9mo ago
  From the way you describe it, our process does not sound that different, except that this > If AI were a thing that could reliably pluck the abstract ideas from my head and turn them into the corresponding lines of code, i.e. automate the "line by line" part, I would use it enthusiastically. It is not. ... is exactly how this often works for me. If you don't get any value out of this at all, and have worked with SOTA tools, we must simply be working in very different problem domains. That said I have used this workflow successfully in many different problem domains, from simple CRUD style apps to advanced data processing. Two recent examples to make it more concrete: 1) Write a function with parameter deckName that uses AnkiConnect to return a list of dataclasses with fields (...) representing all cards in the deck. Here, it one-shots it perfectly and saves me a lot of time sifting through crufty, incomplete docs. 2) Implement a function that does resampling with trilinear interpolation on 3d instance segmentation. Input is a jnp array and resampling factor, output is another array. Write it in Jax. Ensure that no new instance IDs are created by resampling, i.e. the trilinear weights are used for weighted voting between instance IDs on each output voxel. This one I actually worked out on paper first, but it was my first time using Jax and I didn't know the API and many of the parallelization tricks yet. The LLM output was close, but too complex. I worked through it line by line to verify it, and ended up learning a lot about how to parallelize things like this on the GPU. At the end of the day it came out better than I could have done it myself because of all the tricks it has memorized and because I didn't have to waste time looking up trivial details, which causes a lot of friction for me with this type of coding.
- jason_oster 9mo ago
  > If AI were a thing that could reliably pluck the abstract ideas from my head and turn them into the corresponding lines of code, i.e. automate the "line by line" part, I would use it enthusiastically. So I take it you don't let coding agents write your boilerplate code? Do you instead spend any amount of time figuring out a nice way to reduce boilerplate so you have less to type? If that is the case, and as intellectually stimulating as that activity may be, it probably doesn't solve any business problems you have. If there is one piece of wisdom I could impart, it's that you can continue enjoying the same problem solving you are already doing and have the machine automate the monotonous part. The trick is that the machine doesn't absorb abstract ideas by osmosis. You must be a clear communicator capable of articulating complex ideas. Be the architect, let the construction workers do the building. (And don't get me started, I know some workers are just plain bad at their jobs. But bad workmanship is good enough for the buildings you work in, live in, and frequent in the real world. It's probably good enough for your programming projects.)
noduerme 9mo ago
>> AI coding allows me to build tools that solve real world problems for me much faster. If you can't / won't / don't read and write the code yourself, can I ask how you know that the code written for you is working correctly?
- fragmede 9mo ago
  Same way you test code you wrote by hand. In-place and haphazardly, until you have it write unit tests so you can have it done more methodically. If it hallucinates a library or function that doesn't exist, it'll fail earlier in the process ; compilation).
  - noduerme 9mo ago
    I've used Claude to write code, and it is much harder to test that code than it is to test code "haphazardly" as I write it myself. Reason being, I can test mine after each new line I write and make sure that line is doing what I intend it to do. After Claude writes a whole set of functions, it could take hours to test all the potential failure modes. BTW, if it doesn't take you hours to test the failure modes, you're not thinking of enough failure modes. The time savings in writing it myself has a lot to do with this. Plus I get to understand exactly why each line was written, with comments I wrote, not having to read its comments and determine why it did something and whether changing that will have other ramifications. If you're doing anything larger than a sample React site, it's worth taking the time to do it yourself.
    - tokioyoyo 9mo ago
      Well, you could also generate the tests by CC, check them to make sure they’re legitimate, then let it implement it? The main key in steering Claude this month (YMMV), is basically giving tasks that are localized, can be tested out and not too general. Then you kinda connect the dots in your head. Not always, but you can kinda get gist of what works and what doesn’t.
- svara 9mo ago
  I do read it. In my experience the project will quickly turn into crap if you don't. You do need to steer it at a level of granularity that's appropriate for the problem. Also, as I said, I've been coding for a long time. The ability to read the code relatively quickly is important, and this won't work for early novices. The time saving comes almost entirely from having to type less, having to Google around for documentation or examples less, and not having to do long debugging sessions to find brainfart-type errors. I could imagine that there's a subset of ultra experienced coders who have basically memorized nearly all relevant docs and who don't brainfart anymore... For them this would indeed be useless.
ErroneousBosh 9mo ago
> AI coding allows me to build tools that solve real world problems for me much faster. But it can't actually generate working code. I gave it a go over the Christmas holidays, using Copilot to try to write a simple program, and after four very frustrating hours I had six lines of code that didn't work. The problem was very very simple - write a bit of code to listen for MIDI messages and convert sysex data to control changes, and it simply couldn't even get started.
- Rodeoclash 9mo ago
  I'm sure someone is about to jump in and tell you why you're doing it wrong, but I'm in a similar position to you. I spent the last few days using the AI to help me pull together evidence for our ISO audit and while it didn't do a bad job, it was rife with basic errors. Simple things like consistently formatting a markdown document would work 9/10 times with the other time having it ignore the formatting, or deciding to rewrite other bits of the document for no reason.
- shlant 9mo ago
  I know "try this other tool" is probably an eye-roll-worthy response, but as someone who's not a programmer but is in IT and has to write some scripts every once in a while and has a lot of AI-heavy dev friends - all I've ever heard about Copilot is that it's one of the worst. I recently used Claude for a personal project and it was a fairly smooth process. Everyone I know who does a lot of programming with AI uses Claude mostly.
- tokioyoyo 9mo ago
  Yeah, unfortunately quality of tooling varies heavily. Like a range of producing garbage, to working code. Claude Code got significantly good in the last couple of months, and it’s been noticeable. I’ve been trying to plug LLMs into my workflow throughout the year, to make sure I don’t fall behind the industry. And this last month was it when it “clicked”. It works in large and small projects as long as you kinda know how to localize the tasks.
deleted 9mo ago
[deleted]

by svara 9mo ago

omnicognate 9mo ago

> coding line by line This phrase betrays a profoundly different view of coding to that of most people I know who actively enjoy doing it. Even when it comes to the typing it's debatable whether I do that "line by line", but typing out the code is a very small part of the process. The majority of my programming work, even on small personal projects, is coming up with ideas and solving problems rather than writing lines of code. In my case, I prefer to do most of it away from the keyboard. If AI were a thing that could reliably pluck the abstract ideas from my head and turn them into the corresponding lines of code, i.e. automate the "line by line" part, I would use it enthusiastically. It is not.

noduerme 9mo ago
It's not the typing, obviously, you're right. I think the parent is talking about it being an "intellectual exercise" to organize their thoughts about what they wanted to see as a result, whereas we who enjoy programming enjoy the exercise of breaking down thoughts into logical and algorithmic segments, such that no edge cases are left behind, and such that we think through the client's requirements much more thoroughly than they thought through them themselves. A physician might take joy in finding and fixing a human or animal malady. A roofer might take joy in replacing a roof tile, or a whole roof. But what job besides coding offers you the chance to read through the entire business structure of.. a lawyer, a doctor, a roofing company, a bakery.. and then decide how to turn their business into (a) a forward-facing, customer-friendly website, and (b) a lean data-gathering machine and (c) a software suite and hosting infrastructure and custom databases tailored to their exact needs, after you've gleaned those needs from reading all their financials and everything they've ever put out into the world? The joy of writing code is turning abstract ideas into solid, useful things. Whether you do most of it in your head or not, when you sit down to write you will find you know how you want to treat bills - is it an object under payroll or clients or employees or is it a separate system? LLMs suck at conceptualizing schema (and so do pseudocoders and vibe coders). Our job is turning business models into schemata and then coding the fuck out of them into something original, beautiful, and useful. Let them have their fun. They will tire of their plastic toy lawnmowers, and the tools they use won't replace actual thought. The sad thing is: They'll never learn how to think.
- svara 9mo ago
  > The sad thing is: They'll never learn how to think. Drawing a sense of superiority out of personal choices or preferences is a really unfortunate human trait; particularly so in this case since it prevents you from seeing developments around you with clarity.
  - globnomulous 9mo ago
    I agree with the person you're answering. LLM-assisted coding is like reading a foreign language with a facing translation: most students who do this will make the mistake of thinking they've translated and understood the original text. They haven't. People are abysmal at maintaining an accurate mental accounting of attribution, authorship, and ownership.
    - grim_io 9mo ago
      Why is it so hard for people to understand or appreciate the higher layers of abstraction, that lie above their preferred layers of comfort? Think back on assembly programmers scoffing at c programmers. Same arguments, probably same outcomes.
      - globnomulous 9mo ago
        I disagree. When you add an abstraction layer, the user of that layer continues to write code. That's not the case when people rely heavily on LLMs. They're at best reading and tweaking the model's output. That's not the only way to use an LLM. One can instead write a piece of code and then ask the tool for analysis, but that's not the scenario that people like me are criticizing or concerned about -- and it's not how most people imagine LLMs will be used in the future, if models and tools continue to improve. People are predicting that the models will write the software. That's what people like me and the person I agreed with are criticizing and concerned about. I'm uncomfortable with the idea not because it's outside of my area of comfort but because people don't understand code they read the way they understand code they write. Writing the code familiarizes the writer with the problem space (the pitfalls, for instance). When you haven't written it, and you've instead just read it, then you haven't worked through the problems. You don't know the problem space or the reasons for the choices that the author made. To put this another way: you can learn to read a language or understand it by ear without learning to speak it. The skills are related, but they're separate. In turn, people acquire and develop the skills they practice: you don't learn to speak by reading. Junior engineers and young people who learn to code with AI, and don't write code themselves, will learn, in essence, how to read but not how to write or 'speak;' they'll learn how to talk to the AI models, and maybe how to read code, but not how to write software.
svara 9mo ago
From the way you describe it, our process does not sound that different, except that this > If AI were a thing that could reliably pluck the abstract ideas from my head and turn them into the corresponding lines of code, i.e. automate the "line by line" part, I would use it enthusiastically. It is not. ... is exactly how this often works for me. If you don't get any value out of this at all, and have worked with SOTA tools, we must simply be working in very different problem domains. That said I have used this workflow successfully in many different problem domains, from simple CRUD style apps to advanced data processing. Two recent examples to make it more concrete: 1) Write a function with parameter deckName that uses AnkiConnect to return a list of dataclasses with fields (...) representing all cards in the deck. Here, it one-shots it perfectly and saves me a lot of time sifting through crufty, incomplete docs. 2) Implement a function that does resampling with trilinear interpolation on 3d instance segmentation. Input is a jnp array and resampling factor, output is another array. Write it in Jax. Ensure that no new instance IDs are created by resampling, i.e. the trilinear weights are used for weighted voting between instance IDs on each output voxel. This one I actually worked out on paper first, but it was my first time using Jax and I didn't know the API and many of the parallelization tricks yet. The LLM output was close, but too complex. I worked through it line by line to verify it, and ended up learning a lot about how to parallelize things like this on the GPU. At the end of the day it came out better than I could have done it myself because of all the tricks it has memorized and because I didn't have to waste time looking up trivial details, which causes a lot of friction for me with this type of coding.
jason_oster 9mo ago
> If AI were a thing that could reliably pluck the abstract ideas from my head and turn them into the corresponding lines of code, i.e. automate the "line by line" part, I would use it enthusiastically. So I take it you don't let coding agents write your boilerplate code? Do you instead spend any amount of time figuring out a nice way to reduce boilerplate so you have less to type? If that is the case, and as intellectually stimulating as that activity may be, it probably doesn't solve any business problems you have. If there is one piece of wisdom I could impart, it's that you can continue enjoying the same problem solving you are already doing and have the machine automate the monotonous part. The trick is that the machine doesn't absorb abstract ideas by osmosis. You must be a clear communicator capable of articulating complex ideas. Be the architect, let the construction workers do the building. (And don't get me started, I know some workers are just plain bad at their jobs. But bad workmanship is good enough for the buildings you work in, live in, and frequent in the real world. It's probably good enough for your programming projects.)

noduerme 9mo ago

>> AI coding allows me to build tools that solve real world problems for me much faster. If you can't / won't / don't read and write the code yourself, can I ask how you know that the code written for you is working correctly?

fragmede 9mo ago
Same way you test code you wrote by hand. In-place and haphazardly, until you have it write unit tests so you can have it done more methodically. If it hallucinates a library or function that doesn't exist, it'll fail earlier in the process ; compilation).
- noduerme 9mo ago
  I've used Claude to write code, and it is much harder to test that code than it is to test code "haphazardly" as I write it myself. Reason being, I can test mine after each new line I write and make sure that line is doing what I intend it to do. After Claude writes a whole set of functions, it could take hours to test all the potential failure modes. BTW, if it doesn't take you hours to test the failure modes, you're not thinking of enough failure modes. The time savings in writing it myself has a lot to do with this. Plus I get to understand exactly why each line was written, with comments I wrote, not having to read its comments and determine why it did something and whether changing that will have other ramifications. If you're doing anything larger than a sample React site, it's worth taking the time to do it yourself.
  - tokioyoyo 9mo ago
    Well, you could also generate the tests by CC, check them to make sure they’re legitimate, then let it implement it? The main key in steering Claude this month (YMMV), is basically giving tasks that are localized, can be tested out and not too general. Then you kinda connect the dots in your head. Not always, but you can kinda get gist of what works and what doesn’t.
svara 9mo ago
I do read it. In my experience the project will quickly turn into crap if you don't. You do need to steer it at a level of granularity that's appropriate for the problem. Also, as I said, I've been coding for a long time. The ability to read the code relatively quickly is important, and this won't work for early novices. The time saving comes almost entirely from having to type less, having to Google around for documentation or examples less, and not having to do long debugging sessions to find brainfart-type errors. I could imagine that there's a subset of ultra experienced coders who have basically memorized nearly all relevant docs and who don't brainfart anymore... For them this would indeed be useless.

ErroneousBosh 9mo ago

> AI coding allows me to build tools that solve real world problems for me much faster. But it can't actually generate working code. I gave it a go over the Christmas holidays, using Copilot to try to write a simple program, and after four very frustrating hours I had six lines of code that didn't work. The problem was very very simple - write a bit of code to listen for MIDI messages and convert sysex data to control changes, and it simply couldn't even get started.

Rodeoclash 9mo ago
I'm sure someone is about to jump in and tell you why you're doing it wrong, but I'm in a similar position to you. I spent the last few days using the AI to help me pull together evidence for our ISO audit and while it didn't do a bad job, it was rife with basic errors. Simple things like consistently formatting a markdown document would work 9/10 times with the other time having it ignore the formatting, or deciding to rewrite other bits of the document for no reason.
shlant 9mo ago
I know "try this other tool" is probably an eye-roll-worthy response, but as someone who's not a programmer but is in IT and has to write some scripts every once in a while and has a lot of AI-heavy dev friends - all I've ever heard about Copilot is that it's one of the worst. I recently used Claude for a personal project and it was a fairly smooth process. Everyone I know who does a lot of programming with AI uses Claude mostly.
tokioyoyo 9mo ago
Yeah, unfortunately quality of tooling varies heavily. Like a range of producing garbage, to working code. Claude Code got significantly good in the last couple of months, and it’s been noticeable. I’ve been trying to plug LLMs into my workflow throughout the year, to make sure I don’t fall behind the industry. And this last month was it when it “clicked”. It works in large and small projects as long as you kinda know how to localize the tasks.

deleted 9mo ago

[deleted]