Yeah, this is a good observation. Definitely in teams and projects, where you have a good onboarding, is less relevant, but still applicable. There's domain knowledge, project understanding and business understanding that needs to be learned, so definitely takes some time to be fully productive.
I'd also say that a lot of companies still struggle with good onboarding these days. Especially larger companies with more legacy systems. A lot of these companies are at the early stages of AI adoption at this time.
As AI makes building faster, the real engineering advantage may increasingly be in how well we design the environment around the people and systems involved. Speed exposes weak coordination, unclear ownership, and bad incentives much faster.
Indeed, this is crucial to understand. As many people believe that AI will just magically make everyone more productive. But in reality, it doesn't work like that. You need to go after the real bottlenecks and improve on them in order to see the benefits.
The Lindy effect is something I am hearing more an more in these days but in terms of finance and personal economy. I wonder why it seems to be in everyone’s mouth in this period… 😅
Right, The Lindy effect has been challenged a bit due to emergence of AI and it's tools. Since a lot of legacy code can be transformed to more modern codebase easier today. And yeah, in fintech, it's been especially prominent due to so many old codebases. But I think a lot of banks these days are looking to modernize.
Hi Alx, it's just the matter of naming. These are not actual laws, like in physics, as you mentioned, but it's an observation or a set of principles, that has shown to be true time and time again. It's important to mention that a lot of these "laws" have been proven scientifically as well.
Amdahl's Law has a second life in AI-assisted teams. Generation got much faster, but review, the serial step where a human has to understand the change, did not, so total speedup caps out at what review can absorb. GitHub shipped AI approval of code changes on September 1, off by default. That invites a Goodhart problem: once "approved" is the number that matters, it gets optimized.
The teams pulling ahead redesigned around the review step rather than the generation step. Amazon rebuilt a core cloud service with six engineers in 76 days by writing the specification first and keeping a human gate on every change. Do any of Milan's examples show two of these laws compounding, say a metric distortion hiding a coordination problem?
Great article, thank you!
It makes me wonder whether Brooks's Law still holds true when we use AI to accelerate team onboarding.
Yeah, this is a good observation. Definitely in teams and projects, where you have a good onboarding, is less relevant, but still applicable. There's domain knowledge, project understanding and business understanding that needs to be learned, so definitely takes some time to be fully productive.
I'd also say that a lot of companies still struggle with good onboarding these days. Especially larger companies with more legacy systems. A lot of these companies are at the early stages of AI adoption at this time.
As AI makes building faster, the real engineering advantage may increasingly be in how well we design the environment around the people and systems involved. Speed exposes weak coordination, unclear ownership, and bad incentives much faster.
Indeed, this is crucial to understand. As many people believe that AI will just magically make everyone more productive. But in reality, it doesn't work like that. You need to go after the real bottlenecks and improve on them in order to see the benefits.
The Lindy effect is something I am hearing more an more in these days but in terms of finance and personal economy. I wonder why it seems to be in everyone’s mouth in this period… 😅
Right, The Lindy effect has been challenged a bit due to emergence of AI and it's tools. Since a lot of legacy code can be transformed to more modern codebase easier today. And yeah, in fintech, it's been especially prominent due to so many old codebases. But I think a lot of banks these days are looking to modernize.
=laws
why do people use word ? it is NOT laws.
it is clever observation of human behavior in specific field aka programming, soft. designing etc, that is it!!!
laws are different!
= physic laws, like Newton;s laws
= civil laws, voted by legitimate body in each country!
but most important there are consequences for breaking those laws
=1 physic, it is nature. try to jump from roof, and obv you will know ..
or break into other human house, for example.
but there is no penalty for breaking or not using 'laws' mentioned above. it is up to you!
alx
Hi Alx, it's just the matter of naming. These are not actual laws, like in physics, as you mentioned, but it's an observation or a set of principles, that has shown to be true time and time again. It's important to mention that a lot of these "laws" have been proven scientifically as well.
Great article, One should be maintain an open source repository of such laws and principles tangential to software development, human behavior, project management, and system design. Something I blogged a while ago : https://jacobantony.substack.com/p/principles-laws-and-razors-in-software
Amdahl's Law has a second life in AI-assisted teams. Generation got much faster, but review, the serial step where a human has to understand the change, did not, so total speedup caps out at what review can absorb. GitHub shipped AI approval of code changes on September 1, off by default. That invites a Goodhart problem: once "approved" is the number that matters, it gets optimized.
The teams pulling ahead redesigned around the review step rather than the generation step. Amazon rebuilt a core cloud service with six engineers in 76 days by writing the specification first and keeping a human gate on every change. Do any of Milan's examples show two of these laws compounding, say a metric distortion hiding a coordination problem?