AI Amplifies Bad Engineering Practices
Customer Support is just coding in disguise.
This week has been pure action. From a barrage of client work and admin and recording a podcast to the Magic Old School Nationals over the weekend and coping with the heatwave as best as we could. Bryan Johnson would not be proud of the amount of sleep I got this week.
So this will be a short one covering a recurring theme that's been coming up in client conversations: the fear that their engineering teams are leaving a lot on the table.
Maybe they don't see themselves using Claude/Codex enough or expected a bigger uplift in their ability to meet deadlines and ship net new code. There's enough people that seem to be 10x’ing their output and the promised land is far too appealing to stay comfortable.
As I started thinking about ways that engineers fail to benefit from AI, it all seemed to come back to bad engineering practices.
If you were a great engineer, bad process didn't necessarily limit your output in the past. But now it could be preventing you from getting meaningful leverage from AI (the infinite team member that is not a “great engineer”). (This is exactly why some of the best engineers remain the most outspoken about not using or benefiting from AI).
The practices that hurt the most:
+ Being inconsistent
The thing that struck me working at Google was that there were so many standards – it was hard to distinguish code written by one person from another. It was just “Google code”. You want this to be true with LLMs.
+ Not writing down specs
Reviewing code is much harder than reviewing a spec. If code output is increased significantly because of LLMs, this makes reviews much more leaky as people will naturally rush through them. Even if you don't formally review specs, forcing people to share their specs/prompts/plans and checking those into the repo enables compounding.
+ Not having continuous delivery set up
If you don't believe in CI/CD, if you don't optimize the latency from idea to production, you simply won't be able to run agentic loops or long horizon work.
+ Not prioritizing well
Suffice to say if you weren't picking the right things to work on you probably weren't making that much progress. Speeding up a car going in the wrong direction doesn't get you there much faster.
Good prioritization is directly linked to either an engineer being able to wear the PM hat well or having full trust in product management (the latter is so easy on paper but you would be surprised how often engineers see PMs/sales/business as the enemy).
+ Not burning to a deadline
If you are not working towards a clear deadline, the work will always be 85% done: with or without AI. Sure, you will add more (unnecessary scope) but you won't help the business hit the milestones that matter.
There it is. Five reasons you may not be getting the most out of your LLM use. These are opinionated but I've seen enough evidence to compel me to stick with them for most problems.