AI software development, past the demo
Getting a model to produce an impressive answer takes an afternoon. Getting a business to depend on that answer every day is a different discipline, and it is the one that decides whether the project survives.
AI software development means building a system where a model does part of the job and the business can still answer for the result. The model is rarely what fails. What fails is everything around it. Nobody defined what a wrong answer looks like. Where the system must stop and ask a person went undecided. And no record was kept of what it did in March.
Why so much of this work never reaches production
MIT's NANDA initiative reviewed more than 300 publicly disclosed enterprise AI deployments in 2025 and found 95% returned nothing measurable. The interesting part is not the number. What the report blames is workflow fit, not model quality. Better models will not fix that.
That matches what we see. A pilot is graded on whether the output looks right to whoever commissioned it. Production asks harder questions. Can the number be defended? Does the workflow hold when the input is malformed? Who gets woken up when it does not? Each has an engineering answer, and each belongs in the design rather than the retrospective.
- 01A pilot runs on curated inputs. Production runs on the worst week your business actually had.
- 02A demo has no concept of a wrong answer, so nothing in it can tell you how often one happens.
- 03The pilot has no owner after the meeting. The production system needs a named one before launch.
The four shapes this work takes
Almost every AI build we are asked for is one of these, or two of them joined together.
Reading documents nobody standardised
Payroll registers, tax forms, scanned PDFs and inconsistent exports turned into structured data a system can act on. The engineering is in reconciling figures across documents rather than trusting any single extraction.
RAG and the data layer →
Agents that act on your systems
A model that plans a task, calls your tools, and hands back finished work. The hard part is bounding what it may do and proving it stayed inside those bounds.
Agentic automation →
Grounded answers over your own content
Retrieval that cites the source it used, with permissions enforced so a search cannot surface a document the person asking is not allowed to read.
How retrieval goes wrong →
Removing the work between two systems
The copy-paste job somebody does forty times a day between tools that do not talk. Often the least glamorous build and the one with the clearest payback.
Process automation →
- Eval suiteCases your experts graded
- Escalation lineWhere it must ask a person
- LoggingInputs, not just outputs
- VersioningPrompts are release artefacts
- MonitoringDrift caught before a user finds it
- OwnerA named engineer on call
None of these are visible in a demo, and all six are what the build costs. A prompt changed on a Tuesday is a model change with no version bump, which is why we treat prompts as release artefacts rather than configuration.
Decide what the system is not allowed to do alone
The most useful hour of an AI project is the one where you write down which outcomes the business cannot take back. A refund issued. A policy priced. A patient matched to a trial. Anything on that list gets a person approving it, and the system's job becomes preparing the decision rather than making it.
This is also where automation is the wrong call. Some processes are genuinely ambiguous, and two experienced people would disagree on the answer. A model will produce a confident result and hide that disagreement. TrialTriage ranks eligible oncology trials, and a nurse finalises every result before it reaches anyone. That is not a limitation of the model. It is the correct design.
- Calibrate confidence on real documents. A model returning 0.9 for everything routes nothing to a human.
- Log the inputs as well as the outputs, or you cannot reconstruct why a decision was made.
What these systems run on
Models
Application
Data and infrastructure
Voice and messaging
Systems where a model does real work under supervision
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
A pilot and a production system are graded differently
| Criterion | What a pilot is judged on | What production is judged on |
|---|---|---|
| Inputs | A clean sample chosen to demonstrate the idea. | Whatever actually arrives, including the malformed and the missing. |
| Accuracy | It looked right to the people in the room. | Measured against cases your own experts graded, and re-measured after every change. |
| Wrong answers | Undefined, so uncounted. | Defined, counted, and routed to a person past a set threshold. |
| Change | Edit the prompt and re-run it. | Version the prompt, run the evals, and record what moved. |
| Failure | Try again. | An alert, an owner, and a record of what the system did. |
What buyers ask about AI builds
01What is AI software development?
AI software development is building production software where a model performs part of the work, with the engineering that makes its result dependable. That surrounding work is most of the build. It covers evaluation against graded cases, rules for when the system must escalate to a person, logging of inputs and outputs, and monitoring that catches drift after launch.
02Do we need our own data to start?
You need enough real examples to grade, which is usually less than people expect. A few hundred genuine cases will do, with an expert marking the right answer for each. That is enough to build an eval suite and find out whether the approach works. Curated samples are the trap. A system that scores well on tidy inputs tells you nothing about the messy ones.
03Should we fine-tune a model or use retrieval?
Retrieval first, in almost every case where the goal is answers grounded in your own content. Fine-tuning changes how a model behaves, not what it knows. Use it to inject facts and you get a model that is confidently wrong and expensive to correct. Fine-tuning earns its place when you need a consistent format or tone at volume.
04What stops the system inventing an answer?
Grounding it in retrieved source material, and refusing to answer when nothing relevant is found. A system that cites its document gives a reviewer something to check. One that returns nothing is far cheaper than one that returns a plausible fabrication. Past that, evals catch the cases where it still happens, before your users do.
05How do you handle a model being deprecated?
The eval suite is what makes that survivable. When a provider retires a model, you re-run the graded cases against the replacement. You see exactly what moved before anything ships. Without that suite, a forced model change is a rewrite done blind. So we build the evals during the project, not after it.
06Does this suit a startup, or only a large company?
Both, with different first releases. An enterprise usually starts where an existing system cannot be replaced. The work there is integration, plus evidence for whoever audits it later. A startup starts where the product must prove something to users or investors quickly. Its eval suite doubles as the technical due diligence answer.
