AI can write a GDAL-sized codebase in five days. It cannot tell you whether the output is right. That takes engineers who know what right looks like, and a process that measures it before anything ships.
In October 2026 an open-source project called terrio went from first commit to version 0.3.2 in under six days: about 103,000 lines of Rust, published as faster than GDAL. We ran terrio 0.4.1, GDAL 3.13.3 and Bitruvius Spatial Engine through the same tests on the same machines. With all cores in use, Bitruvius Spatial Engine was faster than terrio in every like-for-like cell on both machines: 2.7-5.2× on the Mac and 2.7-8.4× on Windows, depending on operation. It also used a fraction of the memory on large jobs. The more important finding concerned correctness. In our tests, terrio 0.4.1 removed a satellite scene’s ground control points without reporting an error, and its Float32 elevation reprojections differed from GDAL’s exact reference on 97-99% of pixels. Building that much in days, in the open, is a real achievement, and it makes terrio a useful public case study of a wider question: how the output of rapid, AI-led development is validated against an independent reference before release.
This isn’t a story about AI versus humans. Bitruvius builds with AI coding assistants every day, and about 69% of our commits carry an AI co-author line. Our engineers lead the work: they define requirements, make design decisions, guide AI-assisted implementation, review changes and write code directly. The team brings geospatial, compression and systems knowledge to the implementation and challenges generated code against that understanding. Automated checks provide independent evidence of correctness and performance; engineers assess that evidence and remain responsible for what ships. That combination of hands-on development, technical judgment and continuous verification is high-velocity engineering.
terrio 0.4.1, final results. Against terrio, Bitruvius Spatial Engine was faster in every like-for-like all-core cell on both machines; on Windows, 345 of 345. Single-thread results are scored only when measured CPU use stays within the one-core tolerance.
The public timeline
We publicly announced Bitruvius Spatial Engine on October 8, 2026, with measured results on our product webpage, and published our launch blog on October 12. terrio’s first recorded commit is dated October 14. The public record is:
- October 8, 2026: Bitruvius’s LinkedIn company announcement reported GDAL-compatible GeoTIFF, COG and MRF output, up to 9× faster processing, as little as a tenth of the RAM, and 8,452 head-to-head runs. The post linked to our Bitruvius Spatial Engine webpage, presenting measured results and pipeline compatibility.
- October 12, 2026: Unveiling Bitruvius Spatial Engine described more than a year of development, a Rust implementation, GeoTIFF, COG and MRF support, and measured speed and memory results. An October 12 Wayback capture records the announcement.
- October 14, 2026: terrio’s first recorded commit, followed by its first release eleven and a half hours later, as documented in the release history cited below.
We include these dates for context only and draw no inference from them about how terrio was developed. The engineering question is what the released implementations can demonstrate under the same correctness, performance and maintenance expectations.
The landscape: five ways to process geospatial rasters
Almost everything in this market is GDAL, a wrapper around GDAL, or an attempt to replace it. How each one earns trust in its output is the real difference.
| Approach | What it is | How correctness is established | Speed, as we measured it |
|---|---|---|---|
| GDAL | Open-source raster and vector library, started in 1998; an OSGeo project under an MIT-style licence | Decades of production use and an automated test suite in Python and C++; it is the reference others are measured against | The baseline. Multithreading is off by default and must be tuned |
| Esri ArcGIS Pro | Proprietary desktop GIS, licensed per user | Esri’s documentation says most raster formats are supported through GDAL; Esri also created the open LERC codec | Not measured; no published Esri benchmark exists |
| GDAL wrappers (rasterio, rio-cogeo, georust/gdal) | Friendlier interfaces in Python or Rust over the same engine | Inherited from GDAL | Inherited from GDAL |
| Rapid AI-led implementations, e.g. terrio | A new implementation released within a day of its first commit; its README says it is primarily built with an AI model under human direction and review | Its own test suite, including read comparisons with GDAL; our output checks found the discrepancies documented below | Slower than tuned GDAL in most copy and exact-reprojection cells; Bitruvius Spatial Engine was 2.7-5.2× faster |
| Bitruvius Spatial Engine | A new engine, designed from the physics up and built with AI under measured gates; in private beta | Every output diffed against GDAL pixel by pixel and tag by tag; lossless paths bit-identical | 2.5-3.5× faster than tuned GDAL on all cores, 2.0-3.0× on one thread |
The fairness of the baseline matters. GDAL compresses on one thread unless told otherwise, and gdalwarp approximates the transform to 0.125 pixel by default (GDAL docs). terrio’s published benchmarks at v0.3.2 showed it up to 16.5× faster than GDAL, and its docs say GDAL ran with its default settings. Against GDAL tuned for all cores, on terrio’s own test files, its lead was 1.1-3.4×, and it was slower than GDAL on two of five reprojections. To its credit, terrio’s current docs now list the cases where it is slower. Every number in this post uses tuned GDAL.
Built on physics and engineering, not on a prompt
Every speed-up above traces to a physical limit the team designed for. A chat answer can produce code that runs; it cannot tell you which limit your data hits, or prove the output stayed inside it.
| Principle | What it means for raster data | Design decision in Bitruvius Spatial Engine | Measured result |
|---|---|---|---|
| Information theory | Lossless compression is bounded by the data’s entropy. You win by predicting the data better, not by working the encoder harder. | Codecs and predictors chosen per data type; a tool that ignores the requested settings is not a faster encoder | terrio’s WebP at a fixed quality: 2.0-2.2× larger files at 12.9-16.5 dB lower PSNR |
| Numerical precision | Float32 carries about 7 significant digits. Coordinate maths done carelessly in float32 moves elevations by metres. | Exact transforms, computed at full precision, checked against GDAL’s exact path (-et 0) | Largest elevation error 0.0015 m, against terrio’s 10.2 m |
| Memory hierarchy | Most raster kernels are limited by memory bandwidth, not arithmetic. Data that stays in cache is data you don’t wait for. | Streaming, tile-at-a-time pipeline; no allocation or locks per pixel | 126 MiB peak where terrio needs 1,400 MiB and GDAL 1,670 MiB |
| Parallel hardware | A modern core does 4-16 operations per instruction with SIMD, if the code is written for it. | Hand-written SIMD kernels for x86 and ARM, each with a scalar fallback that doubles as its test oracle | 2.0-3.0× faster than tuned GDAL even on one thread |
| Determinism | A lossless path must return the same bits on every machine, every time. | Bit-identical output is the bar for lossless paths; tests also run on optimised release builds | 268 of 268 lossless COGs match the source checksum |
None of this is exotic. It is the working knowledge of a team with more than 75 years of combined industry experience, including previous roles at Esri and Nearmap. What AI changes is how fast that knowledge becomes tested code.
High-velocity engineering: AI inside the whole lifecycle
High velocity means shipping the right thing fast, not shipping something fast. Bitruvius uses AI at every stage, from research and specification to code, benchmarks and documentation. Engineers decide what to build and gates decide what ships.
We use terrio as an example because its development history is public and anyone can check it, not to fault its authors. Its public history records the first commit on 2026-10-14 and a first release eleven and a half hours later. By v0.3.2, five and a half days later, it had shipped six versions and about 103,000 lines of Rust across 194 files, with an AI code-review workflow added on day two. That growth expands the scope requiring validation and maintenance: who understands the implementations, verifies releases, investigates defects and maintains compatibility? Its README says it is primarily built with an AI model working under human direction and review. Our tests of the released binary found the output discrepancies documented below.
terrio has tests, including ones that compare its reads with GDAL. The version we tested still exhibited lost georeferencing, elevation discrepancies and short overview pyramids. Tests derived only from implementation behaviour can preserve mistakes; independently defined expectations matter. Each layer feeds the next: the reader feeds the reprojector, the reprojector feeds the COG writer, and the COG writer feeds the Python and WebAssembly packages and, since v0.4.0, a server for AI agents. An error nobody measured at the bottom is inherited by everything above it.
Independent research points the same way:
- A 2024 study found that LLM-generated test oracles mainly capture what the code actually does, which makes bugs hard to detect.
- Google’s DORA 2024 report associated a 25% rise in AI adoption with a 7.2% drop in delivery stability. DORA 2025 still found a negative link with stability, and put it simply: AI amplifies what a team already has.
- In a randomised trial by METR, experienced open-source developers took 19% longer with AI tools while believing they were 20% faster. METR has since said the picture is changing as tools improve.
- A study of Copilot-generated code found about 40% of programs vulnerable in security-relevant scenarios.
The lesson isn’t to use less AI. It is that speed without measurement compounds errors, and that a team’s expertise decides whether AI amplifies quality or defects.
The right loop builds quality into small changes and provides rapid feedback. Quality assurance covers how requirements, design, review and continuous integration prevent defects; quality control checks actual outputs against independently defined expectations. Both must keep pace with development. These are our measured checks:
- Correctness is measured, not assumed. Outputs are diffed pixel by pixel and tag by tag against GDAL; lossless paths must be bit-identical. A faster wrong answer is a failure.
- Bugs are fixed test-first. A failing test reproduces the bug before the fix lands.
- Performance is a merge gate. Performance changes are timed against the previous build on the same quiet machine, never across machines, and a regression blocks the merge. In our shared SIMD layer a hand-written kernel ships only if it beats plain code by at least 1.2×: one AVX2 kernel measured 0.75-0.81× on an Intel Core Ultra 9 and never shipped.
- Fair benchmarks. GDAL is built from source and tuned for all cores, encoder settings are matched, and untuned numbers appear only as a labelled extra.
- Test what ships. CI runs tests on optimised release builds, not only debug builds, because optimisation can expose bugs a debug build hides. Benchmarks run on both an x86-64 Windows machine and Apple Silicon.
Who owns the work after the announcement?
A release creates responsibilities that outlast the demonstration: correctness, security, compatibility, documentation, defect investigation and support. Responsible commercial teams and established open-source projects address those responsibilities through continuous QA/QC and explicit release criteria. Release frequency and feature count do not establish release readiness.
Established geospatial projects embody years of accumulated knowledge about formats, numerical behaviour, interoperability and failure cases. Reproducing visible functionality creates a corresponding obligation to validate and maintain it. An open-source licence enables collaboration; it does not supply willing maintainers, shared understanding, governance or continuity. Community maintenance depends on people choosing to do that work.
Lost georeferencing makes the downstream cost concrete. Someone must discover the failure, isolate its cause, assess affected outputs, correct it and prevent recurrence. AI can accelerate implementation while that work still falls to authors, users or maintainers. We apply the same scrutiny to our own releases: validation and ongoing ownership must accompany performance claims.
This emphasis aligns with Allen Holub’s principles of small changes, rapid feedback and non-negotiable quality, and Dave Farley’s emphasis on precise intent, independent verification and incremental learning. These principles inform our approach, without implying an assessment by either author of the products compared.
The evidence: faster, leaner and right
With all cores available, Bitruvius Spatial Engine was faster than terrio in every like-for-like cell on both machines, and faster than tuned GDAL in every like-for-like cell on the Mac. On the Apple M3 Max, median speedups over terrio 0.4.1 were 2.70× for copy, 2.75× for COG, 4.78× for exact reprojection and 5.19× for default reprojection. Against GDAL tuned for all cores, the corresponding speedups were 2.50×, 3.50×, 3.24× and 2.86×.
| macOS / Apple Silicon ARM64, all cores | Faster than terrio 0.4.1 | Faster than tuned GDAL |
|---|---|---|
| Copy | 2.70× | 2.50× |
| COG | 2.75× | 3.50× |
| Exact reprojection | 4.78× | 3.24× |
| Default reprojection | 5.19× | 2.86× |
The method is the point. Each machine is its own race: Apple M3 Max (Apple Silicon, ARM64) and Intel Core Ultra 9 285HX (Windows x64, x86-64) results are never compared across machines. The final terrio 0.4.1 runs were completed on October 22 to 23, against GDAL 3.13.3 built from source and tuned for all cores. Mac matrix headlines use the recorded October 5 Bitruvius Spatial Engine build; Windows headlines use the fresh engine pairing. Medians are calculated within each operation and thread mode. Unsupported formats, wrong outputs and incomplete overview pyramids are excluded from like-for-like speed ratios. Encoder settings and output grids are matched; WebP quality is checked separately. Single-thread ratios include only cells that pass the CPU-budget check.
On terrio’s own 11 Mac benchmark tests, Bitruvius Spatial Engine had the lowest elapsed time in all 11: 1.13-7.9× faster than terrio and 1.8-5.7× faster than tuned GDAL. These are observed timings, not 11 fully equivalent-output wins: terrio’s T4 builds only five of seven overview levels, and the correctness failures below also affect eligibility.
Never slower. In every like-for-like cell on the M3 Max, Bitruvius Spatial Engine matched or beat both GDAL and terrio.
On Windows x64 (Intel x86-64), Bitruvius Spatial Engine won all 345 like-for-like all-core cells. Median speedups over terrio were 2.74-2.83× on copy, 3.48-3.70× on full-pyramid COG, 5.02× on exact reprojection and 7.59-8.37× on default reprojection. Against tuned GDAL it was 4.28-4.92× faster on COG, winning 52 of 52 cells in every COG lane. It was also faster than GDAL’s default reprojection in all 122 cells. Among eligible single-thread cells, it was 2.07-4.19× faster than terrio on the Mac and 2.68-4.85× on Windows.
Memory is where engineering shows most. In the Mac reprojection matrix, terrio peaked at 2.8-7.5 GiB against 0.15-0.43 GiB for Bitruvius Spatial Engine. On the large tests in terrio’s own Mac set it required 4-12× Bitruvius Spatial Engine’s RAM. A streaming design keeps the working set small; on cloud infrastructure, that can enable smaller instances or more concurrent jobs within the same memory budget.
| macOS / Apple Silicon ARM64 test, all cores | Bitruvius Spatial Engine streaming | terrio 0.4.1 | Tuned GDAL |
|---|---|---|---|
| M1: elevation mosaic | 305 MiB | 1,222 MiB | 1,005 MiB |
| T1: elevation COG | 275 MiB | 1,458 MiB | 1,480 MiB |
| T5: SAR COG | 190 MiB | 1,622 MiB | 1,395 MiB |
| W1: elevation reprojection | 126 MiB | 1,400 MiB | 1,670 MiB |
Speed means nothing if the map is wrong
Every output was decoded and compared with GDAL’s pixel by pixel, and its georeferencing compared tag by tag. The SAR amplitude scene below is a 739 MB ICEYE image placed on Earth by 1,599 ground control points.
| Output (SAR amplitude scene to COG) | Ground control points kept | Where the image lands |
|---|---|---|
| Source file | 1,599 | Where its GCPs place it |
| GDAL 3.13.3 | 1,599, identical | Correct |
| Bitruvius Spatial Engine | 1,599, every one bit-identical to GDAL’s | Correct |
| terrio 0.4.1 | 0 | An invented grid labelled WGS 84, reaching latitude 19,120°. No error, no warning. |
Elevation data shows the same pattern. Each tool used its exact transform and was compared with GDAL’s exact reprojection (gdalwarp -et 0):
| Reprojection | terrio: pixels that differ | terrio: largest error | Bitruvius Spatial Engine: largest error |
|---|---|---|---|
| Large elevation mosaic to Web Mercator | 99.0% | 10.2 m | 0.0015 m |
| Elevation (DEM) 54 MB to WGS 84 | 97.5% | 0.92 m | 0.0001 m |
| 8-bit RGB to Web Mercator | 0%, identical | 0 | 1 level on 0.0015% of pixels |
Thousands of times more precise. Bitruvius Spatial Engine’s worst elevation error was 1.5 mm on a mosaic where terrio’s reached 10.2 m. In flood, slope or line-of-sight analysis, a difference of that size can change the answer.
These correctness problems persist in terrio 0.4.1: the SAR COG drops all 1,599 GCPs without warning, Float32 reprojections differ from GDAL on 97-99% of pixels, and some COGs contain incomplete overview pyramids (five of seven levels on the optical test). The Float32 discrepancy’s cause has not been isolated.
In our tests, terrio’s WebP output did not change with the requested quality or lossless settings. At requested level 75, its files are 2.0-2.2× larger with PSNR 12.9-16.5 dB lower on the Mac files. Its remaining eligible single-thread timing leads are therefore not like-for-like. At matched quality, Bitruvius Spatial Engine wins the tested WebP copies on both machines. Output requested as lossless WebP did not match the source checksum.
JPEG XL output also failed our round-trip validation on both operating systems. We reproduced this with terrio 0.4.1 on macOS (Apple Silicon ARM64) and Windows x64 (Intel x86-64). In the Windows matrix, four JPEG XL COG outputs could not be read back. Writing a file successfully is insufficient: the output must be decodable and, where lossless output is requested, preserve the source samples. JPEG XL is excluded from the headline speed multiples.
Qualifications and remaining tradeoffs
A benchmark that hides its qualifications is not evidence. These are ours:
| Finding | Detail | Status |
|---|---|---|
| Single-thread eligibility | terrio exceeded the one-core budget in 7 of its own 11 Mac tests and 226 of 345 Windows matrix cells. Disqualified timings are reported but never scored as wins or ties. | Excluded from single-thread scoring |
| WebP timings are not equivalent output | terrio’s remaining qualifying single-thread timing leads are WebP encodes at different quality, producing files about twice as large with lower PSNR. Matched-quality copy checks favour Bitruvius Spatial Engine on both machines. | Excluded from like-for-like wins |
| Bitruvius Spatial Engine is not always lowest on memory | terrio uses less RAM in 18 of 345 Windows all-core cells with the fresh engine pairing, and none of the 345 single-thread cells. Zstd and small-file full-pyramid COG memory remain improvement targets. | Open engine targets |
A thread setting is a compute contract
A passing result must satisfy the whole requirement. Finishing sooner while using more than the permitted CPU budget is a failed single-core comparison. Accepting the timing without checking resource consumption rewards the wrong behaviour.
This illustrates why agentic development needs explicit constraints and independent verification. Engineers must check that the implementation meets the intended requirement, rather than accepting generated code, passing tests or reported results at face value. That responsibility is shared by disciplined commercial teams and established open-source maintainers. AI-generated work deserves the same scrutiny as any other contribution.
terrio 0.4.1 used up to 1.87 cores on the Mac and 2.13 on Windows with its thread pool set to one thread (RAYON_NUM_THREADS=1). A live sample showed two threads each consuming about 97% CPU simultaneously. Our single-thread rule measures process CPU time divided by wall time: a value above 1.05 is disqualified, allowing 5% measurement tolerance. Bitruvius Spatial Engine and GDAL measured 0.91-1.03. terrio exceeded the budget in 7 of its own 11 Mac tests and 226 of 345 Windows cells. Those cells are reported, never scored as wins or ties. A thread setting alone does not enforce a compute budget.
The distinction changes deployment choices. In Kubernetes, a CPU request informs scheduling but is not a hard cap; a container that uses more than its requested CPU can consume spare capacity that other workloads need. An enforced CPU limit instead throttles execution when the budget is exhausted. Docker likewise needs an explicit CPU quota to enforce a budget: selecting one worker thread does not impose that quota.
In serverless environments, CPU allocation depends on the provider and service configuration. Performance measured using more than one core cannot be assumed to carry over to a one-vCPU allocation. Under a hard limit, extra runnable threads share the available budget; without that limit, their consumption reduces the capacity available for other jobs. Buying a larger allocation may restore throughput, but changes the cost comparison.
For batch workers, shared servers and container platforms, unexpected CPU use also makes concurrency and capacity planning less predictable. The deployment question is how much correct work an engine completes within a specified CPU and memory budget. Any speed claim must account for the resources actually consumed, rather than the thread setting alone.
Platform behaviour: Kubernetes resource requests and limits, Docker resource constraints, and AWS Lambda CPU allocation.
Due diligence: eight questions for any geospatial engine
Ask these of any tool before it touches data a decision depends on, whether people or AI wrote it. Bitruvius Spatial Engine has to answer them too.
| Question | How to check it yourself | What a weak answer looks like |
|---|---|---|
| Is the output checked against an independent reference? | Ask for the pixel and tag diffs against GDAL or a standards test suite | “Our tests pass” with no outside reference |
| Does georeferencing survive every path? | Run gdalinfo on the output: GCPs, RPCs, coordinate system, geotransform | Coordinates that change, or are invented, with no warning |
| Are lossless paths actually lossless? | Compare checksums with gdalinfo -checksum | A “lossless” file that is smaller than it can be, or fails the checksum |
| Does it honour the settings you give it? | Change quality or compression level and see if size and PSNR move | Identical output whatever you ask for |
| Is the benchmark fair? | Check tuned baselines, matched encoder settings and measured CPU use; exclude single-thread cells above the one-core tolerance | A headline multiple against single-threaded defaults |
| Are wins and losses both published? | Look for the cells where it loses | Only medians, no ranges, no losses |
| What does it cost in memory? | Measure peak RAM on your largest files | Speed bought with several times the RAM |
| Who owns release quality and ongoing maintenance? | Identified maintainers, release criteria, supported scope, known limitations and a history of investigating and fixing defects | Expanding releases with no verification record or identified maintenance responsibility |
Intellectual property: what is patent-pending
Bitruvius has filed provisional patent applications on its two native formats. Their claims are not public, so this section uses only what we have already published.
| Technology | What is covered, as published | Status | Public results |
|---|---|---|---|
| RIPT (Raster Image Predictive Tiling) | An adaptive tile-based raster system with novel predictors, choosing the best strategy for every tile | Provisional filed; coming soon to private beta | Lidar elevation about 87× smaller at 1 m tolerance; lidar classification about 20.6× smaller losslessly |
| BVC (Bitruvius Volumetric Codec) | One codec for lidar point clouds and Gaussian splats | Provisional filed; coming soon | Lossless files smaller than the incumbents’ lossy ones; 11.8× faster to read than LAZ; decodes on the GPU |
Bitruvius Spatial Engine and the Turbo drop-in codecs ship as compiled software under the Bitruvius licence. Their advantage comes from the engineering described above, and every measured release adds to it.
Don’t take our word for it
Every claim in this post can be checked. Run the head-to-head races in your browser at bitruvius.com/test-it after a one-time sign-up, or race your own WebP, JPEG XL, LERC or SPZ file: it is decoded on your machine and never uploaded. Bitruvius Spatial Engine is in private beta; to run it against GDAL on your own data, contact us.
AI made this team faster. Knowing what right looks like, and refusing to ship until it is measured, is what made it right.
Notes on these results
Benchmarks reflect the specific software versions, hardware, files and settings described above; results on other data and configurations may differ. terrio is an independent open-source project, and the observations here describe the released versions we tested. We welcome corrections and will update this post if later releases change the findings.
Product and project names are trademarks of their respective owners and are used only to identify them; no endorsement is implied.
Sources
Measurements: Bitruvius benchmark report, finalised 2026-10-23: terrio 0.4.1 (re-run October 22 to 23), GDAL 3.13.3 (built from source), Bitruvius Spatial Engine recorded and fresh development builds as identified above; Apple M3 Max (Apple Silicon ARM64, 16 cores, 64 GB) and Intel Core Ultra 9 285HX (Windows x64, x86-64). The report combines multiple benchmark lanes; machine, thread mode, build pairing and output eligibility are kept separate. Raw data and scripts are available to evaluators on request. Historical v0.3.2 release and published-benchmark references below provide chronology, not the version used for the final comparison.
terrio (public record, checked 2026-10-22):
- Repository and README, including its statement on AI authorship
- First commit, 2026-10-14; releases
- AI code-review workflow added, 2026-10-15
- Benchmarks as published at v0.3.2
GDAL, Esri and other tools:
- gdalwarp, COG driver, GeoTIFF driver, GDAL history
- ArcGIS Pro supported raster formats; Esri LERC
- OGC Cloud Optimized GeoTIFF standard
Research on AI-written code:
- Konstantinou, Degiovanni, Papadakis, LLM-generated test oracles, 2024
- Google, DORA 2024 report on AI and DORA 2025
- METR, 2025 randomised trial and 2026 update
- Pearce et al., Asleep at the Keyboard?, IEEE S&P 2022
Principles: Shannon, A Mathematical Theory of Communication, 1948; Williams, Waterman and Patterson, the roofline model, 2009; IEEE 754 single precision.
