obirunda

This is what we call in the business a "fever dream"

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.

https://arxiv.org/abs/2601.02671?hl=en-US

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

Haha wow, you're so so funny. You may have shown too much already. Also, be careful, you might be too smart. You're cute though

Big moat you have there I bet

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.

You keep sidestepping the core issue with LLMs.

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.

The thing that's assumed in "proompting" as the new way of writing code is how much extrapolation are you going to allow the LLM to perform on your behalf. If you describe your requirements in a context-free language you'll have written the code yourself. If you describe the requirements with ambiguity you'll leave enough of narrowing it down to actual code to the LLM.

Have it your way, but the current workflow of proompting/context engineering requires plenty of hand holding with test coverage and a whole lot of token burn to allow agentic loops to pass tests.

If you claim to be a vibe coder proompter with no understanding of how anything works under the hood and claim to build things using English as a programming language, I'd like to see your to-do app.

I don't think you understand why context-free languages are used for programming. If you provide a requirement with any degree of ambiguity the outcome will be non-deterministic. Do you want software that works or kind of works?

If someone doesn't understand, even conceptually how requirements

The dichotomy between the people who are "orchestrating" agents to build software and the people experiencing this less than ideal outcomes from LLMs is fascinating.

I don't think LLM for coding productivity is all hype but I think for the people who "see the magic" there are many illusions here similar to those who fall prey to an MLM pitch.

You can see all the claims aren't necessarily unfounded, but the lack of guaranteed reproducibility leaves the door open for many caveats in favor of belief for the believer and cynicism for everybody else.

For the believers if it's not working for one person, it's a skill issue related to providing the best prompt, the right rules, the perfect context and so forth. At what point is this a roundabout way of doing it yourself anyway?

Yeah, it may feel scary but the biggest issue yet to be overcome is that to replace engineers you need reliable long horizon problem solving skills. And crucially, you need to not be easily fooled by the progress or setbacks of a project.

These benchmark accomplishments are awesome and impressive, but you shouldn't operate on the assumption that this will emerge as an engineer because it performs well on benchmarks.

Engineering is a discipline that requires understanding tools, solutions and every project requires tiny innovations. This will make you more valuable, rather than less. Especially if you develop a deep understanding of the discipline and don't overly rely on LLMs to answer your own benchmark questions from your degree.

I think OpenAi will drop their ambition for AGI and focus on product, they'll never state this of course, but it's clearly telegraphed in this for profit move.

Research and safety have to take a backseat for cost reduction. I mean there are many avenues to profitability for them, one I can think of is they could cut their cost significantly by creating smaller and smaller models that match or nearly match Gpt4, while paid subscribers wouldn't be able to really tell the difference. No one is really challenging them on their benchmark claims.

I think their main challenge is that in 5-10 years from now, if their current definition of AGI is still elusive, models of Gpt4 capabilities or similar (Llama 3 can fool most people I think) will be running locally and freely on pretty much any OS of choice without having to make a single outside API call. Every app will have access to local inference that neither costs developers nor the users anything to use. Especially after the novelty has worn off a bit, it's hard to see consumers or developers paying up to use something that's technically better but not significantly enough to justify a $20+/mo subscription or per token cost. Right now though, local inference has a huge barrier of entry, especially when you think across platforms.

Honestly, I think Google and Apple can afford to spend the cash to develop these models in perpetuity, while OpenAi needs to worry about massive revenue growth for the next few years, and they probably don't really have the personnel to grow revenue aggressively either. It's a research lab. The downside of revenue seeking too, is that sometimes the pursuit kills the product.

I think at its core it's not that there isn't value or future value, but currently there is an assertion, maybe some blind faith, that it's inevitable that a future version will deliver a free lunch for society.

I think the testimonies often repeated by coders that use these code completion tools is that "it saved me X amount of time on this one problem I had, therefore it's great value". The issue is that these all fall into a research of n=1 test subjects. It's only useful information for the subject. It appears we don't realize in these moments that when we use those examples, even to ourselves, we are users reviewing a product, as opposed to validating if our workflow is not just different but objectively better.

The truth lies in the aggregate data of the quality and crucially the speed by which fixes and requirements are being implemented at scale across code bases.

Admittedly, a lot of code is being generated, so I don't think I can say everyone hates it, but until someone can do some real research on this, all we have are product reviews.

Especially when you separate the ethereal "hard problems" from every day queries local LLMs can answer equally as well as SOTA models, the value proposition for these expensive models plummets. If it can't solve real hard, long horizon problems the 10% lift on a given benchmark is not a material value prop to the end user to choose a local free version over the API costs or the monthly subscription.

I think the primary reason is that datasets contain a lot more average/bad code than exceptional, and to add to that problem judging between those is possibly a subjective issue.

Developers using AI will get mostly average solutions faster but exceptional ones will be obviously rare. And, crucially if the idea itself is average or bad there isn't much an elegant coding solution will do for the idea.

I think this ultimately is the divide between the hype and reality of how AI will impact products. If you just give a product manager the keys to do all the coding as no code "prompt engineer", more than likely will lead to further enshitification of features in products with unmaintainable code bases. At the current state, understanding algorithms and thinking computationally is a requirement to improve a code base.

The hopes of having a "build me a $1 billion app" prompt capability, or "improve my shitty app" are too long horizon and subjective requests to bypass the hardships of product ideation and iteration to have the LLM deliver on the requests. It's not magic, it's probability. Averages are the end goal here, not excellence.

If we arrive at a point where LLMs translate general prompts into idealistic versions that are more like version 100 of the idea while still capturing the user's intent, then we will see these improvements. Otherwise it's copy pasta on steroids, and done mindlessly, will mostly lead to enshitification rather than improvements.

Ok. This is even worse. You shouldn't use your misunderstandings from previous discussions with other people and make generalizations with everybody else you meet on new discussions, especially if you are using an incendiary tone.

"the idea that markets balance everything to the advantage of everybody then seems to be just an excuse to be egoistic and without any care for others."

There are two problems here: 1. You misstate and mischaracterize free-market ideology as having the pretense of being to the "advantage of everybody". It's potentially a byproduct but definitely not a first principle. 2. You cast a judgment of value on egotism and selfishness as being the true motivators behind free market proponents. Selfishness and egotism are human characteristics expressed across all ideological spectrums.

"Don't get me wrong, nobody has to care for others and I am not going to be the person to force you, but if you don't care about others please stop pretending you are doing it for the greater good." - Here is where you conflate utilitarian with libertarian ideology, especially as you label those who disagree with your view as pretenders and posers for the greater good, again misstating the position of your ideological opponent and then proceeding to cast a judgment of value on the positions they don't actually hold.

Not trying to be mean here, but have you thought about getting some reading comprehension lessons? It could really help you understand the things that you read as well as give you a more well rounded view things.