8 ms·

Maybe it's because I only code for my own tools, but I still don't understand the benefit of relying on someone/something else to write your code and then readi

Maybe it's because I only code for my own tools, but I still don't understand the benefit of relying on someone/something else to write your code and then reading it, understand it, fixing it, etc. Although asking an LLM to extract and find the thing I'm looking for in an API Doc is super useful and time saving. To me, it's not even about how good these LLMs get in the future. I just don't like reading other people's code lol.

HPsquared 1y ago
The LLM has a much larger "working vocabulary" (so to speak) than I. It's more fluent. It's easier to read a language you're not super comfortable with, than it is to write it.
vmg12 1y ago
Here are the cases where it helps me (I promise this isn't ai generated even though im using a list...) - Formulaic code. It basically obviates the need for macros / code gen. The downside is that they are slower and you can't just update the macro and re-generate. The upside is it works for code that is slightly formulaic but has some slight differences across implementations that make macros impossible to use. - Using apis I am familiar with but don't have memorized. It saves me the effort of doing the google search and scouring the docs. I use typed languages so if it hallucinates the type checker will catch it and I'll need to manually test and set up automated tests anyway so there are plenty of steps where I can catch it if it's doing something really wrong. - Planning: I think this is actually a very under rated part of llms. If I need to make changes across 10+ files, it really helps to have the llm go through all the files and plan out the changes I'll need to make in a markdown doc. Sometimes the plan is good enough that with a few small tweaks I can tell the llm to just do it but even when it gets some things wrong it's useful for me to follow it partially while tweaking what it got wrong. Edit: Also, one thing I really like about llm generated code is that it maintains the style / naming conventions of the code in the project. When I'm tired I often stop caring about that kind of thing.
- mlinhares 1y ago
  The downside for formulaic code kinda makes the whole thing useless from my perspective, I can't imagining a case where that works. Maybe a good case, that i've used a lot, is using "spreadsheet inputs" and teaching the LLM to produce test cases/code based on the spreadsheet data (that I received from elsewhere). The data doesn't change and the tests won't change either so the LLM definitely helps, but this isn't code i'll ever touch again.
  - vmg12 1y ago
    There is a lot of formulaic code that llms get right 90% of the time that are impossible to build macros for. One example that I've had to deal with is language bridge code for an embedded scripting language. Every function I want available in the scripting environment requires what is essentially a boiler plate function to be written and I had to write a lot of them.
    - mlinhares 1y ago
      You could definitely build a code generator that outputs this but definitely a good use case for an LLM.
    - Groxx 1y ago
      There's also fuzzy datatype mapping in general, where they're like 90%+ identical but the remaining fields need minor special handling. Building a generator capable of handling all variations you might need is extremely hard[1], and it still won't be good enough. An LLM will both get it almost perfect almost every time, and likely reuses your existing utility funcs. It can save you from typing out hundreds of lines, and it's pretty easy to verify and fix the things it got wrong. It's the exact sort of slightly-custom-pattern-detecting-and-following that they're good at. 1: Probably impossible, for practical purposes. It almost certainly makes an API larger than the Moon, which you won't be able to fully know or quickly figure out what you need to use due to the sheer size.
      - gf000 1y ago
divan 1y ago
On one codebase I work with, there are often tasks that involve changing multiple files in a relatively predictable way. Like there is little creativity/challenge, but a lot of typing in multiple parts/files. Tasks like these used to take 3-4 hours complete before just because I had to physically open all these files, find right places to modify, type the code etc. With AI agent I just describe the task, and it does the job 99% correct, reducing the time from 3-4 hours to 3-4 minutes.
- throwawayscrapd 1y ago
  Did you ever consider refactoring the code so that you don't have to do shotgun surgery every time you make this kind of change?
  - osigurdson 1y ago
    You mean to future proof the code so requirements changes are easy to implement? Yeah, I've seen lots of code like that (some of it written by myself). Usually the envisioned future never materializes unfortunately.
    - throwawayscrapd 1y ago
      I mean given that you've had this problem repeatedly, I'd call it "past-proofing", but I suppose you know your codebase better than I do.
      - rectang 1y ago
        There’s always a balance to be struck when avoiding premature consolidation of repeated code. We all face the same issue as osigurdson at some point and the productive responses fall in a range.
        osigurdson 1y ago
        If you have some idea of what future changes may be seen, it is fine to design for that. However, it is impossible to design a codebase to handle any change. Realistically, just doing the absolute bare minimum is probably the best defence in that situation.
osigurdson 1y ago
I felt the same way until recently (like last Friday recently). While tools like Windsurf / Cursor have some utility, most of the time I am just waiting around for them while I get to read and correct the output. Essentially, I'm helping out with the training while paying to use the tool. However, now that Codex is available in ChatGPT plus, I appreciate that asynchronous flow very much. Especially for making small improvements , fixing minor bugs, etc. This has obvious value imo. What I like to do is queue up 5 - 10 tasks and the. focus on hard problems while it is working away. Then when I need a break I review / merge those PRs.
esafak 1y ago
If you give a precise enough spec, it's effectively your code, with the remaining difference being inconsequential. And in my experience, it is often better, drawing from a wider pool of idioms.
gejose 1y ago
Just to draw a parallel (not to insult this line of thinking in any way): “ Maybe it's because I only code for my own tools, but I still don't understand the benefit of relying on someone/something else to _compile_ your code and then reading it, understand it, fixing it, etc” At a certain point you won’t have to read and understand every line of code it writes, you can trust that a “module” you ask it to build works exactly like you’d think it would, with a clearly defined interface to the rest of your handwritten code.
- addaon 1y ago
  > At a certain point you won’t have to read and understand every line of code it writes, you can trust that a “module” you ask it to build works exactly like you’d think it would, with a clearly defined interface to the rest of your handwritten code. "A certain point" is bearing a lot of load in this sentence... you're speculating about super-human capabilities (given that even human code can't be trusted, and we have code review processes, and other processes, to partially mitigate that risk). My impression was that the post you were replying to was discussing the current state of the art, not some dimly-sensed future.
  - gejose 1y ago
    I disagree, I think in many ways we're already there
