Unsupervised Coding is Here

Code is Abundant, Service is Scarce: SaaS in the age of AI

This article focuses on an important change occuring for software development in the face of rapidly improving AI. It may not appear directly applicable to logistics as an industry (except for vendors of logistics tech software), I'd argue that changes occuring in this area portent similar scale changes for many other professions in logistics. This is because the logistics industry has two worlds: a front-of-house in which materials must be moved in the real world, and a back-of-house where people mediate their whole work through screens in a purely information environement. What changes in software development has direct lessons for that back office of logistics.

A Lesson in Velocity from Trimble Transportation

Changes made in 2025 brought most engineers in Trimble Transportation (where I work) to a state of Vibe Coding. With the rollout of our in-house developed engineering AI, we'll move this year to Unsupervised Coding. Vibe coding has resulted in 35% of product code committed and merged to master branches to be wholly written by AI, at a cost increase of about 1.5% to our engineering expenses. Unsupervised Coding should at least double the output, i.e. take us to >70% of code going into production being entirely written by AI (obviously still with oversight from humans). Unlike vibe coding, where market tools exist, Unsupervised Coding is something we built in-house and where the IP for how to do so seems to be unmatched by competitors (for now). This gives us a chance to contemplate its impacts prior to most of the market.

What is Unsupervised Coding?

Unsupervised Coding is characterised by the assignment of tickets or stories to AI such that the AI goes and works on it for a long period of time, commits its code into a new branch, and submits the code branch for a merge review. The AI works at the direction of an engineer who perhaps previously would have authored the code but now acts as a boss of the AI and merely assigns it work and subsequently reviews the code. Rejections are rare, AI workers can be spun up on demand, and the AI takes hours to write the code. These, together, mean the human engineer can switch tasks between parallel AI workers resulting in a significant increase in velocity. Repos and engineering staff who work in or near this manner today see nearly all code writing done by AI already, and this is a leading indicator of what to expect for all of Trimble Transportation by end of 2026.

Implications of Unsupervised Coding

The two most consequential outcomes from Unsupervised Coding are on the engineering career itself and the impact of code abundance & velocity on the software business as a whole. I’ll address each in turn.

The End of Authorship: How Unsupervised Coding Changes Engineering

Unsupervised Coding shifts engineer working time towards validating code written by AI rather than authoring code with the help of AI. The result is the weekly working hours concentrate on the pre-coding steps of agreeing what, actually, should be created, as well as verifying the resulting code does what was expected.

This shift to the before & after of code writing is a key experiential change for engineers. Code reviews may become the single biggest time investment, which leads to changes in the ergonomics of code reviews (more on that below).

We ask engineers to review AI code mostly because, as a society, removing a human from the loop is deemed unacceptably risky. The ability of humans to best identify and correct issues is debatable now, and unbelievable in the long term as further progress occurs. But they act as a moral crumple zone of a car in that failures of AI code are seen as the responsibility still of a named engineer rather than an unaccountable “system”.

Perhaps more interesting is the focus of engineers in the pre-coding phase, which shifts engineers towards the kind of decisions once reserved for the “architects” or very senior engineers in their team. This is not to say that the engineer replaces the product manager, rather that more engineers will be deciding architectural questions which then frame the unsupervised coding.

With less time spent coding, ergonomics of code writing are deprioritised. Which segues to the next topic…

Safety by Design: Why AI Prefers Rust and Go

In the AI era, the best languages are those where most incorrect programs cannot exist, and correct programs are simple. That describes Go (simple by design) and Rust (correct by force). The implication is that most engineers will want to retrain away from C++, C#, Java, Python, or Typescript towards Go or Rust.

How programming languages evolve

New languages gain adherence because they improve developer ergonomics and safety in response to concrete pain points of dominant languages. Languages rarely replace predecessors outright. They capture new domains (mobile, cloud, safety-critical, scripting) and then expand. We can expect a similar outcome with AI age applications which, in my estimation, will tend to be built in Go and Rust. The meta-pattern is:

1. A language becomes dominant for a domain

2. Scale reveals hidden costs (safety, concurrency, maintainability)

