71–80 of 611 posts
So the suggestion here is that instead of using battle tested libraries/frameworks, everyone should now build their own versions, each with an unique set of silent bugs?
https://security.stackexchange.com/questions/209652/why-is-i...
Earlier quoted context omitted.
Pain can mean tedium rather than intellectual challenge.
I really struggle to understand how people can find coding more tedious than prompting. To each their own I guess.
I guess if you specialise in maintaining a code base with a single language and a fixed set of libraries then it becomes easier to remember all the details, but for me it will always be less effort to just search the names for whatever tools I want to include in a program at any point.
It's strange to me when articles like this describe the 'pain of writing code'. I've always found that the easy part. Anyway, this stuff makes me think of what it would be like if you had Tolkein around today using AI to assist him in his writing. 'Claude, generate me a paragraph describing Frodo and Sam having an argument over the trustworthiness of Gollum. Frodo should be defending Gollum and Sam should be on his s…
I tend to believe that, in all things, the quality of the output and how it is received is what matters and not the process that leads to producing the output.
If you use an LLM assisted workflow to write something that a lot of people love, then you have created art and you are a great artist. It's probable that if Tolkien was born in our time instead of his, he'd be using modern tools while still creating great art, because his creative mind and his work ethic are the most important factors in the creative process.
I'm not of the opinion that any LLM will ever provide quality that comes close to a master work by itself, but I do think they will be valuable tools for a lot of creative people in the grueling and unrewarding "just make it exist first" stage of the creative process, while genius will still shine as it always has in the "you can make it good later" stage.
My biggest concern with AI is that I'm not sure how a software engineer can build up this sort of high-level intuition: > I still have to deeply think about every important aspect of what I want to build. The architecture, the trade offs, the product decisions, the edge cases that will bite you at 3am. Without a significant development period of this: > What’s gone is the tearing, exhausting manual labour of typing e…
What I don't know is what state I'd be in right now, if I'd had AI from the start. There are definitely a ton of brain circuits I wouldn't have right now.
Counterpoint: I've actually noticed them holding me back. I have 20 years of intuition built up now for what is hard and what is easy, and most of it became wrong overnight, and is now limiting me for no real reason.
The hardest part to staying current isn't learning, but unlearning. You must first empty your cup, and all that.
Earlier quoted context omitted.
Your last sentence describes my thoughts exactly. I try to incorporate Claude into my workflow, just to see what it can do, and the best I’ve ended up with is - if I had written it completely by myself from the start, I would have finished the project in the same amount of time but I’d understand the details far better. Even just some AI-assisted development in the trickier parts of my code bases completely robs me o…
> if I had written it completely by myself from the start, I would have finished the project in the same amount of time but I’d understand the details far better. I believe the argument from the other camp is that you don't need to understand the code anymore, just like you don't need to understand the assembly language.
Gave me way more control/understanding over what the AI would do, and the ability to iterate on it before actually implementing.
It's strange to me when articles like this describe the 'pain of writing code'. I've always found that the easy part. Anyway, this stuff makes me think of what it would be like if you had Tolkein around today using AI to assist him in his writing. 'Claude, generate me a paragraph describing Frodo and Sam having an argument over the trustworthiness of Gollum. Frodo should be defending Gollum and Sam should be on his s…
I wonder how much it comes down to that divide. I also wonder how true that is, or if they’re just more trusting that the function does what its name implies the way they think it should.
I suspect you, like me, feel more comfortable with code we’ve written than having to review totally foreign code. The rate limit is in the high level design, not in how fast I can throw code at a file.
It might be a difference in cognition, or maybe we just have a greater need to know precisely how something works instead of accepting a hand wavey “it appears to work, which is good enough”.
Earlier quoted context omitted.
Some code is fun and some sucks? There's a joke that's not entirely a joke that the job of a Google SWE is converting from one protobuf to another. That's generally not very fun code, IMO (which may differ from your opinion and that's why they're opinions!). Otoh, figuring out and writing some interesting logic catches my brain in a way that dealing with formats and interoperability stuff doesn't usually. We're all d…
I mean, I agree if it's really just "machine translate this code to use the approved method of doing this thing". That seems like a perfect use case for AI. Though one would think Google would already have extensive code mod infrastructure for that kind of thing. But those aren't the stories you hear about with people coding with AI, which is what prompted my response.
I do agree that this:
> What’s gone is the tearing, exhausting manual labour of typing every single line of code.
seems more than a little overblown. But I do sympathize with not feeling motivated to write a lot of glue and boilerplate, and that "meh" often derails me on personal projects where it's just my internal motivation competing against my internal de-motivation. LLMs have been really good there, especially since many of those are cases where only I will run or deal with the code and it won't be exposed to the innertubes.
Maybe the author can't touch type, but that's a separate problem with its own solution. :)
Earlier quoted context omitted.
Your last sentence describes my thoughts exactly. I try to incorporate Claude into my workflow, just to see what it can do, and the best I’ve ended up with is - if I had written it completely by myself from the start, I would have finished the project in the same amount of time but I’d understand the details far better. Even just some AI-assisted development in the trickier parts of my code bases completely robs me o…
> if I had written it completely by myself from the start, I would have finished the project in the same amount of time but I’d understand the details far better. I believe the argument from the other camp is that you don't need to understand the code anymore, just like you don't need to understand the assembly language.
If you only understand the code by talking to AI, you would’ve been able to ask AI “how do we do a business feature” and ai would spit out a detailed answer, for a codebase that just says “pretend there is a codebase here”. This is of course an extreme example, and you would probably notice that, but this applies at all levels.
Any detail, anywhere cannot be fully trusted. I believe everyone’s goal should be to prompt ai such that code is the source of truth, and keep the code super readable.
If ai is so capable, it’s also capable of producing clean readable code. And we should be reading all of it.
The author seems to mistake having to update Node.js for a security patch to be a curse rather than a blessing. The alternative is that your bespoke solution has undiscovered security vulnerabilities, probably no security community, and no easy fix for either of those. You get the privilege of patching Node.js. Similarly, as a hiring manager, you can hire a React developer. You can't hire a "proprietary AI coded inte…
I fail to see the obvious wisdom in having AI re-implement chunks of existing frameworks without the real-world battle testing, without the supporting ecosystem, and without the common parlance and patterns -- all of which are huge wins if you ever expand development beyond a single person. It's worth repeating too, that not everything needs to be a react project. I understand the author enjoys the "vibe", but that d…
In recent months, we have MCPs, helping lots of people realize that huh, when services have usable APIs, you can connect them together!
In the current case: AI can do the tedious things for me -> Huh, discarding vast dependency trees (because I previously wanted the tedious stuff done for me too) lessens my risk surface!
They really are discovered truths, but no one's forcing them to come with an understanding of the tradeoffs happening.