dataviz1000 1y ago
I am beginning to love working like this. Plan a design for code. Explain to the LLM the steps to arrive to a solution. Work on reading, understanding, fixing, planing, ect. while the LLM is working on the next section of code. We are working in parallel. Think of it like being a cook in a restaurant. The order comes in. The cook plans the steps to complete the task of preparing all the elements for a dish. The cook sears the steak and puts it in the broiler. The cook doesn't stop and wait for the steak to finish before continuing. Rather the cook works on other problems and tasks before returning to observe the steak. If the steak isn't finished the cook will return it to the broiler for more cooking. Otherwise the cook will finish the process of plating the steak with sides and garnishes. The LLM is like the oven, a tool. Maybe grating cheese with a food processor is a better analogy. You could grate the cheese by hand or put the cheese into the food processor port in order to clean up, grab other items from the refrigerator, plan the steps for the next food item to prepare. This is the better analogy because grating cheese could be done by hand and maybe does have a better quality but if it is going into a sauce the grain quality doesn't matter so several minutes are saved by using a food processor which frees up the cook's time while working. Professional cooks multitask using tools in parallel. Maybe coding will move away from being a linear task writing one line of code at a time.
- collingreen 1y ago
  I like your take and the metaphors are good at helping demonstrate by example. One caveat I wonder about is how this kind of constant context switching combines with the need to think deeply (and defensively with non humans). My gut says I'd struggle at also being the brain at the end of the day instead of just the director/conductor. I've actively paired with multiple people at once before because of a time crunch (and with a really solid team). It was, to this day, the most fun AND productive "I" have ever been and what you're pitching aligns somewhat with that. HOWEVER, the two people who were driving the keyboards were substantially better engineers than me (and faster thinkers) so the burden of "is this right" was not on me in the way it is when using LLMs. I don't have any answers here - I see the vision you're pitching and it's a very very powerful one I hope is or becomes possible for me without it just becoming a way to burn out faster by being responsible for the deep understanding without the time to grok it.
satvikpendem 1y ago
Fast prototyping for code I'll throw away anyway. Sometimes I just want to get something to work as a proof of concept then I'll figure out how to productionize it later.
rgbrenner 1y ago
if you work on a team most code you see isn’t yours.. ai code review is really no different than reviewing a pr… except you can edit the output easier and maybe get the author to fix it immediately
- addaon 1y ago
  > if you work on a team most code you see isn’t yours.. ai code review is really no different than reviewing a pr… except you can edit the output easier and maybe get the author to fix it immediately And you can't ask "why" about a decision you don't understand (or at least, not with the expectation that the answer holds any particular causal relationship with the actual reason)... so it's like reviewing a PR with no trust possible, no opportunity to learn or to teach, and no possibility for insight that will lead to a better code base in the future. So, the exact opposite of reviewing a PR.
  - flappyeagle 1y ago
    Yes you can
  - arrowleaf 1y ago
    Are you using the same tools as everyone else here? You absolutely can ask "why" and it does a better job of explaining with the appropriate context than most developers I know. If you realize it's using a design pattern that doesn't fit, add it to your rules file.
    - JackFr 1y ago
      Although it cannot understand the rhetorical why as in a frustrated “Why on earth would you possibly do it that brain dead way?” Instead of the downcast, chastened look of a junior developer, it responds with a bulleted list of the reasons why it did it that way.
      - danielbln 1y ago
        Oh, it can infer quite a bit. I've seen many times in reasoning traces "The user is frustrated, understandably, and I should explain what I have done" after an exasperated "why???"
buffalobuffalo 1y ago
I kinda consider it a P!=nP type thing. If I need to write a simple function, it will almost always take me more time to implement it than it will to verify if an implementation of it suits my needs. There are exceptions, but overall when coding with LLMs this seems to hold true. Asking the LLM to write the function then checking it's work is a time saver.
- worldsayshi 1y ago
  I think this perspective is kinda key. Shifting attention towards more and better ways to verify code can probably lead to improved quality instead of degraded.
- a_tartaruga 1y ago
  Came here to post this it is precisely right.
- moritonal 1y ago
  I see it as basically Cunningham's Law. It's easier to see the LLM's attempt a solution and how it's wrong than to write a perfectly correct solution first time.
