5 ms·

> LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building. I’ve always said I’m a builder even thou

by atonse 9mo ago

> LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building. I’ve always said I’m a builder even though I’ve also enjoyed programming (but for an outcome, never for the sake of the code) This perfectly sums up what I’ve been observing between people like me (builders) who are ecstatic about this new world and programmers who talk about the craft of programming, sometimes butting heads. One viewpoint isn’t necessarily more valid, just a difference of wiring.

jimbokun 9mo ago
The new LLM centered workflow is really just a management job now. Managers and project managers are valuable roles and have important skill sets. But there's really very little connection with the role of software development that used to exist. It's a bit odd to me to include both of these roles under a single label of "builders", as they have so little in common. EDIT: this goes into more detail about how coding (and soon other kinds of knowledge work) is just a management task now: https://www.oneusefulthing.org/p/management-as-ai-superpower/ https://www.oneusefulthing.org/p/management-as-ai-superpower...
- simianwords 9mo ago
  i don't disagree. at some point LLM's might become good enough that we wouldn't need exact technical expertise.
ryandrake 9mo ago
I noticed the same thing, but wasn't able to put it into words before reading that. Been experimenting with LLM-based coding just so I can understand it and talk intelligently about it (instead of just being that grouchy curmudgeon), and the thought in the back of my mind while using Claude Code is always: "I got into programming because I like programming, not whatever this is..." Yes, I'm building stupid things faster, but I didn't get into programming because I wanted to build tons of things. I got into it for the thrill of defining a problem in terms of data structures and instructions a computer could understand, entering those instructions into the computer, and then watching victoriously while those instructions were executed. If I was intellectually excited about telling something to do this for me, I'd have gotten into management.
- atonse 9mo ago
  Funny you say that. Because I have never enjoyed management as much as being hands on and directly solving problems. So maybe our common ground is that we are direct problem solvers. :-)
  - Ronsenshi 9mo ago
    For some reason this makes me think of a jigsaw puzzle. People usually complete these puzzles because they enjoy the process where on the end you get a picture that you can frame if you want to. Some people seem to want to get the resulting picture. No interest in process at all. I guess that's the same people who went to all those coding camps during their hay day because they heard about software engineering salaries. They just want the money.
    - direwolf20 9mo ago
      When I last bought a Lego Technic set because I wanted to play with making mechanisms with gears and stuff, I assembled it according to the instructions, which was fun, and then the final result was also cool and I couldn't bear to dismantle it.
- polishdude20 9mo ago
  What I have enjoyed about programming is being able to get the computer to do exactly what I want. The possibilities are bounded by only what I can conceive in my mind. I feel like with AI that can happen faster.
  - testaccount28 9mo ago
    > get the computer to do exactly what I want. > with AI that can happen faster. well, not exactly that.
    - polishdude20 9mo ago
      For simple things it can. But then for more complex things that's where I step it
verdverm 9mo ago
I think the division is more likely tied to writing. You have to fundamentally change how you do your job, from one of writing a formal language for a compiler to one of writing natural language for a junior-goldfish-memory-allstar-developer, closer to management then to contributor. This distinction to me separates the two primary camps
addisonj 9mo ago
IMO, this isn't entirely a "new world" either, it is just a new domain where the conversation amplifies the opinions even more (weird how that is happening in a lot of places) What I mean by that: you had compiled vs interpreted languages, you had types vs untyped, testing strategies, all that, at least in some part, was a conversation about the tradeoffs between moving fast/shipping and maintainability. But it isn't just tech, it is also in methodologies and the words use, from "build fast and break things" and "yagni" to "design patterns" and "abstractions" As you say, it is a different viewpoint... but my biggest concern with where are as industry is that these are not just "equally valid" viewpoints of how to build software... it is quite literally different stages of software, that, AFAICT, pretty much all successful software has to go through. Much of my career has been spent in teams at companies with products that are undergoing the transition from "hip app built by scrappy team" to "profitable, reliable software" and it is painful. Going from something where you have 5 people who know all the ins and outs and can fix serious bugs or ship features in a few days to something that has easy clean boundaries to scale to 100 engineers of a wide range of familiarities with the tech, the problem domain, skill levels, and opinions is just really hard. I am not convinced yet that AI will solve the problem, and I am also unsure it doesn't risk making it worse (at least in the short term)
- dpflan 9mo ago
  “”” Much of my career has been spent in teams at companies with products that are undergoing the transition from "hip app built by scrappy team" to "profitable, reliable software" and it is painful. Going from something where you have 5 people who know all the ins and outs and can fix serious bugs or ship features in a few days to something that has easy clean boundaries to scale to 100 engineers of a wide range of familiarities with the tech, the problem domain, skill levels, and opinions is just really hard. I am not convinced yet that AI will solve the problem, and I am also unsure it doesn't risk making it worse (at least in the short term) “”” This perspective is crucial. Scale is the great equalizer / demoralizer, scale of the org and scale of the systems. Systems become complex quickly, and verifiability of correctness and function becomes harder. Companies that built from day with AI and have AI influencing them as they scale, where does complexity begin to run up against the limitations of AI and cause regression? Or if all goes well, amplification?
