> Use strict linting and formatting rules to ensure code quality and consistency. This will help you and your AI to find issues early.

I've always advocated for using a linter and consistent formatting. But now I'm not so sure. What's the point? If nobody is going to bother reading the code anymore I feel like linting does not matter. I think in 10 years a software application will be very obfuscated implementation code with thousands of very solidly documented test cases and, much like compiled code, how the underlying implementation code looks or is organized won't really matter

▲

orwin an hour ago | parent | next [-]

That's the opposite. I've never read and re-read code more than i do today. The new hires generate 50 more code than they use to, and you _have_ to check it or have compounding production issues (been there, done that). And the errors can now be anywhere, when before you more or less knew what the person writing code is thinking and can understand why some errors are made. LLMs errors could hide _anywhere_, so you have to check it all.

	▲	bornfreddy 32 minutes ago \| parent [-]
		Isn't that a losing proposition? Or do you get 50 times the value out of it too? In my experience the more verbose the code is, the less thought out it is. Lots of changes? Cool, now polish some more and come back when it's below 100 lines change, excluding tests and docs. I don't dare touch it before.

▲

gck1 an hour ago | parent | prev [-]

They serve as guardrails for agents to not do stupid things.

If your goal is for AI to write code that works, is maintainable and extensible, you have to include as many deterministic guardrails as possible.