unshavedyak 1y ago
> I just don't like reading other people's code lol. I agree entirely and generally avoided LLMs because they couldn't be trusted. However a few days ago i said screw it and purchased Claude Max just to try and learn how i can use LLMs to my advantage. So far i avoid it for things where they're vague, complex, etc. The effort i have to go through to explain it exceeds my own in writing it. However for a bunch of things that are small, stupid, wastes of time - i find it has been very helpful. Old projects that need to migrate API versions, helper tools i've wanted but have been too lazy to write, etc. Low risk things that i'm too tired to do at the end of the day. I have also found it a nice way to get movement on projects where i'm too tired to progress on after work. Eg mostly decision fatigue, but blank spaces seem to be the most difficult for me when i'm already tired. Planning through the work with the LLM has been a pretty interesting way to work around my mental blocks, even if i don't let it do the work. This planning model is something i had already done with other LLMs, but Claude Code specifically has helped a lot in making it easier to just talk about my code, rather than having to supply details to the LLM/etc. It's been far from perfect of course, but i'm using this mostly to learn the bounds and try to find ways to have it be useful. Tricks and tools especially, eg for Claude adding the right "memory" adjustments to my preferred style, behaviors (testing, formatting, etc) has helped a lot. I'm a skeptic here, but so far i've been quite happy. Though i'm mostly going through low level fruit atm, i'm curious if 20 days from now i'll still want to renew the $100/m subscription.
gigel82 1y ago
I think there are 2 types of software engineering jobs: the ones where you work on a single large product for a long time, maintaining it and adding features, and the ones that spit out small projects that they never care for again. The latter category is totally enamored with LLMs, and I can see the appeal: they don't care at all about the quality or maintainability of the project after it's signed off on. As long as it satisfies most of the requirements, the llm slop / spaghetti is the client's problem now. The former category (like me, and maybe you) see less value from the LLMs. Although I've started seeing PRs from more junior members that are very obviously written by AI (usually huge chunks of changes that appear well structured but as soon as you take a closer look you realize the "cheerleader effect"... it's all AI slop, duplicated code, flat-out wrong with tests modified to pass and so on) I still fail to get any value from them in my own work. But we're slowly getting there, and I presume in the future we'll have much more componentized code precisely for AIs to better digest the individual pieces.
- esafak 1y ago
  Give it more than the minimal context so it can emulate the project's style. The recent async agents should be good at this.
grogenaut 1y ago
I'm categorizing my expenses. I asked the code AI to do 20 at a time, and suggest categories for all of them in an 800 line file. I then walked the diff by hand correcting things. I then asked it to double check my work. It did this in a 2 column cav mapping. It could do this in code. I didn't have to type anywhere near as much and 1.5 sets of eyes were on it. It did a pretty accurate job and the followup pass was better. This is just an example I had time to type before my morning shower
ar_lan 1y ago
> I just don't like reading other people's code lol. Do you work for yourself, or for a (larger than 1 developer) company? You mention you only code for your own tools, so I am guessing yourself? I don't necessarily like reading other people's code either, but across a distributed team, it's necessary - and sometimes I'm also inspired when I learn something new from someone else. I'm just curious if you've run into any roadblocks with this mindset, or if it's just preference?
bgwalter 1y ago
Some people cannot do anything without a tool. These people are early adopters and power users, who then evangelize their latest discovery. GitHub's value proposition was that mediocre coders can appear productive in the maze of PRs, reviews, green squares, todo lists etc. LLMs again give mediocre coders the appearance of being productive by juggling non-essential tools and agents (which their managers also love).
- danielbln 1y ago
  What is an essential tool? IDE? Editor? Pencil? Can I scratch my code into a French cave wall if I want to be a senior developer?
  - therein 1y ago
    I think it is very simple to draw the line at "something that tries to write for you", you know, an agent by definition. I am beginning to realize people simply would prefer to manage, even if the things they end up managing aren't actually humans. So it creates a nice live action role-play situation. A better name for vibecoding would be larpcoding, because you are doing a live action role-play of managing a staff of engineers. Now not only even a junior engineer can become a manager, they will start off their careers managing instead of doing. Terrifying.
    - crazylogger 1y ago
      It’s not a clear line though. Compilers have been writing programs for us. The plaintext programming language code that we talk about is but a spec for the actual program. From this perspective, English-as-spec is a natural progression in the direction we’ve been going all along.
silverlake 1y ago
You’re clinging to an old model of work. Today an LLM converted my docker compose infrastructure to Kubernetes, using operators and helm charts as needed. It did in 10 minutes what would take me several days to learn and cobble together a bad solution. I review every small update and correct it when needed. It is so much more productive. I’m driving a tractor while you are pulling an ox cart.
- zombiwoof 1y ago
  But you would have learned something if you invested the time. Now when your infra blows up you have no idea what to fix and will go fishing into the LLM lake to find how to fix it
- ofjcihen 1y ago
  “ It did in 10 minutes what would take me several days to learn and cobble together a bad solution.” Another way to look at this is you’re outsourcing your understanding to something that ultimately doesn’t think. This means 2 things: your solution could be severely suboptimal in multiple areas such as security and two because you didn’t bother understanding it yourself you’ll never be able to identify that. You might think “that’s fine, the LLM can fix it”. The issue with that is when you don’t know enough to know something needs to be fixed. So maybe instead of carts and oxen this is more akin to grandpa taking his computer to Best Buy to have them fix it for him?
  - silverlake 1y ago
    No one is an expert on all the things. I use libraries and tools to take care of things that are less important. I use my brain for things that are important. LLMs are another tool, more flexible and capable than any other. So yes, grandpa goes to Best Buy because he’s running his legal practice and doesn’t need to be an expert on computers.
    - ofjcihen 1y ago
      True, but I bet grandpa knows enough to identify when a paralegal has made a case losing mistake ;)
marvstazar 1y ago
As a senior developer you already spend a significant amount of time planning new feature implementations and reviewing other people's code (PRs). I find that this skill transitions quite nicely to working with coding agents.
- worldsayshi 1y ago
  Exactly!
