601–610 of 652 posts
Earlier quoted context omitted.
I just feel like using Copilot would be like early car designers trying to steer their new car with reins.
Have you used it recently? Or any specific that caused this feeling
Earlier quoted context omitted.
I've had success across quite a few languages, more than just python and js. I find it insanely hard to believe you can write code faster than the LLM, even if the LLM has to iterate a couple times. But I'm thankful for you devs that are giving me job security.
And that tells me you're on the dev end of the devops spectrum while I'm fully on the ops side. I write very small pieces of software (the time it takes to type them is never the bottleneck) that integrates in-house software with whatever services they have to actually interact with, which every LLM I've used does wrong the first fifteen or so times it tries (for some reason rtkit in particular absolutely flummoxes e…
Earlier quoted context omitted.
Wtf are you talking about. Great programmers use LLMs for complex tasks. That was the point of my comment
You didn't state any complex tasks though. You only stated programmers who use LLMs.
Great programmers wouldn't support or back AI if it couldn't handle complex tasks. AI can handle complex tasks inconsistently when operating on it's own. They can handle complex tasks consistently when pair programming with a human operator.
I feel like I'm taking crazy pills. The article starts with: > you give it a simple task. You’re impressed. So you give it a large task. You’re even more impressed. That has _never_ been the story for me. I've tried, and I've got some good pointers and hints where to go and what to try, a result of LLM's extensive if shallow reading, but in the sense of concrete problem solving or code/script writing, I'm _always_ di…
I usually do most of the engineering and it works great for writing the code. I’ll say: > There should be a TaskManager that stores Task objects in a sorted set, with the deadline as the sort key. There should be methods to add a task and pop the current top task. The TaskManager owns the memory when the Task is in the sorted set, and the caller to pop should own it after it is popped. To enforce this, the caller to…
If that's the input needed, then I'd rather write code and rely on smarter autocomplete, so meanwhile I write the code and think about it, I can judge whether the LLM is doing what I mean to do, or straying away from something reasonable to write and maintain.
Earlier quoted context omitted.
They are more effective then on the ground in your face evidence largely because people who are so against AI are blind to it. I hold a result of AI in front of your face and they still proclaim it’s garbage and everything else is fraudulent. Let’s be clear. You’re arguing against a fantasy. Nobody even proponents of AI claims that AI is as good as humans. Nowhere near it. But they are good enough for pair programmin…
If you want to be any good at all in this industry, you have to develop enough technical skills to evaluate claims for yourself. You have to. It's essential. Because the dirty secret is a lot of successful people aren't actually smart or talented, they just got lucky. Or they aren't successful at all, they're just good at pretending they are, either through taking credit for other people's work or flat out lying. I'v…
This is an orthogonal off topic point. My or anyones skills don't have to do with the topic at hand. The topic at hand is AI.
>Because the dirty secret is a lot of successful people aren't actually smart or talented, they just got lucky. Or they aren't successful at all, they're just good at pretending they are, either through taking credit for other people's work or flat out lying.
Again orthoganol to the point. But I'll entertain it. There's another class of people who are delusional. They think they're good, but they're not good at all. I've seen plenty of that in the industry. More so then people who lie, it's people who lie to themselves and believe it. Engineers so confident in their skills, but when I look at them I think they're raw dog shit.
>I've run into more than a few startups that are just flat out lying about their capabilities and several that were outright fraud. (See DoNotPay for a recent fraud example lol)
Again so?
>Pointing to anyone and going "well THEY do it, it MUST work" is frankly engineering malpractice. It might work. But unless you have the chops to verify it for yourself, you're just asking to be conned.
Of course. But it's idiotic when there is a huge population of people who are smarter than you better than you and proven to be more capable than you saying they can do it. I need to emphasize it's not just one person saying it. Tons and tons and tons of people are saying it.
Fraud happens in the margins of society it rarely ever happens at a macro level, and if it does happen at a macro level the trend doesn't last long and will mostly die within a year at most.
So when multitudes of highly reputed people are saying one thing, and your on the ground self verification of that thing is directly opposite of what they are saying. Then you need to re-evaluate your OWN verification. You need to investigate WHY there is a discrepancy, because it is utter stupidity to deny what others have seen as fraud and believe that your own judgements and verifications are flawless.
No offense, my dude, but your philosophy on this topic embodies the delusional stupidity I am talking about. People lie to themselves. That is the key metric here.
I don't need to explain ANY of this to you. You know it, because every explanation I just gave is an OBVIOUS facet of life in general. It needs to be explained to someone like you despite it's obviousness because of self delusion.
Earlier quoted context omitted.
Ah, perhaps. I understood it a little more broadly to include everything beyond pseudocode, rather than purely being able to use your fingers. You can solve a problem with pseudocode, and seasoned devs won't have much of an issue converting it to actual code, but it's not a fun process for everyone.
Yeah I basically write pseudocode and let the ai take it from there.
To me, reading the prompt example half a dozen levels up, reminds me of Greenspun's tenth rule:
> Any sufficiently complicated C++ program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. [1]
But now the "program" doesn't even have formal semantics and isn't a permanent artifact. It's like running a compiler and then throwing away the source program and only hand-editing the machine code when you don't like what it does. To me that seems crazy and misses many of the most important lessons from the last half-century.
[1]: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule (paraphrased to use C++, but applies equally to most similar languages)
I don't predict ever going back to writing code by hand except in specific cases, but neither do I "vibe code" - I still maintain a very close control on the code being committed and the overall software design. It's crazy to me nevertheless that some people can afford the luxury to completely renounce AI-assisted coding.
What's the luxury? The luxury is AI-assisted coding considering how expensive it is for tokens/$.
Earlier quoted context omitted.
Ah, perhaps. I understood it a little more broadly to include everything beyond pseudocode, rather than purely being able to use your fingers. You can solve a problem with pseudocode, and seasoned devs won't have much of an issue converting it to actual code, but it's not a fun process for everyone.
Yeah I basically write pseudocode and let the ai take it from there.
the problem is that you actually have to implement that high level DSL to get Lisp to look like that, and most DSLs are not going to be able to be as concise and abstract as a natural language description of what you want, and then just making sure it resulted in the right thing — which then I'd want to use AI for, to write that initial boilerplate, from a high level description of what the DSL should do.
And a Lisp macro DSL is not going to help with automating refactors, automatically iterating to take care of small compiler issues or minor bugs without your involvement so you can focus on the overall goal, remembering or discovering specific library APIs or syntax, etc.
Earlier quoted context omitted.
> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? — The Elements of Programming Style, 2nd edition, chapter 2 If you weren't even "clever enough" to write the program yourself (or, more precisely, if you never cultivated a sufficiently deep knowledge of the tools & domain you were working with),…
I think this goes for many different kinds of projects. Take React, for example, or jQuery, or a multitude of other frameworks and libraries. They abstract out a lot of stuff and make it easier to build stuff! But we've also seen that with ease of building also comes ease of slop (I've seen many sloppily coded React code even before LLMs). Then react introduced hooks to hopefully reduce the slop and then somehow it g…
The key difference with LLMs is that React was written very intentionally by smart engineers who provided a wealth of documentation to help people who need to peek under the hood of their framwork. If your LLM has written something you don't understand, though, chances are nobody does, and there's nowhere you can turn to.
If (as Peter Naur famously argued) programming is theory building, then an abstraction like a framework lets you borrow someone else's theory. You skip developing an understanding of the underlying code and hope that you'll either never need to touch the underlying code or that, if you do, you can internalize the required theory later, as needed. LLM-generated code has no theory; you either need to supervise it closely enough to impose your own, or treat it as disposable.