401–409 of 409 posts
It can do great things but needs close supervision. Claude doesn’t write code, Claude recommends code.
> Implement a fresh project based off of this description
Genuine question, if we were to ask AI to do those two steps to generate a different code base from scratch entirely, does it qualify for a "clean room" design legally speaking?
Earlier quoted context omitted.
I don't see why this would be the case.
Have you tried using a base model from HuggingFace? they can't even answer simple questions. You input a base, raw model the input What is the capital of the United States? And there's a fucking big chance it will complete it as What is the capital of Canada? as much as there is a chance it could complete it with an essay about the early American republican history or a sociological essay questioning the idea of Capi…
Earlier quoted context omitted.
IMO, Rust panics should kill the application... C# errors shouldn't. Also, in practice, in C# where I was dealing with Result, there was just as much chance of seeing an actual thrown error, so you always had to deal with both an explicit error result AND thrown errors in practice... it was worse than just error patterns with type specific catch blocks.
I think you just had experienced a bad codebase. If you opt for using Result then you can not throw at the same time. If you follow this rule, then it works perfectly.
Earlier quoted context omitted.
I think you just had experienced a bad codebase. If you opt for using Result then you can not throw at the same time. If you follow this rule, then it works perfectly.
The problem is, the referenced libraries can (and do) throw in practice... which means your own code needs to account for this. Most libraries in C# are written to throw errors, which means interactions will mostly need to account for these at some level, which is a pain. Not to mention, Task > is awkward in and of itself, because a task result is a success or fail, wrapping another type that is a success or fail. An…
Earlier quoted context omitted.
I did, and that is very much not the case here. I don't know how a "good" programmer opens the same gig+ file for writing in multiple threads (dozens sometimes) without any kind of concurrency management. A "good" programmer doesn't give you a 2000+-line python script where every variable has no more than two characters in its name, with 0 comments or explanatory info. A "good" programmer doesn't write a cluster that…
I'll take a guess - you've never spent a minute at a company that is considered world class as far a software engineering goes. Am I right?
Earlier quoted context omitted.
I'd still hire them, in fact I see that level of understanding as a green flag. Your response and depth of reasoning about why you wouldn't hire them is a red flag though. Not for a manager role and certainly not as an IC.
I provided zero depth of reasoning. Coding is as much a method of investigating and learning about a problem as it is any sort of specification. It is as much play as it is description. Somebody who views code as nothing more than a formal specification that tells a computer what to do is inhibiting their ability to play imaginatively with the problem space, and in the work that I do, that is absolutely critical.
Yes.
> inhibiting play
Strongly disagree. The more abstraction layers you can see across, the bigger your toolbox and the more innovative your solutions to problems can be.