slaymaker1907 9mo ago
I enjoy both and have ended up using AI a lot differently than vibe coders. I rarely use it for generating implementations, but I use it extensively for helping me understand docs/apis and more importantly, for debugging. AI saves me so much time trying to figure out why things aren’t working and in code review. I deliberately avoid full vibe coding since I think doing so will rust my skills as a programmer. It also really doesn’t save much time in my experience. Once I have a design in mind, implementation is not the hard part.
mkozlows 9mo ago
I think he's really getting at something there. I've been thinking about this a lot (in the context of trying to understand the persistent-on-HN skepticism about LLMs), and the framing I came up with[1] is top-down vs. bottom-up dev styles, aka architecting code and then filling in implementations, vs. writing code and having architecture evolve. [1] https://www.klio.org/theory-of-llm-dev-skepticism/ https://www.klio.org/theory-of-llm-dev-skepticism/
- jamauro 9mo ago
  I like this framing. Nice typography btw, a pleasure to read.
Imustaskforhelp 9mo ago
> I enjoy both and have ended up using AI a lot differently than vibe coders. I rarely use it for generating implementations, but I use it extensively for helping me understand docs/apis and more importantly, for debugging. AI saves me so much time trying to figure out why things aren’t working and in code review. I had felt like this and still do but man, at some point, I feel like the management churn feels real & I just feel suffering from a new problem. Suppose, I actually end up having services literally deployed from a single prompt nothing else. Earlier I used to have AI write code but I was interested in the deployment and everything around it, now there are services which do that really neatly for you (I also really didn't give into the agent hype and mostly used browsers LLM) Like on one hand you feel more free to build projects but the whole joy of project completely got reduced. I mean, I guess I am one of the junior dev's so to me AI writing code on topics I didn't know/prototyping felt awesome. I mean I was still involved in say copy pasting or looking at the code it generates. Seeing the errors and sometimes trying things out myself. If AI is doing all that too, idk For some reason, recently I have been disinterested in AI. I have used it quite a lot for prototyping but I feel like this complete out of the loop programming just very off to me with recent services. I also feel like there is this sense of if I buy for some AI thing, to maximally extract "value" out of it. I guess the issue could be that I can have vague terms or have a very small text file as input (like just do X alternative in Y lang) and I am now unable to understand the architectural decisions and the overwhelmed-ness out of it. Probably gonna take either spec-driven development where I clearly define the architecture or development where I saw something primagen do recently which is that the AI will only manipulate code of that particular function, (I am imagining it for a file as well) and somehow I feel like its something that I could enjoy more because right now it feels like I don't know what I have built at times. When I prototype with single file projects using say browser for funsies/any idea. I get some idea of what the code kind of uses with its dependencies and functions names from start/end even if I didn't look at the middle A bit of ramble I guess but the thing which kind of is making me feel this is that I was talking to somebody and shwocasing them some service where AI + server is there and they asked for something in a prompt and I wrote it. Then I let it do its job but I was also thinking how I would architect it (it was some detect food and then find BMR, and I was thinking first to use any api but then I thought that meh it might be hard, why not use AI vision models, okay what's the best, gemini seems good/cheap) and I went to the coding thing to see what it did and it actually went even beyond by using the free tier of gemini (which I guess didn't end up working could be some rate limit of my own key but honestly it would've been the thing I would've tried too) So like, I used to pride myself on the architectural decisions I make even if AI could write code faster but now that is taken away as well. I really don't want to read AI code so much so honestly at this point, I might as well write code myself and learn hands on but I have a problem with build fast in public like attitude that I have & just not finding it fun. I feel like I should do a more active job in my projects & I am really just figuring out what's the perfect way to use AI in such contexts & when to use how much. Thoughts?
coffeeaddict1 9mo ago
But how can you be a responsible builder if you don't have trust in the LLMs doing the "right thing"? Suppose you're the head of a software team where you've picked up the best candidates for a given project, in that scenario I can see how one is able to trust the team members to orchestrate the implementation of your ideas and intentions, with you not being intimately familiar with the details. Can we place the same trust in LLM agents? I'm not sure. Even if one could somehow prove that LLM are very reliable, the fact an AI agents aren't accountable beings renders the whole situation vastly different than the human equivalent.
- inerte 9mo ago
  You don't simply put a body in a seat and get software. There are entire systems enabling this trust: college, resume, samples, referral, interviews, tests and CI, monitoring, mentoring, and performance feedback. And accountability can still exist? Is the engineer that created or reviewed a Pull Request using Claude Code less accountable then one that used PICO?
  - coffeeaddict1 9mo ago
    > And accountability can still exist? Is the engineer that created or reviewed a Pull Request using Claude Code less accountable then one that used PICO? The point is that in the human scenario, you can hold the human agents accountable. You cannot do that with AI. Of course, you as the orchestrator of agents will be accountable to someone, but you won't have the benefit of holding your "subordinates" accountable, which is what you do in a human team. IMO, this renders the whole situation vastly different (whether good or bad I'm not sure).
    - polishdude20 9mo ago
      You can switch to another LLM provider or stop using them altogether. It's even easier than firing a developer.
      - ipaddr 9mo ago
