AI
A straight answer, since everyone asks
01Position
The value is the working software, not the technique
A lot of companies currently lead with AI because it is the thing that gets attention. We do not, for a simple reason: nobody's quoting process was ever fixed by a technique. It was fixed by an application that does the job, and how that application got built is our problem rather than yours.
What AI genuinely changes is the economics. A significant part of our development, testing, and analysis work is automated, which is why a small team can deliver something custom at a price that competes with a generic subscription. That is a real advantage and we will happily explain it. It is just not the thing you are buying.
The other reason to be measured about it is that the failure modes are real. A model will produce a confident, well-formatted, wrong answer, and it will do so in the same tone it uses for correct ones. Any engineer telling you otherwise has not run one in production against something that mattered.
02The obvious worry
Fast and undisciplined is just faster technical debt
There is a lot of software being produced right now by people who could not have written it themselves, cannot tell when the model has got it wrong, and ship it anyway. It demos well and falls apart in month three, usually just as the original author moves on. If that is what you picture when a supplier mentions AI, that is a fair thing to picture.
Every supplier will tell you they are not that. So will we, and you have no particular reason to believe any of us on the strength of the claim. What follows is therefore not an assurance, it is the specific list of things we do, which is checkable, plus a question at the end you can put to anyone including us.
The difference is not using less AI. We use a lot of it. The difference is that nothing skips the engineering standards that applied before any of this existed. A model is very good at producing the code once the hard decisions are made. It has no opinion about whether those decisions were right, and it will implement a bad architecture with total confidence and excellent formatting.
So the judgment stays with a person, and it is the part being paid for. What to build and what to leave out. Which exception in the spreadsheet is load bearing and which is a habit. What breaks when this runs ten times bigger. Where the boundaries between components should sit so it is still changeable in two years. That comes from having built and run systems, and from having led the engineering organizations that had to live with those calls afterwards.
Tests are not optional
Every feature ships with tests, on the backend and the frontend. This is the single clearest line between assisted engineering and generated code, because tests are the thing that catches the plausible-looking mistake, and they are the first thing skipped when the goal is speed for its own sake.
The compiler is not negotiable either
TypeScript in strict mode, no escape hatches, and a Go build that has to pass. A surprising amount of confidently wrong generated code simply does not compile under a strict type checker, which makes it a cheap and unglamorous first filter.
Designed to be testable, deliberately
Interfaces for services and data access, so dependencies can be substituted and behavior can be verified in isolation. That is an architectural decision made up front by a person. It is not something that emerges from asking a model for a feature.
Everything is reviewed
Generated code goes through the same reading a human contributor's would, by someone who can tell the difference between working and correct. Reviewing critically is slower than accepting, which is exactly why it gets dropped by people optimizing for output volume.
Real operational plumbing
Versioned database migrations, deployment automation, and the ability to roll back. The unglamorous parts are what decide whether an application is still maintainable a year later, and they are consistently the parts missing from something assembled quickly.
Measured, not vibed
Where a model is doing work inside the product, its output is evaluated against known-correct examples before a change ships. If someone cannot tell you how they know a change made things better rather than just different, they do not know.
A question worth asking any supplier, including us: how do you know the AI-assisted code you just shipped is correct? If the answer is that it works, or that it looked right, keep looking. If the answer involves tests, types, review, and something measured, you are talking to an engineer.
03In practice
Where it is used, and where it is not
The honest version, including the places we think it is the wrong tool. If your project needs none of this, that is a perfectly good outcome and it does not change the price.
We do
Writing and testing the software
AI-assisted development across the build, which is a large part of why the economics work. Everything it produces goes through the same review, tests, and type checking as anything else. It is a fast collaborator, not an unsupervised one.
We do
Making sense of your spreadsheet
Parsing a workbook into a dependency graph is deterministic, and we keep it that way because the structure has to be exact. Models help with the interpretation layer on top: grouping related calculations, drafting plain descriptions of what a formula is doing, and flagging things that look inconsistent for a human to check.
We do
Reading documents, when that is the problem
Turning scanned or handwritten records into structured data is genuinely something models are good at and rules are not. This is the bulk of the applied work at Cloudline. It is also where the guardrails below came from.
We do
Features in your application, when they earn it
Drafting, summarizing, classifying, or extracting inside the product, where the alternative is a person doing it by hand every time. Always with a defined boundary on what data it touches, agreed before we build it.
We do not
Deciding anything on its own
We do not ship features where a model's output becomes a committed business fact without a person or a deterministic check in between. Not because the model is usually wrong, but because usually is not a standard you can run a business on.
We do not
Replacing a rule that already works
If the logic is knowable and stable, it should be code. Code can be tested, explained, and it gives the same answer twice. Reaching for a model there adds cost, latency, and a failure mode in exchange for nothing.
We do not
A chat box bolted onto the side
Adding a conversational assistant to an application nobody asked for one in is the most common way to spend money on AI and get nothing back. If we cannot say what question it answers that a well-designed screen does not, we will say so.
04Guardrails
Making a probabilistic component safe to depend on
At Cloudline we use models to read aircraft maintenance logbooks: decades of handwritten entries, stamps, and continuation sheets, turned into structured maintenance history. Aircraft records are regulated. An entry saying an airworthiness directive was complied with is a legal record, and getting it wrong is not a bad user experience, it is an airworthiness problem.
So the interesting engineering is not the extraction. It is everything built around the extraction to make its output safe to rely on. This is the pattern we use, and it generalizes well past aviation.
Hover or tab a stage to see what it does
01The model proposes, a person confirms
Nothing a model produces is treated as verified until a human has accepted it. Proposals land in a review queue with the reasoning attached. The system stores an AI suggestion and a confirmed fact differently, because they are different things, and collapsing that distinction is how you end up unable to say which of your data is actually true.
02Stages, with checks between them
Extraction is a pipeline of distinct steps, and the valuable ones are the gates: a quality check and a sanity check sit between reading a document and accepting what was read. Each stage records what it did, so a wrong answer is traced to the step that produced it instead of being blamed on the model in general.
03Uncertainty is surfaced, not smoothed over
A model will answer confidently about a smudged, ambiguous entry. Low-confidence values are flagged and put in front of a person rather than quietly folded into the record. The failure mode you design against is not the obvious error, it is the plausible one that nobody thinks to check.
04Golden sets, so a change can be proven
We keep curated sets of documents with known-correct answers, and any prompt, model, or pipeline change is measured against them before it ships. Without this you are not improving a system, you are changing it and hoping. It is the step teams skip most often and the one that separates an experiment from a product.
05Nothing destructive, everything reversible
Originals are preserved and linked rather than overwritten, including the text as it stood before any automated merge. If the system gets something wrong you can get back to what was actually on the page. In a regulated context that is not a nicety, it is what makes the system defensible.
06An audit trail that can answer why
Every step writes down what it saw and what it decided. We have diagnosed real pipeline defects from that trail alone, by comparing what a stage claimed to do against what it actually wrote. If you cannot reconstruct why a system produced an output, you cannot certify it and you cannot fix it.
05Your data
Where your information goes, decided before we build
This is the part clients are actually worried about when they ask about AI, and it usually goes unanswered in a paragraph of reassurance. Here is the concrete version.
Most of what we do with AI touches our code, not your data. Writing and testing software is the largest use, and that involves the application we are building rather than the records inside it. Where a feature genuinely needs to send your data to a model, that is a decision made with you in advance, in writing, not an implementation detail you discover later.
What we commit to
- We agree what may leave your environment before any model-backed feature is built, and it goes in the contract rather than a conversation
- We tell you which provider, what specifically is sent, and what is retained
- Where the work calls for it we use providers offering zero-retention and no-training terms, and we will show you those terms rather than paraphrase them
- If a requirement cannot be met without sending data somewhere you are not comfortable with, we will tell you that and build it a different way, or not build it
- Your data is never used to improve anything we sell to anyone else
06Regulated work
What aviation taught that other regulated fields are now facing
Aviation has spent decades working out how to trust systems that can fail, which turns out to be useful preparation for a field where the interesting new component is one that is confidently wrong some percentage of the time.
The lesson that transfers is not really about models. It is that trust comes from the structure around a component, not from the component's accuracy figure. Nobody certifies an aircraft system by asserting the part is very reliable. They ask what happens when it is not, whether that state is detected, what the system does next, and whether you can reconstruct the sequence afterwards. Those are the same four questions worth asking about a model in a clinical, financial, or safety-adjacent workflow, and they are better questions than what its benchmark score is.
This is the part of the work Jon is most interested in talking about publicly, including with people working through the same problem in healthcare, where the records are just as regulated and the tolerance for a plausible wrong answer is just as low.
If you want the longer version
Happy to go deeper on any of this, including the parts where we think the current enthusiasm is misplaced. It is a more useful conversation than a capability list.