Re:Being an Engineer in 2026
by yallpendantools on Monday November 09, 2026 @04:43PM
(#50432671)
> I also understand the code.
and the product, the team, and (no matter how shallowly) the organizational pressures and politics. Whether we like it or not, those are part of the problems developers solve. Even something as rudimentary as knowing what is feasible to test given your deadline isn't something you can encode in a model[1]. Code does not exist in a vacuum.
I say this even with the latest models, it seems as soon as your development practice falls out of the ideals written up in blogposts of the previous ZIRP decade, you have to course correct. I use this term because the AI is technically correct (the best kind of correct) but practically useless, if not also irresponsible.
Recent anecdote (literally today): we've been having Claude write exhaustive test suites to eat at the coverage backlog. Lately, we noticed that tests in develop are even more flakier than usual. Our whole suite runs in 30-40min but lately it could exceed an hour and then fail.
It seems Claude took "exhaustive tests" to mean "exhaust the compute resources of the Jenkins node". What's worse is it wrote those tests for features that have been disabled and would soon be rewritten anyway.[1] I've always said that LLMs are great for generating test suites and this is the first time an LLM "failed" this assignment for me.
Code is cheap. The right code (or lack thereof) for the right situation takes meatspacebrainpower.
[1] The solution here is to run your company/team 100% as agents so they have the full context of project timelines, resources, customer feedback, etc. ala stevey and gtan but my reasons why I don't believe in that has already been articulated elsewhere.
and the product, the team, and (no matter how shallowly) the organizational pressures and politics. Whether we like it or not, those are part of the problems developers solve. Even something as rudimentary as knowing what is feasible to test given your deadline isn't something you can encode in a model[1]. Code does not exist in a vacuum.
I say this even with the latest models, it seems as soon as your development practice falls out of the ideals written up in blogposts of the previous ZIRP decade, you have to course correct. I use this term because the AI is technically correct (the best kind of correct) but practically useless, if not also irresponsible.
Recent anecdote (literally today): we've been having Claude write exhaustive test suites to eat at the coverage backlog. Lately, we noticed that tests in develop are even more flakier than usual. Our whole suite runs in 30-40min but lately it could exceed an hour and then fail.
It seems Claude took "exhaustive tests" to mean "exhaust the compute resources of the Jenkins node". What's worse is it wrote those tests for features that have been disabled and would soon be rewritten anyway.[1] I've always said that LLMs are great for generating test suites and this is the first time an LLM "failed" this assignment for me.
Code is cheap. The right code (or lack thereof) for the right situation takes meatspacebrainpower.
[1] The solution here is to run your company/team 100% as agents so they have the full context of project timelines, resources, customer feedback, etc. ala stevey and gtan but my reasons why I don't believe in that has already been articulated elsewhere.