I'm dialing back my LLM usage

I use an LLM primarily for smaller, focused data analysis tasks so it's possible to move fast and still stay reasonably on top of things if I'm even a little bit careful. I think it would be really easy to trash a large code base in a hurry without some discipline and skill in using LLM. I'm finding that developing prompts, managing context, controlling pace, staying organized and being able to effectively review the LLM's work are required skills for LLM-assisted coding. Nobody teaches this stuff yet so you have to learn it the hard way.

Now that I have a taste, I wouldn't give it up. There's so much tedious stuff I just don't want to have to do myself that I can offload to the LLM. After more than 20 years doing this, I don't have the same level of patience anymore. There are also situations where I know conceptually what I want to accomplish but may not know exactly how to implement it and I love the LLM for that. I can definitely accomplish more in less time than I ever did before.

I don't mind when other programmers use AI, and use it myself. What I mind is the abdication of responsibility for the code or result. I don't think that we should be issuing a disclaimer when we use AI any more than when I used grep to do the log search. If we use it, we own the result of it as a tool and need to treat it as such. Extra important for generated code.

Likely (as am I).

> LLMs are exciting but they produce messy code for which the dev feels no ownership. [...] The other side of it is people who seem to have 'gotten it' and can dispatch multiple agents to plan/execute/merge changes across a project

Yup, can confirm, there are indeed people with differing opinions and experience/anecdotes on HN.

> want to tell you how awesome their workflow is without actually showing any code.

You might be having some AI-news-fatigue (I can relate) and missed a few, but there are also people who seem to have gotten it and do want to show code:

Armin Ronacher (of Flask, Jinja2, Sentry fame): https://www.youtube.com/watch?v=nfOVgz_omlU (workflow) and https://lucumr.pocoo.org/2025/6/21/my-first-ai-library/ (code)

Here's one of my non-trivial open source projects where a large portion is AI built: https://github.com/senko/cijene-api (didn't keep stats, I'd eyeball it at conservatively 50% - 80%)

- one big set of users who don't like it because it generates a lot of code and uses its own style of algorithms, and it's a whole lot of unfamiliar code that the user has to load up in their mind - as you said. Too much to comprehend, and quickly overwhelming.

And then to either side

- it unblocks users who simply couldn't have written the code on their own, who aren't even trying to load it into their head. They are now able to make working programs!

- it accelerates users who could have written it on their own, given enough time, but have figured out how to treat it as an army of junior coders, and learned to only maintain the high level algorithm in their head. They are now able to build far larger projects, fast!

My org has 160 engineers working on our e-commerce frontend and middle tiers. I constantly dive into repos and code I have no ownership of. The gitblame shows a contractor who worked here 3 years ago frequently.

Seems LLM does good in small, bad in medium, good again as small modules within big.

This is definitely something I feel is a choice. I've been experimenting quite a bit with AI generated code, and with any code that I intend to publish or maintain I've been very conscious in making the decision that I own the code and that if I'm not entirely happy with the AI generated output I have to fix it (or force the AI to fix it).

Which is a very different way of reviewing code than how you review another humans code, where you make compromises because you're equals.

I think this produces fine code, not particularly quickly but used well probably somewhat quicker (and somewhat higher quality code) than not using AI.

On the flip side on some throwaway experiments and patches to personalize open source products that I have absolutely no intention of upstreaming I've made the decision that the "AI" owns the code, and gone much more down the vibe coding route. This produces unmaintainable sloppy code, but it works, and it takes a lot less work than doing it properly.

I suspect the companies that are trying to force people to use AI are going to get a lot more of the "no human ownership" code than individuals like me experimenting because they think its interesting/fun.

Below is a link to a great article by Simon Willison explaining an LLM assisted workflow and the resulting coded tools.

[0] https://simonwillison.net/2025/Mar/11/using-llms-for-code/ [1] https://github.com/simonw/tools

One example I deal with frequently is creating Pytorch models. Any real model is absolutely not something you want to leave in the hands of an LLM since the entire point of modeling is to incorporate your own knowledge into the design. But there is a lot of tedium, and room for errors, in getting the initial model wiring setup.

While, big picture, this isn't the 10x (or more) improvement that people like to imagine, I find in practice I personally get really stuck on the "boring parts". Reducing the time I spend on tedious stuff tends to have a pretty notable improvement in my overall flow.

Or, often, sell you something.

I don't see why any of this should be surprising. I think it just reflects a lot of developers using this technology and having experiences that fall neatly into one of these two camps. I can imagine a lot of factors that might pull an individual developer in one direction or the other; most of them probably correlate, and people in the middle might not feel like they have anything interesting to say.

