601–610 of 626 posts
Earlier quoted context omitted.
I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock. So...yeah.
It is still possible to write bugs in both Haskell and Rust.
Earlier quoted context omitted.
I'm working on a serious embedded app written in C, and Opus has been invaluable to me. I don't consider myself a C developer, but by carefully reviewing the changes and making lots of my own contributions, I'm finding that I've progressed from junior to intermediate C comprehension. A lot of the idioms are still fuzzy, but I no longer find it intimidating. That's wonderful, because learning C has been something I'd…
I wish you the best of luck, truly. But I have written C in the past, it was almost 20 years ago, and everything seemed to work fine, until the memory leaks. Of course today I would ask the AI, why is my program leaking memory. I think you have a point, AI would be sort of like having a mentor help you find bad practices in your C code. You've inspired me to maybe try my hand at Rust, something I've been wanting to d…
Earlier quoted context omitted.
> if at all realistic numbers are mentioned, I see people claiming 20 - 50% IME most people claim small integer multiples, 2-5x. > all the largest studies I've looked at mention this clearly and explain how they try to address it. Yes, but I think pre-AI virtually everyone reading this would have been very skeptical about their ability to do so. > My current hypothesis, based on the DORA and DX 2025 reports, is that…
> Yes, but I think pre-AI virtually everyone reading this would have been very skeptical about their ability to do so. That's not quite true: while everybody acknowledged it was folly to measure absolute individual productivity, there were aggregate metrics many in the industry were aligning on like DORA or the SPACE framework, not to mention studies like https://dl.acm.org/doi/abs/10.1145/3540250.3558940 Similarly,…
Offshoring did happen, but if you were correct that only the quality control process impacted final quality, the software industry would have looked something like e.g. garment industry, with basically zero people being paid to actually write software in the first world, and hires from the developing world not requiring much skill. What we actually see is that some offshoring occurred, but it was limited and when it did occur companies tried to hire highly trained professionals in the country they outsourced to, not the cheapest bootcamp dev they could find. That's because the quality of the code at generation does matter, so it becomes a tradeoff between cost and quality.
> I still don't think that can be assumed as a fact. The few studies I've seen find comparable outcomes, with LLMs actually having a slight edge in some cases, e.g.
Anthropic doesn't actually believe in their LLMs as strongly as you do. You know how I can tell? Because they just spent millions acquihiring the Bun team instead of asking Claude to write them a JS runtime (not to mention the many software engineering roles they're advertising on their website). They know that their SOTA LLMs still generate worse code than humans, that they can't completely make up for it in the quality control phase, and that they at the very least can't be confident of that changing in the immediate future.
Earlier quoted context omitted.
It's not the only reason, technologies do plateau. We're not living in orbiting cities flying fusion powered vehicles around, even though we built rockets and nuclear power more than half a century ago.
All the current indicators are that AI will plateau far beyond any human capability. Do you have evidence or empirical arguments to the contrary?
Earlier quoted context omitted.
All the current indicators are that AI will plateau far beyond any human capability. Do you have evidence or empirical arguments to the contrary?
Burden of proof is on you sir, not the other way around.
I just find the belief that the continuous rapid improvements in machine intelligence stopping just short of human intelligence quite arbitrary.
Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive. In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. I work in backend, API development, which is completely different from fullstack development with backend development. If you ask PMs about backend requirements, th…
Very well said. More often than not, the job isn't to translate the product requirements into compiling/correctly executing computer code, but rather to reveal the hidden contradictions in a seemingly straightforward natural-language feature specification.
Once these are ironed out, the translation into code quite often does become a somewhat mechanical exercise, at least in my line of work.
We're basically the lawyers the person finding the magic lamp should have consulted with before opening their mouth while facing the genie ;)
Earlier quoted context omitted.
It wasn't code worth formally verifying, but even your description beats almost any programmer's first pass. With how good it is at finding bugs if you ask it, I have little reason to doubt its output.
In the real world, I'd say the 90% of the C code written is somewhere between "worthwhile to spend extra effort to detect and avoid memory errors" and "worth formally verifying". Sure, for prototype sized codebases it might be able to handle finding mistakes a fresh grad might easily make, or even that memory bugs aren't a big problem - but in my experience it happily adds memory bugs to large codebases and multithre…
Earlier quoted context omitted.
> Yes, but I think pre-AI virtually everyone reading this would have been very skeptical about their ability to do so. That's not quite true: while everybody acknowledged it was folly to measure absolute individual productivity, there were aggregate metrics many in the industry were aligning on like DORA or the SPACE framework, not to mention studies like https://dl.acm.org/doi/abs/10.1145/3540250.3558940 Similarly,…
> My hypothesis (based on observations when personally involved) is that this is exactly what allowed offshoring to boom. Offshoring did happen, but if you were correct that only the quality control process impacted final quality, the software industry would have looked something like e.g. garment industry, with basically zero people being paid to actually write software in the first world, and hires from the develop…
A large part of the success was, to your point, achieved by recruiting highly skilled workers at the client and offshoring ends, but they were a small minority. The vast majority of the workforce was much lower skilled. E.g. at one point the bulk of "software engineers" hired didn't even study computer science! The IT outsourcing giants would come in and recruit entire batches of graduates regardless of their education background. A surprisingly high portion of, say, TCS employees have a degree in something like Mechanical Engineering.
They key strategy was that these high-skilled workers acted as high-leverage points of quality control that were scaled to a much larger force of lower-skilled workers via processes. As the lower strata of workers upskilled over time, they were in turn promoted to lead other projects with lower-skilled workers.
In fact, you see this same dynamic in high-performing software teams, where there is a senior tech lead and a number of more junior engineers. The quality of output depends heavily on the skill-level of the lead rather than the more numerous juniors.
Re: Anthropic, I think we're conflating coding and software engineering. Writing an entire JS runtime is not just coding, it's a software engineering project, and I totally agree that AI cannot do software engineering: https://news.ycombinator.com/item?id=46210907
Earlier quoted context omitted.
And people are also still clearly confusing "isn't human or conscious" with "can't possibly create new logical thoughts or come to new logical conclusions i.e. do intellectual labor" when there is a plethora of evidence at this point that the latter is, in fact, the truth
I'm not sure if you mean that as a dig, or not, but if you are referring to me then I have these data points to discuss. 1. I have encountered a problem where AI will suggest 4 different "solutions" and when I point out a problem with one, it cycles on to the next, and stays in that loop, repeating over and over that set of 4, with no recollection of the previous refutation of the soltuion (this is a mix of context r…
I was calling that function with an unpacked slice of string - eg
```Go
foo := []string{"one", "two", "three"}
bar(foo...)
The AI I was using (Claude for the purposes of this discussion) incorrectly told me that I first needed to convert the slice of string to a slice of interface before calling the function
It argued with me when I said that I didn't and demanded I TIAS to prove its point, and report the compile time errors
Of course, I did, and there were no errors
The issue was that the AI (Claude) did not understand that `interface{}` or `any` means that any type can be used there.
Claude is doing a fantastic job, but this is an example of it not actually understanding what's happening.
Earlier quoted context omitted.
That was such a strange aspect. If you will excuse my use of the tortured analogy of comparing programming to wood working, there are is a lot of talk about hand tools versus power tools, but for people who aren't in a production capacity--not making cabinets for a living, not making furniture for a living--you see people choosing to exclusively use hand tools because they just enjoy it more. There isn't pressure abo…
Another key difference is that wood itself has built in visual transparency as to the goodness of the solution - as it is pretty easy to figure out that a cabinet is horrible (I do get that there are defects in wood joining techniques that can surface after some time due to moisture, etc - but still, lot of transparency out of the box). Software has no such transparency built in. The advantage of hand coded solutions…