AI Made Language Programmable

Sixteen years of building systems taught me one hard limit. Software needs clean input. A person could read a rambling customer email and know exactly what to do with it. A machine could not. So we built forms. Dropdowns, radio buttons, required fields, validation rules, all of it engineering around a single stubborn fact: people do not talk in JSON.

That wall came down, and most of the country missed it.

Then language models got good enough to reason about text, and for anyone who thinks in logic gates something specific happened. Words became variables. AI made language programmable. A voicemail transcript became a set of true/false gates. A rambling complaint became a record with a category, a priority and an address attached.

This is the argument I make in every discovery session, so it may as well live somewhere permanent. The interesting part of AI is not what it can write. It is what it can decide.

What Does It Mean to Say Language Is Programmable?

It means a model can take unstructured human text, a voicemail, an email, a scribbled note in a free-text field, and return structured output that a programme can branch on. Urgency as a boolean. Category as a fixed list. Address as a field. The model reads what was meant and hands back data.

That sentence sounds small. Sit with it for a minute, because it removes a constraint that shaped commercial software for fifty years.

Why Did Software Always Need Structured Input?

Because code branches on values, and values have to be unambiguous. A machine cannot evaluate "the hot water's been playing up since Tuesday" against a condition. So we built forms to force people to communicate in shapes software could process, then called the resulting friction user experience.

I have spent a career building those forms. Job intake screens, claim wizards, dropdowns with thirty options where twenty-eight are wrong for the person filling them in. Every one of them existed to convert a human sentence into a database row, using the only converter available at the time, which was the human being asked to fill it out.

The cost was never obvious because it was spread so thin. A few seconds per field, a bit of training, a support call when someone picked the wrong category. Multiply that across a few thousand jobs a year and it becomes a real tax on the business, paid in small coins so nobody ever counts it.

What Changed When Models Learned to Reason About Text?

Reasoning models infer intent rather than parse strings. They weigh implied meaning, tone and context, then commit to a decision. Text that was previously noise becomes an input a system can act on, which means the conversion step stops needing a person in the middle of it.

Nobody has to tick a box marked urgent anymore. The model reads the message and works out that a tenant with no hot water and a newborn is a different call from a tenant asking about a squeaky gate. Nobody needs a dropdown for complaint type either, because a complaint describes its own type if something can read it properly.

This is the bit that made me pay attention. I think in states and functions and gates, and I had spent sixteen years accepting that fuzzy input was somebody else's problem, usually an administrator's. Then the fuzzy input became addressable.

Close (ESC)

Where Does This Show Up in a Real Business?

In the places where a person currently reads something and decides what happens next. Claims triage, job intake, maintenance requests, applications, complaints, quote enquiries. Any workflow with a free-text field and a human bottleneck behind it is a candidate, because the bottleneck was always the conversion step.

What Does a Fuzzy-to-Binary Conversion Look Like in Practice?

It looks like a paragraph going in and a set of fields coming out. We built one that reads a technician's rough notes and produces a finished insurance assessment report, cutting the write-up from about thirty minutes to three, with more consistency across technicians than the handwritten version ever managed.

That project is worth describing because it is so unglamorous. A technician assesses a damaged phone, types a few lines of shorthand, and an insurer needs a formal report. The shorthand was always enough for a person to work from. It was never enough for software, so the technician wrote the report by hand, thirty minutes at a time, at a quality that varied by who was on shift.

Nothing about the business logic changed. Same template, same fields, same insurer wanting the same things. The only new part was a reasoning layer that could read shorthand and fill the template, and you can read how we built it into a FileMaker ERP if you want the mechanics.

Why Is the Free-Text Field the Best Place to Start?

Because it is where a business already admitted its structure ran out. Somebody built that field because the dropdowns could not cover reality. Whatever people type there is the work the system could never model, which makes it the highest-value text in the database and the cheapest place to prove the idea.

Go and look at yours. Every job management system, CRM and claims platform has one, usually called notes or description or additional information. It holds the real detail, and it has been invisible to every report you have ever run.

We built an email-to-database automation for insurance claims on exactly this principle, and it has run for years without anyone watching it. That one predates the current generation of models and did the job with much narrower tools, which is a useful reminder. The goal is structured output. The model is the newest way to get there, and sometimes not the cheapest.

Close (ESC)

Why Do So Many AI Projects Miss This?

Because they buy a tool and hope, when the work is finding a conversion. 87% of NZ organisations report using AI in some form and only 12% have scaled it. The gap is the difference between staff using a chat window beside their work and a business wiring a reasoning step into a workflow that runs whether anyone opens a browser or not.

What Separates Using AI From Embedding It?

Using AI means a person opens a tool, pastes something in, and copies the answer back into the system that matters. Embedding it means the conversion happens inside the workflow, on every record, without anyone choosing to do it. The first depends on somebody's habit. The second runs at 3am on Boxing Day.

That distinction explains most of the gap between adoption and results in New Zealand. Autocomplete in your email client is AI. It is also not touching the thirty minutes a technician spends writing reports, because it was never wired into that job.

The tell is what happens when the enthusiastic person goes on leave. If the AI work stops, it was a habit. If it carries on, it is infrastructure.

What Does This Change About How You Scope a Project?

It moves the opening question from "what could AI do for us" to "where does a person read something and decide". The second question has answers you can point at, count and price. It also hands you your measurement for free, because you already know roughly how long the reading and deciding takes today.

I ask three things in a first session. What do people read, what do they decide after reading it, and how many times a week. Everything worth building falls out of those answers, and so does everything not worth building.

The projects that fail tend to start from the technology and go looking for a home. The ones that pay for themselves start from a person doing a repetitive conversion in their head, forty times a day, and quietly getting slower at it by Friday afternoon.

Close (ESC)

How Do You Find These Conversions in Your Own Business?

Listen for one sentence. Any time somebody says "someone has to read this and decide", you have found a candidate. Write down what they read, what they decide, and how often it happens. That list is your AI roadmap, and you can assemble it in an afternoon without buying anything.

What Should You Write Down for Each One?

Enough to price it and to prove it later. The input and where it arrives, the decision and its possible outcomes, the volume per week, the minutes each one takes, and what goes wrong when somebody gets it wrong. Five fields. They turn a vague ambition into a ranked list.

The ranking usually surprises people. The glamorous idea comes fourth, behind something nobody thought of as an AI project because it looked like admin.

Close (ESC)

What Should an NZ Business Do With This?

Pick the smallest conversion with the clearest before-and-after, measure how long it takes a person today, then build that one. Treat it as an operations problem. If it cannot beat the manual baseline on time, accuracy or cost inside sixty days, it has not earned its keep and it should go.

Start narrow on purpose. One input, one decision, one place the output has to go. A first build that reads maintenance requests and rates urgency is worth more than a twelve-month programme that reads everything, because the narrow one tells you within a fortnight whether your assumptions about the input were right. They usually are not, and that is cheap to learn at this size.

Keep a person on the escalation path from day one. The conversion handles the ordinary cases, which is most of them, and hands the strange ones to somebody who can think. Anyone selling you a system with no escalation path is selling you a future incident.

The businesses getting real value from this are not doing anything clever. They found a spot where a human was converting language into a decision, put a reasoning step there, wired the output into the system they already run, and measured it. That is the whole method. If you want a hand finding your first one, talk to us, or have a look at how the same idea works answering the phone for a trades business.

Close (ESC)