Hacker News Reader

Comment by glimshe | Hacker News Reader

A lot of people here seem to be living in a different universe than me or simply don't know how to work with AI. I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you. They get mad at Excel for the poor investment returns. At this point, this is such a strawman, it isn't worth counter arguing.

I think I'll abandon this discussion and keep using AI quietly while exchanging tips with like-minded people who are interested in using it properly and efficiently.

View on HN

> A lot of people here seem to be living in a different universe than me

I feel this way on this topic too.

> I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.

The problem is; how _should_ I use AI? On a previous thread, I had two replies to the same comment, one saying "provide the LLM all the context it needs and let it go ham", and the other saying "Carefully guide and craft it and review everything". Both subthreads had people agreeing.

My experience with LLMs is leaving them unattended gives very poor results within a handful of iterations, and that carefully guiding them can be a value add, but the effort ot do that is very often as much as just writing the damn code myself, particularly if there's a few iterations that go on.

I think the main cause of different views is just the fact that people have very different products and codebases they're working on. Therefore, the requirements and applicability of AI varies a lot, case-by-case. It would be useful if people always explained their exact use cases when making claims one way or another. I understand it's not feasible for many use cases to reveal exact details, but at least some transparency would be great.

I've found AI to be immensely useful in gamedev, mainly UX development, research, and curation. In those areas I let it go quite wild, with mechanical and visual tests for UX, and summaries for research and curation. I've also made skills, custom subagents, hooks, and scripts (all made with AI assistance) to streamline development.

Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big. If I worked on, let's say banking, I'd be much more careful. On my day job, as a data scientist (moving towards product owner) in a large industrial company, I'm much more careful. UX can run on vibes, but anything that touches data processing or business logic needs to be looked at by a human, row by row. Depending on use cases, it may be fine to look at only the tests. The main problem is that there's so much stuff to review, and maybe 98% of it is fine. It's then very boring to try to spot the 2%. I don't have good solutions for that yet, and idk if anyone does.

> It would be useful if people always explained their exact use cases when making claims one way or another. I understand it's not feasible for many use cases to reveal exact details,

It would be useful if people _ever_ explained the use cases. Even Anthropic when they're publishing their materials are hand wavey about this.

> Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big

I couldn't disagree more. I run an engineering team in GameDev, and AI is great at making a gigantic mess. It's great for generating a lot of code, but the minute that doesn't do what you want it to, you now need to go back and learn _everything_ that it's generated. And IME, doing that is as bad as having just written it yourself in the first place.

> he main problem is that there's so much stuff to review, and maybe 98% of it is fine. It's then very boring to try to spot the 2%. I don't have good solutions for that yet, and idk if anyone does.

I tentatively agree here, except I've found about 50% of it is "fine", 40% of it is "this works but isn't really what I want to put into my product" and 10% is "absolutely not".

AI is great at reading, so give it things to read. Claude will try to throw big markdown docs in your repo, but you don't have to do that. Make it keep docs by the code.

I include a line in AGENTS.md that says "We *always* add docstrings to methods, classes, structs, and namespaces - there should be 100% coverage of docstrings."

It will make better choices about what functions to make or remove if you force it to justify why the function exists.

And when you have to go back and understand, it becomes easier.

It’s clear at this point that agents don’t actually follow agents.md

They try to but they don’t. As an example, we use perforce in games. I regularly have to stop an agent and remind it to use p4 edit rather than blasting through the read only flag, despite the first paragraph of Claude.md being “this is a project using perforce. Batch call p4 edit on all files before modifying, do not manually remove the read only flag”

> It would be useful if people _ever_ explained the use cases. Even Anthropic when they're publishing their materials are hand wavey about this.

Yes, good addition.

> I couldn't disagree more. I run an engineering team in GameDev, and AI is great at making a gigantic mess. It's great for generating a lot of code, but the minute that doesn't do what you want it to, you now need to go back and learn _everything_ that it's generated. And IME, doing that is as bad as having just written it yourself in the first place.

Yeah, I should have been more specific since our use cases are very different. I'm working solo on small games, so it's easier to keep the AI on a leash. I can imagine it can be a nightmare on large code bases with many collaborators.

> I tentatively agree here, except I've found about 50% of it is "fine", 40% of it is "this works but isn't really what I want to put into my product" and 10% is "absolutely not".

