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.
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.
> 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.
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.
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.
Also, you need a different kind of toolset/skillset to grok a system that was vibe coded all the way - different failure scenarios. Older devs tend to just say “see, I told you, it’s just spaghetti underneath, you need to clean it up”, and the newer gen learns to work with that spaghetti.
All this really means is using more AI to cover up their blind spots. Don't flatter them.
So you agree that you're dependent on an LLM to do your work?
Two different kinds of dependence here: one is taking advantage of a pre-existing tool to perform some set of tasks. The other is there to outsource your thinking over concepts you are not able to reason about yourself.
For example for a problem I had recently Claude pointed out (after some prodding for me) that the determinant of the Jacobian of a function I'm interested in is a polynomial in polar coordinates, so I used a fancy root finding library (which I also didn't write) to solve it efficiently.
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.
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.
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.