AI-Forward Development
AI-forward, not AI-first. On a production system, the difference is everything.
AI has genuinely changed what a small team of senior engineers can take on. On legacy code it makes the unreadable readable; on a new build it turns the first month of scaffolding into part of the first week. We've rebuilt our delivery process around it. What we haven't done is let it decide anything that matters on its own.
What actually changed
The wins are real, and they're narrower than the marketing suggests.
We've been building software since 1997, which is long enough to have watched several technologies get oversold. Here is where AI has measurably changed our work, and where it hasn't.
Codebase archaeology
Reading a large, undocumented codebase to answer "where does this actually happen?" used to be weeks of billable time nobody wanted to fund. Models can now traverse a two-hundred-thousand-line legacy application and produce a first-pass map of it in an afternoon. This is the single biggest change to legacy work in our lifetime as a firm.
Mechanical translation
Pascal to C#. VBScript to C#. CFML to something maintainable. The tedious, high-volume, low-judgement part of a port is exactly what this technology is good at, provided a person reviews the output and a test suite catches what the reviewer misses.
Test generation
Legacy systems rarely come with tests. Generating a characterisation suite that pins down what the current code does, right or wrong, is now cheap enough to do before touching anything. That safety net is what makes the rest of a modernization defensible.
Where it hasn't changed much
Architecture. Knowing which of four migration paths fits your business. Telling a client the honest answer is "don't". Debugging a race condition that only shows up on your production hardware. Judgement under real consequences is still the job, and it's still done by people.
Inside our delivery process
Where AI sits in an actual engagement.
Not as a novelty, and not in the sales deck. Here's the working reality.
-
Discovery: AI reads first, we verify second
Every source file goes through analysis that produces call graphs, data-flow notes, dependency inventories and candidate business rules. An engineer then checks the findings against the running system. Roughly speaking, AI gives us the questions; the system and the client give us the answers.
-
Specification: recovering what was never written down
The output of discovery is a document your team can read: what the system does, which rules are deliberate and which are accidents that have hardened into policy. Clients tell us this is often worth more than the code changes that follow.
-
Implementation: drafted fast, reviewed properly
AI drafts, refactors and translates. Every commit is read by an engineer before it merges. We use it hardest on code that is repetitive and verifiable, and most cautiously on code where being subtly wrong is expensive.
-
Verification: differential testing against the original
On ports we run old and new side by side against real inputs and compare outputs. Divergences are triaged one at a time. This is unglamorous and it is the reason a port can be trusted.
-
Documentation and handover
The system ends the engagement better documented than it started. For a codebase that arrived with nothing that is not a high bar to clear, but it is enormously valuable to whoever maintains it next.
AI in your product
And when you want AI features in the software itself.
Practical capabilities with clear business cases, built on current models, with sensible fallbacks for when a model is unavailable or wrong.
Document extraction
Pulling structured data out of invoices, forms, contracts and scanned records that currently require a person to retype them. Usually the fastest payback of anything on this list.
Search that understands meaning
Retrieval over your own documents, tickets and knowledge base, with answers that cite their sources so users can check them.
Classification & routing
Triaging inbound requests, tagging records, and flagging exceptions for human attention, with confidence thresholds you control.
Assistants inside your application
Natural-language interfaces onto features your users already have but can't find, scoped to what that user is permitted to see.
Legacy-to-modern bridges
An AI layer that makes a thirty-year-old system's data usable in modern tooling, without modifying the system itself.
Honest scoping
Including telling you when the problem in front of you is better solved by a database index, a form redesign, or a rule engine than by a model.
Guardrails
The commitments we make about how AI touches your code and your data.
Reasonable questions to ask any firm claiming to be AI-forward. These are our answers, in writing, before you ask.
- A person reads every line that ships. AI drafts; an engineer is accountable. We do not merge code no human has reviewed.
- Your code and data stay within agreed boundaries. We'll work under your restrictions on where source may be processed, up to and including engagements where nothing leaves your environment.
- No training on your material. We use providers and settings that don't train on submitted content, and we'll confirm the specifics in writing for your engagement.
- Ports are verified, not trusted. Translated code is proven against the original with differential testing before it's considered done.
- We tell you where AI was used. If you want a component built without it, say so and we'll do that instead.
- Model-agnostic by design. We build so the underlying model can be swapped as the field moves, because it will.
The short version: AI made us meaningfully faster at the hardest part of our work: understanding code nobody understands anymore. It did not change who is responsible when your billing run produces the wrong number at two in the morning. That's still us.
Curious what this looks like on your codebase, or on something you haven't built yet?
A discovery engagement is fixed-price and fixed-duration, and the written assessment is yours regardless of what you do next.