Engineers' accountability when building with AI
Originally published on LinkedIn
๐๐ป๐ด๐ถ๐ป๐ฒ๐ฒ๐ฟ๐' ๐ฎ๐ฐ๐ฐ๐ผ๐๐ป๐๐ฎ๐ฏ๐ถ๐น๐ถ๐๐ ๐๐ต๐ฒ๐ป ๐ฏ๐๐ถ๐น๐ฑ๐ถ๐ป๐ด ๐๐ถ๐๐ต ๐๐ I started writing an article about engineering accountability then ranted instead๐ก
It was going to be about technical debt, backlogs, habits of documenting problems rather than fixing them which is now false economy. Then it turned into a rant.
I prefer the rant so here it is.. I have a trigger.
๐จ I'm in the middle of a production incident. The site's down. Customers are calling. The business wants answers now.
Then an engineer says:
โWe knew about that issue. There's a backlog item for it.โ
*$£%"@*! No.
What you've just told me is that you knew this could cause a production incident. You investigated it. You understood it. You wrote a ticket..
Maybe even a beautiful Confluence page describing how it could fail.
And thenโฆ you stopped.
Maybe someone else made the call to ship. Product, delivery, whoever, technically, you're covered. ๐ You documented it. ๐ You raised the risk. ๐ You created the backlog item.
You can point at it and say: โI knew this would happen.โ Again Hell no!
I don't want a blame culture. People make mistakes. Systems fail. Good teams learn from that.
But a ๐ป๐ผ-๐ฏ๐น๐ฎ๐บ๐ฒ culture is very different from a ๐ป๐ผ-๐ฎ๐ฐ๐ฐ๐ผ๐๐ป๐๐ฎ๐ฏ๐ถ๐น๐ถ๐๐ culture.
When production is down and everyone's response is essentially, โI did my partโ something is very wrong as there must have been a mistake down the line somewhere.
And now AI raises the bar.
Engineers increasingly say ๐ถ๐บ๐ฝ๐น๐ฒ๐บ๐ฒ๐ป๐๐ฎ๐๐ถ๐ผ๐ป ๐ถ๐ ๐ฐ๐ต๐ฒ๐ฎ๐ฝ. The difficult work is the thinking. The architecture. The design. Understanding the problem and making the right trade-offs.
Fine.
But if you've already done that thinking, understood the failure mode, documented the solution and written the backlog itemโฆ
Why didn't you change it!?!
At some point, a backlog item stops being engineering work and starts becoming a disclaimer โI spotted this, so it isn't on me.โ Someone else made a decision.
I didn't like that before AI. With AI, my tolerance for it is much lower. We used to hear:
โ ๏ธ โWe had to get it out.โ โ ๏ธ โThere was too much delivery pressure.โ โ ๏ธ โWe didn't have time to do it properly.โ โ ๏ธ โThe fix would have taken too long.โ
Sometimes those were legitimate trade-offs. But if AI has changed the economics of implementation, we have to be consistent about what that means.
You don't get to celebrate 10x productivity for feature delivery and then rediscover the old cost of implementation when it's time to fix resilience, observability, security, testing or technical debt.
๐๐ป๐ผ๐๐ถ๐ป๐ด about a problem isn't owning it. ๐๐ผ๐ฐ๐๐บ๐ฒ๐ป๐๐ถ๐ป๐ด a risk isn't engineering it out. ๐ช๐ฟ๐ถ๐๐ถ๐ป๐ด a ticket isn't fixing it.
โI told you soโ is not an engineering outcome.
๐ค AI isn't reducing engineers' accountability. It's increasing it.
#EngineeringLeadership #SoftwareEngineering #AIEngineering #TechnicalDebt #DevOps #EngineeringCulture