AI consulting for CTOs
CTO to CTO · audit, fractional or a standing call · day rate on consulting
Most CTOs are somewhere between a board that has read about agents and a team that has actually tried them. Far Horizons works on that gap from the engineering side: what to build, how to gate it, what it's going to cost and what to leave alone. Every engagement is led by Luke Chadwick, and the people you talk to are the people doing the work.
Where it usually goes wrong
01
The bill arrives before the plan
Coding agents and LLM features tend to get switched on team by team, and nobody looks at the total until finance comes around in a bit of a panic. It's entirely possible to spend more on AI than the developers it was meant to speed up would cost. Getting spend visible per team and per feature, every week, is an unglamorous first step, and it's usually the right one.
02
Speed without gates
Agents writing the code is the easy part. What makes it hold up is the gauntlet: a proper spec before any code gets written, review by more than one model, and test suites long enough that a bad change can't get through. With that in place, agents can merge to production. Without it, you get regressions faster.
03
Rewriting because the AI prefers it
A replatform tends to pause the business for a year, and it's almost always a mistake. Upgrade in place, carve the old system out piece by piece with a strangler fig, and keep shipping the whole time. Agents help here. On one engagement, a framework upgrade that everyone said was impossible because of dependencies was shown to work in about a day. Agents also don't much care which stack they're on, which weakens most of the arguments for standardising.
04
Treating engineers as the cost to cut
Typing was never the hard part of software engineering. The hard part is judgment: what to build, how it fits together, what's going to break. With agents, engineers move up a level. They own the specs, the architecture and the QA, and they drive the agents, which is a lot like going from developer to managing a team of developers. Cutting the people with the judgment to pay for tokens doesn't tend to end well.
Four ways in
Architecture audit
two weeks · fixed price
Far Horizons reads the codebase, talks to your engineers, and writes down what the AI system will do under load, what it costs, and what to fix in order. The usual starting point.
Fractional CTO
one–two days a week
A second senior technical voice in the room, or the first one. Architecture, hiring, vendor calls and shipping cadence, worked through with someone who is in the repo.
Team enablement
two–five days on your repo
Your engineers, your codebase, coding agents set up properly: multi-agent workflows, review discipline, and the places they actually fail.
Advisory retainer
a few hours a month
A standing call and an open channel. Somebody to talk the build-or-buy, the model switch or the reorg through with before you commit, and to ring when something breaks.
The decisions stay yours
Far Horizons gives you a straight opinion and the reasoning behind it, and then it's your call. If estimates are being forced out of the team by Tuesday, or a rewrite is being sold as an AI initiative, you'll hear that plainly, including when it's not what the board wants to hear.
Who leads it
Luke Chadwick. Shipping software since 2001, still writing code with agents every day, co-founder of REALABS at REA Group, production LLM systems since 2022 for Scout24, AutoScout24 and others. The case studies include a 2019 rescue delivered under the original deadline.
Before you write
Will this work with our stack?
Probably. Far Horizons has worked on most of the common stacks, from PHP and Grails monoliths through to TypeScript, Python and Flutter, and the audit starts from the system you actually run.
Will it slow the roadmap down?
An audit is mostly reading. Your engineers give up a handful of conversations, not a sprint. Fractional and enablement work happens inside your normal cadence, on real tickets.
We have no AI strategy yet. Where do we start?
Not with a strategy deck. Start with what your engineers are already using and what it costs, then pick one feature that matters and get it into production properly. The strategy tends to come out of doing that.
Are we spending too much on AI, or too little?
It's the question CTOs ask most, and the honest answer is that it depends on headcount, product and what's already in production. There isn't a reliable industry benchmark, and the range is wide: Far Horizons' own usage would cost well over $15,000 a month at API prices. The audit gets you to a number you can defend to the board.
Are you going to tell us to replace engineers with agents?
No. Far Horizons will tell you which work agents should take on, how to gate it, and what your engineers should be doing instead. Usually that's more specs, more review and more QA, not fewer people.
Write to hello@farhorizons.io with the system, the team size and what you're trying to solve. You'll hear back within a business day. If Far Horizons isn't the right practice for it, you'll be told so.