- aqme28 1y ago
  Yeah was going to make the same point. > I still don't understand the benefit of relying on someone/something else to write your code and then reading it, understand it, fixing it, etc. What they're saying is that they never have coworkers.
  - colonelspace 1y ago
    They're also saying that they don't understand that writing code costs businesses money.
- munificent 1y ago
  I don't disagree but... wouldn't you rather be working with actual people? Spending the whole day chatting with AI agents sounds like a worst-of-both-worlds scenarios. I have to bring all of my complex, subtle soft skills into play which are difficult and tiring to use, and in the end none of that went towards actually fostering real relationships with real people. At the end of the day, are you gonna have a beer with your agents and tell them, "Wow, we really knocked it out of the park today?" Spending all day talking to virtual coworkers is literally the loneliest experience I can imagine, infinitely worse than actually coding in solitude the entire day.
  - cwyers 1y ago
    My employer can't go out and get me three actual people to work under me for $30 a month. EDIT: You can quibble on the exact rate of people's worth of work versus the cost of these tools, but look at what a single seat on Copilot or Cursor or Windsurf gets you, and you can see that if they are only barely more productive than you working without them, the economics are it's cheaper to "hire" virtual juniors than real juniors. And the virtual juniors are getting better by the month, go look at the Aider leaderboards and compare recent models to older ones.
hintymad 1y ago
> I still don't understand the benefit of relying on someone/something else to write your code and then reading it Maybe the key is this: our brains are great at spotting patterns, but not so great at remembering every little detail. And a lot of coding involves boilerplate—stuff that’s hard to describe precisely but can be generated anyway. Even if we like to think our work is all unique and creative, the truth is, a lot of it is repetitive and statistically has a limited number of sound variations. It’s like code that could be part of a library, but hasn’t been abstracted yet. That’s where AI comes in: it’s really good at generating that kind of code. It’s kind of like NP problems: finding a solution may take exponentially longer, but checking one takes only polynomial time. Similarly, AI gives us a fast draft that may take a human much longer to write, and we review it quickly. The result? We get more done, faster.
- amrocha 1y ago
  Copy and paste gives us a fast draft of repetitive code. That’s never been the bottle neck. The bottle neck is in the architecture and the details. Which is exactly what AI gets wrong, and which is why any engineer who respects his craft sees this snake oil for what it is.
jdalton 1y ago
No different than most practices now. PM write a ticket, dev codes it, PRs it, then someone else reviews it. Not a bad practice. Sometimes a fresh set of eyes really helps.
- pianopatrick 1y ago
  I am not too familiar with software development inside large organizations as I work for myself - are there any of those steps the AI cannot do well? I mean it seems to me that if the AI is as good as humans at text based tasks you could have an entire software development process with no humans. I.e. user feedback or error messages go to a first LLM that writes a ticket. That ticket goes to a second LLM that writes code. That code goes to a 3rd LLM that reviews the code. That code goes through various automated tests in a CI / CD pipeline to catch issues. If no tests fail the updated software is deployed. You could insert sanity checks by humans at various points but are any of these tasks outside the capabilities of an LLM?
dkkergoog 1y ago
[dead]
mgraczyk 1y ago
When you write code, you have to spend time on ALL of the code, no matter how simple or obvious it is. When you read code, you can allocate your time to the parts that are more complex or important.
bob1029 1y ago
My most productive use of LLMs has been to stub out individual methods and have them fill in the implementations. I use a prompt like: public T MyMethod<T>(/*args*/) /*type constraints*/ { //TODO: Implement this method using the following requirements: //1 ... //2 ... //... } Anything beyond this and I can't keep track of which rabbit is doing what anymore.
pinoy420 1y ago
[dead]
mewpmewp2 1y ago
It is just faster and less effort. I can't write code as quickly as the LLM can. It is all in my head, but I can't spit it out as quickly. I just see LLMs as getting what is in my head quickly out there. I have learned to prompt it in such a way that I know what to expect, I know its weakspots and strengths. I could predict what it is going output, so it is not that difficult to understand.
- andhuman 1y ago
  Yes, the eureka moment with LLMs is when they started outputting the things I was beginning to type. Not just words but sentences, whole functions and even unit tests. The result is the same as I would have typed it, just a lot faster.
stirfish 1y ago
I use it almost like an RSI mitigation device, for tasks I can do (and do well) but don't want to do anymore. I don't want to write another little 20-line script to format some data, so I'll have the machine do it for me. I'll also use it to create basic DAOs from schemas, things like that.
resonious 1y ago
It's an intentional (hopefully) tradeoff between development speed and deep understanding. By hiring someone or using an agent, you are getting increased speed for decreased understanding. Part of choosing whether or not to use an agent should include an analysis of how much benefit you get from a deep understanding of the subsystem you're currently working on. If it's something that can afford defects, you bet I'll get an agent to do a quick-n-dirty job.
KronisLV 1y ago
> I still don't understand the benefit of relying on someone/something else to write your code and then reading it, understand it, fixing it, etc. Friction. A lot of people are bad at getting started (like writer's block, just with code), whereas if you're given a solution for a problem, then you can tweak it, refactor it and alter it in other ways for your needs, without getting too caught up in your head about how to write the thing in the first place. Same with how many of my colleagues have expressed that getting started on a new project from 0 is difficult, because you also need to setup the toolchain and bootstrap a whole app/service/project, very similar to also introducing a new abstraction/mechanism in an existing codebase. Plus, with LLMs being able to process a lot of data quickly, assuming you have enough context size and money/resources to use that, it can run through your codebase in more detail and notice things that you might now, like: "Oh hey, there are already two audit mechanisms in the codebase in classes Foo and Bar, we might extract the common logic and..." that you'd miss on your own.