I suspect that's at least partially because all of that doesn't stop the hype from being pushed on and on without mercy. Which in turn is probably because the perverse amounts of investment that went into this have to be reclaimed somehow with monetization. Imagine all those VCs having to realize that hundreds of billions of $$$ are lost to wishful hallucinations. Before they concede that there will of course be much astroturfing in the vein of your last paragraph.

People will always blame someone or something else for laziness.

When I first got into web development there were people using HTML generators based on photoshop comps. They would produce atrocious HTML. FE developers started rewriting the HTML because otherwise you'd end up with brittle layout that was difficult to extend.

By the time the "responsive web" became a thing HTML generators were dead and designers were expected to give developers wireframes + web-ready assets.

Same thing pretty much happened with UML->Code generators, with different details.

There's always been a tradeoff between the convenience and deskilling involved in generated code and the long term maintainability.

There's also the fact that coding is fundamentally an activity where you try to use abstractions to manage complexity. Ideally, you have interfaces that are good enough that the code reads like a natural language because you're expressing what you what the computer to do at the exact correct layer of abstraction. Code generators tend to both cause and encourage bad interfaces. Often the impetus to use a code generator is the existing interfaces are bad, bureaucratic, or obscure. But using code generators ends up creating more of the same.

But also. But also, LLMs are incredibly powerful and capable tools at discovering and finding what the architecture of things is. They have amazing abilities to analyze huge code bases & to build documents and diagrams to map out the system. They can answer all manners of questions, to let us probe in.

I'm looking for good links here. I know I have run across some good stuff before. But uhh I guess this piece that I just found introduces the idea well enough. https://blog.promptlayer.com/llm-architecture-diagrams-a-pra...

And you can see an example in the ever excellent @simonw's review of prompts in copilot. At the end, they briefly look at testing, and it's a huge part of the code base. They ask Gemini for a summary and it spits out a beautiful massive document on how copilot testing works! https://simonwillison.net/2025/Jun/30/vscode-copilot-chat/ https://github.com/simonw/public-notes/blob/main/vs-code-cop...

Now, whether LLMs generate well architects systems is largely operator dependent. There's lots of low effort zero shot ways to give LLMs very little guidance and get out who knows what. But when I reflect on the fact that, for now, most code is legacy code, and most code is hideously under documented, most people reading code don't really have access to experts or artifacts to explain the code and it's architecture, my hope and belief is that LLMs are incredible tools to radically increase maintainability versus where we are now, that they are powerful peers in building the mental model of programming & systems.

This happens with any sufficiently big/old codebase. We can never remember everything, even if we wrote it ourselves

I do agree with the sentiment and insight about the 2 branches of topics frequently seen lately on HN about AI-assisted coding

Would really like to see a live/video demo of semi-autonomous agents running in parallel and executing actual useful tasks on a decently complex codebase, ideally one that was entirely “manually” written by devs before agents are involved - and that actually runs a production system with either lots of users or paid customers

Wow you really nail the point, that's what I felt but I did not understand. Thanks for the comment.

an argument can be made that the code doesn't matter as long as the product works as it's supposed to (big asterisk here)

This is a great read on the situation. Do you think these people are just making it up/generating baseless hype?

I don't think that's the main reason. Well written code is easier to follow even when you haven't written it yourself (or maybe you did but forgot about it).

How you get good results as a team is to develop a shared mental model, and that typically needs to exist in design docs. I find that without design docs, we all agree verbally, and then are shocked at what everyone else thought we'd agreed on. Write it down.

LLMs, like junior devs, do much better with design docs. You can even let the junior dev try writing some design docs.

So if you're a solo developer, I can see this would be a big change for you. Anyone working on a team has already had to solve this problem.

On the subject of ownership: if I commit it, I own it. If the internet "goes down" and the commit has got my name on it, "but AI" isn't going to cut it.

There have been grifters hopping onto every trend. Have you noticed they never show you what exactly they built or if it was ever useful.

honestly, the vast majority of basically CRUD apps out there we are inflating our skills a bit too much here. even if the code is junk you can adapt your mindset to accept what LLMs produce, clean it up a bit, and come out with something maintainable.

