The problem is that you are identifying a symptom of an ongoing societal moral decline with an economic system. Spend some time on Dostoevsky or Kant. When morality is solely based on our current nationalism/hedonism hybrid in the West you end up at these extreme morally dubious exploits whether in a free or autocratic society. I don't claim to know what can help society become more ethical. What do you propose will improve society's ethical foundations? It's often the case that staunch critics of a system or another don't usually have much to offer in terms of ethics, they pontificate in favor or counter a given system without exploring whether society's ethics dwell on shaky foundations, they spend a lot of time talking about the technicalities, the merits of this or that implementations when in reality all societies whose ethical foundations crater, do not recover their ethics through policy reform alone.
There are so many examples of this disconnect. Prohibition did not make for a society that wanted less alcohol, or felt that consuming alcohol was unethical, it actually had the counter effect, opening the door for a considerable larger problem of crime supported production. The war on drugs was/has been no different.
To see this as the top comment here, where you picked Adam Smith as your straw man, could have been Karl Marx or any other thinker, and say it boils down to this or that simple mistake.. Are you serious? There are much deeper issues driving this thirst for Gambling we have embraced of late amongst other dubious things that have been normalized. But pick whatever economic system you want, install it anywhere and the existing ethical issues you currently have will still be there.
Tokens will become significantly more expensive in the short term actually. This is not stemming from some sort of anti-AI sentiment. You have two ramps that are going to drive this. 1. Increase demand, linear growth at least but likely this is already exponential. 2. Scaling laws demand, well, more scale.
Future better models will both demand higher compute use AND higher energy. We cannot underestimate the slowness of energy production growth and also the supplies required for simply hooking things up. Some labs are commissioning their own power plants on site, but this is not a true accelerator for power grid growth limits. You're using the same supply chain to build your own power plant.
If inference cost is not dramatically reduced and models don't start meaningfully helping with innovations that make energy production faster and inference/training demand less power, the only way to control demand is to raise prices. Current inference costs, do not pay for training costs. They can probably continue to do that on funding alone, but once the demand curve hits the power production limits, only one thing can slow demand and that's raising the cost of use.
This underestimates how much of the Internet is actually compressed into and is an integral part of the model's weights. Gemini 2.5 can recite the first Harry Potter book verbatim for over 75% of the book.
What humans are known to do, and apparently there is no limit to what they won't, is anthropomorphizing. I think there's not been a single one of these discussions where someone inevitably says LLM's don't do X as well as a human and someone interjects in cult-like fashion.
Software moats were never really a moat in and of themselves. You always had to be a first mover. It's true that there are fewer and fewer first mover opportunities, but that has less to do with recent LLMs advancements and more that we have already solved a lot of software problems on first principles. It's partially why LLMs work so well, they are pulling the "widgets" from distribution and synthesizing into your requirements. Before, we probably thought we were writing novelty when it was literally solved 1000x over.
If you aren't a first mover, your success was always dependent on other skills and great execution across multiple disciplines, and also a lot of stubbornness. The software layer has always been important, but a support role of successful enterprises. Start-ups have always been hard to pull together successfully for a lot of other reasons unrelated to code.
If you find a disruptive algorithm (like pagerank) there is little evidence that LLMs will infer your solution by looking at your app. Anything else, they are just design choices and have never been moats either, but say you have a qualitative edge, you'll make the choices that can create a recognizable brand where someone vibing a copycat may not care as much. Nothing has changed on this. Your chance of succeeding rests on your ability to reach your users and iterate in a crowded space, this is what you always had to do anyway.
There are things, however, that aren't worth working on anymore with the advent of LLMs. Some of these have been fully dismissed, for example sentiment analysis. A single API call for the cheapest (even local) LLM vendor will give you SOTA classification. There are many more examples but they are so obvious. Essentially, the "build me 1 billion dollar app" prompt will never work, so if you have a burning desire to build something, do it. Just remember, there never was and never will be a promise of unlimited fortunes whatever you do.
The claim that users who don't adopt AI now will pay for it later or some other notion is a contradiction of their position. People who are bullish on AI should support this view wholesale. Opus 4.5 is easier to use than GPT 3.5. It can actually code a full toy project one shot where you couldn't dream of it before. Opus 4.5 isn't perfect, so people have a lot of things they do for a competitive advantage. Though anything you think you're building with all the prompt alchemy and .md rules or whatever will be useless and futile on Opus 10, every "really good practice" is instantly absorbed by labs so when something great is in the wild everyone eventually benefits by the base .md or system prompts. So even if you feel like you have a competitive advantage right now, it will evaporate by either the labs improving their tools or become generally unnecessary in future versions of the models.
The goal of the labs is to continue these leaps will get even bigger with every generation. Unless you secretly believe that some portion of the craft will be left unexplored by the labs or the things that are still relatively borked now will not be worked on or fixed later is a silly notion to me. Future versions will be easier to prompt and the tools will do more of the heavy lifting of following up and re-rolling misinterpretations. I argue that a user sleeping through all of this is likely to use a future version better than someone who is obsessing with all their assumptions on how to coerce these models to work right now, current version hyper users will likely bring unnecessary baggage imo.
For now, even with Opus 4.5 the time horizon for delivering a full-stack project is not significantly different than before, it's still limited by how much you can push it. I'd argue that someone without understanding of how things work is unlikely to succeed in getting production-grade outcomes from these current versions. The point is, if you choose to learn more and get better in understanding and building things that work (with AI or otherwise) you'll be just fine to use the versions that have fully or mostly automated the entire process. Nobody will be left behind, only those who stop building altogether.
It's an interesting comparison, because Segway really didn't have any real users or explosive growth, so it was certainly hype. It was also hardware with a large cost. LLMs are indeed more akin to Google Search where adoption is relatively frictionless.
I think the core issue is separating the perception of value versus actual value. There have been a couple of studies to this effect, pointing to a misalignment towards overestimating value and productivity boosts.
One reason this happens imo, is because we sequester a good portion of the cognitive load of our thinking to the latter parts of the process so when we are evaluating the solution we are primed to think we have saved time when the solution is sufficiently correct, or if we have to edit or reposition it by re-rolling, we don't account for the time spent because we may feel we didn't do anything.
I feel like this type of discussion is effectively a top topic every day. To me, the hype is not in the utility it does have but in its future utility. The hype is based on the premise that these tools and their next iteration can and will make all knowledge-based work obsolete, but crucially, will yield value in areas of real need; cancer, aging, farming, climate, energy and etc.
If these tools stop short of those outcomes, then the investment all of SV has committed to it at this point will have been over invested and
How is this ironic? I asked you about your process and you haven't responded once, only platitudes and hyperbole about it and now you claim I'm making assumptions? I'd love to see your proompting.
Again. You were the one that actually claimed to be using English as the programming language, and have been vehemently defending this position.
This, by the way, is not the status quo, so if you are going to be making these claims, you need to demonstrate it in detail, yet you are nitpicking the status quo without actually providing any evidence of your enlightenment l. Meanwhile you expect me or anyone you interact with (probably LLMs exclusively at this point) to take your word for it. The answer to that is, respectfully no.
Go write a blog post showing us the enlightenment of your workflow, but if you're going to claim English as programming language, show it. Otherwise shut it.
First of all. I never said that typing brackets and semicolons is what I'm arguing the benefits will come from. That's a very reductionist view of the process.
You have really strawmanned that and positioned my point as stemming from this concept of typing language specific code as being sacrosanct in some way. I'm defending that, because it's not my argument.
I'm arguing that you are being dishonest when you claim to be using English as the programming language in a way that actually expedites the process. I'm saying this is your evidence-free opinion.
I'm also confused by what your involvement is in the implementation and the extent of your specifications. When you write your specifications in English is all pseudo-code? Or are you leaving a lot for the LLM to deduce and implement?
By definition, if you are allowing some level of autonomy and "creative decision making" to the model, you are using it as an abstraction. But this is a dangerous choice, because you cannot guarantee it's reliably abstracting, especially if it's the latter. If it's the former, then I don't see the benefit of writing requirements so detailed as to pseudo-code level to have it write in compilable code for you just so you don't have to type brackets and semicolons.
LLMs aren't good enough yet to deliver reliable code in a project where you can actually consider that portion fully abstracted. You need to code review and test anything that comes out of it. If you're also considering the tests as being abstracted by LLMs then you have a proper feedback loop of slop.
Also, I'm not suggesting that it's impossible for you to understand, conceptually what you're trying to accomplish without writing the code yourself. That's ludicrous, I'm strictly calling B.S, when you are claiming to be using English as a programming language as if that has been abstracted. Whatever your "workflow" is, you're fooling yourself into thinking you have arrived at some productivity nirvana and are just accumulating technical debt for the future you.
Here is the thing. Your initial claim was that English is the programming language. By virtue of making that claim you are claiming LLM has deterministic reliability equivalent to programming language -> compiler. This is simply not true.
If you're considering the LLM translation to be equivalent to the compiler abstraction, I'm sorry I'm not drinking that Kool aid with you.
You conceded above that LLMs aren't deterministic, yet you proceeded to call them an abstraction (conflating). If the output is not 100% equivalent, it's not an abstraction.
In C, you aren't required to inspect the assembly generated by the C compiler. It's guaranteed to be equivalent. In this case, you really need not write/debug assembly, you can use the language and tools to arrive at the same outcome.
Your entire argument is based on the premise that we have a new layer of abstraction that accomplishes the same. Not only it does not, but when it fails, it does so often in unexpected ways. But hey, if you're ready to call this an abstraction that frees up your cognitive load, continue to sip that Kool aid.
If all that you are really doing is writing your code in English and asking the LLM to re-write it for you in your language of choice (probably JS), then end of discussion. But your tone really implies you're a big fan of the vibes of automation this gives.
Your repeated accusations of "conflating" are a transparent attempt to deflect from the hollowness of your own arguments. You keep yapping about me conflating things. It's ironic because you are the one committing this error by treating the process of software engineering as a set of neatly separable, independent tasks.
You've built your entire argument on a fragile, false dichotomy between "strategic" and "mechanical" work. This is a fantasy. The "mechanical" act of implementation is not divorced from the "strategic" act of architecture. The architectural insights you claim to get from "running code and testing behavior" are a direct result of the specific implementation choices that were made. You don't get to wave a natural language wand, generate a black box of code, and then pretend you have the same deep understanding as someone who has grappled with the trade-offs at every level of the stack.
Implementation informs architecture, and vice versa. By offloading the implementation, you are severing a critical feedback loop and are left with a shallow, surface-level understanding of your own product.
Your food processors and compiler analogy—are fundamentally flawed because they compare deterministic tools to a non-deterministic one. A compiler or food processor doesn't get "creative." An LLM does. Building production systems on this foundation isn't "transformative"; it's reckless.
You've avoided every direct question about your actual workflow because there is clearly no rigor there. You're not optimizing for results; you're optimizing for the feeling of speed while sacrificing the deep, hard-won knowledge that actually produces robust, maintainable software. You're not building, you're just generating.
Do you understand what conflating means? Maybe ask your favorite gpt to describe it for you.
I'm talking about the entire stack of development, from the architectural as well as the actual implementation. These are intertwined and assuming they somehow live separately is significant oversight on your part. You have claimed English is the programming language.
Also. On the topic of conflating, you seem to think that LLMs have become defacto pre-compilers for English as a programming language, how do they do that exactly? In what ways do they compare/contrast to compilers?
You have only stated this as a fact, but what evidence do you have in support of this? As far as the evidence I can gather no one is claiming LLMs are deterministic, so please, support your claims to the contrary, or are you a magician?
You also seem to shift away from any pitfalls of agentic workflows by claiming to be doing all the due diligence whilst also claiming this is easier or faster for you. I sense perhaps that you are of the lol, nothing matters class of developers, reviewing some but not all the work. This will indeed make you faster, but like I said earlier, it's not a cost-free decision.
For individual developers, this is a big deal. You may not have time to wear all the hats all at once, so writing the code may be all the time you also have for code review. Getting code back from an LLM and reviewing it may feel faster but like I said unless it's correct, it's not actually saving time, maybe it feels that way, but we aren't talking about feelings or vibes, we are talking about delivery.
This is called being obtuse. Also, this illustrates my ambiguity point further, your workflow is not clearly described and only further muddled with every subsequent equivocation you've made.
Also, are you actually using agents or just chatting with a bot and copy-pasting snippets? If you write requirements and let the agent toil, to eventually pass the tests you wrote, that's what I assume you're doing... Oh wait, are you also asking the agents to write the tests?
Here is the thing, if you wrote the code or had the LLM do it for you, who is reviewing it? If you are reviewing it, how is that eliminating actual cognitive load? If you're not reviewing it, and just taking the all tests passed as the threshold into production or worse yet, you have an agent code review it for you, then I'm actually suggesting incompetence.
Now, if you are thoroughly reviewing everything and writing your own tests, then congrats you're not incompetent. But if you're suggesting this is somehow reducing cognitive load, maybe that's true for you, in a "your truth" kind of way. If you simply prefer code reviewing as opposed to code writing have it your way.
I'm not sure you're joining the crowd that says this process makes them 100x more productive in coding tasks, I find that dubious and hilarious.
It's not the same. Compilers compile to equivalent assembly, LLMs aren't in the same family of outcomes.
If you are arguing for some sort of euphoria of getting lines of code from your presumably rigorous requirements much faster, carry on. This goes both ways though, if you are claiming to be extremely rigorous in your process, I find it curious that you are wrestling with language syntax. Are you unfamiliar with the language you're developing with?
If you know the language and have gone as far as having defined the problem and solution in testable terms, the implementation should indeed be trivial. The choice of writing the code and gaining a deeper understanding of the implementation where you stand to gain from owning this part of the process come with the price of a higher time spent in the codebase, versus offloading it to the model which can be quicker, but it comes with the drawback that you will be less familiar with your own project.
The question ofhow do I implement this? Is an engineering question, not a please implement this solution I wrote in English.
You may feel like the implementation mechanics are divorced from the problem domain but I find that to hardly be the case, most projects I've worked on the implementation often informed the requirements and vice versa.
Abstractions are usually adopted when they are equivalent to the process they are abstracting. You may see capability, and indeed models are capable, but they aren't yet as reliable as the thing you allege them to be abstracting.
I think the new workflows feel faster, and may indeed be on several instances, but there is no free lunch.
The point I'm driving at is why? Why program in English if you have to go through similar rigour. If you're not actually handing off the actual engineering, you're putting the solution and having it translate to your language of preference whilst telling everyone how much more productive you are for effectively offloading the trivial part of the process. I'm not arguing that you can't get code from well defined, pedantically written requirements or pseudo code. All I'm saying is that that is less than what is claimed by ai maximalists. Also, if that's all that you're doing with your "agents" just write the code on not deal with the pitfalls?
LLMs do not revoke ambiguity from the English language.. Look, if you prefer to use this as part of your workflow and you understand the language and paradigms being chosen by the LLM on your behalf, and can manage to produce extensible code with it, then that's a matter of preference and if you find yourself more productive that way, all power to you.
But when you say English as a programming language, you're implying that we have bypassed its ambiguity. If this was actually possible, we would have an English compiler, and before you suggest LLMs are compilers, they require context. Yes, you can produce code from English but it's entirely non-deterministic, and they also fool you into thinking because they can reproduce in-training material, they will be just as competent at something actually novel.
Your point about waiting on an engineer for a PR is actually moot. What is the goal? Ship a prototype? Build maintainable software? If it's the latter, agents may cost less but they don't remove your personal cognitive load. Because you can't actually let the agent develop truly unattended, you still have to review, validate and approve. And if it's hot garbage you need to spin it all over and hope it works.
So even if you are saving on a single engineer's cost, you have to count your personal cost of baby sitting this "agent". Assuming that you are designing the entire stack this can go better, but if you "forget the code even exits" and let the model also architect your stack for you then you are likely just wasting token money on proof-of-concepts rather than creating a real product.
I also find interesting that so many cult followers love to dismiss other humans in favor of this technology as if it already provides all the attributes that humans possess. As far as I'm concerned cognitive load can still only be truly decreased by having an engineer who understands your product and can champion it foward. Understanding the goal and the mission in real meaningful ways.