So this post was shared today – and I’m sure we’ve all seen similar:
We were all talking about it, and I chimed in as well. High level: I’ve seen this before in other organizations – where it seems the business and technical sides of the org don’t communicate or accept the value of each other. This leads to conflict, and to those outside of leadership, a perception of helplessness.
Here was my response:
10K feet up: That post is a leadership issue. TLDR; 12-13 hours a day with AI acceleration? That would be a terrible, toxic life. I’d leave, even if it was $300K/year. You can’t work 60 hour weeks for months on end and have no sense of critical accomplishment. It’s against human nature. You also can’t complain that this is happening, and not inform leadership to try changing things – which is what I’m hearing here – a lot of complaining, but not a single sentence of “I’ve tried to talk to make things change”. Not blaming the victim. Still, any time there is a conflict, it is rarely 100% the “fault” of one side.
My experience thus far: I find the AI has shifted me even more to planning before having any code written. Generally, yes, by AI. But with a plan. Before, I’d have an idea of how I want to approach it, get initial high level deliverables into ADO, and start. Tackling pieces of the problem – this being done by the team or myself, depending on resourcing – over time, eventually getting to done, barring any change requests. The foundations took the longest time, and that was a race for change requests to come in. It doesn’t how many resources you have – refactoring can be hard and takes time.
Enter AI, and that “build foundation and move on” problem is mostly solved. No way could I get another architect’s time and plan as in depth and as quickly as I can with a “partner” like I have with Copilot (or whatever harness you use). I feel much more confident in what’s being implemented, knowing we agreed on everything ahead of time. The risk introduced by – and aversion to – change requests seems miniscule now. The issue was rarely the feature – it was the impact on the system and all the little things that were impacted.
I still read most, if not all of the code, with the understanding “we agreed to a definition of done” before a single line was written. Unlike human beings, that definition of done can be kept top of mind with every token written. This means, whether it’s a foundational change, or a feature, the system’s structure stays intact. Now, this wasn’t the case in the “old days of AI” – a scant year ago, perhaps? Today, with the modern, and ever evolving best practices, and our becoming acclimated to the tools, we can build more complex, and still reliable software faster than ever before.
If the guy in the post isn’t experiencing that, I feel for him. AI isn’t the cause of bad leadership. Though, like any organization where the business and technical sides are relatively uninformed about each other or don’t communicate or integrate effectively, it can certainly lead to such perceptions and nightmares like what this guy – and I imagine his team – is experiencing.
Auri's Blog 