3. New language reframes tradeoffs. Ergonomics first, performance later

4. Tooling and ecosystem accelerate adoption and lock in the language.

Previous, canonical examples:

C → C++ / Objective-C

Abstraction without abandoning native performance

Failure:

• Manual memory management

• No abstraction mechanisms beyond functions/structs

• Poor large-system composability

Response:

• C++: RAII, classes, templates (zero-cost abstractions)

• Objective-C: Message passing, late binding (for UI-heavy systems)

C / C++ → Java

Predictability and safety over maximal control

Failure:

• Memory safety bugs (buffer overflows, use-after-free)

• Undefined behavior

• Painful cross-platform deployment

Response:

• Garbage collection

• Stronger type safety

• JVM “write once, run anywhere”

Java → C#

Productivity via language-tooling co-design

Failure:

• Verbosity

• Weak native/OS integration

• Slow language evolution

Response:

• Properties, events, LINQ

• First-class tooling (Visual Studio)

• Faster iteration via .NET ecosystem

Java / C# → Python / Ruby

Cognitive load reduction and flow

Failure:

• High ceremony to task ratio

• Poor scripting experience

Response:

• Minimal syntax

• Dynamic typing

• REPL-first workflows

Python / Ruby → Go

Operational simplicity at scale

Failure:

• Poor concurrency models

• Slow startup and deployment complexity

• Performance unpredictability

Response:

• Goroutines + channels

• Fast compile times

• Static binaries

C / C++ / Java → Rust

Making illegal states unrepresentable

Failure:

• Memory safety (C/C++)

• GC latency and lack of control (Java)

• Concurrency bugs

Response:

• Ownership and borrowing

• Compile-time safety guarantees

• No GC

JavaScript → TypeScript

Scalability without ecosystem fracture

Failure:

• Large-scale JS codebases fragile

• Refactoring unsafe

• Tooling limitations

Response:

• Gradual typing

• Structural types

• Zero-runtime-cost abstraction

Go and Rust are best suited for the AI age

Unsupervised Coding with AI produces large volumes of syntactically valid code, shifting human engineering time from authorship to verification (i.e. code review). The human review must address the fact that AI is good at generating plausible solutions, not necessarily correct ones.

The bottleneck on code review is therefore reasoning and trust: can the human reviewer reason their way through the code to independently confirm “what it does”, or can they trust in some other mechanism to ensure the code without doing their own reasoning?

1. On the ease of reasoning, Go is a small language of explicit logic and minimal automation. It reads quickly. Rust has compiler-enforced invariants and therefore fewer states to reason about.

2. On the ability to trust-without-verifying, languages that constrain AI output outperform those that rely on human discipline. Go constrains AI output with straightforward runtime behaviour, few abstraction, and limited ways to do things. Rust’s ownership, lifetimes, and borrowing prevent whole classes of bugs. The Rust “correctness by construction” seems perfect for probabilistic code generation. Finally, in an AI workflow the compiler is not just a build step—it’s a first reviewer. Go offers extremely clear error messages and a fast edit–compile–fix loop suitable for AI-assisted iteration. Rust’s compiler encodes deep semantic rules that in other languages would be left to disciplined human review.

Finally, the pure speed and scale of AI code generation mean that we need languages that offer operational stability, predictably low maintenance costs, and ease of context-switching (since most humans won’t see the code base beyond code reviews, i.e. they won’t build deep mental models of the code through repeated exposure). We see these qualities already in areas favoured by Go and Rust:

• Go: cloud control planes, networking, internal services

• Rust: databases, crypto, safety-critical infrastructure

AI amplifies rationales already well understood for picking Go and Rust.

The Death of “Build Once, Sell Forever”: Software Strategy in an Era of Abundance

Traditionally, software businesses (like Trimble Transportation) are anchored to the difficulty of coding in a way that is hard to overstate. Modern software companies invest a lot to make a code base and then race for maximum distribution because the incremental cost of a new customer on the same code base is vanishingly small compared to the value they can create & therefore share for the customer. It most closely resembles a media business where a piece of creative content is produced (such as a movie) and then sold over and over and over. The decoupling of the cost to create vs the cost to deliver is the seat of these two business models.

