• 23 Posts
  • 16.2K Comments
Joined 3 years ago
cake
Cake day: June 20th, 2023

help-circle







  • Precisely.

    I have serious and significant objections to how LLM codegen models have and are being created/trained, marketed, deployed, and used, for a whole litany of ethical, personal, and professional reasons.

    To my deep chagrin, I and my team have effectively been forced to start using those tools to expedite some of our work lately, largely due to the very fucky and understaffed state my team has been in for the better part of a year. So, yeah, I do use claude, and I am fully versed in how to get higher-quality output from it by including adversarial and specialist agents in workflows, and how to present goals in a way that you minimize nonsense and maximize targeted, incisive agentic changesets. But I always treat that agentic output as a draft, and wherever possible, give my workflows a manually, tightly coded baseline example to serve as a change template. I categorically refuse to yeet LLM output into a PR - in fact, there was a multi-month period earlier this year where a bunch of contractors were doing just that, and I consistently took the piss out of them - and after enough restatements to make it clear they weren’t listening and didn’t care, we fired three of them.

    There is a reasonable and incisive way to employ codegen tools, but you absolutely have to know what you’re doing, and you have to be conscientious about it.

    Fully cuck coding is generally a recipe for disaster, including horrifying security vulnerabilities, awful performance, and various exciting categories of bugs that can yield interesting prod issues and outages. It will tank your code quality if you let it - and worst of all, it will make you a worse engineer if you intellectually lean on it too much. Delegation of your critical reasoning and technical aptitude to the clankers is a great way to allow those skills to atrophy to an alarming degree, and on top of that, you will have a much shakier understanding of the systems you are building and supporting.












  • The truly silly (and simultaneously neat and fascinating, and to a large extent, very logical and obvious) part is that US attempts to cripple Chinese ML/LLM development by putting most advanced GPU tech behind ITAR has more or less made the Chinese ML industry just write straight up better and more optimized code for the domain.

    US and western companies are currently relying on throwing bleeding edge hardware at the problem (read: very obviously brute-forcing the problem), whereas Chinese companies and engineers, having to rely on comparatively less advanced (though still highly capable) hardware has meant they’re staying competitive by optimizing the software layer more effectively.

    This has very interesting and likely negative long-term implications for western engineering practices in a lot of ways. And it’s also very much not a new problem - simply throwing compute at things is a mindset that became highly prevalent in the west around when The Cloud became a thing. Previously, you couldn’t just spawn another mainframe in your company’s datacenter, but when it’s as simple as aws ec2 start-instances ..., the barrier to entry for getting more compute is so low that most people were just going “hey, it’s faster”. I feel like the engineering expertise around embedded/baremetal optimization has just been largely evaporating over the last couple decades; in the vast majority of professional software domains, it’s simply not a valued skill anymore (or, more correctly, at the moment). It’s sad for me in several ways - not least of which because I did my degree in EECS, and hardware/software interplay and optimization is an area of engineering that I have always found very interesting.