I tend to do the main structural parts myself and tell it to fill in the gaps and add tests, which sort of works 70% of the time. It may not be worth what my company is being charged.
I was with the article - especially the bit about the 10% an LLM loses and how that loss can be de-amplified across eventual meaning, but then...
"My first instinct is to laugh and shake my head. One need not look very far to find indignant software developers absolutely certain that their jobs cannot possibly be automated away by the very tools their industry contemporaries are creating to replace them. I suspect you’d also not have to look far into their posting histories to find those same people comparing cabbies to buggy whip makers."
What a rude and callous comment. I'm one of those developers, I'd love to see an LLM even fractionally capable of some of the things my job entails. Laugh at me as I defend my lifelong career, why don't you? I'm also one who decries such things as the removal of local services, taxi and otherwise, for those in the cloud. Screw you, man.
> I'd love to see an LLM even fractionally capable of some of the things my job entails
If you don't mind could you please elaborate on what tasks or knowledge your job requires that you feel an LLM isn't even _fractionally_ capable of? I understand if you said that out of emotion and frustration, but if you're serious I'm intensely and genuinely curious because nowadays it seems like the frontier models are capable of more programming tasks than not with the proper harness and engineer. When was the last time you tried?
I just want to emphasize that this is not a further provocation, just potentially in awe of what you do at your job and would like to know more.
If we're truthful, yes the LLM ("agent") can't do much by itself, but thanks to all the theft which no one was compensated for, they can do something based on what was done.
Not GP but honestly I don't even spend 10% of my time writing code - even if these tools were perfect code generators that could read my mind (instead of having to prompt) it wouldn't significantly impact my work.
If you want to be in awe of basic support tasks then sure! I frequently need to assist with support tickets, communicate between departments to solve customer queries and sometimes manually fix slop that AI has put in there. No LLM rig can do that for me, nor does anyone want it to.
classic example of the goomba fallacy - "all software engineers are one single person-caricature I have in my head and are therefore a stupid walking contradiction whenever two of them express different opinions".
Do these hypothetical laid off software engineers with no empathy for buggy drivers exist outside the imagination of people who hate software engineers? I know in my education we had a bunch of mandatory courses about automation and the effects on workers, how to consult with workers on how to lift them up rather than be antagonistic, and consider different stakeholders (where "the business" or "product" was but one of many) etc.
It's not easy being a developer right now. We went from being dorky and unpopular in school to being superstars (at work) and now the writing's on the wall. I can sympathize, but I'll concede that our recently developed attention for the state of nature and the fair distribution of capital is .. interesting.
I don't disagree, but the absolute hubris to think that our job is particularly difficult is also ridiculous. One by one our responsibilities will be able to be shifted into highly leveragable software, whether it's years or decades away.
There’s no irony. Author made a straw man of some bad, bad developer laughing at poor cabbies and it all clicked once VCs came for the fellow professionals.
Tech bro lamenting and berating developers how immoral and hypocritical they’re for “laughing” (has this ever happened?) at other professions, while doing the same. Story as old as time.
Article literally says their first instinct was to laugh. I'm not a tech bro, just a guy with a job (for now) and I made it clear from my comment that I have never laughed at tech taking the jobs of others, or made it happen myself. Try reading again.
The point of this sentence is to show that there are Software Developers who are looking at this in a short-sighted way. There doesn't seem anything rude about it.
You are definitely going to have to. I see these massive skills as soon-to-be artefacts of the past, they will be unwieldy in the non-subsidised world. I won't pretend to know what replaces them.
We have lots of open-weight models like DeepSeek V4 Pro that are very close to SOTA and we know the cost of running them.
This helps keeps the other players honests: there's a limit to which they can raise prices when there are already alternatives today and when there's zero lock in.
That those companies can make revenues but only at the cost of burning investors money: that's not my problem.
My take on it is simple: "Give me something MUCH better than the best open-weight models at a price that's not crazy or you're not getting my money".
And it happens to be the take of many devs.
I'm still paying Anthropic, Google and OpenAI (OpenAI because I didn't manage to cancel my subscription and now their model is competitive vs Anthropic's models again) but eye'ing a "Pi + open weights" solution.
Raise the prices too much and those companies selling access to private models aren't getting my money anymore.
I'm with you there. I can't stand the CLI that wants to take you away from the mostly bad code it writes. Give me the structure, let me finesse it - to do that I need to actually see it no matter how much Anthropic pretends that it's perfect.
I run Claude code inside an emacs vterm for moderately long lived work streams, and an ever shifting set of tmuxes for quick small features or bug fixes. The way I ensure I read the code at least a bit is the same as for wholly hand written code: I never do git add . only for one file at a time, and I got diff each file just prior to adding it (except sometimes for code genned files). I also arrange mostly to do incremental dev, sort of agile where I am the client and claude is the dev team and I check the utility of each feature one by one, so what I end up with delights me. It does tend to do more than is needed, so I will mostly delete code it has written rather than fix things. Like really not every module tunable constant needs to be over rideable from env vars. I am happy with the resulting systems, they have not collapsed into unmaintainable messes yet; the Claude in vterm in emacs is nice where I can think and run shell commands and look at code or git history while having a longer running discussion is nice UX.
I'm no physics professor but this aligns with the way I use the tools in my "senior engineer" space. I bring the fundamentals to sanity-check the trigger-happy agent and try to imbue other humans with those fundamentals so they can move towards doing the same. It feels like the only way this whole thing will work (besides eventually moving to local models that do less but companies can afford).
Considering anybody with a noggin is going to be separating the SQL into it’s own module or whatever rather than just throwing straight inline SQL at your database wherever you it, you’re hardly less likely to have things like accidental writes, anyway. This is clearly someone who fell in love with Postgres, felt ORM abstractions that diluted the Postgres goodness were bad, and then did some mental experiments to consider all of the theoretical ways ORMs suck.
Yeah ORMs help when they're appropriate but ya gotta learn how they work and where the footguns are plus you still really want to know how a database server works. Given the articles title, I doubt the prerequisites were met.
It seems that poor tech leadership are fearing that they won't be able to move onto their next job if they don't put "implemented AI efficiencies" on their CV now. It's up to us grunts to work out how to actually make it not suck.
That's a very thorough takedown of something the guy you're replying to never said. The end of their comment was "yet look at most of the replies here".
> That's a very thorough takedown of something the guy you're replying to never said.
Nah. Consider the context:
Aren't we all tired by this anti-AI stuff?
"Look at how I use this cool new technology" tends to be much more interesting to me than "this new technology has changed my job and I refuse to use it because I'm afraid".
[Copyright concerns, openness, sovereignty, privacy, deskilling, manipulation and AGI doom] are interesting topics to discuss. "AI is useless and I refuse to use it and hate you if you do" isn't, yet look at most of the replies here.
This trail of complaints was about the article from which I quoted.
Given the opinion on anti-"AI" articles suggested by that trail of complaints, I'd wager he either didn't read, or didn't thoroughly read the article and the supporting materials it links to. That's totally fine; but do folks the courtesy of going back and reading more carefully (or at all) when someone indicates that one's understanding of the material is substantially incorrect.
One way I've found is to break the problem down, and think about each step in reverse. So for example, what does the final stage want to do in order to achieve the result in a simple way? It might be that to get the final result it needs to sum numbers, but also needs to know their matching index in another array, plus some other identifier you got from an as-yet-unwritten previous step. This means your final stage needs a bunch of records that are (number, idx, sourceId), which means the step before needs to construct them - what information does it need to transform into that?
Write the simple code you want to write, and think about what makes the prior step possible in the easiest way and build your structures from there, filling in the gaps.
