batshit_beaver

AGI

I’m personally a huge fan of viewing LLMs as linear algebra machines. They seem a lot less fascinating when you do that.

If faster intelligence was “groundbreaking” we would still be worshipping pocket calculators.

If we’re talking about ease of entry, doesn’t entrepreneurship fit the bill? It’s not an industry per se, but I don’t think it’s ever been easier or cheaper to start a business of any kind. Succeeding is, of course, a different matter.

What do you mean there’s no frontier industry? ML, infra, robotics, and even space all fall into this category. Not to mention medicine and biotech are starting to pick up.

I’m sure out of the many attempts to automate the production of software and get rid of those pesky, expensive devs, THIS one will work.

> subscription

Well yes when your tokens are nearly free, then getting literally any business value is a good outcome.

For once I actually agree with Simon, and fortunately the percentage of engineers interested in software architecture and business concerns is so low already that I doubt they’ll have trouble in the job market. Pure “coders” were not safe from layoffs and PIPs even before LLMs, in my experience, since their jobs could so easily be outsourced and offshored.

> Software is unique in that regard that the results can be verified quickly and easily fixed

Neither of these statements are true if your team is building anything remotely complex with real customers. You can’t quickly verify if your decisions will survive the test of time and past mistakes can’t always be easily fixed. LLMs trivialize the easy parts of software development and enable faster enshittification of the projects they’re used on, but that’s about it.

You can’t abstract away the need to capture requirements in a symbolic language. It doesn’t matter which programming or formal language you choose to specify your requirements in, but it cannot be natural language.

When people install npm packages, they typically only install ones the community trusts. These packages have clear APIs, open source, good docs, test coverage, security checks, and, importantly, usually no undocumented side effects.

Engineers introduce these packages into their own projects that have far fewer of the above guarantees than OSS, are built under pressure from deadlines, and have a constantly churning set of maintainers.

I think from the perspective of a business its own code does call for greater scrutiny than its dependencies.

The first sentence is easily verifiable, but the second carries the burden of proof.

For the record I’m fully on board with slopification being a bad thing. My point is that businesses don’t seem to care at this time.

> It's your job to explain to them the consequences of shipping code faster than the people whose job it is to understand it can do so.

The problem we’re collectively running into is that nobody knows if this actually poses a problem anymore. We’ll find out in 5-10 years, but businesses and clients can’t wait that long.

As a side note, I don’t think it’s fair to blame the “management” for setting expectations around AI use. They’re driven by market forces. If competitors are producing slop and customers are gobbling it up, then from a business perspective it _is_ a mistake to abstain from AI use.

What I’m finding quite fascinating is that we’re in a weird spot right now where we’re both expected to produce slop AND understand it / be responsible for it. Seems unreasonable.

Time. The limit is time. With or without agents there’s an X number of lines of code my brain can digest per work day. But rate of production of code is effectively unlimited or heavily influenced by people who let go of at least some percentage of understanding. This forces the rest of the team to also let go to keep up. Without guardrails around the rate of code production, _teams_ tend toward 0% code understanding. Individuals working on solo projects or in tiny teams that can enforce social contracts are not affected.