From "The Mythical Man-month" (1995 ed)
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.
The separation can be blurred if you follow an iterative approach (also explained in the book), but it aligned roughly with my experience. And whenever I helped a colleague in the past, coding was not the problem. It was either the lack of planning (no data modelling, no rough algorithm design), or no test setup (trial and error coding). It was never the coding part. Syntax errors is trivial to solve (with any good editor) and most libraries have good reference docs (not learning the library is an orthogonal matter).That's nice, but not authoritative for ~20 years (since before VMs and AWS). This book was before CI was commonplace.
Say what you want about reducible fractions but that's a pretty nonintuitive way to describe how you divvy up time. Weird to not use percentages or a common denominator...
AI practically zeroes out the coding and component test part of the process and massively accelerates the system test. What's left is "planning" which under a modern iterative model apparently includes deployment/distribution and getting/understanding/incorporating feedback. With a fully optimized process, knowing what to build is nearly the entire problem.