I am a developer who has to deliver finished products, so I do not think my view is necessarily the correct answer.
But based on my experience, I suspect the important thing is not just whether we use AI or not. On HN, people often say that using AI will degrade your ability. But if we assume that people will use it anyway, then I think developers first need to accumulate the experience of failure.
There will probably be many people who go through large failures with AI. They will hit bottlenecks, fix them, and record what happened. Over time, companies will have people who have failed with AI inside their actual product codebases. Those people will become better at judging where bottlenecks tend to appear in an AI-assisted workflow.
For example, simple CRUD has a low bottleneck score because GPT may be better than me at generating it. But GPT also tends to create god objects, so maintainability can become bad. In that case, architecture and refactoring should be given a high bottleneck score.
In general, AI seems strong in high-level languages and areas where memory is not directly managed. But it is weaker in memory-related areas, low-level details, and places where subtle resource ownership matters. For those areas, I would use more conservative estimates and rely more on traditional estimates based on human developer skill.
From this perspective, I think “resources” should mean assigning people who have the right cognitive experience of failure for a given software area.
Recently I have been intentionally doing AI “vibe coding” to observe where it fails and where bottlenecks appear. I divide work into P0, P1, and P2: what AI is good at, what I must handle myself, and what can safely be delegated.
For P0, I put things like JWT authentication, business logic, and domain design. I do these myself, and I estimate them from the perspective of a human developer.
For P1, I put connection logic that touches P0. For example, glue code around core logic. I estimate this at roughly half of the traditional time, but I include a verification layer in that estimate.
For P2, I put things like non-critical frontend logic or minor UI behavior that does not cause serious damage even if it fails. I mostly let AI handle those parts.
When I run GPT in parallel, I can get around 3,000 lines of code in about five minutes. So I think each company and each developer will need their own conservative estimate based on AI skill, failure experience, and the specific feature area.
However, this is only the perspective of a programmer who usually works below roughly 80,000 lines of code. Once a project reaches 400,000 or 500,000 lines, modularization and boundary design become exponentially more complex. At that point, I think the estimate should be left to senior developers who understand the system boundaries deeply.
I think the estimation variable will ultimately be less about an “AI productivity multiplier” and more about accumulated experience with AI failure patterns.
I am a developer who has to deliver finished products, so I do not think my view is necessarily the correct answer.
But based on my experience, I suspect the important thing is not just whether we use AI or not. On HN, people often say that using AI will degrade your ability. But if we assume that people will use it anyway, then I think developers first need to accumulate the experience of failure.
There will probably be many people who go through large failures with AI. They will hit bottlenecks, fix them, and record what happened. Over time, companies will have people who have failed with AI inside their actual product codebases. Those people will become better at judging where bottlenecks tend to appear in an AI-assisted workflow.
For example, simple CRUD has a low bottleneck score because GPT may be better than me at generating it. But GPT also tends to create god objects, so maintainability can become bad. In that case, architecture and refactoring should be given a high bottleneck score.
In general, AI seems strong in high-level languages and areas where memory is not directly managed. But it is weaker in memory-related areas, low-level details, and places where subtle resource ownership matters. For those areas, I would use more conservative estimates and rely more on traditional estimates based on human developer skill.
From this perspective, I think “resources” should mean assigning people who have the right cognitive experience of failure for a given software area.
Recently I have been intentionally doing AI “vibe coding” to observe where it fails and where bottlenecks appear. I divide work into P0, P1, and P2: what AI is good at, what I must handle myself, and what can safely be delegated.
For P0, I put things like JWT authentication, business logic, and domain design. I do these myself, and I estimate them from the perspective of a human developer.
For P1, I put connection logic that touches P0. For example, glue code around core logic. I estimate this at roughly half of the traditional time, but I include a verification layer in that estimate.
For P2, I put things like non-critical frontend logic or minor UI behavior that does not cause serious damage even if it fails. I mostly let AI handle those parts.
When I run GPT in parallel, I can get around 3,000 lines of code in about five minutes. So I think each company and each developer will need their own conservative estimate based on AI skill, failure experience, and the specific feature area.
However, this is only the perspective of a programmer who usually works below roughly 80,000 lines of code. Once a project reaches 400,000 or 500,000 lines, modularization and boundary design become exponentially more complex. At that point, I think the estimate should be left to senior developers who understand the system boundaries deeply.
I think the estimation variable will ultimately be less about an “AI productivity multiplier” and more about accumulated experience with AI failure patterns.