Yeah, probably our use cases are very different here too. We mostly develop/maintain dozens of microservices for internal use, mostly greenfield, relatively small in scope, and with 1-3 developers in each. And maybe 98% was a bit too optimistic. The larger and older the codebase, the more problems AI tends to create. But it's very good at helping to understand old codebases (even those written by myself haha).

Oh, and esoteric data science topics can be a minefield too. If there's a topic that's new to me, It's difficult to know what is hallucination and what is not. It's best to let AI suggest alternative methods and then study those yourself.

> Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big

Hi, professional game dev here. No it's not. Thank you for reading.

Yeah, as I said in a reply to another comment, I oversimplified there. What I should have said is that solo or almost-solo gamedev with relatively small games is a good example of where AI shines. I don't have experience of developing larger games in larger teams.

I've found that these models are extremely good at reasoning since late last year, but they're basically 200 IQ Amelia Bedelias. So my working model earlier this year was to give it a brief instruction and watch how it failed, which was generally a lack of context that it couldn't have possibly known. Then I'd add that context to the team AI docs repo, try again from scratch, and iterate until it did what I wanted without me having to give a bunch of detail in the prompt. Over the course of 2-3 months, I needed to give new context and steering less and less.

I also encouraged my team to paste any inquiries or alerts we got in our slack channel verbatim into codex and follow that procedure until it could figure it out as a one-shot.

I still treat it as more of a design and coding partner day-to-day, so I'm typically not trying to one-shot, but it can e.g. be triggered by a pagerduty alert, reference our code, check grafana panels, query application state across different servers/clusters, and come up with bug fix PRs all autonomously, and then post its analysis, mitigation suggestions, and PR link to slack for the on-caller to review. This was all just some docs, scripts, and a little listener service to trigger a one-shot model prompt that we built.

As a design partner, it's made it easier to add more telemetry or create rapid prototypes to check my assumptions. I've encouraged my team to regularly ponder on what facts they wish they knew, no matter how difficult it would be to find out. Pretend you could just ask God anything you want to know. Then ask the AI to go add whatever's needed to find out. We should all move toward a perfect intuition for what our system is doing because all questions can now be easily answered if we can only think to ask them.

The reality of the current situation is that we have dozens of families of different model; each of which is differentiated further into various revision numbers and power levels, and depending on which one you use and what the nature of the tasks is, you very much need a different usage style that can only be discerned after multiple (Sometimes very many) sessions of using that individual model for that category of task. It is not one size fits all, and trying to pretend that it is will lead to failure.

> It is not one size fits all, and trying to pretend that it is will lead to failure.

I'm not asking for a one size fits all solution. I'm asking for "vibe coding with Codex on GPT 5.6 with high is the way, but if you want to be more ivnolved, Sonnet 4.6 on Claude is the path. Here's the proof."

Saying that it depends and it's impossible to quantify allows the camp who are claiming it's more productive to say "you're holding it wrong".

It’s a very soft skill that changes as the capabilities of AI change.

But one thing that doesn’t change is the need to specify an end goal correctly and precisely. I think the emphasis of knowledge/information-processing work is going to increasingly be placed on verification mechanisms. This is practically equivalent to precisely defining an end goal.

Spend time deeply thinking about what it means for a solution to be correct. What properties will a correct solution have? What of those properties are testable? Write those things down and tell the agent.

As models get better, agents will be able to target more and more difficult end goals. The strategy just becomes more useful. (It’s useful for people as well.)

For example, if you want an agent to write a photo editor, think about what end properties the editor should have. There are reference images for color space and rendering transformations. That’s a good start.

Sometimes the goal will be fuzzier. “I want a feature like CaptureOne where I provide a reference image and it makes my image look like that.” Well, time to think really hard about what that means. Iterate with AI on how to test for that precisely. Come up with some good metrics/heuristics. Maybe it means local contrast should match. Maybe the overall distribution of colors. Maybe something more complicated.

Then you have a target and you can let an implementation agent work against that. If it fails, it’s either because the agent is bad or your target was incorrect or incomplete. As models get better, the limiting factor becomes your ability to correctly define a problem.

I don't generally use AI to write code I feel I can write efficiently. In these cases, I'll just ask AI for a review. But when I need to write code in areas I'm less confident about, I'll let AI take the reins and the do a thorough review myself. These instances are not too common, though.

I also ask direct questions to AI for brainstorming and advanced programming language usage. In these cases, AI isn't touching the code.

