First off, even if GDAL were up for taking this LLM generated code by policy, the following is not ready. To start with, there are many quirks in there specific to the google3 monorepo.
For the local use of GDAL in google3, I've been in need of better C++ test coverage of GDAL to guard against trouble when updating from GDAL's master branch. I started gdal-autotest2 more than 10 years ago. It was slow going to get the 22K lines of C++ test code that I had in there. So, I've taken a go at creating a multiagent setup with one agent trying to write per GDAL C++ file test coverage that is > 90% test coverage and have multiple tools and LLM agents review the code. The result is 360K more lines of googletest based C++ test code. It's set up to not use files from disk. As such, the whole thing builds and runs much quicker than the python test code (which is still used). The tests have lots of redundancy and google3 only has a small subset of GDAL's drivers in it. A test suite covering all the GDAL drivers done this way would likely have more than double the lines of code. Be warned that these new tests are not human curated, so there are plenty of silly tests. But even with all those caveats, some folks may find the code useful. The repo is Apache 2.0 license, but I am fine with the license changing to MIT licensed for folks porting it to other repositories.
https://github.com/schwehr/gdal-autotest2/tree/master/cpp
I'm planning to do the same in cpp/third_party for geos, hdf4, hdf5, libgeotiff, netcdf, proj, and maybe some others, but no promises.
I see these tests as being in a similar category to fuzzers + a corpus of files that cover as many branches as possible. I used to maintain order 1M files for fuzzers to run though on each commit, but that had diminishing returns and was hard to maintain/update.