HPsquared 1y ago

The LLM has a much larger "working vocabulary" (so to speak) than I. It's more fluent. It's easier to read a language you're not super comfortable with, than it is to write it.

vmg12 1y ago

Here are the cases where it helps me (I promise this isn't ai generated even though im using a list...) - Formulaic code. It basically obviates the need for macros / code gen. The downside is that they are slower and you can't just update the macro and re-generate. The upside is it works for code that is slightly formulaic but has some slight differences across implementations that make macros impossible to use. - Using apis I am familiar with but don't have memorized. It saves me the effort of doing the google search and scouring the docs. I use typed languages so if it hallucinates the type checker will catch it and I'll need to manually test and set up automated tests anyway so there are plenty of steps where I can catch it if it's doing something really wrong. - Planning: I think this is actually a very under rated part of llms. If I need to make changes across 10+ files, it really helps to have the llm go through all the files and plan out the changes I'll need to make in a markdown doc. Sometimes the plan is good enough that with a few small tweaks I can tell the llm to just do it but even when it gets some things wrong it's useful for me to follow it partially while tweaking what it got wrong. Edit: Also, one thing I really like about llm generated code is that it maintains the style / naming conventions of the code in the project. When I'm tired I often stop caring about that kind of thing.

mlinhares 1y ago
The downside for formulaic code kinda makes the whole thing useless from my perspective, I can't imagining a case where that works. Maybe a good case, that i've used a lot, is using "spreadsheet inputs" and teaching the LLM to produce test cases/code based on the spreadsheet data (that I received from elsewhere). The data doesn't change and the tests won't change either so the LLM definitely helps, but this isn't code i'll ever touch again.
- vmg12 1y ago
  There is a lot of formulaic code that llms get right 90% of the time that are impossible to build macros for. One example that I've had to deal with is language bridge code for an embedded scripting language. Every function I want available in the scripting environment requires what is essentially a boiler plate function to be written and I had to write a lot of them.
  - mlinhares 1y ago
    You could definitely build a code generator that outputs this but definitely a good use case for an LLM.
  - Groxx 1y ago
    There's also fuzzy datatype mapping in general, where they're like 90%+ identical but the remaining fields need minor special handling. Building a generator capable of handling all variations you might need is extremely hard[1], and it still won't be good enough. An LLM will both get it almost perfect almost every time, and likely reuses your existing utility funcs. It can save you from typing out hundreds of lines, and it's pretty easy to verify and fix the things it got wrong. It's the exact sort of slightly-custom-pattern-detecting-and-following that they're good at. 1: Probably impossible, for practical purposes. It almost certainly makes an API larger than the Moon, which you won't be able to fully know or quickly figure out what you need to use due to the sheer size.
    - gf000 1y ago

divan 1y ago

On one codebase I work with, there are often tasks that involve changing multiple files in a relatively predictable way. Like there is little creativity/challenge, but a lot of typing in multiple parts/files. Tasks like these used to take 3-4 hours complete before just because I had to physically open all these files, find right places to modify, type the code etc. With AI agent I just describe the task, and it does the job 99% correct, reducing the time from 3-4 hours to 3-4 minutes.

throwawayscrapd 1y ago
Did you ever consider refactoring the code so that you don't have to do shotgun surgery every time you make this kind of change?
- osigurdson 1y ago
  You mean to future proof the code so requirements changes are easy to implement? Yeah, I've seen lots of code like that (some of it written by myself). Usually the envisioned future never materializes unfortunately.
  - throwawayscrapd 1y ago
    I mean given that you've had this problem repeatedly, I'd call it "past-proofing", but I suppose you know your codebase better than I do.
    - rectang 1y ago
      There’s always a balance to be struck when avoiding premature consolidation of repeated code. We all face the same issue as osigurdson at some point and the productive responses fall in a range.
      - osigurdson 1y ago
        If you have some idea of what future changes may be seen, it is fine to design for that. However, it is impossible to design a codebase to handle any change. Realistically, just doing the absolute bare minimum is probably the best defence in that situation.

osigurdson 1y ago

I felt the same way until recently (like last Friday recently). While tools like Windsurf / Cursor have some utility, most of the time I am just waiting around for them while I get to read and correct the output. Essentially, I'm helping out with the training while paying to use the tool. However, now that Codex is available in ChatGPT plus, I appreciate that asynchronous flow very much. Especially for making small improvements , fixing minor bugs, etc. This has obvious value imo. What I like to do is queue up 5 - 10 tasks and the. focus on hard problems while it is working away. Then when I need a break I review / merge those PRs.

esafak 1y ago

If you give a precise enough spec, it's effectively your code, with the remaining difference being inconsequential. And in my experience, it is often better, drawing from a wider pool of idioms.

gejose 1y ago

Just to draw a parallel (not to insult this line of thinking in any way): “ Maybe it's because I only code for my own tools, but I still don't understand the benefit of relying on someone/something else to _compile_ your code and then reading it, understand it, fixing it, etc” At a certain point you won’t have to read and understand every line of code it writes, you can trust that a “module” you ask it to build works exactly like you’d think it would, with a clearly defined interface to the rest of your handwritten code.

addaon 1y ago
> At a certain point you won’t have to read and understand every line of code it writes, you can trust that a “module” you ask it to build works exactly like you’d think it would, with a clearly defined interface to the rest of your handwritten code. "A certain point" is bearing a lot of load in this sentence... you're speculating about super-human capabilities (given that even human code can't be trusted, and we have code review processes, and other processes, to partially mitigate that risk). My impression was that the post you were replying to was discussing the current state of the art, not some dimly-sensed future.
- gejose 1y ago
  I disagree, I think in many ways we're already there

