Artificial Intelligence has already broken everything, there's no going back. We live here now. Here's an incomplete list of what I'm holding on to and what I'm throwing away...
Sorry, Francis, but this article rather highlights your incompetence in the area. Do you think any of the large events that you mentioned at the beginning of the article, like API format changes, Mobile and Cloud areas emerging, affected the optimal team sizes and the Dunbar number of inter-human connections? Checking basic algorithms during the interview or asking the candidate to do leetcode-type challenge instead of asking real work and experience-related questions has been criticized for decades. The documentation - you literally underlined that the good documentation should explain "why" and not "what" and then saying that AI can summarize the code, which can not explain the context in which this code was written or the solution created that ADR is supposed to capture. If we don't do estimations and the board comes to you and say - when are we going to integrate with Client X, are you also going to tell them that they are hallucinating?
Yes, AI is changing the industry; it has the potential to become revolutionary by increasing engineering productivity and potentially reducing time spent on coding in favour of solutioning, ensuring quality, and compliance. But in no way does it throw out the window the basics you mentioned in the article.
John, I appreciate you taking the time to engage critically with this - these are exactly the conversations we need to be having. Let me address your points because I think we might be closer in agreement than it appears:
On Documentation: You've actually pinpointed exactly my argument - good documentation should explain "why" but how much of your documentation actually does that versus just describing what the code does? My point is that most teams have let their documentation drift into describing "how it works" (which AI can now do instantly), while neglecting the critical "why we made this choice". I'm not throwing out documenting "the Why".
On Estimation: I'm not suggesting don't estimate, but velocity-based sprint estimation models are breaking down when cycle times are this volatile. We still need to answer "when will Feature X ship?" - but you're probably better off with continuous discovery, and transparent risk and de-risking up front in so much as its possible.
On Team Size: You're right that Dunbar's number hasn't changed but what is changing is the leverage each person has (assuming the right know how). That changes the team dynamic and has a knock on effect - see back to my point around estimation.
Overall though you're absolutely right - the basics don't get thrown out. That's why I ended on customer understanding, good taste, and clear thinking. The craftsmanship matters more, not less.
What has your experience been? Where are you seeing teams successfully adapt versus getting stuck?
Francis. Those are the words of a wise craftsman who understands the inside, the outside, and the relationship between the two. Thank you for sharing this articulation. I agree with your assessment of what's broken, what will soon break, and what actually matters (on-the-ground) that has never and will never change. In my opinion, however, the most important point that you invite us to think about is: WHY are we building? In a world where AI is accelerating the DEGENERATION of LIFE itself through its gargantuan demand for energy and fresh water (OECD/Cornell estimate that AI uses one water bottle for 36 queries in the US), and through its negative impact on job markets (not mentioning any doomsday scenarios that the fathers of AI themselves are warming us about), we MUST consider the "why" more than ever. before. Like everyone else, I get involved with AI projects every day... and my answer to my "whys" are always "because its short-term benefits, for life or for humans, compensate for its potential degenerative costs.
Sorry, Francis, but this article rather highlights your incompetence in the area. Do you think any of the large events that you mentioned at the beginning of the article, like API format changes, Mobile and Cloud areas emerging, affected the optimal team sizes and the Dunbar number of inter-human connections? Checking basic algorithms during the interview or asking the candidate to do leetcode-type challenge instead of asking real work and experience-related questions has been criticized for decades. The documentation - you literally underlined that the good documentation should explain "why" and not "what" and then saying that AI can summarize the code, which can not explain the context in which this code was written or the solution created that ADR is supposed to capture. If we don't do estimations and the board comes to you and say - when are we going to integrate with Client X, are you also going to tell them that they are hallucinating?
Yes, AI is changing the industry; it has the potential to become revolutionary by increasing engineering productivity and potentially reducing time spent on coding in favour of solutioning, ensuring quality, and compliance. But in no way does it throw out the window the basics you mentioned in the article.
John, I appreciate you taking the time to engage critically with this - these are exactly the conversations we need to be having. Let me address your points because I think we might be closer in agreement than it appears:
On Documentation: You've actually pinpointed exactly my argument - good documentation should explain "why" but how much of your documentation actually does that versus just describing what the code does? My point is that most teams have let their documentation drift into describing "how it works" (which AI can now do instantly), while neglecting the critical "why we made this choice". I'm not throwing out documenting "the Why".
On Estimation: I'm not suggesting don't estimate, but velocity-based sprint estimation models are breaking down when cycle times are this volatile. We still need to answer "when will Feature X ship?" - but you're probably better off with continuous discovery, and transparent risk and de-risking up front in so much as its possible.
On Team Size: You're right that Dunbar's number hasn't changed but what is changing is the leverage each person has (assuming the right know how). That changes the team dynamic and has a knock on effect - see back to my point around estimation.
Overall though you're absolutely right - the basics don't get thrown out. That's why I ended on customer understanding, good taste, and clear thinking. The craftsmanship matters more, not less.
What has your experience been? Where are you seeing teams successfully adapt versus getting stuck?
Francis. Those are the words of a wise craftsman who understands the inside, the outside, and the relationship between the two. Thank you for sharing this articulation. I agree with your assessment of what's broken, what will soon break, and what actually matters (on-the-ground) that has never and will never change. In my opinion, however, the most important point that you invite us to think about is: WHY are we building? In a world where AI is accelerating the DEGENERATION of LIFE itself through its gargantuan demand for energy and fresh water (OECD/Cornell estimate that AI uses one water bottle for 36 queries in the US), and through its negative impact on job markets (not mentioning any doomsday scenarios that the fathers of AI themselves are warming us about), we MUST consider the "why" more than ever. before. Like everyone else, I get involved with AI projects every day... and my answer to my "whys" are always "because its short-term benefits, for life or for humans, compensate for its potential degenerative costs.
Thanks for reading Will. Appreciate the feedback.