senderista 9mo ago
Maybe there's an intermediate category: people who like designing software? I personally find system design more engaging than coding (even though I enjoy coding as well). That's different from just producing an opaque artifact that seems to solve my problem.
monkaiju 9mo ago
So far I haven't seen it actually be effective at "building" in a work context with any complexity, and this despite some on our team desperately trying to make that the case.
- barrell 9mo ago
  Agreed. I don’t care for engineering or coding, and would gladly give it up the moment I can. I’m also running a one man business where every hour counts (and where I’m responsible for maintaining every feature). The fact of the matter is LLMs produce lower quality at higher volumes in more time than it would take to write it myself, and I’m a very mediocre engineer. I find this seperation of “coding” vs “building” so offensive. It’s basically just saying some people are only concerned with “inputs”, while others with “outputs”. This kind of rhetoric is so toxic. It’s like saying LLM art is separating people into people who like to scribble, and people who like to make art.
  - Applejinx 9mo ago
    Would you accept 'people who like to make art, and people who like to commission somebody to make art and give them lots of notes in the process'?
    - barrell 9mo ago
      I mean it’s closer, but I don’t think it’s right to equate commissioning an artist with paying a multi-billion dollar corporation to steal from artists. These tools are just lazy shortcuts. And that’s fine, there’s no problem with taking the lazy way. I’m never going to put in the time to learn to draw, so it’s cool there’s an option for me. I just take ire with pretending it’s something grand and refined, or spitting in the face of the ones who are willing to put in the work
- FeepingCreature 9mo ago
  I have! You have to be realistic about the projects. The more irreducible local context it needs, the less useful it will be. Great for greenfield code, oneshots, write once read once run for months.
codyb 9mo ago
I think there's a place for both. We have services deployed globally serving millions of customers where rigor is really important. And we have internal users who're building browser extensions with AI that provide valuable information about the interface they're looking at including links to the internal record management, and key metadata that's affecting content placement. These tools could be handed out on Zip drives in the street and it would just show our users some of the metadata already being served up to them, but it's amazing to strip out 75% of the process of certain things and just have our user (in this case though, it's one user who is driving all of this, so it does take some technical inclination) build out these tools that save our editors so much time when doing this before would have been months and months and months of discovery and coordination and designs that probably wouldn't actually be as useful in the end after the wants of the user are diluted through 18 layers of process.
globular-toast 9mo ago
I like building, but I don't fool myself into thinking it can be done by taking shortcuts. You could build something that looks like a house for half the cost but it won't be structurally sound. That's why I care about the details. Someone has to.
concats 9mo ago
I remember leaving university going into my first engineering job, thinking "Where is all the engineering? All the problem solving and building complex system? All the math and science? Have I been demoted to a lowly programmer?" Took me a few years to realize that this wasn't a universal feeling, and that many others found the programming tasks more fulfilling than any challenging engineering. I suppose this is merely another manifestation of the same phenomena.
asimovDev 9mo ago
To me this is similar to car enthusiasms. Some people absolutely love to build their project car, it's a major part of the hobby for them. Others just love the experience of driving, so they buy ready cars or just pay someone to work on the car.
- stevenhuang 9mo ago
  Alternatively, others just want to get to their destination.