dataviz1000 1y ago

I am beginning to love working like this. Plan a design for code. Explain to the LLM the steps to arrive to a solution. Work on reading, understanding, fixing, planing, ect. while the LLM is working on the next section of code. We are working in parallel. Think of it like being a cook in a restaurant. The order comes in. The cook plans the steps to complete the task of preparing all the elements for a dish. The cook sears the steak and puts it in the broiler. The cook doesn't stop and wait for the steak to finish before continuing. Rather the cook works on other problems and tasks before returning to observe the steak. If the steak isn't finished the cook will return it to the broiler for more cooking. Otherwise the cook will finish the process of plating the steak with sides and garnishes. The LLM is like the oven, a tool. Maybe grating cheese with a food processor is a better analogy. You could grate the cheese by hand or put the cheese into the food processor port in order to clean up, grab other items from the refrigerator, plan the steps for the next food item to prepare. This is the better analogy because grating cheese could be done by hand and maybe does have a better quality but if it is going into a sauce the grain quality doesn't matter so several minutes are saved by using a food processor which frees up the cook's time while working. Professional cooks multitask using tools in parallel. Maybe coding will move away from being a linear task writing one line of code at a time.

collingreen 1y ago
I like your take and the metaphors are good at helping demonstrate by example. One caveat I wonder about is how this kind of constant context switching combines with the need to think deeply (and defensively with non humans). My gut says I'd struggle at also being the brain at the end of the day instead of just the director/conductor. I've actively paired with multiple people at once before because of a time crunch (and with a really solid team). It was, to this day, the most fun AND productive "I" have ever been and what you're pitching aligns somewhat with that. HOWEVER, the two people who were driving the keyboards were substantially better engineers than me (and faster thinkers) so the burden of "is this right" was not on me in the way it is when using LLMs. I don't have any answers here - I see the vision you're pitching and it's a very very powerful one I hope is or becomes possible for me without it just becoming a way to burn out faster by being responsible for the deep understanding without the time to grok it.

satvikpendem 1y ago

Fast prototyping for code I'll throw away anyway. Sometimes I just want to get something to work as a proof of concept then I'll figure out how to productionize it later.

rgbrenner 1y ago

if you work on a team most code you see isn’t yours.. ai code review is really no different than reviewing a pr… except you can edit the output easier and maybe get the author to fix it immediately

addaon 1y ago
> if you work on a team most code you see isn’t yours.. ai code review is really no different than reviewing a pr… except you can edit the output easier and maybe get the author to fix it immediately And you can't ask "why" about a decision you don't understand (or at least, not with the expectation that the answer holds any particular causal relationship with the actual reason)... so it's like reviewing a PR with no trust possible, no opportunity to learn or to teach, and no possibility for insight that will lead to a better code base in the future. So, the exact opposite of reviewing a PR.
- flappyeagle 1y ago
  Yes you can
- arrowleaf 1y ago
  Are you using the same tools as everyone else here? You absolutely can ask "why" and it does a better job of explaining with the appropriate context than most developers I know. If you realize it's using a design pattern that doesn't fit, add it to your rules file.
  - JackFr 1y ago
    Although it cannot understand the rhetorical why as in a frustrated “Why on earth would you possibly do it that brain dead way?” Instead of the downcast, chastened look of a junior developer, it responds with a bulleted list of the reasons why it did it that way.
    - danielbln 1y ago
      Oh, it can infer quite a bit. I've seen many times in reasoning traces "The user is frustrated, understandably, and I should explain what I have done" after an exasperated "why???"

buffalobuffalo 1y ago

I kinda consider it a P!=nP type thing. If I need to write a simple function, it will almost always take me more time to implement it than it will to verify if an implementation of it suits my needs. There are exceptions, but overall when coding with LLMs this seems to hold true. Asking the LLM to write the function then checking it's work is a time saver.

worldsayshi 1y ago
I think this perspective is kinda key. Shifting attention towards more and better ways to verify code can probably lead to improved quality instead of degraded.
a_tartaruga 1y ago
Came here to post this it is precisely right.
moritonal 1y ago
I see it as basically Cunningham's Law. It's easier to see the LLM's attempt a solution and how it's wrong than to write a perfectly correct solution first time.

unshavedyak 1y ago

> I just don't like reading other people's code lol. I agree entirely and generally avoided LLMs because they couldn't be trusted. However a few days ago i said screw it and purchased Claude Max just to try and learn how i can use LLMs to my advantage. So far i avoid it for things where they're vague, complex, etc. The effort i have to go through to explain it exceeds my own in writing it. However for a bunch of things that are small, stupid, wastes of time - i find it has been very helpful. Old projects that need to migrate API versions, helper tools i've wanted but have been too lazy to write, etc. Low risk things that i'm too tired to do at the end of the day. I have also found it a nice way to get movement on projects where i'm too tired to progress on after work. Eg mostly decision fatigue, but blank spaces seem to be the most difficult for me when i'm already tired. Planning through the work with the LLM has been a pretty interesting way to work around my mental blocks, even if i don't let it do the work. This planning model is something i had already done with other LLMs, but Claude Code specifically has helped a lot in making it easier to just talk about my code, rather than having to supply details to the LLM/etc. It's been far from perfect of course, but i'm using this mostly to learn the bounds and try to find ways to have it be useful. Tricks and tools especially, eg for Claude adding the right "memory" adjustments to my preferred style, behaviors (testing, formatting, etc) has helped a lot. I'm a skeptic here, but so far i've been quite happy. Though i'm mostly going through low level fruit atm, i'm curious if 20 days from now i'll still want to renew the $100/m subscription.

