> Its solved. Adapt and learn to use them effectively or get left behind; seems to be the unfortunate reality.
Every time. Every single time. People who say they never look at code anymore always say the trite things about "management of software development", how they have no issues, and that if you have issues, it's the problem with your skills with a side of snide remarks about your intelligence.
And then you press them for details.
After a few rounds of more and more trite answers they either go away or it turns out that their "automated everything" and "processes" and "coding is solved" are:
- a bunch of "make no mistakes" aka untold numbers of random markdown files aka skills, "guidelines", "memories", "ADRs", "technical docs" etc. Which are routinely ignored by any and all models.
- a bunch of tools that can't or don't catch all the mistakes the models routinely make. E.g. there are very few tools that reliably detect code duplication (especially code duplication with subtle changes in behavior), or reliably detect bad data access patterns, or reliably detect suboptimal algorithms etc.
- an overreliance on tests. The very same tests that are written by the very same very models
Also, if the models could actually "validate inputs" and other "coding is solved" things, you wouldn't actually need dozens of tools around to catch the mistakes they do. Ironically, you need "processes" and "engineering management".
---
As a related aside.
I have multiple tools from linters to semantic analysis running as routine checks, and still. Here are the responses by Claude for some of the things I caught it doing in just the past few days:
- "The [test data] generator can sometimes fail, and create duplicated data, so I increased the number of times it runs to 100" (instead of fixing it)
- "The tests check this in an indirect way. They send megabytes of data and watch the memory of the whole VM. Unrelated processes change that number. The direct check is the number of body bytes that the server read. Do you want me to rewrite these tests" (Claude wrote all these tests to begin with)
- "The previous research covered only a few CSS files. It did not cover the design system documents, the components, or the pages that already use them." (so much for "No this isn't a magic prompt like 'make no mistakes'" as it had an explicit requirement to use the design system)
- "The too_large_message/1 helper has three copies, two of them private, with no good reason for them..."
And that's just some I documented for myself.