chrisjj 9mo ago
> > LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building. This is much less significant than the fact LLMs split engineers on those who primarily like quality v. those who primarily like speed.
- chickensong 9mo ago
  That split has always existed. LLMs can be used on either side of the divide.
  - chrisjj 9mo ago
    We see a ton of "AI let me code a program X faster than ever before." We see almost no "AI let me code a program X better than ever before."
    - Philpax 9mo ago
      See this episode of Oxide and Friends, where they discuss just that: https://oxide-and-friends.transistor.fm/episodes/engineering-rigor-in-the-llm-age https://oxide-and-friends.transistor.fm/episodes/engineering...
    - chickensong 9mo ago
      I can't argue that. The scale was already imbalanced as well, and vibe coding has lowered the bar even more, so the gap will continue to grow for now. I'm just saying that LLMs aren't causing the divide. Accelerating yes, but I think simply equating AI usage to poor quality is wrong. Craftsmen now have a powerful tool as well, to analyze, nitpick, and refactor in ways that were previously difficult to justify. It also seems premature for so many devs to jump to hardline "AI bad" stances. So far the tech is improving quite well. We may not be able to 1-shot much of quality yet, but it remains to be seen if that will hold. Personally, I have hopes that AI will eventually push code quality much higher than it's ever been. I might be totally wrong of course, but to me it feels logical that computers would be very good at writing computer programs once the foundation is built.
bjackman 9mo ago
There's more to it than just coding Vs building though. For a long time in my career now I've been in a situation where I'd be able to build more if I was willing to abstract myself and become a slide-merchant/coalition-builder. I don't want to do this though. Yet, I'm still quite an enthusiastic vibe-coder. I think it's less about coding Vs building and more about tolerance for abstraction and politics. And I don't think there are that many people who are so intolerant of abstraction that they won't let agents write a bunch of code for them.
greenie_beans 9mo ago
makes sense if you are a data scientist where people need to be boxed into tidy little categories. but some people probably fall into both categories.
giancarlostoro 9mo ago
Yeah, I think this is a bit of insight I had not realized / been able to word correctly yet. There's developers who can let Claud go at it, and be fearless about it like me (though I mostly do it for side projects, but WOW) and then there's developers who will use it like a hammer or axe to help cut down or mold whatever is in their path. I think both approaches are okay, the biggest thing for me is the former needs to test way more, and review the code more, as developers we don't read code enough, with the "prompt and forget" approach we have a lot of free time we could spend reading the code, asking the model to refactor and refine the code. I am shocked when I hear about hundreds of thousands of lines in some projects. I've rebuilt Beads from the ground up and I'm under 10 lines of code. So we're going to have various level of AI Code Builders if you will: Junior, Mid, Senior, Architect. I don't know if models will ever pick up the slack for Juniors any time soon. We would need massive context windows for models, and who will pay for that? We need a major AI breakthrough to where the cost goes down drastically before that becomes profitable.
nfgrep 9mo ago
I’ve heard something similar: “there are people who enjoy the process, and people who enjoy the outcome”. I think this saying comes moreso from artistic circles. I’ve always considered myself a “process” person, I would even get hung-up on certain projects because I enjoyed crafting them so much. LLM’s have taken a bit of that “process” enjoyment from me, but I think have also forced some more “outcome” thinking into my head, which I’m taking as a positive.
netcraft 9mo ago
agree completely. I used to be (and still would love to be) a process person, enjoying hand writing bulletproof artisanal code. Switching to startups many years ago gave me a whole new perspective, and its been interesting the struggle between writing code and shipping. Especially when you dont know how long the code you are writing will actually live. LLMs are fantastic in that space.
lelanthran 9mo ago
> > LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building. > I’ve always said I’m a builder even though I’ve also enjoyed programming (but for an outcome, never for the sake of the code) > This perfectly sums up what I’ve been observing between people like me (builders) who are ecstatic about this new world and programmers who talk about the craft of programming, sometimes butting heads. That's one take, sure, but it's a specially crafted one to make you feel good about your position in this argument. The counter-argument is that LLM coding splits up engineers based on those who primarily like engineering and those who like managing. You're obviously one of the latter. I, OTOH, prefer engineering.
- theshrike79 9mo ago
  I prefer engineering too, I tried management and I hated it. It's just the level of engineering we're split on. I like the type of engineering where I figure out the flow of data, maybe the data structures and how they move through the system. Writing the code to do that is the most boring part of my job. The LLM does it now. I _know_ how to do it, I just don't want to. It all boils down to communication in a way. Can you communicate what you want in a way others (in this case a language model) understands? And the parts you can't communicate in a human language, can you use tools to define those (linters, formatters, editorconfig)? I've done all that with actual humans for ... a decade? So applying the exact same thing to a machine is weirdly more efficient, it doesn't complain about the way I like to have my curly braces - it just copies the defined style. With humans I've found out that using impersonal tooling to inspect code style and flaws has a lot less friction than complaining about it in PR reviews. If the CI computer says no, people don't complain, they fix it.
dimas_codes 9mo ago
I feel like this is the core issue that will actually stall LLM coding tools short of actually replacing coding work at large. 'Coders' make 'builders' keep the source code good enough so that 'builders' can continue building without breaking what they built. If 'builders' become x10 productive and 'coders' become unable to keep up with unsurmountable pile of unmaintainable mess that 'builders' proudly churn out, 'bullders' will start to run into impossibility to build further without starting over and over again hoping that agents will be able to get it right this time.
- theshrike79 9mo ago
  "Coders" can code tools that programmatically define quality. We have like 80% of those already. Then force the builders to use those tools to constrain their output.