gigel82 1y ago

I think there are 2 types of software engineering jobs: the ones where you work on a single large product for a long time, maintaining it and adding features, and the ones that spit out small projects that they never care for again. The latter category is totally enamored with LLMs, and I can see the appeal: they don't care at all about the quality or maintainability of the project after it's signed off on. As long as it satisfies most of the requirements, the llm slop / spaghetti is the client's problem now. The former category (like me, and maybe you) see less value from the LLMs. Although I've started seeing PRs from more junior members that are very obviously written by AI (usually huge chunks of changes that appear well structured but as soon as you take a closer look you realize the "cheerleader effect"... it's all AI slop, duplicated code, flat-out wrong with tests modified to pass and so on) I still fail to get any value from them in my own work. But we're slowly getting there, and I presume in the future we'll have much more componentized code precisely for AIs to better digest the individual pieces.

esafak 1y ago
Give it more than the minimal context so it can emulate the project's style. The recent async agents should be good at this.

grogenaut 1y ago

I'm categorizing my expenses. I asked the code AI to do 20 at a time, and suggest categories for all of them in an 800 line file. I then walked the diff by hand correcting things. I then asked it to double check my work. It did this in a 2 column cav mapping. It could do this in code. I didn't have to type anywhere near as much and 1.5 sets of eyes were on it. It did a pretty accurate job and the followup pass was better. This is just an example I had time to type before my morning shower

ar_lan 1y ago

> I just don't like reading other people's code lol. Do you work for yourself, or for a (larger than 1 developer) company? You mention you only code for your own tools, so I am guessing yourself? I don't necessarily like reading other people's code either, but across a distributed team, it's necessary - and sometimes I'm also inspired when I learn something new from someone else. I'm just curious if you've run into any roadblocks with this mindset, or if it's just preference?

bgwalter 1y ago

Some people cannot do anything without a tool. These people are early adopters and power users, who then evangelize their latest discovery. GitHub's value proposition was that mediocre coders can appear productive in the maze of PRs, reviews, green squares, todo lists etc. LLMs again give mediocre coders the appearance of being productive by juggling non-essential tools and agents (which their managers also love).

danielbln 1y ago
What is an essential tool? IDE? Editor? Pencil? Can I scratch my code into a French cave wall if I want to be a senior developer?
- therein 1y ago
  I think it is very simple to draw the line at "something that tries to write for you", you know, an agent by definition. I am beginning to realize people simply would prefer to manage, even if the things they end up managing aren't actually humans. So it creates a nice live action role-play situation. A better name for vibecoding would be larpcoding, because you are doing a live action role-play of managing a staff of engineers. Now not only even a junior engineer can become a manager, they will start off their careers managing instead of doing. Terrifying.
  - crazylogger 1y ago
    It’s not a clear line though. Compilers have been writing programs for us. The plaintext programming language code that we talk about is but a spec for the actual program. From this perspective, English-as-spec is a natural progression in the direction we’ve been going all along.

silverlake 1y ago

You’re clinging to an old model of work. Today an LLM converted my docker compose infrastructure to Kubernetes, using operators and helm charts as needed. It did in 10 minutes what would take me several days to learn and cobble together a bad solution. I review every small update and correct it when needed. It is so much more productive. I’m driving a tractor while you are pulling an ox cart.

zombiwoof 1y ago
But you would have learned something if you invested the time. Now when your infra blows up you have no idea what to fix and will go fishing into the LLM lake to find how to fix it
ofjcihen 1y ago
“ It did in 10 minutes what would take me several days to learn and cobble together a bad solution.” Another way to look at this is you’re outsourcing your understanding to something that ultimately doesn’t think. This means 2 things: your solution could be severely suboptimal in multiple areas such as security and two because you didn’t bother understanding it yourself you’ll never be able to identify that. You might think “that’s fine, the LLM can fix it”. The issue with that is when you don’t know enough to know something needs to be fixed. So maybe instead of carts and oxen this is more akin to grandpa taking his computer to Best Buy to have them fix it for him?
- silverlake 1y ago
  No one is an expert on all the things. I use libraries and tools to take care of things that are less important. I use my brain for things that are important. LLMs are another tool, more flexible and capable than any other. So yes, grandpa goes to Best Buy because he’s running his legal practice and doesn’t need to be an expert on computers.
  - ofjcihen 1y ago
    True, but I bet grandpa knows enough to identify when a paralegal has made a case losing mistake ;)

marvstazar 1y ago

As a senior developer you already spend a significant amount of time planning new feature implementations and reviewing other people's code (PRs). I find that this skill transitions quite nicely to working with coding agents.

worldsayshi 1y ago
Exactly!
aqme28 1y ago
Yeah was going to make the same point. > I still don't understand the benefit of relying on someone/something else to write your code and then reading it, understand it, fixing it, etc. What they're saying is that they never have coworkers.
- colonelspace 1y ago
  They're also saying that they don't understand that writing code costs businesses money.
