7 ms·

You've really hit the crux of the problem and why so many people have differing opinions about AI coding. I also find coding more fun with AI. The reason is tha

• pdntspa 9mo ago
  You are hitting the nail on the head. We are not being hired to write code. We are being hired to solve problems. Code is simply the medium.
  • wahnfrieden 9mo ago
    I believe wage work has a significant factor in all this. Most are not paid for results, they're paid for time at desk and regular responsibilities such as making commits, delivering status updates, code reviews, etc. - the daily activities of work are monitored more closely than the output. Most ESOP grant such little equity that working harder could never observably drive an increase in its value. Getting a project done faster just means another project to begin sooner. Naturally workers will begin to prefer the motions of the work they find satisfying more than the result it has for the business's bottom line, from which they're alienated.
    • Sammi 9mo ago
      > Naturally workers will begin to prefer the motions of the work they find satisfying more than the result it has for the business's bottom line, from which they're alienated. Wow. I've read a lot of hacker news this past decade, but I've never seen this articulated so well before. You really lifted the veil for me here. I see this everywhere, people thinking the work is the point, but I haven't been able to crystallize my thoughts about it like you did just now.
      • thenewwazoo 9mo ago
        Marx had a lot of good ideas, though you wouldn't know it by listening to capitalist-controlled institutions. https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation
    • order-matters 9mo ago
      I think it's related. The nature of the wage work likely also self-selects for people who simply enjoy coding and being removed from the bigger picture problems they are solving. Im on the side of only enjoy coding to solve problems and i skipped software engineering and coding for work explicitly because i did not want to participate in that dynamic of being removed from the problems. instead i went into business analytics, and now that AI is gaining traction I am able to do more of what I love - improving processes and automation - without ever really needing to "pay dues" doing grunt work I never cared to be skilled at in the first place unless it was necessary.
    • hibikir 9mo ago
      It gets worse than that: You can possibly get rewarded based on your manager's goals, or maybe your skip level's, but that doesn't necessarily have to line up all that well with more serious business goals. I am sure I am not the only one that had to help initiatives that I thought would be, at best, just wasteful to the business, or that we could get 80% of the value with 20% of the efforts. But it's ultimately about the person who writes the review. This gets us to the rule number one of being successful at a job: Make sure your manager likes you. Get 8 layers of people whose priority is just to be sure their manager likes them, and what is getting done is very unlikely to have much to do with shareholder value, customer happiness, or anything like that.
  • agumonkey 9mo ago
    but do you solve the problem if you just slap a prompt and iterate while the LLM gathers diffs ?
    • eclipxe 9mo ago
      Yes?
    • ben_w 9mo ago
      Depends what the problem is. Sometimes you can, sometimes you have to break the problem apart and get the LLM to do each bit separately, sometimes the LLM goes funny and you need to solve it yourself. Customers don't want you wasting money doing by hand what can be automated, nor do they want you ripping them off by blindly handing over unchecked LLM output when it can't be automated.
      • agumonkey 9mo ago
        there are other ways: being scammed by lazy devs using AI to produce what devs normally do and not saving any money for the customer. i mentioned it in another thread, i heard first hand people say "i will never report how much time savings i get from gemini, at best i'll say 1 day a month"
        • Dylan16807 9mo ago
          If you produce the same product, then you get to ask for the same pay. That's not a scam. If enough people can make the product faster, then competition will drive the price down. But the ability to charge less is not at all an obligation to charge less.
          • agumonkey 9mo ago
            it's paradoxical, the llm is not helping consumers, it's not helping the experienced engineer, it's helping a new class of devs that just want the easy way out. and ultimately this wave will make the price go down to the point the skilled dev won't be able to sustain long term growth because learning more and more advanced will not be valued by the economy.. just a thought but i don't see a nice path ahead now
• agumonkey 9mo ago
  it's true that 'code' doesn't mean much, but the ability to manage different layers, states to produce logic modules was the challenge getting things solved entirely feels very very numbing to me even when gemini or chatgpt solves it well, and even beyond what i'd imagine.. i feel a sense of loss
