5 ms·

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 l

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.

whateveracct 2mo ago
thanks i hate it
deleted 2mo ago
[deleted]
sitzkrieg 2mo ago
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
j4yav 2mo ago
Being a programmer in the era of AI means not being a programmer
- hirvi74 2mo ago
  That is why I am very thankful for my job. We are not really allowed to use LLMs for much of anything.
  - bigstrat2003 2mo ago
    That sounds like an absolute dream.
- chpatrick 2mo ago
  Typing the code was never the interesting part.
  - jplusequalt 2mo ago
    >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.
    - avgDev 2mo ago
      I have a blazor app in poduction, Codex made errors which it could not fix and it required me reading documentation. I won't argue that it didn't make my life simpler, tasks which would take me days are done in hours, sometimes without touching code.
      - unshavedyak 2mo ago
        Yea, i still deal with a ton of code in AI heavy workflows. If anything the frustrating part is absorbing the code quickly enough. AI (Claude for me) writes in cryptic text and the code flows can often be non-obvious. I need (and am exploring) custom review tooling to improve this AI->Human code flow. Reviewing PRs were always the hardest part for me in programming. They were often full of the developers decisions and you have to rediscover those as you're reading code for it to make sense[1]. However i find this even more difficult to discover these decisions from AI. However unlike human PRs we can ask more of AI. Rarely have i had a developer put on a presentation for a PR - but AI could right? AI could produce a guided walkthrough of the code. Not sure if it will help of course, but my thought is we're all stuck in the old "PR review flow" but instead of PRs it's AI - and the volume of them is far greater than anything prior. So i expect we need to tweak how we review, how we get information from LLMs. [1]: I'm speaking generally, and about larger PRs. Not some small func where you can easily see what it does. Business logic and complex code can be difficult to decipher in PRs, imo.
        othmanosx 2mo ago
        I'm building https://pyor.review https://pyor.review to fix this problem, try it out and let me know what you think.
- shostack 2mo ago
  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.
  - ahartmetz 2mo ago
    Don't forget probabilistic.
  - vrighter 2mo ago
    the thing that allowed me to effectively climb higher in the abstraction stack, is to dive lower first.
- josephg 2mo ago
  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.
chowells 2mo ago
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.
- wredcoll 2mo ago
  > (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.
  - chowells 2mo ago
    No. C is a language with a specification independent of implementation. If you write correct C code (according to the specification, which no one does), it does not depend on any of those factors. C is almost uniquely bad in terms of accepting broken programs and just compiling them differently. But that doesn't change the fact that the language has semantics, even if most code that violates the documented preconditions those semantics depend on.
crnkofe 2mo ago
Lots of people mention this higher abstraction level but its not really the case. C has a grammar. You write C and get C as output. Assembly is hidden from the user. Natural language also has a grammar ("sort of"). You write prose into your preferred cli/app of choice BUT it outputs code in C or other language. So its basically a code generator. A code generator is not even remotely a form of abstraction. Its just a facade that breaks down as soon as the generator fails to produce a meaningful result.

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.

whateveracct 2mo ago

thanks i hate it

deleted 2mo ago

[deleted]

sitzkrieg 2mo ago

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

j4yav 2mo ago

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

hirvi74 2mo ago
That is why I am very thankful for my job. We are not really allowed to use LLMs for much of anything.
- bigstrat2003 2mo ago
  That sounds like an absolute dream.
chpatrick 2mo ago
Typing the code was never the interesting part.
- jplusequalt 2mo ago
  >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.
  - avgDev 2mo ago
    I have a blazor app in poduction, Codex made errors which it could not fix and it required me reading documentation. I won't argue that it didn't make my life simpler, tasks which would take me days are done in hours, sometimes without touching code.
    - unshavedyak 2mo ago
      Yea, i still deal with a ton of code in AI heavy workflows. If anything the frustrating part is absorbing the code quickly enough. AI (Claude for me) writes in cryptic text and the code flows can often be non-obvious. I need (and am exploring) custom review tooling to improve this AI->Human code flow. Reviewing PRs were always the hardest part for me in programming. They were often full of the developers decisions and you have to rediscover those as you're reading code for it to make sense[1]. However i find this even more difficult to discover these decisions from AI. However unlike human PRs we can ask more of AI. Rarely have i had a developer put on a presentation for a PR - but AI could right? AI could produce a guided walkthrough of the code. Not sure if it will help of course, but my thought is we're all stuck in the old "PR review flow" but instead of PRs it's AI - and the volume of them is far greater than anything prior. So i expect we need to tweak how we review, how we get information from LLMs. [1]: I'm speaking generally, and about larger PRs. Not some small func where you can easily see what it does. Business logic and complex code can be difficult to decipher in PRs, imo.
      - othmanosx 2mo ago
        I'm building https://pyor.review https://pyor.review to fix this problem, try it out and let me know what you think.
shostack 2mo ago
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.
- ahartmetz 2mo ago
  Don't forget probabilistic.
- vrighter 2mo ago
  the thing that allowed me to effectively climb higher in the abstraction stack, is to dive lower first.
josephg 2mo ago
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.

chowells 2mo ago

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.

wredcoll 2mo ago
> (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.
- chowells 2mo ago
  No. C is a language with a specification independent of implementation. If you write correct C code (according to the specification, which no one does), it does not depend on any of those factors. C is almost uniquely bad in terms of accepting broken programs and just compiling them differently. But that doesn't change the fact that the language has semantics, even if most code that violates the documented preconditions those semantics depend on.

crnkofe 2mo ago

Lots of people mention this higher abstraction level but its not really the case. C has a grammar. You write C and get C as output. Assembly is hidden from the user. Natural language also has a grammar ("sort of"). You write prose into your preferred cli/app of choice BUT it outputs code in C or other language. So its basically a code generator. A code generator is not even remotely a form of abstraction. Its just a facade that breaks down as soon as the generator fails to produce a meaningful result.