I’m Abi. For five years I built and ran production data and cloud systems — first at Nielsen, where the volume was the hard part, then at Optum, where the data was regulated and the tolerance for “we’ll fix it next sprint” was close to zero.
That work is not glamorous. It is pipelines that have to land before the business opens, schemas that change without warning, and cloud bills that grow quietly until someone in finance finally asks a question. It is also the single best training I could have had for what I do now, because it teaches you to design for the worst day rather than the demo.
Somewhere in the middle of that I finished an MS in Computer Science at the University at Buffalo, mostly in distributed systems and machine learning. I went in wanting the theory. What stuck was how little of a real system’s difficulty lives in the algorithm and how much of it lives in everything wrapped around it.
Why I moved to AI infrastructure
When teams started shipping LLM features in earnest, I kept seeing the same shapes I’d seen in data engineering a decade earlier. Prototypes promoted to production without a queue or a retry. No observability, so failures surfaced as customer complaints. One person who understood the whole thing.
But there was a new failure mode too, and it’s the one that gets people’s attention: cost. When every call has a price, architecture decisions turn into line items. Sending a trivial classification to a frontier model, or stuffing an entire document into context because it was easier than chunking it, or retrying three times on a malformed response — each of those is a design choice, and each of them shows up on the bill at the end of the month, multiplied by your traffic.
That intersection is what I work on now: the orchestration, routing, and automation layers between a model and a business, plus the measurement that tells you whether any of it is actually working.
What I’m not
I’m not a strategy consultant. I don’t produce roadmap decks about where AI is heading, and I have no interest in convincing you to use more of it than you need. Several of my more useful engagements have ended with a recommendation to replace an LLM call with about forty lines of ordinary code, because that was the correct answer.
I also don’t take work I can’t do well. If your problem is really a data-quality problem, or a product problem wearing an AI costume, I’ll tell you on the first call rather than three invoices in.
How I like to work
Small scopes with clear outcomes. Code in your repository, running on your infrastructure, from the first week. Written findings you can circulate internally without me in the room. And a handoff that leaves your engineers able to change what I built without calling me — which is the only honest definition of a finished consulting engagement.
Between client work I write about the specific problems I run into, with the numbers attached. If you want a sense of how I think before you get in touch, the blog is the fastest way to find out.