As coding becomes easier, thanks to Unsupervised Coding, the safe harbours from commoditization are shifting. I’ve written previously that cornered data, network effects, and brand are viable safe harbours for established logistics software companies. What I’d like to propose today is that the entire paradigm of software businesses could head in a new direction. I’ll propose three models that may hold clues for the future, though what emerges is likely not whole-sale foreseen by them.

Hospitality

When we say “Software as a Service” we really mean that its costs sit in operating expense instead of capital expenses. Customers buy access to our software rather than own some version of it as an asset. For the hospitality industry, the word service has a deeper and more natural meaning. Service in hospitality is about how people feel, how they have been served by other people above all. To build such businesses one creates different forms of systems and scale advantages than in software. The systems are about enabling personalisation to the customer, about creating fertile ground for bespoke moments to happen organically rather than by force. This means staff, almost all of whom are frontline, are empowered to act on their instincts and taste towards the customer. A culture of attention to detail, of taste for small gestures, compounds into a culture that values noticing and acting on all levels of experience regardless of their apparent immediate impact. Attending to quality internally, in the life of the mind, leads to curation of great experiences for customers externally.

Architecture

At first glance, the qualities of a successful architecture firm might look like those of hospitality. But the differences are telling. In architecture, we are promised bespoke outcomes, but we get there through methodologies that tailor solutions. Hospitality offers the bespoke through frameworks that prepare for but still yield maximum autonomy in the moment. Architecture centers on interaction between the customer and the architect’s team. The customer doesn’t just value the work product’s result (a design) but experiences craft elevated by creativity of a small team, even perhaps one person. Most crucially, they experience the architecture as a member of that team and therefore the resulting design is also a story of the act of creation in which they are author not consumer. This explains why architectural firms mostly don’t scale: the magic is in the client co-design sessions and these grow linear in input and outcome.

Luxury

Pivoting again from architecture, we come to luxury. Like architecture it centers on story and brand. Like hospitality it is also a services business (even if there is a good being bought), and attention to detail is paramount. Where luxury differs is that its personalisation is extreme while never quite placing the customer at the center of the business. Customers participate in the luxury brand but, in the final analysis, must qualify for it rather than the reverse. Experiences are tailored (like hospitality) but rare and intentionally exclusive: designed to make customers feel uniquely valued, part of a privileged group, and emotionally connected to the brand narrative. Emotional resonance ties to the good purchased and therefore endures for a long time, perhaps a whole lifetime at a deeply personal level.

So, what to does this mean?

Consider the contrast of these business models:

• ⁠ ⁠Hospitality is about surprises that form lasting memories. Neither Luxury nor Architecture can anchor to surprise in this way.

• Architecture is about co-designing and therefore a narrative: how a thing was made is the story at the center of satified customers. Hospitality is ephemeral, architecture is an enduring legacy / story.

• Luxury and hospitality both emphasize emotional experience, but luxury layers in exclusivity, narrative, and status, giving clients a sense of belonging to a privileged circle.

• None of these models have the “invest once, sell copies forever” aspect of media or SaaS. They can achieve similar or higher profitability, but rarely achieve economies of scale. But we can expect software to retain business model engines of cornered data and network effects that do have economies of scale effects.

When I previously wrote or presented about brand as a defensible strategy to mitigate commoditization in the software business after AI, I realise now I was thinking of a weak version of brand effect. I was thinking of the brand halo of “trusted”, i.e. we are not a start-up and you can rely on us to be here for our customers in the long term. That's fine, but compared to the brand power of luxury it is minor. In 2025, I promulgated a concept of “Build to Order” using AI to simply make the code for what our customers want on-demand as they ask for it. But, I failed to explore the potential of service in the sense that it is a cornerstone of hospitality and architecture. These businesses therefore offer important lessons on how to not just survive into the AI age where Unsupervised Coding renders software abundant and fastly produced. They offer paradigms for elevating brand (Luxury & Architecture) and service (Hospitality & Architecture) to levels not seen yet in the software business.