by atonse 9mo ago

jimbokun 9mo ago

The new LLM centered workflow is really just a management job now. Managers and project managers are valuable roles and have important skill sets. But there's really very little connection with the role of software development that used to exist. It's a bit odd to me to include both of these roles under a single label of "builders", as they have so little in common. EDIT: this goes into more detail about how coding (and soon other kinds of knowledge work) is just a management task now: https://www.oneusefulthing.org/p/management-as-ai-superpower/ https://www.oneusefulthing.org/p/management-as-ai-superpower...

simianwords 9mo ago
i don't disagree. at some point LLM's might become good enough that we wouldn't need exact technical expertise.

ryandrake 9mo ago

I noticed the same thing, but wasn't able to put it into words before reading that. Been experimenting with LLM-based coding just so I can understand it and talk intelligently about it (instead of just being that grouchy curmudgeon), and the thought in the back of my mind while using Claude Code is always: "I got into programming because I like programming, not whatever this is..." Yes, I'm building stupid things faster, but I didn't get into programming because I wanted to build tons of things. I got into it for the thrill of defining a problem in terms of data structures and instructions a computer could understand, entering those instructions into the computer, and then watching victoriously while those instructions were executed. If I was intellectually excited about telling something to do this for me, I'd have gotten into management.

atonse 9mo ago
Funny you say that. Because I have never enjoyed management as much as being hands on and directly solving problems. So maybe our common ground is that we are direct problem solvers. :-)
- Ronsenshi 9mo ago
  For some reason this makes me think of a jigsaw puzzle. People usually complete these puzzles because they enjoy the process where on the end you get a picture that you can frame if you want to. Some people seem to want to get the resulting picture. No interest in process at all. I guess that's the same people who went to all those coding camps during their hay day because they heard about software engineering salaries. They just want the money.
  - direwolf20 9mo ago
    When I last bought a Lego Technic set because I wanted to play with making mechanisms with gears and stuff, I assembled it according to the instructions, which was fun, and then the final result was also cool and I couldn't bear to dismantle it.
polishdude20 9mo ago
What I have enjoyed about programming is being able to get the computer to do exactly what I want. The possibilities are bounded by only what I can conceive in my mind. I feel like with AI that can happen faster.
- testaccount28 9mo ago
  > get the computer to do exactly what I want. > with AI that can happen faster. well, not exactly that.
  - polishdude20 9mo ago
    For simple things it can. But then for more complex things that's where I step it

verdverm 9mo ago

I think the division is more likely tied to writing. You have to fundamentally change how you do your job, from one of writing a formal language for a compiler to one of writing natural language for a junior-goldfish-memory-allstar-developer, closer to management then to contributor. This distinction to me separates the two primary camps

addisonj 9mo ago

IMO, this isn't entirely a "new world" either, it is just a new domain where the conversation amplifies the opinions even more (weird how that is happening in a lot of places) What I mean by that: you had compiled vs interpreted languages, you had types vs untyped, testing strategies, all that, at least in some part, was a conversation about the tradeoffs between moving fast/shipping and maintainability. But it isn't just tech, it is also in methodologies and the words use, from "build fast and break things" and "yagni" to "design patterns" and "abstractions" As you say, it is a different viewpoint... but my biggest concern with where are as industry is that these are not just "equally valid" viewpoints of how to build software... it is quite literally different stages of software, that, AFAICT, pretty much all successful software has to go through. Much of my career has been spent in teams at companies with products that are undergoing the transition from "hip app built by scrappy team" to "profitable, reliable software" and it is painful. Going from something where you have 5 people who know all the ins and outs and can fix serious bugs or ship features in a few days to something that has easy clean boundaries to scale to 100 engineers of a wide range of familiarities with the tech, the problem domain, skill levels, and opinions is just really hard. I am not convinced yet that AI will solve the problem, and I am also unsure it doesn't risk making it worse (at least in the short term)

dpflan 9mo ago
“”” Much of my career has been spent in teams at companies with products that are undergoing the transition from "hip app built by scrappy team" to "profitable, reliable software" and it is painful. Going from something where you have 5 people who know all the ins and outs and can fix serious bugs or ship features in a few days to something that has easy clean boundaries to scale to 100 engineers of a wide range of familiarities with the tech, the problem domain, skill levels, and opinions is just really hard. I am not convinced yet that AI will solve the problem, and I am also unsure it doesn't risk making it worse (at least in the short term) “”” This perspective is crucial. Scale is the great equalizer / demoralizer, scale of the org and scale of the systems. Systems become complex quickly, and verifiability of correctness and function becomes harder. Companies that built from day with AI and have AI influencing them as they scale, where does complexity begin to run up against the limitations of AI and cause regression? Or if all goes well, amplification?

