I'm really interested in the additional time cost of your switch. As you say, measuring productivity is seems nearly impossible.
But I would expect your 40 developers now have more time to do other things, because AI is taking on some of the workload? So have you noticed developers now doing 'new' things, like experimenting with new ideas, shorter hours, more holidays, or spending more time learning non-core topics? I think that would be visible. The 'Friday for personal projects' becomes 'Thu and Fri for personal projects', for example.
When frameworks became popular ten or so years ago, developers made the 'this will be much more efficient' argument. All that seemed to happen was the time they used to spend thinking/learning the core language (or engineering concepts) was swapped for time learning the framework. So there was no significant productivity gain, despite tasks feeling easier to do.
You list AI management/maintenance tasks that didn't need to be done before. I assume not all of these are 40x across your developers. It will be interesting to see if this management workload becomes similar to infrastructure management, and develops into a new job type providing a shared service. At least maybe during the transition away from flesh-based development to AI development.
I guess your end goal is that AI writes all (literal) code and owns the codebase, directed by people in the company? Do you have a plan to transition developers away from tech roles, is that something that's discussed?
thisdougb•9mo ago
I'm really interested in the additional time cost of your switch. As you say, measuring productivity is seems nearly impossible.
But I would expect your 40 developers now have more time to do other things, because AI is taking on some of the workload? So have you noticed developers now doing 'new' things, like experimenting with new ideas, shorter hours, more holidays, or spending more time learning non-core topics? I think that would be visible. The 'Friday for personal projects' becomes 'Thu and Fri for personal projects', for example.
When frameworks became popular ten or so years ago, developers made the 'this will be much more efficient' argument. All that seemed to happen was the time they used to spend thinking/learning the core language (or engineering concepts) was swapped for time learning the framework. So there was no significant productivity gain, despite tasks feeling easier to do.
You list AI management/maintenance tasks that didn't need to be done before. I assume not all of these are 40x across your developers. It will be interesting to see if this management workload becomes similar to infrastructure management, and develops into a new job type providing a shared service. At least maybe during the transition away from flesh-based development to AI development.
I guess your end goal is that AI writes all (literal) code and owns the codebase, directed by people in the company? Do you have a plan to transition developers away from tech roles, is that something that's discussed?