two weeks ago I started heavily using Codex (I have 20y+ dev xp).
At first I was very enthusiastic and thought Codex is helping me multiplex myself. But you actually spend so much time trying to explain Codex the most obvious things and it gets them wrong all the time in some kind of nuanced way that in the end you spend more time doing things via Codex than by hand.
So I also dialed back Codex usage and got back to doing many more things by hand again because its just so much faster and much more predictable time-wise.
This is pretty much the conclusion I've come to as well. It's not good at being an autocomplete for entire chunks of your codebase. You lose the mental model of what is doing what, and exactly where. I prefer to use it as a personalized, faster-iterating StackOverflow. I'll ask it to give me a rundown of a concept I'm not familiar with, or for a general direction to point me in if I'm uncertain of what a good solution would be. Then I'll make the decision, and implement it myself. That workflow has worked out much better for me so far.
I don’t have it write of my Python firmware or Elixir backend stuff.
What I do let it rough in is web front end stuff. I view the need for and utility of LLMs in the html/css/tailwind/js space as an indictment of complexity and inconsistency. It’s amazing that the web front end stuff has just evolved over the years, organically morphing from one thing to another, but a sound well engineered simple-is-best set of software it is not. And in a world where my efforts will probably work in most browser contexts, no surprise that I’m willing to mix in a tool that will make results that will probably work. A mess is still a mess.
LLMs have limits. They are super powerful but they can't make the kind of leap humans can. For example, I asked both Claude and Gemini below problem.
"I want to run webserver on Android but it does not allow binding on ports lower than 1000. What are my options?"
Both responded with below solutions
1. Use reverse proxy
2. Root the phone
3. Run on higher port
Even after asking them to rethink they couldn't come up with the solution I was expecting. The solution to this problem is HTTPS RR records[1]. Both models knew about HTTPS RR but couldn't suggest it as a solution. It's only after I included it in their context both agreed it as a possible solution.
I've gone the other way and put a lot of effort into figuring out how to best utilize these things. It's a rough learning curve and not trivial, especially given how effortless stuff looks and feels at first.
My point of view: LLMs should be taken as a tool, not as a source of wisdom. I know someone who likes to answer people-related questions through a LLM. (E.g.: "What should this person do?" "What should we know about you?" etc.) More than once, this leads to him getting into a state of limbo when he tries to explain what he means with what he wrote. It feels a bit wild - a bit like back in school, when the guy who copied your homework, is forced to explain how he ended up with the solution.
These seem like good checkpoints (and valid criticisms) on the road to progress.
But it's also not crazy to think that with LLMs getting smarter (and considerable resources put into making them better at coding), that future versions would clean up and refactor code written by past versions. Correct?
I've found the Cursor autocomplete to be nice, but I've learned to only accept a completion if it's byte for byte what I would've written. With the context of surrounding code it guesses that often enough to be worth the money for me.
Am I spending too much time on HN or is every post/comment section filled with this same narrative? Basically, LLMs are exciting but they produce messy code for which the dev feels no ownership. Managing a codebase written by an LLM is difficult because you have not cognitively loaded the entire thing into your head as you do with code written yourself. They're okay for one-off scripts or projects you do not intend to maintain.
This is blog post/comment section summary encountered many times per day.
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 and want to tell you how awesome their workflow is without actually showing any code.
Honestly, they produce what they were trained on -- mediocre code. That doesn't mean people can't use that to make money, deliver customer value, etc. but is it code that's going to win any awards or be inspiring? No. Not in the slightest. Probably never. Because you are what you eat.
The question is, what do you expect from an LLM? What do you want to use it for?
They're plenty useful but, with anything, you need to use it responsibly and with proper expectations.
That applies just to one segment- the developers. What about people who wouldn’t be able to develop due to time constraints? I think it will be majority of coding LLM users. I am not talking about third group, the non-developers. But people who know languages, frameworks and design patterns. Not develop at all?
I think there is a middle ground, where you still make the important decisions and let an LLM fill out the rest. You don't need every implementation detail in your head (though you should of course review it), but you need to keep control over the structure and data flow.
I use LLM's for my developments constantly, so I have a pretty good grasp of what works and doesn't work.
Github copilot really gets it, as in: it's a "co-pilot", and you are the "pilot".
LLM's are able to generate code way faster than me, so in a lot of cases, writing a prompt, letting the LLM's generate a diff and me quickly reviewing, is faster than me writing/shuffling all the code. This is basically a "I know what has to be done, I just have to do it".
But let's be clear: LLM's are useful in small steps, not huge steps. Huge steps are only possible if you have a blank page.
I have code that was written by an LLM and I never really reviewed it: It's a visual effect in shaders that works, I quickly glanced over the code and it seemed complicated and fine. Since this is not crucial code, it works, and I don't have to touch it, it's fine for me.
Also an observation: once the LLM gets it wrong, it will continuously get it wrong after different instructions. After 1 or 2 failures, quickly decide to write it yourself.
The least amount of benefit any developer should get out of it is an "apply stack overflow suggestion". In the "old" days you searched google for your issue, read Stack Overflow comments, and try to apply it. LLM's let you shortcut this by going straight from prompt to diff suggestion.
You can push it a bit further than a "Stack Overflow on steroids", but don't expect it to maintain a codebase by itself.
"Also an observation: once the LLM gets it wrong, it will continuously get it wrong"
Oh yes, so very very much! I often see people keep iterating, not just with coding assistants but also general knowledge or research queries, when the first response is obviously wrong. I don't think that has ever ended up in a better response down the line. If the first response is garbage, then that means garbage is all this particular LLM is able to give you in return for what you ask. All the iterating does is travel through randomland - often until the person doing the prompting gets a response which they, for some reason, find more acceptable, even if it's just as wrong as all the others.
I'm somewhere between the two extremes.. it's not so bad that I want to put it down, and it is also not as good as what some claim. On average, it's better than hand coding everything though, and even for digging into code written by others
LLMs save me a lot of time as a software engineer because they save me a ton of time doing either boilerplate work or mundane tasks that are relatively conceptually easy but annoying to actually have to do/type/whatever in an IDE.
But I still more-or-less have to think like a software engineer. That's not going to go away. I have to make sure the code remains clean and well-organized -- which, for example, LLMs can help with, but I have to make precision requests and (most importantly) know specifically what I mean by "clean and well-organized." And I always read through and review any generated code and often tweak the output because at the end of the day I am responsible for the code base and I need to verify quality and I need to be able to answer questions and do all of the usual soft-skill engineering stuff. Etc. Etc.
So do whatever fits your need. I think LLMs are a massive multiplier because I can focus on the actual engineering stuff and automate away a bunch of the boring shit.
But when I read stuff like:
"I lost all my trust in LLMs, so I wouldn't give them a big feature again. I'll do very small things like refactoring or a very small-scoped feature."
I feel like I'm hearing something like, "I decided to build a house! So I hired some house builders and told them to build me a house with three bedrooms and two bathrooms and they wound up building something that was not at all what I wanted! Why didn't they know I really liked high ceilings?"
I like Zed's way of doing stuff (Ask mode). Just ask it a question and let it go through the whole thing. I still haven't figured out how to form the question so it doesn't just rail off and start implementing code. I don't care about code, I ask it to either validate my mental model or improve it
My favorite use case for LLMs in long term software production (they're pretty great at one off stuff since I don't need to maintain) is as an advanced boiler plate generator.
Stuff that can't just be abstracted to a function or class but also require no real thought. Tests are often (depending on what they're testing) in this realm.
I was resistant at first, but I love it. It's reduced the parts of my job that I dislike doing because of how monotonous they are and replaced them with a new fun thing to do - optimizing prompts that get it done for me much faster.
Writing the prompt and reviewing the code is _so_ much faster on tedious simple stuff and it leaves the interesting, though provoking parts of my work for me to do.
I think they are making me more productive in achieving my targets and worse in my ability to program.
They are exactly like steroids - bigger muscles fast but tons of side effects and everything collapses the moment you stop. Companies don't care because they are more concerned about getting to their targets fast instead of your health.
Another harmful drug for our brain if consumed without moderation. I won't entirely stop using them but I have already started to actively control/focus my usage.
LLMs seem to be really good at reproducing the classic Ball of Mud, that can't really be refactored or understood.
There's a lot of power in creating simple components that interact with other simple components to produce complex functionality. While each component is easy to understand and debug and predict its performance. The trick is to figure out how to decompose your complex problem into these simple components and their interactions.
I suppose once LLMs get really good at that skill, will be when we really won't need developers any more.
I wonder if this is as good as LLMs can get, or if this is a transition period between LLM as an assistant, and LLM as a compiler. Where in the latter world we don’t need to care about the code because we just care about the features. We let the LLM deal with the code and we deal with the context, treating code more like a binary. In that world, I’d bet code gets the same treatment as memory management today, where only a small percent of people need to manage it directly and most of us assume it happens correctly enough to not worry about it.
Can relate. I've also shifted towards generating small snippets of code using LLMs, giving them a glance, and asking to write unit tests for them. And then I review the unit tests carefully. But integrating the snippets together into the bigger system, I always do that myself. LLMs can do it sometimes but when it becomes big enough that it can't fit into the context window, then it's a real issue because now LLMs doesn't know what's going on and neither do you. So, I'll advise you to use LLMs to generate tedious bits of code but you must have the overall architecture committed into your memory as well so that when AI messes up, at least you have some clue about how to fix it.
I think that people are just too quick to assume this is amazing, before it is there. Which doesn't mean it won't get there.
Somehow if I take the best models and agents, most hard coding benchmarks are at below 50% and even swe bench verified is like at 75 maybe 80%. Not 95. Assuming agents just solve most problems is incorrect, despite it being really good at first prototypes.
Also in my experience agents are great to a point and then fall off a cliff. Not gradually. Just the type of errors you get past one point is so diverse, one cannot even explain it.
Over the last couple months I've gone from highly skeptical to a regular user (Copilot in my case). Two big things changed: First, I figured out that only some models are good enough to do the tasks I want (Claude Sonnet 3.7 and 4 out of everything I've tested). Second, it takes some infrastructure. I've added around 1000 words of additional instructions telling Copilot how to operate, and that's on top of tests (which you should have anyway) and 3rd party documentation. I haven't tried the fleet-of-agents thing, one VS Code instance is enough and I want to understand the changes in detail.
Edit: In concrete terms the workflow is to allow Copilot to make changes, see what's broken, fix those, review the diff against the goal, simplify the changes, etc, and repeat, until the overall task is done. All hands off.
I’m using ChatGPT (enterprise version paid by my employer) quite a lot lately, and I find it a useful tool. Here’s what I learned over time.
Don’t feed many pages of code to AI, it works best for isolated functions or small classes with little dependencies.
In 10% of cases when I ask to generate or complete code, the quality of the code is less than ideal but fixable with extra instructions. In 25% of cases, the quality of generated code is bad and remains so even after telling it what’s wrong and how to fix. When it happens, I simply ignore the AI output and do something else reasonable.
Apart from writing code, I find it useful at reviewing new code I wrote. Half of the comments are crap and should be ignored. Some others are questionable. However, I remember a few times when the AI identified actual bugs or other important issues in my code, and proposed fixes. Again, don’t copy-paste many pages at once, do it piecewise.
For some niche areas (examples are HLSL shaders, or C++ with SIMD intrinsics) the AI is pretty much useless, probably was not enough training data available.
Overall, I believe ChatGPT improved my code quality. Not only as a result of reviews, comments, or generated codes, but also my piecewise copy-pasting workflow improved overall architecture by splitting the codebase into classes/functions/modules/interfaces each doing their own thing.
64 comments
[ 2.8 ms ] story [ 69.5 ms ] threadAt first I was very enthusiastic and thought Codex is helping me multiplex myself. But you actually spend so much time trying to explain Codex the most obvious things and it gets them wrong all the time in some kind of nuanced way that in the end you spend more time doing things via Codex than by hand.
So I also dialed back Codex usage and got back to doing many more things by hand again because its just so much faster and much more predictable time-wise.
I don’t have it write of my Python firmware or Elixir backend stuff.
What I do let it rough in is web front end stuff. I view the need for and utility of LLMs in the html/css/tailwind/js space as an indictment of complexity and inconsistency. It’s amazing that the web front end stuff has just evolved over the years, organically morphing from one thing to another, but a sound well engineered simple-is-best set of software it is not. And in a world where my efforts will probably work in most browser contexts, no surprise that I’m willing to mix in a tool that will make results that will probably work. A mess is still a mess.
"I want to run webserver on Android but it does not allow binding on ports lower than 1000. What are my options?"
Both responded with below solutions
1. Use reverse proxy
2. Root the phone
3. Run on higher port
Even after asking them to rethink they couldn't come up with the solution I was expecting. The solution to this problem is HTTPS RR records[1]. Both models knew about HTTPS RR but couldn't suggest it as a solution. It's only after I included it in their context both agreed it as a possible solution.
[1]: https://rohanrd.xyz/posts/hosting-website-on-phone/
But it's also not crazy to think that with LLMs getting smarter (and considerable resources put into making them better at coding), that future versions would clean up and refactor code written by past versions. Correct?
The chatbot portion of the software is useless.
This is blog post/comment section summary encountered many times per day.
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 and want to tell you how awesome their workflow is without actually showing any code.
The question is, what do you expect from an LLM? What do you want to use it for?
They're plenty useful but, with anything, you need to use it responsibly and with proper expectations.
Github copilot really gets it, as in: it's a "co-pilot", and you are the "pilot".
LLM's are able to generate code way faster than me, so in a lot of cases, writing a prompt, letting the LLM's generate a diff and me quickly reviewing, is faster than me writing/shuffling all the code. This is basically a "I know what has to be done, I just have to do it".
But let's be clear: LLM's are useful in small steps, not huge steps. Huge steps are only possible if you have a blank page.
I have code that was written by an LLM and I never really reviewed it: It's a visual effect in shaders that works, I quickly glanced over the code and it seemed complicated and fine. Since this is not crucial code, it works, and I don't have to touch it, it's fine for me.
Also an observation: once the LLM gets it wrong, it will continuously get it wrong after different instructions. After 1 or 2 failures, quickly decide to write it yourself.
The least amount of benefit any developer should get out of it is an "apply stack overflow suggestion". In the "old" days you searched google for your issue, read Stack Overflow comments, and try to apply it. LLM's let you shortcut this by going straight from prompt to diff suggestion.
You can push it a bit further than a "Stack Overflow on steroids", but don't expect it to maintain a codebase by itself.
Oh yes, so very very much! I often see people keep iterating, not just with coding assistants but also general knowledge or research queries, when the first response is obviously wrong. I don't think that has ever ended up in a better response down the line. If the first response is garbage, then that means garbage is all this particular LLM is able to give you in return for what you ask. All the iterating does is travel through randomland - often until the person doing the prompting gets a response which they, for some reason, find more acceptable, even if it's just as wrong as all the others.
Don't give LLM second chances.
But I still more-or-less have to think like a software engineer. That's not going to go away. I have to make sure the code remains clean and well-organized -- which, for example, LLMs can help with, but I have to make precision requests and (most importantly) know specifically what I mean by "clean and well-organized." And I always read through and review any generated code and often tweak the output because at the end of the day I am responsible for the code base and I need to verify quality and I need to be able to answer questions and do all of the usual soft-skill engineering stuff. Etc. Etc.
So do whatever fits your need. I think LLMs are a massive multiplier because I can focus on the actual engineering stuff and automate away a bunch of the boring shit.
But when I read stuff like:
"I lost all my trust in LLMs, so I wouldn't give them a big feature again. I'll do very small things like refactoring or a very small-scoped feature."
I feel like I'm hearing something like, "I decided to build a house! So I hired some house builders and told them to build me a house with three bedrooms and two bathrooms and they wound up building something that was not at all what I wanted! Why didn't they know I really liked high ceilings?"
Stuff that can't just be abstracted to a function or class but also require no real thought. Tests are often (depending on what they're testing) in this realm.
I was resistant at first, but I love it. It's reduced the parts of my job that I dislike doing because of how monotonous they are and replaced them with a new fun thing to do - optimizing prompts that get it done for me much faster.
Writing the prompt and reviewing the code is _so_ much faster on tedious simple stuff and it leaves the interesting, though provoking parts of my work for me to do.
They are exactly like steroids - bigger muscles fast but tons of side effects and everything collapses the moment you stop. Companies don't care because they are more concerned about getting to their targets fast instead of your health.
Another harmful drug for our brain if consumed without moderation. I won't entirely stop using them but I have already started to actively control/focus my usage.
https://www.youtube.com/watch?v=SxdOUGdseq4
LLMs seem to be really good at reproducing the classic Ball of Mud, that can't really be refactored or understood.
There's a lot of power in creating simple components that interact with other simple components to produce complex functionality. While each component is easy to understand and debug and predict its performance. The trick is to figure out how to decompose your complex problem into these simple components and their interactions.
I suppose once LLMs get really good at that skill, will be when we really won't need developers any more.
https://news.ycombinator.com/item?id=44003700
Somehow if I take the best models and agents, most hard coding benchmarks are at below 50% and even swe bench verified is like at 75 maybe 80%. Not 95. Assuming agents just solve most problems is incorrect, despite it being really good at first prototypes.
Also in my experience agents are great to a point and then fall off a cliff. Not gradually. Just the type of errors you get past one point is so diverse, one cannot even explain it.
Edit: In concrete terms the workflow is to allow Copilot to make changes, see what's broken, fix those, review the diff against the goal, simplify the changes, etc, and repeat, until the overall task is done. All hands off.
Don’t feed many pages of code to AI, it works best for isolated functions or small classes with little dependencies.
In 10% of cases when I ask to generate or complete code, the quality of the code is less than ideal but fixable with extra instructions. In 25% of cases, the quality of generated code is bad and remains so even after telling it what’s wrong and how to fix. When it happens, I simply ignore the AI output and do something else reasonable.
Apart from writing code, I find it useful at reviewing new code I wrote. Half of the comments are crap and should be ignored. Some others are questionable. However, I remember a few times when the AI identified actual bugs or other important issues in my code, and proposed fixes. Again, don’t copy-paste many pages at once, do it piecewise.
For some niche areas (examples are HLSL shaders, or C++ with SIMD intrinsics) the AI is pretty much useless, probably was not enough training data available.
Overall, I believe ChatGPT improved my code quality. Not only as a result of reviews, comments, or generated codes, but also my piecewise copy-pasting workflow improved overall architecture by splitting the codebase into classes/functions/modules/interfaces each doing their own thing.
LLM will even through irrelevant data points in the output which causes further churn.
I feel not much has changed.
People really want a quick, low effort fix that appeals to the energy conserving lizard brain while still promising all the results.
In reality there aren't shortcuts, there's just tradeoffs, and we all realize it eventually.