slaymaker1907 9mo ago

I enjoy both and have ended up using AI a lot differently than vibe coders. I rarely use it for generating implementations, but I use it extensively for helping me understand docs/apis and more importantly, for debugging. AI saves me so much time trying to figure out why things aren’t working and in code review. I deliberately avoid full vibe coding since I think doing so will rust my skills as a programmer. It also really doesn’t save much time in my experience. Once I have a design in mind, implementation is not the hard part.

mkozlows 9mo ago

I think he's really getting at something there. I've been thinking about this a lot (in the context of trying to understand the persistent-on-HN skepticism about LLMs), and the framing I came up with[1] is top-down vs. bottom-up dev styles, aka architecting code and then filling in implementations, vs. writing code and having architecture evolve. [1] https://www.klio.org/theory-of-llm-dev-skepticism/ https://www.klio.org/theory-of-llm-dev-skepticism/

jamauro 9mo ago
I like this framing. Nice typography btw, a pleasure to read.

Imustaskforhelp 9mo ago

> I enjoy both and have ended up using AI a lot differently than vibe coders. I rarely use it for generating implementations, but I use it extensively for helping me understand docs/apis and more importantly, for debugging. AI saves me so much time trying to figure out why things aren’t working and in code review. I had felt like this and still do but man, at some point, I feel like the management churn feels real & I just feel suffering from a new problem. Suppose, I actually end up having services literally deployed from a single prompt nothing else. Earlier I used to have AI write code but I was interested in the deployment and everything around it, now there are services which do that really neatly for you (I also really didn't give into the agent hype and mostly used browsers LLM) Like on one hand you feel more free to build projects but the whole joy of project completely got reduced. I mean, I guess I am one of the junior dev's so to me AI writing code on topics I didn't know/prototyping felt awesome. I mean I was still involved in say copy pasting or looking at the code it generates. Seeing the errors and sometimes trying things out myself. If AI is doing all that too, idk For some reason, recently I have been disinterested in AI. I have used it quite a lot for prototyping but I feel like this complete out of the loop programming just very off to me with recent services. I also feel like there is this sense of if I buy for some AI thing, to maximally extract "value" out of it. I guess the issue could be that I can have vague terms or have a very small text file as input (like just do X alternative in Y lang) and I am now unable to understand the architectural decisions and the overwhelmed-ness out of it. Probably gonna take either spec-driven development where I clearly define the architecture or development where I saw something primagen do recently which is that the AI will only manipulate code of that particular function, (I am imagining it for a file as well) and somehow I feel like its something that I could enjoy more because right now it feels like I don't know what I have built at times. When I prototype with single file projects using say browser for funsies/any idea. I get some idea of what the code kind of uses with its dependencies and functions names from start/end even if I didn't look at the middle A bit of ramble I guess but the thing which kind of is making me feel this is that I was talking to somebody and shwocasing them some service where AI + server is there and they asked for something in a prompt and I wrote it. Then I let it do its job but I was also thinking how I would architect it (it was some detect food and then find BMR, and I was thinking first to use any api but then I thought that meh it might be hard, why not use AI vision models, okay what's the best, gemini seems good/cheap) and I went to the coding thing to see what it did and it actually went even beyond by using the free tier of gemini (which I guess didn't end up working could be some rate limit of my own key but honestly it would've been the thing I would've tried too) So like, I used to pride myself on the architectural decisions I make even if AI could write code faster but now that is taken away as well. I really don't want to read AI code so much so honestly at this point, I might as well write code myself and learn hands on but I have a problem with build fast in public like attitude that I have & just not finding it fun. I feel like I should do a more active job in my projects & I am really just figuring out what's the perfect way to use AI in such contexts & when to use how much. Thoughts?

coffeeaddict1 9mo ago

But how can you be a responsible builder if you don't have trust in the LLMs doing the "right thing"? Suppose you're the head of a software team where you've picked up the best candidates for a given project, in that scenario I can see how one is able to trust the team members to orchestrate the implementation of your ideas and intentions, with you not being intimately familiar with the details. Can we place the same trust in LLM agents? I'm not sure. Even if one could somehow prove that LLM are very reliable, the fact an AI agents aren't accountable beings renders the whole situation vastly different than the human equivalent.

inerte 9mo ago
You don't simply put a body in a seat and get software. There are entire systems enabling this trust: college, resume, samples, referral, interviews, tests and CI, monitoring, mentoring, and performance feedback. And accountability can still exist? Is the engineer that created or reviewed a Pull Request using Claude Code less accountable then one that used PICO?
- coffeeaddict1 9mo ago
  > And accountability can still exist? Is the engineer that created or reviewed a Pull Request using Claude Code less accountable then one that used PICO? The point is that in the human scenario, you can hold the human agents accountable. You cannot do that with AI. Of course, you as the orchestrator of agents will be accountable to someone, but you won't have the benefit of holding your "subordinates" accountable, which is what you do in a human team. IMO, this renders the whole situation vastly different (whether good or bad I'm not sure).
  - polishdude20 9mo ago
    You can switch to another LLM provider or stop using them altogether. It's even easier than firing a developer.
    - ipaddr 9mo ago

