Comment by paulpauper

12 hours ago

Being a programmer in the era of AI now means configuring the AI and run environments to produce the sought result, than manipulating the code itself. It's like how C runs on top of assembly.

It's nothing at all how like C runs on top of assembly. C has semantics. Code means something without ever being run. You can check in your source code and (assuming it actually follows the C standard and your compiler's documented extensions, which almost no real C code does - C was a horrible example) it will work just as well in a year as it does today.

Try checking in only your prompts and nothing else. Just the parts you actually typed. See how well it works to regenerate the same application next week, let alone next year. Prompts are fundamentally a different sort of thing from code. Do not mix them up.

  • > (assuming it actually follows the C standard and your compiler's documented extensions, which almost no real C code does - C was a horrible example) it will work just as well in a year as it does today.

    > See how well it works to regenerate the same application next week, let alone next year. Prompts are fundamentally a different sort of thing from code

    I mean... yes, but also no. C is actually a great example. So much of the code we wrote is about manipulating the specifics of that specific computer system we happen to be using at that exact moment. Everything from cpu specific instructions to how the ram behaves or how much of it there is all the way up to how library functions operate at any given point in time.

    And in relatively short amounts of time, it can all change out from underneath you.

Being a programmer in the era of AI means not being a programmer

  • Being a programmer has always meant dealing with abstraction layers and climbing up the abstraction ladder.

    You are simply learning a new language, whose syntax happens to look like English (or whatever language you speak), but with new, undiscovered, and constantly changing design patterns and best practices.

  • It depends how much you outsource to the llm.

    If you outsource everything to a llm, I just don’t think you get very good results right now. Language models aren’t great at remembering all the little design decisions that are needed in medium to large projects. The code ends up riddled with semi-conflicting design choices, which have been slammed together and maintained by context inertia. For a lot of projects this is more than fine - sometimes higher quality work simply isn’t worth my time. But for a lot of projects, you will pay for that slop later.

    But I think there is a useful middle ground. If you carefully review all the decisions an llm makes, I think you can often be more productive than just programming everything by hand. But it’s a very different way to do engineering. I think I learn more this way than if I program by hand - if only because I’m touching more code. My mind roves around the design space a lot more. I don’t lock in as much as when I’m programming each piece individually.

    If you work with an llm like this, your engineering skill matters more than ever.

  • Typing the code was never the interesting part.

    • >> Typing the code was never the interesting part.

      Code is fascinating! An abstract language to compile to program a CPU. So many ways to do this!

      Now we're using natural language, which at times is extremely verbose. "[{}]" versus "array of objects", for example.

    • >Typing the code was never the interesting part.

      But solving hard problems and developing systems intuition was. If you're trying to tell me that people working on code bases predominantly written by AI are still solving hard problems themselves, or understand the systems the AI is building, I think they're lying to themselves.

      5 replies →

luckily there are still some people who know and care about actually understanding what is happening. but dwindling. market correction needed to wash larpers out