like do these people ever have to review code from other people or juniors? the feedback loop here is tighter (although the drawback is your LLM doesn't "learn").

i wouldn't use it for anything super novel or cutting edge i guess, but i don't know, i guess everyone on HN might be coding some super secret advanced project that an LLM can't handle....?

But I’m in no rush to invite an army of people to compete with me just yet. I’ll be back when I’m sipping coladas on a beach to tell you what I did.

  - Use Cline with Sonnet 4.  Other models can work but this is the best balance of price and effectiveness.
  - Always use "plan" mode first, and only after the plan mode looks good do you switch to "act" mode.
  - Treat the LLM as though you are pair-programming with a junior engineer.  
  - Review every line that gets written as it gets written.  Object or change it if you don't like it for any reason.
  - Do test-driven development, and have the LLM always write tests first.

But even he doesn't think AI shouldn't be used. Go ahead and use it for stuff like email but don't use it for your core work.

[1] https://calnewport.com/does-ai-make-us-lazy/

Like, I might ask an LLM on its opinion on the best way to break something down, to see if it 'thinks' of anything i havent, and then ask it to implement that. I wouldn't ask it to do the whole thing from scratch with no input on how to structure things.

This, but but only for code. I've seen "leaders" at work suggest that we "embrace" AI, even for handling production systems and managing their complexity. That's like saying: "We've built this obscure, inscrutable system, therefore we need another obscure, inscrutable system on top of it in order to understand it!". To me, this sounds deranged, but the amount of gaslighting that's going on also makes you think you're the only to believe that...

I don't really get this argument. So when LLMs become "perfect" software developers are we just going to have them running 24/7 shitting out every conceivable piece of software ever? What would anyone do with that?

Or do you expect every doctor, electrician, sales assistant, hairdresser, train driver etc. to start developing their own software on top of their existing job?

What's more likely is a few people will make it their jobs to find and break down problems people have that could use a piece of software and develop said piece of software using whatever means they have available to them. Today we call these people software developers.

Only recently have I started interacting with LLM's more (I tried out a previous "use it as a book club partner" suggestion, and it's pretty great!).

When coding with them (via cursor), there was an interaction where I nudged it: "hey, you forgot xyz when you wrote that code the first time" (ie: updating an associated data structure or cache or whatever), and I find myself INTENTIONALLY giving the machine at least the shadow of a benefit of the doubt that: "Yeah, I might have made that mistake too if I were writing that code" or "Yeah, I might have written the base case first and _then_ gotten around to updating the cache, or decrementing the overall number of found items or whatever".

In the "book club" and "movie club" case, I asked it to discuss two movies and there were a few flubs: was the main character "justly imprisoned", or "unjustly imprisoned" ... a human might have made that same typo? Correct it, don't dwell on it, go with the flow... even in a 100% human discussion on books and movies, people (and hallucinating AI/LLM's) can not remember with 100% pinpoint accuracy every little detail, and I find giving a bit of benefit of the doubt to the conversation partner lowers my stress level quite a bit.

I guess: even when it's an AI, try to keep your interactions positive.

I guess it's also actually supported, unlike SRV that are more like supported only by some applications? Matrix migrated from SRV to .well-known files for providing the data. (Or I maybe it supports both.)

Yes, an experienced person might be able to suss out what the real problem was, but it's not really the LLMs fault for answering the specific question it was asked. Maybe you just wanted to run a server for testing and didn't realize that you can add a non-standard port to the URL.

I agree it's good for helping writing smaller bits like functions. I also use it to help me write unit tests which can be kind of tedious otherwise.

I do think that the quality of AI assistance has improved a lot in the past year. So if you tried it before, maybe take another crack at it.

The hard parts of engineering have always been decision making, socializing, and validating ideas against cold hard reality. But writing code just got easier so let's do that instead.

Prior to LLMs writing 10 lines of code might have been a really productive day, especially if we were able to thoughtfully avoid writing 1,000 unnecessary lines. LLMs do not change this.

Whether someone’s litmus test is well-developed is another matter.

Maybe quite a few pounds, if the cure in question hasn't been invented yet and may turn out to be vaporware.

Chat mode on the other hand follows my rules really well.

I mostly use o3 - it seems to be the only model that has "common sense" in my experience

I hear this frequently from LLM aficionados. I have a couple of questions about it:

1) If there is so much boilerplate that it takes a significant amount of coding time, why haven't you invested in abstracting it away?

2) The time spent actually writing code is not typically the bottleneck in implementing a system. How much do you really save over the development lifecycle when you have to review the LLM output in any case?

Often times there's a lot of repetition in the app I'm working on, and there's a lot of it that's already been abstracted away, but we still have to import the component, its dependencies, and setup the whole thing which is indeed pretty boring. It really helps to tell the LLM to implement something and point it to an example of the style I want.