senderista 9mo ago

Maybe there's an intermediate category: people who like designing software? I personally find system design more engaging than coding (even though I enjoy coding as well). That's different from just producing an opaque artifact that seems to solve my problem.

monkaiju 9mo ago

So far I haven't seen it actually be effective at "building" in a work context with any complexity, and this despite some on our team desperately trying to make that the case.

barrell 9mo ago
Agreed. I don’t care for engineering or coding, and would gladly give it up the moment I can. I’m also running a one man business where every hour counts (and where I’m responsible for maintaining every feature). The fact of the matter is LLMs produce lower quality at higher volumes in more time than it would take to write it myself, and I’m a very mediocre engineer. I find this seperation of “coding” vs “building” so offensive. It’s basically just saying some people are only concerned with “inputs”, while others with “outputs”. This kind of rhetoric is so toxic. It’s like saying LLM art is separating people into people who like to scribble, and people who like to make art.
- Applejinx 9mo ago
  Would you accept 'people who like to make art, and people who like to commission somebody to make art and give them lots of notes in the process'?
  - barrell 9mo ago
    I mean it’s closer, but I don’t think it’s right to equate commissioning an artist with paying a multi-billion dollar corporation to steal from artists. These tools are just lazy shortcuts. And that’s fine, there’s no problem with taking the lazy way. I’m never going to put in the time to learn to draw, so it’s cool there’s an option for me. I just take ire with pretending it’s something grand and refined, or spitting in the face of the ones who are willing to put in the work
FeepingCreature 9mo ago
I have! You have to be realistic about the projects. The more irreducible local context it needs, the less useful it will be. Great for greenfield code, oneshots, write once read once run for months.

codyb 9mo ago

I think there's a place for both. We have services deployed globally serving millions of customers where rigor is really important. And we have internal users who're building browser extensions with AI that provide valuable information about the interface they're looking at including links to the internal record management, and key metadata that's affecting content placement. These tools could be handed out on Zip drives in the street and it would just show our users some of the metadata already being served up to them, but it's amazing to strip out 75% of the process of certain things and just have our user (in this case though, it's one user who is driving all of this, so it does take some technical inclination) build out these tools that save our editors so much time when doing this before would have been months and months and months of discovery and coordination and designs that probably wouldn't actually be as useful in the end after the wants of the user are diluted through 18 layers of process.

globular-toast 9mo ago

I like building, but I don't fool myself into thinking it can be done by taking shortcuts. You could build something that looks like a house for half the cost but it won't be structurally sound. That's why I care about the details. Someone has to.

concats 9mo ago

I remember leaving university going into my first engineering job, thinking "Where is all the engineering? All the problem solving and building complex system? All the math and science? Have I been demoted to a lowly programmer?" Took me a few years to realize that this wasn't a universal feeling, and that many others found the programming tasks more fulfilling than any challenging engineering. I suppose this is merely another manifestation of the same phenomena.

asimovDev 9mo ago

To me this is similar to car enthusiasms. Some people absolutely love to build their project car, it's a major part of the hobby for them. Others just love the experience of driving, so they buy ready cars or just pay someone to work on the car.

stevenhuang 9mo ago
Alternatively, others just want to get to their destination.

chrisjj 9mo ago

> > LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building. This is much less significant than the fact LLMs split engineers on those who primarily like quality v. those who primarily like speed.

chickensong 9mo ago
That split has always existed. LLMs can be used on either side of the divide.
- chrisjj 9mo ago
  We see a ton of "AI let me code a program X faster than ever before." We see almost no "AI let me code a program X better than ever before."
  - Philpax 9mo ago
    See this episode of Oxide and Friends, where they discuss just that: https://oxide-and-friends.transistor.fm/episodes/engineering-rigor-in-the-llm-age https://oxide-and-friends.transistor.fm/episodes/engineering...
  - chickensong 9mo ago
    I can't argue that. The scale was already imbalanced as well, and vibe coding has lowered the bar even more, so the gap will continue to grow for now. I'm just saying that LLMs aren't causing the divide. Accelerating yes, but I think simply equating AI usage to poor quality is wrong. Craftsmen now have a powerful tool as well, to analyze, nitpick, and refactor in ways that were previously difficult to justify. It also seems premature for so many devs to jump to hardline "AI bad" stances. So far the tech is improving quite well. We may not be able to 1-shot much of quality yet, but it remains to be seen if that will hold. Personally, I have hopes that AI will eventually push code quality much higher than it's ever been. I might be totally wrong of course, but to me it feels logical that computers would be very good at writing computer programs once the foundation is built.

