4 ms·

>> 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 a

by noduerme 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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.
- noduerme 10mo ago
  I mean, I'm curious what kind of code it's saving you time on. For me, it's worse than useless, because no prompt I could write would really account for the downwind effects in systems that have (1) multiple databases with custom schema, (2) a back-end layer doing user validations while dispatching data, (3) front-end visual effects / art / animation that the LLM can't see or interpret, all working in harmony. Those may be in 4 different languages, but the LLM really just can't get a handle on what's going on well enough. Just ends up hitting its head on a wall or writing mostly garbage. I have not memorized all the docs to JS, TS, PHP, Python, SCSS, C++, and flavors of SQL. I have an intuition about what question I need to ask, if I can't figure something out on my own, and occasionally an LLM will surface the answer to that faster than I can find it elsewhere... but they are nowhere near being able to write code that you could confidently deploy in a professional environment.
  - maccard 10mo ago
    I’m far more in the camp of not AI than pro LLM but I gave Claude the HTML of our jira ticket and told it we had a Jenkins pipeline that we wanted to update specific fields on the ticket of using python. Claude correctly figured out how we were calling python scripts from Jenkins, grabbed a library and one shorted the solution in about 45 seconds. I then asked it to add a post pipeline to do something else which it did, and managed to get it perfectly right. It was probably 2-3 hours work of screwing around figuring out issue fields, python libraries, etc that was low priority for my team but causing issues on another team who were struggling with some missing information. We never would have actually tasked this out, written a ticket for it, and prioritised it in normal development, but this way it just got done. I’ve had this experience about 20 times this year for various “little” things that are attention sinks but not hard work - that’s actually quite valuable to us
mlrtime 10mo ago
Because it does what I want it to do? Not sure how this is so hard to understand. If you have closed source software, how do you know its's working?

fragmede 10mo 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 10mo 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 10mo 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 10mo 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.

noduerme 10mo ago
I mean, I'm curious what kind of code it's saving you time on. For me, it's worse than useless, because no prompt I could write would really account for the downwind effects in systems that have (1) multiple databases with custom schema, (2) a back-end layer doing user validations while dispatching data, (3) front-end visual effects / art / animation that the LLM can't see or interpret, all working in harmony. Those may be in 4 different languages, but the LLM really just can't get a handle on what's going on well enough. Just ends up hitting its head on a wall or writing mostly garbage. I have not memorized all the docs to JS, TS, PHP, Python, SCSS, C++, and flavors of SQL. I have an intuition about what question I need to ask, if I can't figure something out on my own, and occasionally an LLM will surface the answer to that faster than I can find it elsewhere... but they are nowhere near being able to write code that you could confidently deploy in a professional environment.
- maccard 10mo ago
  I’m far more in the camp of not AI than pro LLM but I gave Claude the HTML of our jira ticket and told it we had a Jenkins pipeline that we wanted to update specific fields on the ticket of using python. Claude correctly figured out how we were calling python scripts from Jenkins, grabbed a library and one shorted the solution in about 45 seconds. I then asked it to add a post pipeline to do something else which it did, and managed to get it perfectly right. It was probably 2-3 hours work of screwing around figuring out issue fields, python libraries, etc that was low priority for my team but causing issues on another team who were struggling with some missing information. We never would have actually tasked this out, written a ticket for it, and prioritised it in normal development, but this way it just got done. I’ve had this experience about 20 times this year for various “little” things that are attention sinks but not hard work - that’s actually quite valuable to us

mlrtime 10mo ago

Because it does what I want it to do? Not sure how this is so hard to understand. If you have closed source software, how do you know its's working?