but when you have requirements,
why not render the code to fulfil them?
> why not render the code to fulfil them?
Because 95% of the time the LLM can turn the requirements into code, faster, cheaper, and with fewer defects on the first attempt, than most humans.
The ancients knew it all along!
What utter twaddle.
I’m old enough to remember pre AI programming and it very very much was the bottleneck.
So old enough the remember the ancient times back in 2023?
The Heuristic Compiler, dating back to the early 1960s, is generally considered the first instance of AI programming.
Maybe you mistakenly confused AI with a particular technology, like LLMs? But even then we had LLM-based code completion tools in 2020.
Is 2023 when you became old enough to start remembering things?
For some years I have been successfully using the following rule of thumb for scheduling a software task:
l/3 planning
l/6 coding
l/4 component test and early system test
l/4 system test, all components in hand.
It meshes with my experience. Coding was never the bottleneck. Understanding what the customer/business wanted or needed was always the vast majority of the time spent on a project. A developer might not have seen that, depending how the organization worked. If you got specs from a manager you might not have been aware that those were 6 months in the making. If most of what you experienced was writing code then that could feel like the bottleneck especially if your manager demanded frequent status reports.
Have this been measured, not comparatively, but absolutely? Where you plan, but don't code, instead leave the task to an agent (while you do something else), then test the result (maybe a quick look at the code), and ship. Is it sustainable? Or is it for greenfield setup and common ideas (things you would use tooling and snippets before)?
> What's left is "planning" which under a modern iterative model apparently includes deployment/distribution and getting/understanding/incorporating feedback.
That is not "planning" means. Planning is usually understanding, research, and design.
AI has been a huge disruption to that status quo though because it enables people like me that were stuck managing these bozos to just do the thing on a timeline that wasn’t feasible before. AI also removed any excuses these people could make for never getting anything done. It exposes clearly for anyone tangentially involved in these projects that the bozos often can’t even begin to understand the problems they are trying to solve.
With the level of detail that I had to specify things for them to be productive, it’s easier and more effective to just give that (often much less detail tbh) to GitHub Copilot or Claude.
It has massively changed the game for me and helps me enjoy my job quite a bit more.
so actually it sounds like coder management was the bottleneck, not coding itself.