Earlier quoted context omitted.
Could you be more specific in your feedback please.
100% test coverage, for most projects of modest size, is extremely bad advice.
AI is forcing us to write good code
31–40 of 229 posts
Re: AI is forcing us to write good code
#32Strong agreement with everything in this post. At Qlty, we are going so far as to rewrite hundreds of thousands of lines of code to ensure full test coverage, end-to-end type checking (including database-generated types). I’ll add a few more: 1. Zero thrown errors. These effectively disable the type checker and act as goto statements. We use neverthrow for Rust-like Result types in TypeScript. 2. Fast auto-formatting…
But the weird thing is: those things have always been important to me.
And it has always been a good idea to invest in those, for my team and me.
Why am doing this 200% now?
Re: AI is forcing us to write good code
#33I’m increasingly finding that the type of engineer that blogs is not they type of engineer anyone should listen to.
Can you say more? I see a lot of teams struggling with getting AI to work for them. A lot of folks expect it to be a little more magical and "free" than it actually is. So this post is just me sharing what works well for us on a very seasoned eng team.
100% coverage for AI generated code is a very different value proposition than 100% coverage for human generated code (for the reasons outlined in the article).
Re: AI is forcing us to write good code
#34Re: AI is forcing us to write good code
#35I don't know about all this AI stuff. How are LLMs going to stay on top of new design concepts, new languages, really anything new? Can LLMs be trained to operate "fluently" with regards to a genuinely new concept? I think LLMs are good for writing certain types of "bad code", i.e. if you're learning a new language or trying to quickly create a prototype. However to me it seems like a security risk to try to write "g…
Re: AI is forcing us to write good code
#36Wouldn't a better title be "How we're forcing AI to write good code (because it's normally not that good in general, which is crazy, given how many resources it's sucking, that we need to add an extra layer on top of it and use it to get anything decent)"
Re: AI is forcing us to write good code
#37I’m increasingly finding that the type of engineer that blogs is not they type of engineer anyone should listen to.
The value of the blog post is negatively correlated to how good the site looks. Mailing list? Sponsors? Fancy Title? Garbage. Raw HTML dumped on a .xyz domain, Gold!
That's a negative correlation signal for me (as are all the other weird TLDs that I have not seen besides SEO spam results and perhaps the occasional HN submission.) On the other hand, .com, .net, and .org are a positive signal.
Re: AI is forcing us to write good code
#38I don't know about all this AI stuff. How are LLMs going to stay on top of new design concepts, new languages, really anything new? Can LLMs be trained to operate "fluently" with regards to a genuinely new concept? I think LLMs are good for writing certain types of "bad code", i.e. if you're learning a new language or trying to quickly create a prototype. However to me it seems like a security risk to try to write "g…
They are retrained every 12-24 months and constantly getting new/updated reinforcement learning layers. New concepts are not the problem. The problem is outdated information in the training data, like only crappy old Postgres syntax in most of the Stackoverflow body.
This is true now, but it can't stay true, given the enormous costs of training. Inference is expensive enough as is, the training runs are 100% venture capital "startup" funding and pretty much everyone expects them to go away sooner or later
Can't plan a business around something that volatile
Re: AI is forcing us to write good code
#39Author should ask AI to write a small app with 100% code coverage that breaks in every path except what is covered in the tests.
Re: AI is forcing us to write good code
#40Strong agreement with everything in this post. At Qlty, we are going so far as to rewrite hundreds of thousands of lines of code to ensure full test coverage, end-to-end type checking (including database-generated types). I’ll add a few more: 1. Zero thrown errors. These effectively disable the type checker and act as goto statements. We use neverthrow for Rust-like Result types in TypeScript. 2. Fast auto-formatting…
I‘m on the same page as you, I‘m investing into DX and test coverage and quality tooling like crazy. But the weird thing is: those things have always been important to me. And it has always been a good idea to invest in those, for my team and me. Why am doing this 200% now?