bjackman 9mo ago

There's more to it than just coding Vs building though. For a long time in my career now I've been in a situation where I'd be able to build more if I was willing to abstract myself and become a slide-merchant/coalition-builder. I don't want to do this though. Yet, I'm still quite an enthusiastic vibe-coder. I think it's less about coding Vs building and more about tolerance for abstraction and politics. And I don't think there are that many people who are so intolerant of abstraction that they won't let agents write a bunch of code for them.

greenie_beans 9mo ago

makes sense if you are a data scientist where people need to be boxed into tidy little categories. but some people probably fall into both categories.

giancarlostoro 9mo ago

Yeah, I think this is a bit of insight I had not realized / been able to word correctly yet. There's developers who can let Claud go at it, and be fearless about it like me (though I mostly do it for side projects, but WOW) and then there's developers who will use it like a hammer or axe to help cut down or mold whatever is in their path. I think both approaches are okay, the biggest thing for me is the former needs to test way more, and review the code more, as developers we don't read code enough, with the "prompt and forget" approach we have a lot of free time we could spend reading the code, asking the model to refactor and refine the code. I am shocked when I hear about hundreds of thousands of lines in some projects. I've rebuilt Beads from the ground up and I'm under 10 lines of code. So we're going to have various level of AI Code Builders if you will: Junior, Mid, Senior, Architect. I don't know if models will ever pick up the slack for Juniors any time soon. We would need massive context windows for models, and who will pay for that? We need a major AI breakthrough to where the cost goes down drastically before that becomes profitable.

nfgrep 9mo ago

I’ve heard something similar: “there are people who enjoy the process, and people who enjoy the outcome”. I think this saying comes moreso from artistic circles. I’ve always considered myself a “process” person, I would even get hung-up on certain projects because I enjoyed crafting them so much. LLM’s have taken a bit of that “process” enjoyment from me, but I think have also forced some more “outcome” thinking into my head, which I’m taking as a positive.

netcraft 9mo ago

agree completely. I used to be (and still would love to be) a process person, enjoying hand writing bulletproof artisanal code. Switching to startups many years ago gave me a whole new perspective, and its been interesting the struggle between writing code and shipping. Especially when you dont know how long the code you are writing will actually live. LLMs are fantastic in that space.

lelanthran 9mo ago

> > LLM coding will split up engineers based on those who primarily liked coding and those who primarily liked building. > I’ve always said I’m a builder even though I’ve also enjoyed programming (but for an outcome, never for the sake of the code) > This perfectly sums up what I’ve been observing between people like me (builders) who are ecstatic about this new world and programmers who talk about the craft of programming, sometimes butting heads. That's one take, sure, but it's a specially crafted one to make you feel good about your position in this argument. The counter-argument is that LLM coding splits up engineers based on those who primarily like engineering and those who like managing. You're obviously one of the latter. I, OTOH, prefer engineering.

theshrike79 9mo ago
I prefer engineering too, I tried management and I hated it. It's just the level of engineering we're split on. I like the type of engineering where I figure out the flow of data, maybe the data structures and how they move through the system. Writing the code to do that is the most boring part of my job. The LLM does it now. I _know_ how to do it, I just don't want to. It all boils down to communication in a way. Can you communicate what you want in a way others (in this case a language model) understands? And the parts you can't communicate in a human language, can you use tools to define those (linters, formatters, editorconfig)? I've done all that with actual humans for ... a decade? So applying the exact same thing to a machine is weirdly more efficient, it doesn't complain about the way I like to have my curly braces - it just copies the defined style. With humans I've found out that using impersonal tooling to inspect code style and flaws has a lot less friction than complaining about it in PR reviews. If the CI computer says no, people don't complain, they fix it.

dimas_codes 9mo ago

I feel like this is the core issue that will actually stall LLM coding tools short of actually replacing coding work at large. 'Coders' make 'builders' keep the source code good enough so that 'builders' can continue building without breaking what they built. If 'builders' become x10 productive and 'coders' become unable to keep up with unsurmountable pile of unmaintainable mess that 'builders' proudly churn out, 'bullders' will start to run into impossibility to build further without starting over and over again hoping that agents will be able to get it right this time.

theshrike79 9mo ago
"Coders" can code tools that programmatically define quality. We have like 80% of those already. Then force the builders to use those tools to constrain their output.