It appears that the only available endpoint (as of this writing) requires enabling "Allow paid endpoints that train on request data" in the OpenRouter privacy settings. I hope additional paid providers will become available that don't require training on data.
This blog post illustrates the importance of NEVER outsourcing your critical thinking or outsourcing decision-making to an LLM. And to never take shortcuts with learning. Learning is hard, but learning things properly allows you to understand what is happening and allows you to ask the right questions about whether the changes an agent wants to make are the changes that will best serve the goals of the project (without creating an unwieldy level of tech debt in the future).
Personally speaking (and I'd love to hear others' takes on this): when using an LLM for work-related and development tasks, I never use the "full-auto" mode, and I never manually approve of something that I don't understand. When I don't understand something an agent wants to do, I go on a side-quest to learn more about said thing and to educate myself first. This takes extra time, but I feel that it's the right thing to do, so I can at least approve/deny/redirect from a more informed position, rather than flying blind and hoping for the best.
In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.
> In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.
I know it's a cliche but the old IBM adage holds very true today
Machines should work, people should think
Maybe that's part of the problem I have with LLMs writing code. It would be nice if they just did the work, but there's a lot of underlying thinking and decision making with software work that is being offloaded any time you have the LLM do it
It seems like those decisions are being handwaved off as "not important" nowadays. Just let the LLM make those choices! But that is not sitting right with me for whatever reason. Something I should think about I guess
The decisions are important, but the understanding is that you define them as constraints. Which is what a segment of the software community, the upper class if you will, has always believed you should do, even before LLMs were a thing. The LLM simply becomes a constraint solver: machines do the work, people do the thinking.
This is the challenge of the middle class developer. They aren't accustomed to working with constraint thinking and they're past the junior stage where one is expected to still be shaping their thinking so they are struggling to find a fit.
> They aren't accustomed to working with constraint thinking
That's one way to frame it I guess
I would frame it as "they have been abused by AGILE and impatient PMs into never actually taking time to do constraint based thinking or design"
It is impossible to think about constraints, or really do any proper engineering, if you are constantly "sprinting"
Edit: I also don't personally like engineering based on constraints. It feels like constructing a building based on where walls aren't allowed to go. I get that defining constraints and letting the software go is where a lot of useful emergent behavior lives, but I struggle a lot to think that way. Maybe I'm not wired right for software in the end
That's ironic given that some of the Agile Manifesto signatories are some of the biggest proponents of constraint-based development. While the Principles behind the Agile Manifesto is not prescriptive, I am not certain you could, in practice, even satisfy many of the principles without constraint-based development.
> I also don't personally like engineering based on constraints. It feels like constructing a building based on where walls aren't allowed to go.
Engineering is all about constraints. That you then shift to talking about constructing a building is curious as it would be atypical for an engineer to work on constructing a building. The engineer's role in building constriction is typically only in defining the constraints. Construction crews, made up of an entirely different group of people, then construct the building within the constraints set. "Constructing a building based on where walls aren't allowed to go" is essentially how buildings are usually constructed. It is an interesting parallel as the LLM is somewhat like the construction crew, which is something software hasn't really had before in any kind of big way.
Engineer gets thrown around pretty loosely in the world of software, but elsewhere, especially in places where failure can cause serious harm, someone who constructs a building by applying judgment, experience, and craftsmanship as they go would be considered an artisan, craftsman, or something to that effect rather than an engineer. That seems closer to the world you like to live in. There is nothing wrong with being a craftsman, of course, but the economic fit is becoming less clear as the industry matures. Which is something that seems par for the course. The early days of building construction was also dominated by craftsmen but as it matured engineers became dominant.
> someone who constructs a building by applying judgment, experience, and craftsmanship as they go would be considered an artisan, craftsman, or something to that effect rather than an engineer. That seems closer to the world you like to live in
Yes absolutely. I don't call myself an engineer, I'm a developer. Software Engineer is a title that my jobs give me, but I'm rarely given the time or resources to do any engineering.
It has become very clear to me over the years that I would much rather be an artisan than an engineer though.
> I'm rarely given the time or resources to do any engineering.
Are you sure it is that you are not given the time rather than your artisan ways consumes your time 'unnecessary'?
Failure in (most) software isn't going to harm anyone, so there isn't much technical need for engineering in software. As I am sure you can attest, artisans are fully capable of delivering great software. Some of the best software out there was created by artisans!
The software industry is headed towards engineering anyway because engineers can build software faster, which is considered a virtue in business. That was true even before LLMs, but has become especially pronounced in this next era.
> It has become very clear to me over the years that I would much rather be an artisan than an engineer though.
Understandable. I suspect a lot of engineers would rather be artisans—not just in software but in general. Artisans get to run at the forefront of new technologies and ideas before rigour is able to be established so it is, on balance, naturally more exciting.
That doesn't mean your artisan ways aren't consuming time 'unnecessarily', even of it is an employer request that is driving the 'unnecessary' work. It's a bit like the employer asking you to clean the office for half the day. Your available working time is the same, giving you time, but it is being squandered on 'unnecessary' work.
However, it seems like both you and your employer both want artisans anyway, so it sounds like you have found a good fit. The software industry is putting more and more emphasis on engineers, but that is far from being universal yet (and will likely never be 100%).
"This blog post illustrates the importance of NEVER outsourcing your critical thinking or outsourcing decision-making to an LLM."
This is a sentence that if written just 5 years ago would result in you being seen as crazy. "LLM capable of any sort of critical thinking? Haha. Not in 50 years."
It never ceases to amaze me how people are stuck in the here in the now and just accept the new reality as if it had always been this way, and will continue being this way in the foreseeable future.
This is the worst LLMs will ever be. Not outsourcing critical thinking to LLM will be seen as a liability in the not so distant future. Just a year or two ago almost no one even took LLM seriously for coding. Now the status quo has moved for also critical thinking, and we hear comments like this. LLM's chances of making a mistake will be orders of magnitude lowers than humans. Slowly learn to let the wheel go. AI will be much better at holding and controlling it.
"We should NEVER outsource number crunching to calculators. They are not 100% reliable and we can make mistakes when inputting the data." Someone in 1920's probably. I know it's a metaphor, and like all metaphors can't be compared 1-1. But it's to make a point how it illustrates my argument above.
> This is the worst LLMs will ever be. Not outsourcing critical thinking to LLM will be seen as a liability in the not so distant future. Just a year or two ago almost no one even took LLM seriously for coding. Now the status quo has moved for also critical thinking, and we hear comments like this. LLM's chances of making a mistake will be orders of magnitude lowers than humans. Slowly learn to let the wheel go. AI will be much better at holding and controlling it.
If that's true, you're fucked. Because then what good are you for? How long do you think they'll pay you to be useless meat-in-the-middle?
Not outsourcing your critical thinking means trying to preserve a scrap of value-add for having you around.
> "We should NEVER outsource number crunching to calculators. They are not 100% reliable and we can make mistakes when inputting the data." Someone in 1920's probably. I know it's a metaphor, and like all metaphors can't be compared 1-1. But it's to make a point how it illustrates my argument above.
That's a dumb analogy. Automating one activity cannot be extrapolated justify automating all the activities, including some of the most human ones.
We're moving toward a future where intellectual workers are, indeed, fucked. At least intellectual work will be the first real casualty.
I'm not AI maximalist. But with how things have progressed the past 4-5 years, I'm more confident on the above being true, than not.
I don't think intellectual work will drop off overnight. There will be a long period, perhaps decade or two, where many jobs will just gradually disappear, where salaries will be suppressed, and humans will just become AI-babysitters and auditors.
It is a uncomfortable scenario, but people - especially young ones about the enroll college or early in their career - should consider the possibility as realistic.
> I don't think intellectual work will drop off overnight. There will be a long period, perhaps decade or two, where many jobs will just gradually disappear, where salaries will be suppressed, and humans will just become AI-babysitters and auditors.
What I'm sick of is this passive acceptance of technological determinism. Why build a technology that's so corrosive and so destructive to so many? You've got powerful people talking about creating a permanent underclass, and happily charging forward anyway. AI is literally the most anti-human thing ever, and should be opposed politically.
But there's been so much indoctrination it will be very difficult. For instance, software engineers were so fucking smug for decades, foolishly adopting libertarian ideas while imagining themselves to be capitalists. We resisted any efforts towards unionization to create translate our (former) economic power into political power. Now we're literally the first on the chopping block.
> Some see it as the road to dystopia, other see it as the road to universal basic income, and a less laborious future.
A less laborious future is called mass unemployment. We have none of the sociological or ideological infrastructure to make that anything but a dystopia, and are making no progress on that front. Just look at what happened to the rust belt, what reason do you have to think things will be different this time?
If a happy, abundant communist future was in the cards, we'd have had it decades ago. The limit was never technological.
"Universal basic income" is just a sop to mute resistance to buy time while a small few grab most if not all economic power.
> The fact that you’re nervous means you will be the first to be replaced!
Is that sarcasm? Cause it's not too different from something I'd say sarcastically (e.g. it's very 10X AI engineer, very overconfident while missing pretty obvious things).
The fact that LLMs (or their client-side harnesses, at any rate) have improved substantially in the last year does not, ipso facto, mean they will continue doing so forever. Nor does it imply, even if they do keep improving, that they will displace human judgment and decision-making and that they will reach a point where they have literally zero limitations.
I don't agree with _never_ outsourcing decisions to an LLM, but the parent is right to point out the importance of thinking critically instead of blindly trusting LLMs. If only to understand their biases and common failure modes. The 1920s calculator metaphor is apt because practitioners using plugboards and Hollerith machines would have been avid early adopters but still keenly aware of the limitations of the device. They used that knowledge to decompose problems into units the device could solve, and to sanity-check the outputs of problems based on their understanding of mathematics and the capabilities of the machines.
I am often amazed at the dismissiveness of AI skeptics given the remarkable results we have seen in the last few years. And the stunning inefficiency of major LLM models and inaccessibility of underlying data mean there are a lot more gains to be had. But despite that, I'm even more flabbergasted by those who claim that AI superintelligence is a thing, that LLMs of all things will outcompete humans on creative and critical thinking tasks. It's a naive extrapolation at best and is completely unsupported by any coherent model of technological evolution, economics, game theory, or human history.
But all that said, I'm of course biased. I am of the belief that humans can do things that machines will never be able to no matter how advanced they become. A quasi-religious belief? Perhaps. But AI boosterism just as indefensible.
"This is the worst LLMs will ever be." does not logically preclude "This is the best LLMs will ever be." Telling people to count their chickens before they've hatched is the hallmark of the swindler.
It reminds me of the part in the film `I, Robot (2004)`. The protagonist, Detective Spooner, is driving down a freeway. Driving has been automated at this point in the future, however drivers can manually drive if they elect to do so. And the driver's passenger (the robot shrink) was utterly shocked that Detective Spooner engaged manual driving.
Will we eventually be so accustomed to LLM's that we will be similarly shocked when someone elects to not use them?
The Claude Pro subscription is basically useless at this point, in terms of usage limits with respect to the settings required to achieve actual useful output.
Meanwhile with 20 bucks a month for gpt plus, you can get shit ton of usage out of gpt 5.5 on codex if you know what you are doing and not just letting it swallow the whole project like an idiot.
Agreed, they also have great documentation. There's something to be said for documentation that is so concise, well laid out, and immediately actionable for those looking to get started quickly.
I'm in the same boat as you. Wish I had known this before my subscription renewed. There's no longer any value in paying them for this service when I can cut them out of the equation and pay the model providers directly.
I've been thinking of doing this — using one of the "pretty good but not Opus 4.6-good, YET very cheap" models for the implementation part of more basic code features, AFTER first using Opus 4.6 high for the planning stage.
Do you think this would be a decent approach?
Also, which client would I use for this? OpenCode? I don't think Claude Code supports using other models. Thoughts?
I have been doing this and the results have been fairly good.
I use claude to build requirements.md -> implementation.md -> todo.md. Then I tell opencode + openrouter to read those files and follow the todo using a cheap (many times free) model.
It works 90% of the time. The other 10% it will get stuck, in which case I revert to claude.
That has allowed me to stay on the $20/month claude subscription as opposed to the $100.
