I never said anything about not understanding them.
If it's something simple, like getting a date from a string, a quick glance will tell me if it'll work. If it's more complex, a quick glance or two will give me the general idea and then I can test it against what I think will be edge cases.
If you don't know what kind of a string you'll have to process then you can't really know if any regex is correct, and if you do testing it in most cases is pretty easy and quick. You'd have to test even if you write it yourself.
And in the cases where it's wrong it usually gives me a good starting point.
Who cares if they're correct? If they fail a test, you can fix them. If they turn out to be wrong in production you can isolate the example and add it as a test. Producing regexes that pass all current tests but contain a subtle bug satisfy 100% of what programmers are incentivized to do. Producing them very quickly will get you promoted.
I think we will very soon start seeing a clear separation between programmers ("co-pilot operators") and software engineers (those who do the thinking and understanding when there's someone "who cares").
We already have that bifurcation in the sense that the majority of programmers can use frameworks, libraries, etc. to get work done but don't have the deeper knowledge to build them well.
I feel like you only see programmers as cogs, and not programmers as invested in the success of their product with the statement like "satisfy 100% of what programmers are incentivized to do"
Generally the people using regexes care if they're correct. Frequently, all possible input variants are not enumerated in tests. Frequently, companies want to have confidence in their production code. Imagine this regex is deployed on a sign up flow, and its failures invisibly increase your churn rate. Can it happen with a hand crafted regex? Yes, of course. But I'd imagine it will happen even more frequently with an AI produced custom regex plus a person who doesn't actually understand regexes.
Programmers often feel invested in the success of their product but that's not what they're incentivized to do. They're incentivized to produce fast results that are bad in ways that you have to be a programmer to understand.
If you have to be a programmer to understand why something's bad, who's going to prevent it? This is a major unsolved problem in the structure and organization of working.
The CTO who used to be a dev. More generally anyone in management with a technical background. They may not exist in some companies, but that's not because it's "a major unsolved problem in the structure and organization of working", it's because the company sucks in that regard.
Except testers and users aren’t programmers. Code reviews are what’s supposed to catch this stuff, but it’s rare for a team lead or other programmer to investigate every single commit.
