A wave of AI-powered-human-in-the-loop services firms has arrived, and is showing no signs of slowing down.

These firms are driven by teams of subject-matter-experts, software engineering and adjacent professionals, and 10-in-1 operators; and for each one of these forces, AI has unlocked new ways to cross-functionally experiment and explore, making it far easier to discover untapped potential in a firm's data, processes, and fundamentals that simply did not exist before, and do not exist in pre-existing firms.

This type of business has the potential to unlock the pricing power of traditional services firms, but at the traditional margins of software businesses. Services-as-a-software if you will.

I'm lucky enough to be building one of these firms from the ground up at Crosby. After one year there, I've seen, built, and learned so much with an incredible multi-disciplinary team, and I wanted to share my thoughts, both general and specific to Crosby.

Cross-Functional Force Multipliers

I've found that it's not enough to simply build a system of record anymore (i.e. what data is valuable), you also need to build a system of understanding (i.e. how the data is leveraged matters).

I think you have a working system of understanding when your subject-matter-experts, in Crosby's case: contract-reviewing lawyers, have their "I know kung-fu" moment. This means that subject-matter-experts can easily query the firm's codebase, task manager, data model, and databases with natural language to create explanations, applications, and even experiences for clients entirely out of band of engineering or product awareness. This can be super high leverage, but I think the biggest unlock for this at scale is leveraging secure primitives for compute, network, and storage. Rapidly adding value add capability for your business is important, and it should be done securely.

The gap that makes software a competitive advantage might be shrinking, but the number of people and agents operating with some kind of software or code in the loop is definitely not.

For AI services, I think this means that "designing for the operator" is a super important principle. To me "design for the operator" means; what priorities and challenges does your subject-matter-expert (or operator) have when doing some job with a certain type of client with a certain desired outcome?

As a builder, observing how your operators engage with clients and systems today can seriously improve the systems and experiences you can create for them tomorrow. Those better systems will lead to more effective and efficient decision making processes, and when those decisions lead to data and timeseries of actions, you can attempt to automate the entire process, which in turn might 1000x your operator's unique advantage. This is when your operators go parabolic.

Engineering Perspective and Practice

I'm way more bullish on AI and early career engineers than ever before.

AI has completely changed the way I build software in the past year. For net new, empty-editor work, I still feel the need to create patterns and infrastructure by hand so that I can propagate best practices and patterns from a strong foundation so that feature and systems development is accelerated. This is my #1 slop prevention technique; define and enforce high quality conventions early. I still think high quality, curated examples and conventions are some of the most valuable sources of context for an AI infused SDLC.

I also think context engineering is incredible. For example, if I want to change something about a state machine or certain areas of a web UI, I run a command that copies necessary context to my clipboard based on some namespaces and then I'll paste it into Claude or Codex with some clear, concise directions. I'll ask if the model needs any more context to be confident to suggest approaches, and that's almost always a great start!

Creating a bunch of dialogues like this in parallel is a huge force multiplier for me because I context switch quite a lot during the day. Although, I haven't made the jump to "agentic" just yet... there's still something about letting an LLM execute commands on my laptop that doesn't quite sit right with me. I'm much more interested in running agentic workflows in cloud sandboxes first.

That said, I fear that AI is affecting our ability to build skills, think critically, and develop our own individual taste and style of programming. I think there's something deeply valuable in questioning the status quo and then taking the time to figure out a new and better way over a weekend or whatever without the use of a LLM: learning that's completely guided by your own intuition and observation.

We can still choose to spend time solving problems "the hard way", but when the hard way is so disincentivized by business demands and a culture of "people like us do things like this", what choice do we really have? My hope is that the next generation figures out a new way to build skills and taste. It's a brave new professional world, where everyone is now an early career engineer. None of us know for sure where we're going with all this, so I'll take the long view on people just starting out. Hello world, new engineers!

Two Ideas

I have a couple of ideas about what will separate winners from losers in the arena of human-AI hybrid professional services firms.

1. Bending the curve

