The force-feeding of AI features on an unwilling public • Hacker News Board

Re: The force-feeding of AI features on an unwilling public

#381

Post by fehu22 » Mon, Jul 07, 2025, 4:54 PM UTC

dang wrote: post #115

I also find these features annoying and useless and wish they would go away. But that's not because LLMs are useless, nor because the public isn't using them (as daishi55 pointed out here: https://news.ycombinator.com/item?id=44479578 ) It's because the integrations with existing products are arbitrary and poorly thought through, the same way that software imposed by executive fiat in BigCo offices for trend-chasing…

google is sending pop-up sonyliv open emails suggesting that they will use our data and help us with a. i. which should not be accepted at all the pop-ups even don't disappear this is a real cheating and fraud

Re: The force-feeding of AI features on an unwilling public

#382

Post by [deleted] » Mon, Jul 07, 2025, 4:54 PM UTC

obirunda wrote: post #379

handfuloflight wrote: post #377

Earlier quoted context omitted.

Yes, I maintain the same engineering rigor: but that rigor now goes toward solving the actual problem instead of wrestling with syntax, debugging semicolons, or managing language specific quirks. My cognitive load shifts from "how do I implement this?" to "what exactly do I want to build?" That's not a trivial difference, it's transformative. You're calling implementation "trivial" while simultaneously arguing I shou…

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 th…

[deleted]

Re: The force-feeding of AI features on an unwilling public

#383

Post by handfuloflight » Mon, Jul 07, 2025, 4:58 PM UTC

obirunda wrote: post #379

handfuloflight wrote: post #377

Earlier quoted context omitted.

Yes, I maintain the same engineering rigor: but that rigor now goes toward solving the actual problem instead of wrestling with syntax, debugging semicolons, or managing language specific quirks. My cognitive load shifts from "how do I implement this?" to "what exactly do I want to build?" That's not a trivial difference, it's transformative. You're calling implementation "trivial" while simultaneously arguing I shou…

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 th…

'I find it curious that you are wrestling with language syntax': this reveals you completely missed my point while questioning my competence. You've taken the word 'wrestling', which I used to mean 'dealing with', and twisted it to imply incompetence. I'm not 'wrestling' with syntax due to incompetence. I'm eliminating unnecessary cognitive overhead to focus on higher-level problems.

You're also conflating syntax with implementation. Implementation is the logic, algorithms, and architectural decisions. Syntax is just the notation system for expressing that implementation. When you talk about 'implementation informing requirements,' you're describing the feedback loop of discovering constraints, bottlenecks, and design insights while building systems. That feedback comes from running code and testing behavior, not from typing semicolons. You're essentially arguing that the spelling of your code provides architectural insights, which is absurd.

The real issue here is that you're questioning optimization as if it indicates incompetence. It's like asking why a professional chef uses a food processor instead of chopping everything by hand. The answer isn't incompetence: it's optimization. I can spend my mental energy on architecture, system design, and problem-solving instead of semicolon placement and bracket matching.

By all means, spend your time as you wish! I know some people have a real emotional investment in the craft of writing syntax. Chop, chop, chop!

Re: The force-feeding of AI features on an unwilling public

#384

Post by [deleted] » Mon, Jul 07, 2025, 5:03 PM UTC

AppleBananaPie wrote: post #256

spacemadness wrote: post #241

Having seen the almost rabid and fearful reactions of product owners first hand around forcing AI into every product, it’s because all these companies are in panic mode. Many of these folks are not thinking clearly and have no idea what they’re doing. They don’t think they have time to think it through. Doing something is better than nothing. It’s all theatre for their investors coupled with a fear of being seen as f…

Yeah the internal 'experts' pushing ai having no idea what they're doing but acting like they do is like a weird fever dream lol Everyone nodding along, yup yup this all makes sense

[deleted]

Re: The force-feeding of AI features on an unwilling public

#385

Post by obirunda » Mon, Jul 07, 2025, 5:49 PM UTC

handfuloflight wrote: post #383

obirunda wrote: post #379

Earlier quoted context omitted.

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 th…

'I find it curious that you are wrestling with language syntax': this reveals you completely missed my point while questioning my competence. You've taken the word 'wrestling', which I used to mean 'dealing with', and twisted it to imply incompetence. I'm not 'wrestling' with syntax due to incompetence. I'm eliminating unnecessary cognitive overhead to focus on higher-level problems. You're also conflating syntax wit…

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.

Re: The force-feeding of AI features on an unwilling public

#386

Post by nitwit005 » Mon, Jul 07, 2025, 5:56 PM UTC

daishi55 wrote: post #62

ChatGPT is the 5th most-visited website on the planet and growing quickly. that’s one of many popular products. Hardly call that unwilling. I bet only something like 8% of Instagram users say they would pay for it. Are we to take this to mean that Instagram is an unpopular product that is rbi g forced on an unwilling public?

People want these features as much as they wanted Cortana on Windows.

Which is to say, there's already a history of AI features failing at a number of these larger companies. The public truly is frequently rejecting them.

Re: The force-feeding of AI features on an unwilling public

#387

Post by handfuloflight » Mon, Jul 07, 2025, 6:09 PM UTC

obirunda wrote: post #385

handfuloflight wrote: post #383

Earlier quoted context omitted.

'I find it curious that you are wrestling with language syntax': this reveals you completely missed my point while questioning my competence. You've taken the word 'wrestling', which I used to mean 'dealing with', and twisted it to imply incompetence. I'm not 'wrestling' with syntax due to incompetence. I'm eliminating unnecessary cognitive overhead to focus on higher-level problems. You're also conflating syntax wit…

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, a…

You're conflating different types of cognitive overhead. There's mechanical overhead (syntax, compilation, language quirks) and strategic overhead (architecture, algorithms, business logic). I'm eliminating the mechanical to focus on the strategic. You're acting like they're the same thing.

Yes, I still need to verify that the generated code implements my architectural intent correctly, but that's pattern recognition and evaluation, not generation. It's the difference between proofreading a translation versus translating from scratch. Both require language knowledge, but reviewing existing code for correctness is cognitively lighter than simultaneously managing syntax, debugging, and logic creation.

You are treating all cognitive overhead as equivalent, which is why you can't understand how automating the mechanical parts could be valuable. It's a fundamental category error on your part.

Re: The force-feeding of AI features on an unwilling public

#388

Post by obirunda » Mon, Jul 07, 2025, 6:47 PM UTC

handfuloflight wrote: post #387

obirunda wrote: post #385

Earlier quoted context omitted.

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, a…

You're conflating different types of cognitive overhead. There's mechanical overhead (syntax, compilation, language quirks) and strategic overhead (architecture, algorithms, business logic). I'm eliminating the mechanical to focus on the strategic. You're acting like they're the same thing. Yes, I still need to verify that the generated code implements my architectural intent correctly, but that's pattern recognition…

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.

Re: The force-feeding of AI features on an unwilling public

#389

Post by handfuloflight » Mon, Jul 07, 2025, 6:59 PM UTC

obirunda wrote: post #388

handfuloflight wrote: post #387

Earlier quoted context omitted.

You're conflating different types of cognitive overhead. There's mechanical overhead (syntax, compilation, language quirks) and strategic overhead (architecture, algorithms, business logic). I'm eliminating the mechanical to focus on the strategic. You're acting like they're the same thing. Yes, I still need to verify that the generated code implements my architectural intent correctly, but that's pattern recognition…

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 L…

You're projecting. You're the one conflating here, not me.

You've conflated "architectural feedback from running code" with "architectural feedback from typing syntax." I am explicitly saying implementation feedback comes from "running code and testing behavior, not from typing semicolons", yet you keep insisting that the mechanical act of typing syntax somehow provides architectural insights.

You've also conflated "intertwined" with "inseparable." Yes, architecture and implementation inform each other, but that feedback loop comes from executing code and observing system behavior, not from the physical act of typing curly braces. I get the exact same architectural insights from reviewing, testing, and iterating on generated code as I would from hand-typing it.

Most tellingly, you've conflated the process of writing code with the value of understanding code. I'm not eliminating understanding: I'm eliminating the mechanical overhead while maintaining all the strategic thinking. The cognitive load of understanding system design, debugging performance bottlenecks, and architectural trade-offs remains exactly the same whether I typed the implementation or reviewed a generated one.

Your entire argument rests on the false premise that wisdom somehow emerges from keystroke mechanics rather than from reasoning about system behavior. That's like arguing that handwriting essays makes you a better writer than typing them : confusing the delivery mechanism with the intellectual work.

So yes, I understand what conflating means. The question is: do you?

Re: The force-feeding of AI features on an unwilling public

#390

Post by obirunda » Mon, Jul 07, 2025, 7:39 PM UTC

handfuloflight wrote: post #389

obirunda wrote: post #388

Earlier quoted context omitted.

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 L…

You're projecting. You're the one conflating here, not me. You've conflated "architectural feedback from running code" with "architectural feedback from typing syntax." I am explicitly saying implementation feedback comes from "running code and testing behavior, not from typing semicolons", yet you keep insisting that the mechanical act of typing syntax somehow provides architectural insights. You've also conflated "…

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.