The Limitations of System Design

While It's important to think in both code and systems, I think the rush to just connect modular pieces (hopefully with stage introspection points!) is short-sighted. It misses the opportunity to be creative and understand boundaries, contracts, and affordances. AI-generated summaries can be helpful but incorrect and very limiting.

I saw a SWE manager post about this exact subject in hiring interviews, where it's unfortunate when candidates say they're only interested in systems design and leaving all implementation logic and understanding to coding agents.

I think systems design & architecture is important for great prototyping where we can creatively imagine and put things together. But if the prototype becomes more valuable, then we absolutely have to understand its deficiencies, then improve based on their relative priority.

This has always been true whether it's copying scripts, using published/inferred patterns, licensed software or OSS. Not understanding the low-level system mechanics and implications will risk poor QA and decision-making confidence.

Maybe the best people to answer this are experienced physical architects, engineers, and designers. Though their outputs are relatively static, their performance, maintenance, resilience, and sustainability are dependent on layered intentional choices that have consequences.

Just focusing on systems design for the sake of speed is only okay if we understand the risks taken and the need for further timely further analysis and situational state assessment.

This is a perennial subject that'll become increasingly important when we can generate code and workflows faster, and with it, entropy as well.