This graph shows two functions $a$ and $b$ intersecting at point $c$. Think of $a$ as a function of overall AI market access; all firms can access LLM APIs, AI powered workspace applications, etc; and over time it will improve at a constant rate based on access and distribution. Now think of function $b$ as how your AI services firm is going to add value over time to your clients.

If you primarily choose to spend time doing things that other people tell you to do, especially those that control the factors that go into curve $a$ (incumbents), you won't accrue competitive advantage because you're blending your unique advantage into the market.

The bend happens because your unique foundation gets to ride the same rising market tide as everyone else, but from a higher leverage point that nobody else can replicate. Once you reach that leverage point ($c$) that should signal hypergrowth.

This is very tricky though. Move too slow and you may not be able to establish yourself as a market leader in time, move too fast and you risk not having enough unique advantage to sustain a lead in the market. It could be helpful to strike a balance by testing what kinds of clients you can retain the best and where that momentum leads you as you go upmarket with a couple of customers.

2. Choose your customer, choose your infrastructure.

We have the CAP theorem for describing tradeoffs when designing software systems, but we don't have something that helps us describe tradeoffs when selecting how to design infrastructure so that we can best serve our customers. So here goes something. I call it, TSMD (Tenant Model × Sale Dimension).

This 2x2 illustrates my thought process for figuring out how to select your infrastructure to best serve your clients.

Let's consider quadrant $A$ a B2C company; Spotify for example. Your end customers don't really care whether or not you're using Kubernetes, they care whether or not they can listen to their music and podcasts and it all just works. Here you can pick whatever you need to serve your customers, with the caveat that success and growth mean you'll have to wrestle with serious engineering challenges at scale. So you might find yourself building your own solutions down the line. Certainly a good problem to have.

Quadrant $B$ is a funky one. It's likely that in this quadrant you'll need to design your software to run wherever your customer needs it, so maybe you'll need to support a docker container runtime, a kubernetes operator, or maybe everything's in a GitHub repo that the user clones and runs, or maybe it's a binary they run with a license key if it's even a service they pay for? Think of something like home automation software, and often times you might see this as a "self-service" deployment option too.

Quadrants $C$ and $D$ are my favorites. I've spent a good amount of time here. Let's consider GitHub as an example. Most companies can just sign up to use GitHub as a free tier, pro tier, team tier, and enterprise tier, all while staying on github.com! But what if ACME, a big enterprise customer, asks you to run GitHub on ACME's infrastructure... for your biggest deal ever.

We've now entered quadrant $D$, for dollar sign. How do you easily make github.acme.com happen? In cases like this, if you initially took the approach of infrastructure selection in quadrant $A$ you could get screwed because you might not be able to easily replicate the PaaS or IaaS in ACME's infrastructure. This is when kubernetes really shines; almost all customers at this level are leveraging a cloud vendor that has some kind of kubernetes distribution that you can leverage with what I like to call; The Contract of Infrastructure. Simply put for this post; if your customer stands up a cluster with minimum requirements, you can either run a script that can hit their infra, or you package up a manifest and containers and share it with them in a secure file share with instructions. Done.

Think of $C$ as having really incredible platform and systems leverage and $D$ unlocks incredible deployment speed and opens new doors for GTM.

If I were to add another dimension I would add security and privacy specifics, but then I'd need another blog post.

Closing & Summary

{YOUR_NOUN_HERE} is infrastructure, and for Crosby, it's contracts.

One thing I love about Crosby is that we are investing in something that will never change; people want fast, fair, high quality negotiations to happen when they do business with other people. This will never go away, and if it does, please find me working on a vineyard somewhere in northern Italy and tell me I was wrong.

At Crosby, our processes, systems, operator tooling, and our infrastructure choices, are in service of strengthening the connective tissue between our team and our clients, without losing the human judgment that makes Crosby trustworthy.

Technology will keep changing. The need won't; so we're bending the curve to find something that unlocks truly safe, automated negotiation.

Sound exciting? Join the fun! Crosby is hiring!