• breuleux 9mo ago
  I think it ultimately comes down to whether you care more about the what, or more about the how. A lot of coders love the craft: making code that is elegant, terse, extensible, maintainable, efficient and/or provably correct, and so on. These are the kind of people who write programming languages, database engines, web frameworks, operating systems, or small but nifty utilities. They don't want to simply solve a problem, they want to solve a problem in the "best" possible way (sometimes at the expense of the problem itself). It's typically been productive to care about the how, because it leads to better maintainability and a better ability to adapt or pivot to new problems. I suppose that's getting less true by the minute, though.
  • doug_durham 9mo ago
    Crafting code can be self-indulgent since most common patterns have been implemented multiple times in multiple languages. A lot of time the craft oriented developer will reject an existing implementation because it doesn't match their sensibilities. There is absolutely a role for craft, however the amount of craft truly needed in modern development is not as large as people would like. There are lots of well crafted libraries and frameworks that can be adopted if you are willing to accommodate their world view.
    • breuleux 9mo ago
      As someone who does that a lot... I agree. Self-indulgent is the word. It just feels great when the implementation is a perfect fit for your brain, but sometimes that's just not a good use of your time. Sometimes, you strike gold, so there's that.
      • sfn42 9mo ago
        I kind of struggle with this. I basically hate everyone elses code, and by that I mean I hate most people's code. A lot of people write awesome code but most people write what I'd call trash code. And I do think there's more to it than preference. Like there's actual bugs in the code, it's confusing and because it's confusing there's more bugs. It's solving a simple problem but doing so in an unnecessarily convoluted way. I can solve the same problem in a much simpler way. But because everything is like this I can't just fix it, there's layers and layers of this convolution that can't just be fixed and of course there's no proper decoupling etc so a refactor is kind of all or nothing. If you start it's like pulling on a thread and everything just unravels. This is going to sound pompous and terrible but honestly some times I feel like I'm too much better than other developers. I have a hard time collaborating because the only thing I really want to do with other people's code is delete it and rewrite it. I can't fix it because it isn't fixable, it's just trash. I wish they would have talked to me before writing it, I could have helped then. Obviously in order to function in a professional environment i have to suppress this stuff and just let the code be ass but it really irks me. Especially if I need to build on something someone else made - itsalmost always ass, I don't want to build on a crooked foundation. I want to fix the foundation so the rest of the building can be good too. But there's no time and it's exhausting fixing everyone else's messes all the time.
• ben_w 9mo ago
  > > I think we have different opinions on what's fun and what's boring! > You've really hit the crux of the problem and why so many people have differing opinions about AI coding. Part of it perhaps, but there's also a huge variation in model output. I've been getting some surprisingly bad generations from ChatGPT recently, though I'm not sure if that's ChatGPT getting worse or me getting used to a much higher quality of code from Claude Code which seems to test itself before saying "done". I have no idea if my opinion will flip again now 5.2 is out. And some people are bad communicators, an important skill for LLMs, though few will recognise it because everyone knows what they themselves meant by whatever words they use. And some people are bad planners, likewise an important skill for breaking apart big tasks that LLMs can't do into small ones they can do.
  • danielmarkbruce 9mo ago
    This isn't just in coding. My goodness the stuff I see people write into an LLM and then say "see! It's stupid!". Some people are naturally good at prompting and some people just are not. The differences in output are dramatic.
• libraryofbabel 9mo ago
  I like this framing; I think it captures some of the key differences between engineers who are instinctively enthusiastic about AI and those who are not. Many engineers walk a path where they start out very focussed on programming details, language choice, and elegant or clever solutions. But if you're in the game long enough, and especially if you're working in medium-to-large engineering orgs on big customer-facing projects, you usually kind of move on from it. Early in my career I learned half a dozen programming languages and prided myself on various arcane arts like metaprogramming tricks. But after a while you learn that one person's clever solution is another person's maintainability nightmare, and maybe being as boring and predictable and direct as possible in the code (if slightly more verbose) would have been better. I've maintained some systems written by very brilliant programmers who were just being too clever by half. You also come to realize that coding skills and language choice don't matter as much as you thought, and the big issues in engineering are 1) are you solving the right problem to begin with 2) people/communication/team dynamics 3) systems architecture, in that order of importance. And also, programming just gets a little repetitive after a while. Like you say, after a decade or so, it feels a bit like "more of the same." That goes especially for most of the programming most of us are doing most of the time in our day jobs. We don't write a lot of fancy algorithms, maybe once in a blue moon and even then you're usually better off with a library. We do CRUD apps and cookie-cutter React pages and so on and so on. If AI coding agents fall into your lap once you've reached that particular variation of a mature stage in your engineering career, you probably welcome them as a huge time saver and a means to solve problems you care about faster. After a decade, I still love engineering, but there aren't may coding tasks I particularly relish diving into. I can usually vaguely picture the shape of the solution in my head out the gate, and actually sitting down and doing it feels rather a bore and just a lot of typing and details. Which is why it's so nice when I can kick off a Claude session to do it instead, and review the results to see if they match what I had in mind. Don't get me wrong. I still love programming if there's just the right kind of compelling puzzle to solve (rarer and rarer these days), and I still pride myself on being able to do it well. Come the holidays I will be working through Advent of Code with no AI assistance whatsoever, just me and vim. But when January rolls around and the day job returns I'll be having Claude do all the heavy lifting once again.
  • 9mo ago
