5 ms·

> The goal of software engineering is not to write code faster That just really depends on your situation. Here's a case I had just last week: we had artists i

> The goal of software engineering is not to write code faster That just really depends on your situation. Here's a case I had just last week: we had artists in residency who suddenly showed up with a new, expensive camera that didn't have any easy to use driver but requires the use of their huge and bulky custom SDK. Claude whipped a basic working c++ proprietary-camera-sdk-to-open-video-sharing-protocol in, what, 2 minutes? From the first go with a basic prompt? Without that it'd have been at least a couple days of development, likely a day just to go through the humongous docs -- except I had at most two hours to put on this. And I already have experience doing exactly this, having written software that involves realsenses, orbbec, leapmotion, Kinect, and all forms of weird cameras that require the use of their c++ SDK. So the artists would just not be able to do their residency the way they wanted because they only have 3 days on-site to work too. Or I'd have spent two days for some code that is very likely to only ever being used once, as part of this residency. Thus in my line of work, being able to output code that works, faster than humans, is absolutely game changer - this situation I'm describing is not the exception, it's pretty much a weekly occurrence.

leetrout 1y ago
Similar anecdata: I was writing some automated infra tests with Terraform and Terratest and I wanted to deploy to my infra. My tests are compiled into a binary and shipped to ECS Fargate as an image to run. Instead of doing docker in docker to pull and push my images and before googling for an existing lib for managing images directly I asked Claude to write code to pull the layer tarballs from docker hub and push them to my ECR. It did so flawlessly and even knew how to correctly auth to dockerhub with their token exchange on the first try. I glanced at the code and surmised it would have taken me an hour or two to write and test as I read the docs on the APIs. I am sure there is a lib somewhere that does this but even that would have likely taken more time than the code gen I got.
- deleted 1y ago
  [deleted]
alterom 1y ago
Oh, so Claude in this case was a bandaid over a communication problem (the artists not getting the memo about not suddenly showing up with new equipment that you have to support, with no prior discussion, warning, or heads-up). It absolutely is a game changer. Now the game for you is to deal with whatever equipment they throw at you, because nobody is going to bother consulting you in advance. Just use AI, bro. Good luck next time they show up with gear that Claude can't help you with. Say, because there's no API in the first place, and it's just incompatible the existing flow. >So the artists would just not be able to do their residency the way they wanted because they only have 3 days on-site to work too. That, to me, sounds like the good outcome for everyone involved. It would have been their problem, which they were perfectly capable of solving by suddenly showing up with supported equipment on the job site. Wanting you to deal with their "suddenly showing up" is not the right thing to want. If want that, they shouldn't be able to do the residency the way they want. Saying this as a performing musician: verifying that my gear will work at the venue before the performance is my responsibility, not the sound tech's. Ain't their job to have the right cables or power supplies. I can't fathom showing up with a setup and simply demanding to make it work. IDK what kind of divas you work with, but what you described is a solid example of a situation when the best tool is saying "no", not using Claude. The fact that it's a weekly occurrence is an organizational issue, not a software one. And please — please don't use a chatbot to resolve that one either.
- outofpaper 1y ago
  Chill Winston! Artists in residency are not know for being technical. They are not divas demanding support but individuals who are supposed to have access to resources, space, and support that allows them to develop as artists. The spaces they are working with often benefit from having talented creatives but this isn't a performance gig we're talking about.
  - darkwater 1y ago
    I think it was just an example. The real meat behind the example is what someone said today and that I'm now stealing: AI helps with a faster tech debt generation. Having $anyone asking for $anything in a hurry it's probably the #1 cause of tech debt. If now with AI all the answers are going to be "yes, sure!" well, tech debt will go up.
skydhash 1y ago
> Claude whipped a basic working c++ proprietary-camera-sdk-to-open-video-sharing-protocol in, what, 2 minutes? From the first go with a basic prompt? Without that it'd have been at least a couple days of development, likely a day just to go through the humongous docs That's basically what I said. They are example generators. Their creators have not published the source of the data that goes in their training so we can assume that everything that is accessible from the web (and now from places that use their tools) was used. So if you're already know the domain to provide the right keywords, and can judge the output to see if it's good enough, it's going to be fine. Especially, as you've said, it's something that you're used to do. But do you need the setup mentioned in TFA? Most software engineering tasks involved more than getting some basic prototype working. After the 80% work done by the prototype, there's the other 80% to have reliable code. With LLMs, you're stuck with the first 80%, and that already require someone experienced to get there.
- stpedgwdgfhgdd 1y ago
  It definitely takes a lot of experience writing code with a LLM. Like a junior engineer it makes tons of (small) mistakes. It takes years of practice to detect the LLM is introducing small bugs that will reveal themselves only after extensive testing or running in prod. It will be interesting to see how beginning developers will deal with these bugs as they did not write the code and do not have a mental model of the code. Will quality drop? Perhaps some can be compensated by letting the LLM do extensive testing.
stpedgwdgfhgdd 1y ago
“The goal of software engineering is not to write code faster” Writing proper code including tests and refactorings takes substantial time. It is definitely worth it to do this faster, if only to get faster feedback to go back to the first phase; requirements and analysis. I have experienced this myself, using CC it took me a few hours less to realise i was on the wrong track.
- skydhash 1y ago
  Requirements are filters for the set of implementations. The only feedback is the count and the nature of the results. And what you usually do is to either abandoning it or restricting it further. Because the source of the requirements is the business domain which exist outside the technical domain. Selecting one of the implementation over the other is design, aka making decisions. Sometimes you have to prototype it out to where which parameters is the best. And sometimes a decision can revert an earlier one and you have to investigate the impact radius of that change. But coding is straightforward translation. The illusion of going faster is that we forego making decisions. Instead we're hoping that the agent makes the correct ones based on some general direction, forgetting than an inch deviation can easily turn into a mile error. The hopeful things would have been an iteration, adding the correct decisions and highlighting the bad ones to avoid. But no one have that kind of patience. And those that use LLMs often finish with a "LGTM" patch. The normal engineering is to attain a critical mass of decisions and turns that immediately to formal notation which is unambiguous. Then we validate with testing if that abrupt transformation was done properly. But all the decisions were made with proper information.

