๐ฅ Human-readable code just isnโt that important anymore
Originally published on LinkedIn
๐ฅ ๐๐๐บ๐ฎ๐ป-๐ฟ๐ฒ๐ฎ๐ฑ๐ฎ๐ฏ๐น๐ฒ ๐ฐ๐ผ๐ฑ๐ฒ ๐ท๐๐๐ ๐ถ๐๐ปโ๐ ๐๐ต๐ฎ๐ ๐ถ๐บ๐ฝ๐ผ๐ฟ๐๐ฎ๐ป๐ ๐ฎ๐ป๐๐บ๐ผ๐ฟ๐ฒ Weโre moving away from human hands on keyboards writing code โ toward AI-first engineering, where AI generates 100%, replacing handcrafted traditional coding.
That shift forces us to rethink what engineering standards even mean anymore. ๐ญ
Traditionally, coding standards exist for two main reasons: 1๏ธโฃ ๐ฅ๐ฒ๐ฎ๐ฑ๐ฎ๐ฏ๐ถ๐น๐ถ๐๐: So humans can maintain and evolve the code. 2๏ธโฃ ๐ฆ๐๐ฟ๐๐ฐ๐๐๐ฟ๐ฒ ๐ฎ๐ป๐ฑ ๐พ๐๐ฎ๐น๐ถ๐๐: Ensuring sound architecture, separation of concerns, scalability, resilience, and other non-functionals.
Ultimately, both feed into maintainability โ the first from an understanding perspective, and the second from an extensibility perspective.
But in an AI-first world, it's a question whether the first even matters anymore.
Iโm not saying we should have junk code โ AI, like humans, still benefits from clear structure. If itโs unreadable, itโll struggle just like you or me. But the difference is in the minutiae โ the little things we used to obsess over: tabs vs spaces, newlines, bracket positions, variable naming conventions.
If those things matter, linting tools and auto-formatters can enforce them.
Or better yet, have Copilot or your codegen AI apply your teamโs standards automatically. If your AI context includes your style rules (Cursor config, rule files, etc.), it should already be generating compliant code.
So why spend time in PRs nitpicking style? Why manually rewrite what an AI could auto-correct in seconds โ or even change it at all if itโs already readable and understandable to both the AI and any human who might need to look at it? ๐ค Whatโs the real value in that?
๐ง๐ต๐ฎ๐โ๐ ๐ป๐ผ๐ ๐๐ต๐ฒ๐ฟ๐ฒ ๐ฎ๐ป ๐ฒ๐ป๐ด๐ถ๐ป๐ฒ๐ฒ๐ฟโ๐ ๐๐ฎ๐น๐๐ฒ ๐น๐ถ๐ฒ๐ ๐ฎ๐ป๐๐บ๐ผ๐ฟ๐ฒ. ๐ซ
๐๐ป ๐ฒ๐ป๐ด๐ถ๐ป๐ฒ๐ฒ๐ฟโ๐ ๐๐ฎ๐น๐๐ฒ ๐ถ๐ ๐ถ๐ป defining how the system should work โ its patterns, its non-functionals, its scalability, its resilience. Not in writing code, but in architecting and shaping it. Not in fixing syntax, but in defining acceptance criteria that ensure the code meets intent.
There are a hundred valid ways to write a solution. If two versions meet the requirements, are maintainable, and perform well โ does your stylistic preference really matter?
So to engineers: ๐ ๐๐ฟ๐ฒ ๐๐ผ๐ ๐ฟ๐ฒ๐ฎ๐ฑ๐ ๐๐ผ ๐น๐ฒ๐ ๐ด๐ผ ๐ผ๐ณ ๐ฐ๐ฎ๐ฟ๐ถ๐ป๐ด ๐ฎ๐ฏ๐ผ๐๐ ๐๐๐๐น๐ฒ ๐บ๐ถ๐ป๐๐๐ถ๐ฎ๐ฒ โ ๐ฎ๐ป๐ฑ ๐๐๐ฒ ๐ญ๐ฌ๐ฌ% ๐ผ๐ณ ๐๐ผ๐๐ฟ ๐๐ถ๐บ๐ฒ ๐ผ๐ป ๐๐ต๐ฎ๐ ๐ฟ๐ฒ๐ฎ๐น๐น๐ ๐บ๐ฎ๐๐๐ฒ๐ฟ๐?
To tech leadership: ๐ก ๐ช๐ต๐ฎ๐ ๐ฑ๐ผ ๐๐ผ๐ ๐๐ฎ๐ป๐ ๐๐ผ๐๐ฟ ๐๐ฒ๐ฎ๐บ๐ ๐๐ผ ๐ณ๐ผ๐ฐ๐๐ ๐ผ๐ป โ perfect-looking code, or scalable, well-structured systems delivered faster?
Iโve had countless discussions on LinkedIn debating whether AI can code. Thatโs not the question โ we know it can.
โ Many engineers are already using it to generate 100% of their code today.
The real question now is how we adapt our engineering practices.๐