Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Most of this article went over my head, but I think this is key point:

    if your prompt is not specific enough, many decisions are a coin flip.

    If you are using AI, you still have to know what you want it to do. If you are a project manager and give your team incomplete requirements, the result may not be unlike this.

    by userbinator
  • Yes, you certainly still do have to think. But you’re thinking about how to isolate risk via architecture and about which languages the AI can most naturally work in for a given task.

    You’re thinking: Should I put a protobuf here and build a separate service? Which side should own the protocol? How do I ensure the AI never couples concerns A and B? Can we prove this works with smarter automated testing, or do we need additional manual QA in this critical area before release?

    Port my whole legacy codebase to another language with no guidance is a novelty problem. It is not comparable to what professionally managed AI driven development actually looks like.

    by iforgotmypasswo
  • All of this "you need to understand the code" discussion reminds me of when I was an undergrad. I worked in a computer with someone a fair bit older -- they had even worked with punchcard systems. He was always happy to oblige us with war stories from the olden times & we would lap them up.

    He favorite axe to grind was how my generation put too much trust into the compiler. "Just because it compiles doesn't mean you're done. You need to look at the actual assembly. Compilers can be VERY inefficient."

    This was in the 90s. There was some merit to his claim.

    But today? How many people who write Javascript look at the actual assembly code that is run? Not many.

    I can't help but wonder if this current "you need to understand the code" is the same thing all over again. And if in a few years, almost nobody will look at the generated Python, Ruby, etc.

    by wdr1
  • Yes I agree thinking is still needed off course, but it has never been easier to ship 'half baked' things that don't actually matter and just works. What I mean is, if something has little proven business value, why waste time making sure it is correctly implemented? I'd rather spend time thinking about things that has actual proven business value, otherwise I'm not opposed to shipping something that I understand only 60 or 70% and save energy. ie: how it works at a high level.

    If we are going to the moon, then by all means I think we should probably scrutinize every single line of code, but most business aren't going to the moon.

    by adventure331
  • Yep AI will just invent the missing stuff; that's not purely an AI thing, we do the same as well until we become experienced enough to know what questions to ask in order to narrow down vague requirements.

    If I'm tired, yep I'm going to write more sloppy code, I'll put less thought into it and be more tempted to tell the AI 'just do it'. That hasn't changed. I'm not sure where this new breed of "don't read the code" is coming from when it's actual software engineers making the statement; maybe it's just over-excitement and it'll die down (hopefully).

    Or it's just over-simplification -- I don't read ALL the code either anymore, but at the same time I'm reading SOME of the code. Tell your AI agent you're doing a code review workshop, ask it to select ten files at random and then go through them with you one at a time. Ask it to review common anti-patterns and put them in your coding standard. Then you can start asking it to review and fix code against your standard as a first pass. You'll still need to manually review the code to keep it in check, but at least you can make it a bit less daunting and a little more fun by actively collaborating on the AI with the review.

    I'm learning it's just a 'different kind of tired'. AI has made some stuff much more efficient, including the choice between efficiency and carefulness. You can make that choice at a micro level and very quickly now if you want. There's still fatigue though, it's just a different kind of fatigue. You still get tired from all the thinking. You can still choose to put the work in or not and it still makes a difference. It's just a different kind of difficult. Doesn't mean that the thing to do is to throw your hands in the air and declare that your job shouldn't be difficult or include hard work anymore.

    by Fr0styMatt88
  • You need to understand the system you're working on enough to make well-informed decisions about its current and future states.

    In some cases you can get away with not reading the code. And maybe in the future that will be more common. But for now, I personally prefer to read (or skim) the code, and not abdicate to AI.

    by Ozzie_osman
  • It's worth noting that the context here is a system that was translated by an LLM which is the ideal use case for it. 90% of the thinking had already been done by developers of the existing system.
    by discreteevent
  • This article just reminds me that workslop is so hard to counter because it takes no effort to produce and immense effort to debunk
    by variety8675

Explore Birbla archives