My AI skeptic friends are all nuts

I think it works a bit like pre-training: to find what you want quickly you need to have a model of coding process, i.e. why certain files were put into certain directories, etc.

I don't think this process is incompatible with LLM use...

Well, except that in order to fix that 1% you'd need to read and understand whatever the LLM did and then look for that 1%. I get the shills just thinking about this, whether the original programmer was human or not. I'd rather just write everything myself to begin with.

I find these tools incredibly useful. But I constantly edit their output and frequently ask for changes to other peoples' code during review, some of which is AI generated.

But all of that editing and reviewing is informed by decades of writing code without these tools, and I don't know how I would have gotten the reps in without all that experience.

So I find myself bullish on this for myself and the experienced people I work with, but worried about training the next generation.

> If you’re making requests on a ChatGPT page and then pasting the resulting (broken) code into your editor, you’re not doing what the AI boosters are doing. No wonder you’re talking past each other.

They’re playing 3D chess while you’re stuck at checkers.

I do things suboptimally while learning the ropes or just doing things casually. That doesn’t mean that I judge the approach itself by my sloppy workflow. I’m able to make inferences about what a serious/experienced person would do. And it wouldn’t involve pasting things through three windows like I would do.

So of course I don’t judge AI by “ask chatty and paste the response”.

Yes indeed: “deploying agents” is what I would imagine the Ask Chatty And Paste workflow taken to Perfection to look like.

> LLMs can write a large fraction of all the tedious code you’ll ever need to write. And most code on most projects is tedious. LLMs drastically reduce the number of things you’ll ever need to Google. They look things up themselves. Most importantly, they don’t get tired; they’re immune to inertia.

Most Rube Goldberg machines are very tedious and consist of fifty-too-many parts. But we can automate most of that for you—

I could not have ever imagined a more Flintstones meets Science Fiction clash than AI According To Software Engineers. You’re using AI to generate code. And no one cares how much. It’s just so tedious in any case.

A wortwhile approach would have been to aspire to make or generate technology artifacts that could be hidden behind a black box surface with a legible interface in front. Is the code tedious? Then make the AI come up with something that is well-designed, where the obvious things you want is given freely, where minor customizations are just minor tweaks, and larger deviations require only proportionally larger changes. Uh, how about no? How about generating 20KLOC line “starter” some-framework project with all the 20KLOC “tedious” bits hanging out, then we can iterate from there. The AI made a Git log and everything so it’s ya know audited.

But maybe I’m being unfair. Maybe we are moving towards something not quite as stupid as Deploy ChatGPT 50X? Or maybe it’s effectively going to behind a black box. Because ya know the AI will deal with it all by itself?

> Are you a vibe coding Youtuber? Can you not read code? If so: astute point. Otherwise: what the fuck is wrong with you?

> You’ve always been responsible for what you merge to main. You were five years go. And you are tomorrow, whether or not you use an LLM.

No!, and what the fuck is wrong with you? We are Flintstone technologists and I’ll be damned if I can’t get my AI brain chip-injected, genetically enhanced for speed horsey cyborg for my modern horse-drawn carriage patent.

> Part of being a senior developer is making less-able coders productive, be they fleshly or algebraic. Using agents well is both a both a skill and an engineering project all its own, of prompts, indices, and (especially) tooling. LLMs only produce shitty code if you let them.

A junior developer often has negative value to a team, because they're sapping the time of more senior developers who have to help train them, review code, fix mistakes, etc. It can take a long while to break even.

The raw cost of Cursor's subscription is surely dwarfed by your own efforts, given that description. The actual calculous here should be the cost to corral Cursor, against the value of the code it generated.