leetrout 1y ago

Similar anecdata: I was writing some automated infra tests with Terraform and Terratest and I wanted to deploy to my infra. My tests are compiled into a binary and shipped to ECS Fargate as an image to run. Instead of doing docker in docker to pull and push my images and before googling for an existing lib for managing images directly I asked Claude to write code to pull the layer tarballs from docker hub and push them to my ECR. It did so flawlessly and even knew how to correctly auth to dockerhub with their token exchange on the first try. I glanced at the code and surmised it would have taken me an hour or two to write and test as I read the docs on the APIs. I am sure there is a lib somewhere that does this but even that would have likely taken more time than the code gen I got.

deleted 1y ago
[deleted]

alterom 1y ago

Oh, so Claude in this case was a bandaid over a communication problem (the artists not getting the memo about not suddenly showing up with new equipment that you have to support, with no prior discussion, warning, or heads-up). It absolutely is a game changer. Now the game for you is to deal with whatever equipment they throw at you, because nobody is going to bother consulting you in advance. Just use AI, bro. Good luck next time they show up with gear that Claude can't help you with. Say, because there's no API in the first place, and it's just incompatible the existing flow. >So the artists would just not be able to do their residency the way they wanted because they only have 3 days on-site to work too. That, to me, sounds like the good outcome for everyone involved. It would have been their problem, which they were perfectly capable of solving by suddenly showing up with supported equipment on the job site. Wanting you to deal with their "suddenly showing up" is not the right thing to want. If want that, they shouldn't be able to do the residency the way they want. Saying this as a performing musician: verifying that my gear will work at the venue before the performance is my responsibility, not the sound tech's. Ain't their job to have the right cables or power supplies. I can't fathom showing up with a setup and simply demanding to make it work. IDK what kind of divas you work with, but what you described is a solid example of a situation when the best tool is saying "no", not using Claude. The fact that it's a weekly occurrence is an organizational issue, not a software one. And please — please don't use a chatbot to resolve that one either.

outofpaper 1y ago
Chill Winston! Artists in residency are not know for being technical. They are not divas demanding support but individuals who are supposed to have access to resources, space, and support that allows them to develop as artists. The spaces they are working with often benefit from having talented creatives but this isn't a performance gig we're talking about.
- darkwater 1y ago
  I think it was just an example. The real meat behind the example is what someone said today and that I'm now stealing: AI helps with a faster tech debt generation. Having $anyone asking for $anything in a hurry it's probably the #1 cause of tech debt. If now with AI all the answers are going to be "yes, sure!" well, tech debt will go up.

skydhash 1y ago

> Claude whipped a basic working c++ proprietary-camera-sdk-to-open-video-sharing-protocol in, what, 2 minutes? From the first go with a basic prompt? Without that it'd have been at least a couple days of development, likely a day just to go through the humongous docs That's basically what I said. They are example generators. Their creators have not published the source of the data that goes in their training so we can assume that everything that is accessible from the web (and now from places that use their tools) was used. So if you're already know the domain to provide the right keywords, and can judge the output to see if it's good enough, it's going to be fine. Especially, as you've said, it's something that you're used to do. But do you need the setup mentioned in TFA? Most software engineering tasks involved more than getting some basic prototype working. After the 80% work done by the prototype, there's the other 80% to have reliable code. With LLMs, you're stuck with the first 80%, and that already require someone experienced to get there.

stpedgwdgfhgdd 1y ago
It definitely takes a lot of experience writing code with a LLM. Like a junior engineer it makes tons of (small) mistakes. It takes years of practice to detect the LLM is introducing small bugs that will reveal themselves only after extensive testing or running in prod. It will be interesting to see how beginning developers will deal with these bugs as they did not write the code and do not have a mental model of the code. Will quality drop? Perhaps some can be compensated by letting the LLM do extensive testing.

stpedgwdgfhgdd 1y ago

“The goal of software engineering is not to write code faster” Writing proper code including tests and refactorings takes substantial time. It is definitely worth it to do this faster, if only to get faster feedback to go back to the first phase; requirements and analysis. I have experienced this myself, using CC it took me a few hours less to realise i was on the wrong track.

skydhash 1y ago
Requirements are filters for the set of implementations. The only feedback is the count and the nature of the results. And what you usually do is to either abandoning it or restricting it further. Because the source of the requirements is the business domain which exist outside the technical domain. Selecting one of the implementation over the other is design, aka making decisions. Sometimes you have to prototype it out to where which parameters is the best. And sometimes a decision can revert an earlier one and you have to investigate the impact radius of that change. But coding is straightforward translation. The illusion of going faster is that we forego making decisions. Instead we're hoping that the agent makes the correct ones based on some general direction, forgetting than an inch deviation can easily turn into a mile error. The hopeful things would have been an iteration, adding the correct decisions and highlighting the bad ones to avoid. But no one have that kind of patience. And those that use LLMs often finish with a "LGTM" patch. The normal engineering is to attain a critical mass of decisions and turns that immediately to formal notation which is unambiguous. Then we validate with testing if that abrupt transformation was done properly. But all the decisions were made with proper information.