> But when I need to write code in areas I'm less confident about, I'll let AI take the reins and the do a thorough review myself.

I see this mindset a bunch, and I just don’t get it. Reviewing code is so much harder than writing code! To write code, I need to find one path to achieve my goal, and convince myself, the compiler, and the reviewer that it does so. To review code, I need to consider all reasonable paths to achieve the goal, and confirm that a sufficiently-good one was selected. This is why we have junior engineers write code and seniors review it. If you’re beyond your comfort level writing it, how can you possibly review whether the author (AI or otherwise) made good choices? You only have exposure to one possible choice lane, and by problem statement you weren’t comfortable populating the other lanes…

To write code, I effectively need to do a mini-review as I go, and type vastly slower than the AI. To review code, given that all the automated checks are out of the way, I need to consider the objectives of the code (in terms of fitting into the existing codebase, having a reasonably appropriate style, etc.) and ensure there isn't anything too far out of line. Knowing that something is "sufficiently good" doesn't entail awareness of all possibilities, because you aren't ranking the thing but measuring it.

Seniors review code because they have a much better understanding of the necessary taste and discretion, and an awareness of the larger system the code will integrate into, whereas there's only so much you can learn about coding that's relevant to most of the code you'll write (and only so fast you'll ever really be able to type it, and most of the issues can be caught by automated, deterministic systems).

Seeing a solved problem and verifying the solution's correctness is much easier than solving the problem yourself. it's a bit like riddles. You can find examples of that when studying any topic. I disagree that reviewing code is harder than writing code in all/most instances.

Also, there's code that is just tedious and repetitive to write. AI can write that and reviewing is pretty easy.

You could ask someone a math question, and they can write an equation down, and the equation can be mathematically sound, but it still not be the right form of the equation, or even relate to the question correctly at all. If all you're being asked to do is validate the mathematical soundness of the equation then sure, it's not that hard and it often mechanical, probably easier than having to generate the equation. But that isn't review -- that's cargo-culting what review is supposed to be.

To bring back to code: They are making the point that verifying "correctness" is not the be all and end all of code review. In every situation, there are multiple "correct" solutions, and only a few of them are actually correct and fit within the past, current and future context (technical and business). If someone isn't doing this, they aren't reviewing effectively and are acting as a glorified linter, which is an astonishingly low value-add use of human capacity.

There are situations where nobody really cares about the output, and nobody wants the true form of review, so it reverts to (at best) human-linting. In those situations, engineering capability of any kind functionally has no moat and all participants are equally fungible. If the business is dependent on engineering it's also a horrendous business. I would personally avoid being involved in these environments in an engineering capacity. I mean this in a diagnostic sense - it's a terrible career move, though there will always be busy work that's exactly what we have LLMs for.

Latest models like Opus 5.0 work well in both scenarios. You can just give it a goal and let it make a plan, review the plan and then let it go ham.

Or you can also use it piece-meal and have it do parts of work that you want. It works in both ways and works really well.

I don't think there is any model right now that you can use with 0 oversight, but you can do pretty complex stuff without writing single line of code at this point.

What can be concluded is that some get immense value out of Ai and some are incredibly critical of that claim.

I do not know what the secret sauce is.

But I have a responsibility to the team I lead. I need to protect our velocity. Which means that my hiring practices now include specific checks that people are able to work with ai.

In the end, it might be a step thing. Some people are just inherently incapable of working with this technology...

it depends on what it is you are doing. if the complexity is low (frontend, GUI) you can just prompt it once and refine at the end.

if the complexity is high but you know how the task is to be done then what you can do is divide the task into pieces yourself or with the help of the LLM and use an LLM for each piece.

if the task is complex and you don't have a good idea how it is to be done then you need to start exploratory work with the LLM (multiple sessions, don't reuse the sessions for code).

how to use an LLM correctly is a skill in and of itself. the people who say that LLM's are bad either haven't used any good ones and have such disorganized thinking processes that they are unable to encode them into English good enough for an LLM.

The truth is that using AI well is a skill much like anything else. There's no one single way to use it much like there's no one single way to write a program that serves hackernews.

>There's no one single way to use it

The fact that people jump on the "you're simply using it wrong" wagon in every HN comment section whenever someone shares their negative/neutral experience with it implies otherwise.

There can be many correct ways to use a tool, while still having incorrect ways to use it.

