Earlier quoted context omitted.
>For example, people hate on Stalin a lot, but his 5-year plans were so wildly productive and successful you mean productive as in Holodomor?
Churchill purposefully starved the people of Bengal yet he is still revered. The Bengal famine had a similar death toll to the holodomor, yet one is ignored and the other used as a constant point to discredit. You literally proved my point, One can't say "Stalin's 5-year plans were overall successful and copied by other countries" without "but holodomor". Yet you can say all you want about Churchill or Britain's poli…
Devin: AI Software Engineer
601–604 of 604 posts
Re: Devin: AI Software Engineer
#602Earlier quoted context omitted.
>For example, people hate on Stalin a lot, but his 5-year plans were so wildly productive and successful you mean productive as in Holodomor?
Yea, it's insane OP went from a really great comment at the top to this. Weird.
By all means Op can say that they agree with some Marxist ideas, but when the real human costs of that model are very well proven out by now it should be a red flag if someone doesn’t acknowledge those costs from the jump. I’m not surprised this quickly went to suggesting Stalin wasn’t so bad.
Re: Devin: AI Software Engineer
#603Earlier quoted context omitted.
While you sound reasonable, I can't tell the difference between an honest opinion and a sales pitch here.
I am making a sales pitch on behalf of all the projects I mentioned (not just the one I'm involved with). I see LLMs failing at coding daily (one of the "perks" of working in the space), and I'm incredibly bullish on this approach. And I don't think it'll replace humans or junior engineers. As programmers, we've been "replacing" ourselves since the days of assembler that replaced direct machine coding. This is just a…
Assembler replacing direct machine coding or C replacing assembler was a new higher level ruleset replacing an existing lower level ruleset. But that change was largely static, meaning that you could learn a concept of a mapping of C syntax -> generated assembler and rely on it being predictive of the outcome of your program with relative ease. This is what enabled you to "forget about" assembler and move on with C only.
With libraries and frameworks, we introduced another level of abstraction that introduced an element of dynamism since the underlying framework could change at any time. This caused a lot of frustration with many developers already.
Now, with AI, another layer of dynamism and an additional layer of "lack of precision" is introduced. What the machine figures out as a solution may change in each run, the AI itself may change, the libraries, frameworks and programming language that it uses may change - all at the same time.
This raises the question how any human being should afford the time to train themselves in all the underlying components and the AI so as to be a meaningful expert in the field. Given the speed of development in the AI field, this seems like a losing proposition for anyone to invest their time in. Much different from the direct machine coding to assembler analogy that you mentioned initially.
Re: Devin: AI Software Engineer
#604Earlier quoted context omitted.
You are vastly overselling current generation AI here. It can do some things -- GitHub Copilot has been useful for people to reduce the boilerplate generation, for example -- but in terms of actual programming which 98% of the time is maintenance (fixing bugs, debugging, adding tests, refactoring, adding features) it's performing mostly bad. It's only good at generating code and maybe "understanding" some of it. Prov…
what do you think about devin? just curious