• altmanaltman 9mo ago
  A few counterpoints: 1. If you don't care about code and only care about the "thing that it does when it's done", how do you solve problems in a way that is satisfying? Because you are not really solving any problem but just using the AI to do it. Is prompting more satisfying than actually solving? 2. You claim you're done "learning about coding and stretching my personal knowledge in the area" but don't you think that's super dangerous? Like how can you just be done with learning when tech is constantly changing and new things come up everyday. In that sense, don't you think AI use is actually making you learn less and you're just justifying it with the whole "I love solving problems, not code" thing? 3. If you don't care about the code, do the people who hire you for it do? And if they do, then how can you claim you don't care about the code when you'll have to go through a review process and at least check the code meaning you have to care about the code itself, right?
  • pdntspa 9mo ago
    Why can't both things be true? You can care about the code even if you don't write it. You can continue learning things by reading said code. And you can very rigidly enforce code quality guidelines and require the AI adhere to them.
    • altmanaltman 9mo ago
      I mean if you're reading it and "rigidly" enforcing code quality guidelines, then you do care about the code, right? But the parent comment said they don't care about the code but what it does. Both of them cannot be true at the same time, since in your example, you do care about the code enough to read it and refactor it based on guidelines and not just "what the code" does.
  • keeda 9mo ago
    Note I'm not saying one is better than the other, but my takes: 1. The problem solving is in figuring out what to prompt, which includes correctly defining the problem, identifying a potential solution, designing an architecture, decomposing it into smaller tasks, and so on. Giving it a generic prompt like "build a fitness tracker" will result in a fully working product but it will be bland as it would be the average of everything in its training data, and won't provide any new value. Instead, you probably want to build something that nobody else has, because that's where the value is. This will require you to get pretty deep into the problem domain, even if the code itself is abstracted away from you. Personally, once the shape of the solution and the code is crystallized in my head typing it out is a chore. I'd rather get it out ASAP, get the dopamine hit from seeing it work, and move on to the next task. These days I spend most of my time exploring the problem domain rather than writing code. 2. Learning still exists but at a different level; in fact it will be the only thing we will eventually be doing. E.g. I'm doing stuff today that I had negligible prior background in when I began. Without AI, I would probably require an advanced course to just get upto speed. But now I'm learning by doing while solving new problems, which is a brand new way of learning! Only I'm learning the problem domain rather than the intricacies of code. 3. Statistically speaking, the people who hire us don't really care about the code, they just want business results. (See: the difficulty of funding tech debt cleanup projects!) Personally, I still care about the code and review everything, whether written by me or the AI. But I can see how even that is rapidly becoming optional. I will say this: AI is rapidly revolutionizing our field and we need to adapt just as quickly.
• standarditem 9mo ago
  I feel the same way when writing code for work. It's pretty neat to have an AI bot working on the grunt work for me while I review and write high level algorithms. It's quicker and I get less burnt out. But I still love getting my hands dirty and writing code as a mental puzzle. And the best puzzles tend to happen outside of a work environment anyways. So I continue to work through advent of code problems (for example) as a way of exercising that muscle.
• RHSeeger 9mo ago
  > I don't much care about the code itself anymore. I use writing the code as a way to investigate the options and find new ones. By the time I'm sure of the correct way to implement something, half the code is written [1]. At that point, now that I know what and how I'm going to do, it starts to get boring. I think what would work best for me would be able to say "ok, now finish this" to the AI and have it do that boring part. [1] This also makes my LOEs horrible, because I don't know what I'm going to build until I've completed half of it. And figuring out how long it will take to do something that isn't defined is... inaccurate.