Sometimes you need to set your oven to grill, other times fan force. But if you're complaining about getting burned then, yes, you're simply using it wrong.

I agree with you.

> I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.

However this is how it’s marketed. C-suite is telling people eventually you won’t need to read code, frontier labs saying programmers won’t exist etc.

The reality is like you said, a tool to accelerate you.

You can today develop a mobile app with 20 screens without ever reviewing any of the code generated.

If you test each feature and have it iterate on your feedback, you can build a decent product in this way.

Does it write too much code? Perhaps. Could I bring those 100k lines through code review in a team where some members nitpick? No.

That does not change the fact that it works, and that you do not need to read the code even today.

Unless progress slows down dramatically and soon, it seems rather likely that most of us will not be reading code in the near future. Their marketing is not wrong.

Unless the app is released and running on user’s device, your “it works” is on the level of hackathon’s demo. Being on prod has always been the true testing ground of code.

It seems like when people are talking about production level quality and how the AI. should be helping them there, plenty of people comes up with their “it works on my machine” anecdotes.

Honestly, things have really changed in the past 6 months. Opus 4.5 got most of the way there, and Fable can now literally one-shot your run off the mill CRUD app.

I use a few of them daily. While there are still bugs, there are significantly less than there used to be back when everything was being maintained in my spare time.

Still not Netflix/Google standard yet, but definitely better than the average side project or pre-AI Bangalore special.

I use the app every day and I am confident in the quality.

I will launch it by the end of August. After ~4 months of hard work.

If it’s 4 months of hard work, then it’s not like you’re blindly doing it as the top commenter mentioned.

That is true, I was mostly speaking about a supposed need to review the code.

My effort instead goes to manual QA testing, providing feedback and preferences, and asking questions.

The limitation here is mostly that the model does not know what looks and feels good.

With improvements to the vision capabilities and a better understanding of motion, or what looks appealing to humans, the implementation could probably happen much more autonomously.

> That is true, I was mostly speaking about a supposed need to review the code.

Until you go to prod, you can believe a lot of things about the state of your code. Reviewing code is not merely about “Does this things work”. Testing and linting do cover most of that. Reviewing is mostly about: Will this design cover the current set of constraints (some may be conformance) and can it evolve? Are the assumptions correct? Is the security layer good enough?…

The user interface part of the code is only one single component out of many.

In the context of a mobile app the user interface is the main part.

Testing and linting often do not cover whether things work or provide decent UX. The 'security layer' is almost irrelevant here.

Do you do mobile app development? I would guess not.

Then you would have guessed wrong.

Even though a lot of mobile app are just presentation layer for a backend service, there are indeed a few stuff that warrants carefulness.

Like any data saved offline. Any update to that offline format means a migration plan unless it’s just a cache for the online data. Then if you support something like multiple organization, you don’t want user data to jump the separation between those siloes. And finally, if you you data that are created locally, or present data that are transformed locally using some feature, you have to be sure you’re not corrupting it or open some side vulnerabilities (think about the clickable vulnerability in messaging apps).

UX and UI can be designed using a prototyping tool coupled with user feedbacks. And with the wealth of components in the mobile SDK and the UI toolkit ability to create custom widgets, it’s very easy to implement the final version of that design. Most of the delicate work is presenting the correct information and that each interaction proceeds well.

I was not talking about a backend service here.

Regarding clickable vulnerabilities in messaging apps, are you referring to the exploits that were enabled by vulnerabilities in system media parser and browser components?

This has essentially no practical relevance to app implementation.

What we are left with is not corrupting user data, particularly during migrations on app updates.

Compared to the attack surface of a backend service that handles user data, this is trivial.

We agree that the delicate work is presentation and interactions working well on device.

In my opinion this is best supported by extensive manual QA and user testing, rather than code review. This is what unlocks tremendous productivity for mobile app development with AI.

I really hope vibe coded apps have to be labeled as such so I can make sure to avoid using them. As a customer, I have zero interest in using something that was made with little care or expertise.

If you think that the app I am working on suffers from little care or expertise, you would be mistaken.

It works far better than the competition.

Did you think for a second that maybe other people work with other languages, domains, tools and work approaches than you?

It's so bizarre that noone realizes that there's a bit of a difference between banging together JavaScript into websites, writing firmware for widgets, herding servers or fixing medical devices?