munificent 1y ago
I don't disagree but... wouldn't you rather be working with actual people? Spending the whole day chatting with AI agents sounds like a worst-of-both-worlds scenarios. I have to bring all of my complex, subtle soft skills into play which are difficult and tiring to use, and in the end none of that went towards actually fostering real relationships with real people. At the end of the day, are you gonna have a beer with your agents and tell them, "Wow, we really knocked it out of the park today?" Spending all day talking to virtual coworkers is literally the loneliest experience I can imagine, infinitely worse than actually coding in solitude the entire day.
- cwyers 1y ago
  My employer can't go out and get me three actual people to work under me for $30 a month. EDIT: You can quibble on the exact rate of people's worth of work versus the cost of these tools, but look at what a single seat on Copilot or Cursor or Windsurf gets you, and you can see that if they are only barely more productive than you working without them, the economics are it's cheaper to "hire" virtual juniors than real juniors. And the virtual juniors are getting better by the month, go look at the Aider leaderboards and compare recent models to older ones.

hintymad 1y ago

> I still don't understand the benefit of relying on someone/something else to write your code and then reading it Maybe the key is this: our brains are great at spotting patterns, but not so great at remembering every little detail. And a lot of coding involves boilerplate—stuff that’s hard to describe precisely but can be generated anyway. Even if we like to think our work is all unique and creative, the truth is, a lot of it is repetitive and statistically has a limited number of sound variations. It’s like code that could be part of a library, but hasn’t been abstracted yet. That’s where AI comes in: it’s really good at generating that kind of code. It’s kind of like NP problems: finding a solution may take exponentially longer, but checking one takes only polynomial time. Similarly, AI gives us a fast draft that may take a human much longer to write, and we review it quickly. The result? We get more done, faster.

amrocha 1y ago
Copy and paste gives us a fast draft of repetitive code. That’s never been the bottle neck. The bottle neck is in the architecture and the details. Which is exactly what AI gets wrong, and which is why any engineer who respects his craft sees this snake oil for what it is.

jdalton 1y ago

No different than most practices now. PM write a ticket, dev codes it, PRs it, then someone else reviews it. Not a bad practice. Sometimes a fresh set of eyes really helps.

pianopatrick 1y ago
I am not too familiar with software development inside large organizations as I work for myself - are there any of those steps the AI cannot do well? I mean it seems to me that if the AI is as good as humans at text based tasks you could have an entire software development process with no humans. I.e. user feedback or error messages go to a first LLM that writes a ticket. That ticket goes to a second LLM that writes code. That code goes to a 3rd LLM that reviews the code. That code goes through various automated tests in a CI / CD pipeline to catch issues. If no tests fail the updated software is deployed. You could insert sanity checks by humans at various points but are any of these tasks outside the capabilities of an LLM?

dkkergoog 1y ago

[dead]

mgraczyk 1y ago

When you write code, you have to spend time on ALL of the code, no matter how simple or obvious it is. When you read code, you can allocate your time to the parts that are more complex or important.

bob1029 1y ago

My most productive use of LLMs has been to stub out individual methods and have them fill in the implementations. I use a prompt like: public T MyMethod<T>(/*args*/) /*type constraints*/ { //TODO: Implement this method using the following requirements: //1 ... //2 ... //... } Anything beyond this and I can't keep track of which rabbit is doing what anymore.

pinoy420 1y ago

[dead]

mewpmewp2 1y ago

It is just faster and less effort. I can't write code as quickly as the LLM can. It is all in my head, but I can't spit it out as quickly. I just see LLMs as getting what is in my head quickly out there. I have learned to prompt it in such a way that I know what to expect, I know its weakspots and strengths. I could predict what it is going output, so it is not that difficult to understand.

andhuman 1y ago
Yes, the eureka moment with LLMs is when they started outputting the things I was beginning to type. Not just words but sentences, whole functions and even unit tests. The result is the same as I would have typed it, just a lot faster.

stirfish 1y ago

I use it almost like an RSI mitigation device, for tasks I can do (and do well) but don't want to do anymore. I don't want to write another little 20-line script to format some data, so I'll have the machine do it for me. I'll also use it to create basic DAOs from schemas, things like that.

resonious 1y ago

It's an intentional (hopefully) tradeoff between development speed and deep understanding. By hiring someone or using an agent, you are getting increased speed for decreased understanding. Part of choosing whether or not to use an agent should include an analysis of how much benefit you get from a deep understanding of the subsystem you're currently working on. If it's something that can afford defects, you bet I'll get an agent to do a quick-n-dirty job.

KronisLV 1y ago

> I still don't understand the benefit of relying on someone/something else to write your code and then reading it, understand it, fixing it, etc. Friction. A lot of people are bad at getting started (like writer's block, just with code), whereas if you're given a solution for a problem, then you can tweak it, refactor it and alter it in other ways for your needs, without getting too caught up in your head about how to write the thing in the first place. Same with how many of my colleagues have expressed that getting started on a new project from 0 is difficult, because you also need to setup the toolchain and bootstrap a whole app/service/project, very similar to also introducing a new abstraction/mechanism in an existing codebase. Plus, with LLMs being able to process a lot of data quickly, assuming you have enough context size and money/resources to use that, it can run through your codebase in more detail and notice things that you might now, like: "Oh hey, there are already two audit mechanisms in the codebase in classes Foo and Bar, we might extract the common logic and..." that you'd miss on your own.