You don't have to know. The Calamares installer annotates your partitions and explains what will happen in natural language. If you can order a pizza online, you can install Linux.
Isn't this pretty much the standard across projects that make heavy use of AI code generation?
Using AI to generate all your code only really makes sense if you prioritize shipping features as fast as possible over the quality, stability and efficiency of the code, because that's the only case in which the actual act of writing code is the bottleneck.
I don't think that's true at all. As I said, in a response to another person blaming it on agentic coding above, there are a very large number of ways to use coding agents to make your programs faster, more efficient, more reliable, and more refined that also benefit from agents making the code writing research, data piping, and refactoring process quicker and less exhausting. For instance, by helping you set up testing scaffolding, handling the boilerplate around tests while you specify some example features or properties you want to test and expands them, rewriting into a more efficient language, large-scale refactors to use better data structures or architectures, or allowing you to use a more efficient or reliable language that you don't know as well or find to have too much boilerplate or compiler annoyance to otherwise deal with yourself. Then there are sort of higher level more phenomenological or subjective benefits, such as helping you focus on the system architecture and data flow, and only zoom in on particular algorithms or areas of the code base that are specifically relevant, instead of forever getting lost in the weeds of thinking about specific syntax and compiler errors or looking up a bunch of API documentation that isn't super important for the core of what you're trying to do and so on.
Personally, I find this idea that "coding isn't the bottleneck" completely preposterous. Getting all of the API documentation, the syntax, organizing and typing out all of the text, finding the correct places in the code base and understanding the code base in general, dealing with silly compiler errors and type errors, writing a ton of error handling, dealing with the inevitable and inoraticable boilerplate of programming (unless you're one of those people that believe macros are actually a good idea and would meaningfully solve this), all are a regular and substantial occurrence, even if you aren't writing thousands of lines of code a day. And you need to write code in order to be able to get a sense for the limitations of the technology you're using and the shape of the problem you're dealing with in order to then come up with and iterate on a better architecture or approach to the problem. And you need to see your program running in order to evaluate whether it's functionality and design a satisfactory and then to iterate on that. So coding is actually the upfront costs that you need to pay in order to and even start properly thinking about a problem. So being able to get a prototype out quickly is very important. Also, I find it hard to believe that you've never been in a situation where you wanted to make a simple change or refactor that would have resulted in needing to update 15 different call sites to do properly in a way that was just slightly variable enough or complex enough that editor macros or IDE refactoring capabilities wouldn't be capable of.
That's not to mention the fact that if agentic coding can make deploying faster, then it can also make deploying the same amount at the same cadence easier and more relaxing.
You're both right. AI can be used to do either fast releases or well designed code. Don't say both, as you're not making time, you're moving time between those two.
Which one you think companies prefer? Or if you're a consulting business, which one do you think your clients prefer?
> AI can be used to do either fast releases or well designed code
I have yet to actually see a single example of the latter, though. OpenCode isn't an isolated case - every project with heavy AI involvement that I've personally examined or used suffers from serious architectural issues, tons of obvious bugs and quirks, or both. And these are mostly independent open source projects, where corporate interests are (hopefully) not an influence.
I will continue to believe it's not actually possible until I am proven wrong with concrete examples. The incentives just aren't there. It's easy to say "just mindlessly follow X principle and your software will be good", where X is usually some variation of "just add more tests", "just add more agents", "just spend more time planning" etc. but I choose to believe that good software cannot be created without the involvement of someone who has a passion for writing good software - someone who wouldn't want to let an LLM do the job for them in the first place.
Although it is not OSI approved, the license theoretically didn't add any more restrictions beyond attribution, which stays in line with The Open Source Definition.
Correct. (and I know you already know this but just for the record: (Nearly?) Everybody abuses the term "open source" when it comes to models. OSI have a post about it: https://opensource.org/ai/open-weights
> they must be losing so much money on each Claude Code subscriber that if a million people all said "we're switching" they just wouldn't care.
You're looking at it completely wrong. Claude Code is Anthropic's flagship product, not the API. They want to attract as many users as possible to Claude Code and lock them into their ecosystem, so they can squeeze them later. All of their questionable actions surrounding Claude Code and its subscription are ultimately in service of this goal.
The subscription isn't some kind of charity, it exists specifically because they know the average user isn't willing to pay the exorbitant API prices to vibe code their groundbreaking new B2B SaaS idea, but they want to capture that market share anyway, because it's the core of their long-term strategy. The subscription arose from that: it's a form of predatory pricing designed to attract as many users as possible while they still have VC money to burn.
Once that runs out and the time comes to IPO and start making real profits, they are going to increase the price drastically, and what's where the lock-in comes into play. If everyone is using some open-source alternative that natively supports every other provider on earth, they will be far less likely to continue paying for Claude specifically instead of just switching to a competitor. Not to mention, they'd also lose out on the free advertising from things like CLAUDE.md and the commit co-signing (because that's all those things are, the only reason Claude Code doesn't support AGENTS.md is because CLAUDE.md serves as an advertisement in public repositories).
> like they all think they're Gods above mere mortals, serving some higher purpose, and nothing matters to them except Building the Machine God.
This is all just part of their marketing strategy, and you shouldn't read too much into it.
They don't need any actual written law behind their actions, all they need is money. What are you gonna do, fight them in court? Good luck with that, especially against a company directly associated with the US government and Palantir.
False equivalence. x86 assembly is a programming language, C is a programming language, Javascript is a programming language. English is NOT a programming language.
If it was, you wouldn't need "AI" to convert English into a real programming language before that, in turn, can be converted to machine code.
> But that's not programming because its a natural-language conversation?
Correct. Programming is writing code. You are not writing code, therefore you are not programming. I don't understand what's so complicated about this.
I'm literally making a program. Present-progressive of the verb to program. I feel like you're pearl-clutching on semantics. By my read, programming != writing code, but writing code is most definitely programming. Oxford defines 'to program' as both.
You're not making a program. You're managing the AI that is making a program. You're a manager, maybe a designer or architect too, but not a programmer.
These are well defined roles that existed well before AI. You don't get to redefine them just because you feel like you should get to be part of some imaginary "programmers' club" without doing the actual thing that defines the "programmer" role.
If you micromanage the mechanic, then yeah you might get production credits for fixing the car.
You could argue that I'm playing the manager, sure. I guess people who write software with nocode or visual data flow tools aren't programming in some form either? They aren't 'visual programming'? What about if I draw buttons and text boxes on a form in Visual Basic? I haven't hooked up the events yet, but that isn't programming?
Would you say that I am not programming if I make a synthesizer in Reaktor or Max? What about using blueprints in Unreal? Are those not programming?
This assertion that programming requires writing code is incorrect. I suspect the distinction cuts a little too close to home, which is why we are arguing semantics here.
It's sad to watch the mental gymnastics at play. I guess by asking my mechanic to service my car, I'm a mechanic too? I want it > it gets done > I am the doer. Ridiculous.
Sounds like you just don't like programming. And that's okay! It's okay to not like things.
But "I love programming now that I don't do any programming" is an utterly nonsensical statement. Please stop and reflect over what you said for a moment.
> Going to McDonalds made me realize that the reason I love cooking isn't the actual cooking itself. Being able to order a food at McDonalds and getting it without doing anything myself is the best part about cooking! Now that I only eat McDonalds, I feel like I'm _good_ at cooking.
You do not like and have never liked programming. You wanted to be a manager. They are completely different things.
a lot of the replies on here (not just yours, I just picked yours to respond to) make it clear I didn't articulate what I was meaning to very well - I'm still doing the "engineering". I used "programming" in a more general sense: building stuff with computers. I still go through the same motions. I try something, hit some failure mode, have to think of and (with the help of claude) execute on that, evaluate it, decide if its better or not, identify when the agent is off track or deviating from the vision I have, etc.
it seems you and others took my words a bit more literally than I intended for them to come across. it's not like I'm just one-shotting all my ideas directly into existence, I still need to understand how to use the tool to do it. it's just a different tool. one that's allowing me to build way more than I ever have, while having a ton of fun doing it.
and sure, your analogy seems reasonable if I was simply buying the code w/ my tokens. that wouldn't be fun or fulfilling at all - it's more like there is some new "cooking" tool that immediately spawns 90% of the ingredients pre-cut & prepped (maybe the other 10% isn't exactly what I asked for but I can improvise with it) and gives me a decent recipe based on the idea of what I wanted to cook in the first place that fills in (and gives me a starting point to learn about) the gaps that I didn't even realize I was missing. I see it more as: "All this time I thought I loved chopping onions and setting up the grill, but actually I just loved cooking".
you weren't wrong about the mcdonalds though. I do love mcdonalds
That's silly, they don't want to manage people, they prefer to build actually useful things. I've recently learned how many programmers actually don't care about building things.
They love the craft, for all they care they could be working in a black box in a void as long as it fed them interesting problems to solve.
They don't see any actual benifit in the AI increasing the velocity of how fast they build useful things. That was never of value to them, all they see is the problems becoming more boring to solve.
You are vastly overestimating the percentage of the population that knows what a "drive" is. Not saying that's a good thing, but it's the reality.
reply