This right here is the truth. Too often people talk in abstract ways, not disclosing what they're actually working on. And then they tell their experiences as universal facts.

The goal of software development is to eventually be done. Yes there are new incentives or new use cases that come up, but the aim should be towards a stable state where you're barely have to work on the software anymore. It's like an house where you spend a good chunk of money to build it, but afterwards you just maintain it.

That's my main issue with AI hypers. There's often no goal in sight, they're just busy for the sake of being busy. They talk about their process, but not their objectives. It's not about progress for them, it's only about being in motion.

The reason they don’t disclose what they’re working on is because it’s always some CRUD app

This (fixing bugs, making code better, refactoring), is the best fit for AI.

I think a lot of us were excited that we will finally be able to polish our old software.

Many of us were never given the opportunity and were tasked to produce new features at an ever increasing pace. Depending on where you landed you can be either elated or jaded.

It appears to me that this is the same pattern you often see when junior employees are given one or more resources intended to help them succeed. Despite having access to those resources, there is frequently no shortage of complaints about how incompetent people are, that they "should know" esoteric home-built sowtware patterns or business knowledge without being told or that they failed to perform a task in the one specific way that someone considers the "correct" approach.

LLMs are the first tech topic I’ve seen that attracts as much wishcasting as political debates. Some people get attached to the conclusion they want to believe and get angry at anyone who disagrees with them.

Most of the tech people I talk to outside of HN, Reddit, Twitter, and other debate heavy spaces have a more nuanced view. In group chats we share stories about the amazing things we got out of an LLM today, or the hilarious failures or mistakes they made. We share tips and battle stories. We talk about the pros and cons of different models. We discuss the hard things we’re doing that LLMs can’t handle yet.

Go on HN or LinkedIn or Lobsters and there are some comments from people who seem like they’re coming from a different universe or timeline. Some people claim LLMs are doing everything in their life perfectly. They’re posting thought leader Tweets about working 2 hours per day and doing everything with ChatGPT voice so they don’t even need to be at their computer. Others are claiming that LLMs are useless and they can’t get anything usable out of them at all, or that they create more problems than they solve.

It’s weird. I can’t recall a time when people in tech were having hot takes that disagreed with such polarized extremes. Like I can look at LLM output all day long and see that both of the extreme takes are not right, but they’re all steadfast in their ideas.

I find plenty of nuanced takes on HN. Honestly I think it's easier here than elsewhere; I just have to filter down to them. On other platforms, polarized takes are incentivized by the struggle for "engagement". (Youtubers often have fairly nuanced takes, but are incentivized to clickbait by misrepresenting themselves as believing something more extreme. Then they're incentivized to make a longer video, wasting your time and distributing the interesting bits across the middle.)

I think LinkedIn belongs in a natural category with Reddit and Twitter far more than HN does.

Reminds me those Bitcoin threads where I would explain a use case it solved for me and everyone was like "nope that's impossible, there's no use case". And before the inevitable replies come in: no, I'm not saying AI is like Bitcoin.

There is an argument that there is a lot propaganda in this space - because the issue of AI is now an issue of international security and politics.

I see a lot of the disagreement here has the same form as many of the political arguments from 10 years ago.

Hell, $20/month is a pretty good deal for something that can proofread a 100 page report, do some light research work, and write some quick and dirty scripts. It doesn't have to replace the entire job of programming to be really damn useful. The pushback against using it even for these simple tasks seems utterly unreasonable to me.

Just exploit the edge while it lasts lol

[flagged]

It's true that metacommenting about leaving a discussion in order to leave a supercilious last word is a flamebait trope. But please don't respond by breaking the site guidelines yourself. That only makes things worse.

https://news.ycombinator.com/newsguidelines.html

Understood, I've read the guidelines and will endeavour to follow them.

Appreciated!

[flagged]

Please don't use quotation marks to make it look like you're quoting someone when you aren't. That's also a snark trope, and we're trying to avoid those here.

https://news.ycombinator.com/newsguidelines.html

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

> A lot of people here seem to be living in a different universe than me or simply don't know how to work with AI. I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.

Where do you suppose those misconceptions on how to use the tool comes from? That's rhetorical because the answer is obvious: the people selling the tools and their army of bots and sycophants. You can't be mad at people for being like "hey I tried to use this tool in the way it has been sold to me and its not delivering on its promises"

Reply on news.ycombinator.com