Turn AI ambition into working systems.

From Boardroom Intent to Working Code — Repairing the Requirements Pipeline

Engagement: senior delivery team Duration: 3–4 weeks Stack: Qdrant, frontier LLMs, Jira / Azure DevOps Outcome: ~70% less clarification traffic, ~30% faster rollout

In most organizations, features follow the same lossy path. An executive describes what they want in a meeting. Business analysts translate that conversation into Jira or Azure DevOps work items. Developers then build from those descriptions. Meaning erodes at every step — analysts do not read code, and developers were never in the room where the feature was born. The result is a long tail of clarification cycles that everyone accepts as the cost of doing business.

I spent two years attacking this problem with AI. Straightforward RAG over frontier models produced positive results; so did fine-tuning open models such as Qwen. Neither was good enough. Context windows were too small then — and today, when an agent can roam entire repositories, the token bill starts to rival a human salary. Brute force is not an architecture.

My team's answer is an advanced retrieval index: Qdrant with both dense and sparse vectors over the codebase and work-item history, combined with disciplined prompting inside a custom workflow. Work items are analyzed against the actual code — and enriched with the context developers need — before a developer ever picks them up. The workflow is not limited to text: it also understands the images that requirements actually arrive with — architecture diagrams, whiteboard sketches, UI design fragments — and folds them into the same analysis. I deliberately deliver this as a consulting methodology built on your infrastructure, not a product you must license and maintain.

Two engagements so far, three and four weeks each. Both produced the same pattern: developer–analyst back-and-forth reduced by roughly 70%, and average feature rollout time cut by 30%.

Taming AI Coding Costs Across Multiple Repositories

Engagement: project delivery Stack: Qdrant, custom MCP server, Claude Code, OpenAI Codex Outcome: retrieval replaces exploration — token spend cut sharply

AI coding agents like Claude Code and OpenAI Codex are transformative — until the bill arrives. In a multi-repository codebase, agents burn enormous token budgets just finding their bearings: scanning directories, grepping across projects, re-reading the same files in every session. The agent spends most of its context window (and your money) on discovery rather than on writing code.

I solved this with a retrieval layer purpose-built for coding agents. Every repository in the organization is indexed into Qdrant, a high-performance vector database, using embeddings tuned for source code — functions, classes, configuration, and documentation are all searchable semantically, not just by keyword. On top of the index sits a custom MCP (Model Context Protocol) server, so any MCP-capable agent can query it as a native tool.

The result changes how agents work. Instead of exploring the file tree, an agent asks the MCP server "where is authentication handled?" and receives the precise files and symbols it needs — including matches from repositories it would never have thought to open. Cross-repo dependencies become visible in a single query. Context windows stay small, sessions stay focused, and token consumption drops dramatically, because retrieval replaces exploration.

The same index serves every agent and every developer, and it stays current through incremental re-indexing on commit. One piece of infrastructure — and the whole fleet of AI tools gets cheaper, faster, and smarter about the codebase.

PowerIntel: Rebuilding Software Delivery Around Three AI-Augmented Senior Engineers

Engagement: delivery transformation Team: 31 outsourced → 3 senior in-house Stack: multi-model LLM routing, LLM-as-a-judge Outcome: full code ownership, faster delivery

PowerIntel was carrying a 31-person outsourced development team — and the hidden costs that come with one: uneven code quality, heavy coordination overhead, and growing concern about source code security and IP exposure across an extended external organization. Leadership wanted the codebase back under tight control without slowing delivery.

My answer was to rebuild delivery around a team of three senior engineers, each deeply proficient with AI-assisted development. The bet: a small, trusted, in-house team amplified by the right AI tooling can outperform a large outsourced one — at a fraction of the coordination cost and with a dramatically smaller security surface.

Two pieces of AI engineering made the economics work. First, a multi-model strategy: instead of sending everything to a single premium LLM, each task was routed to the model that fit it — inexpensive models for boilerplate and refactoring, frontier models only where deep reasoning paid for itself — cutting token costs substantially. Second, LLM-as-a-judge: generated code and outputs were automatically evaluated by a second model against quality and style criteria before a human ever looked at them, catching defects early and keeping the small team's review load manageable.

The outcome: a 10x smaller team, full in-house ownership of the code, tighter security, and delivery velocity the previous structure never achieved. Headcount is not capability — leverage is.

RAG by Measurement, Not Fashion: Model Selection Studies

Engagement: evaluation study Method: customer-specific gold dataset, recall metrics Outcome: measured cost-vs-quality curve + reusable evaluation harness

A RAG pipeline is not one model decision — it is a chain of them. The embedding model, the chunking strategy, the model that enriches chunks before indexing, the model that rephrases the user's query before retrieval, and the model that generates the final answer are all separate choices. Each affects quality and cost differently, and the combinations multiply quickly. Most teams pick whatever is currently fashionable, wire it together, and never measure the result.

We run these studies properly. Chunking is parametrized and tuned to the corpus — size, overlap, and structure-aware boundaries — rather than left at library defaults. Chunk enrichment and query rephrasing are treated as distinct stages, each assignable to a different model: an inexpensive model is often entirely adequate for reformulating a query, while enrichment may justify something stronger. The frontier model is reserved for the one place it earns its price.

The discipline that makes this engineering rather than opinion is the evaluation set. For every customer we build a specific "gold" dataset — real questions with verified answers drawn from their own corpus — and score every pipeline configuration against it, with recall as the primary metric. The output is not a recommendation slide; it is a measured cost-versus-quality curve, and the customer chooses their operating point on it knowingly.

The evaluation harness stays with the client's team. New models ship monthly; the ability to re-run the study in an afternoon outlasts any single verdict.

AI Readiness Begins with Knowing Your Data

Engagement: readiness assessment Stack: AWS Macie, Microsoft Purview Alignment: ISO 27001, SOC 2, HIPAA, PCI-DSS 4.0 Outcome: governance perimeter drawn before AI build

Every AI initiative eventually collides with the same uncomfortable question: what, exactly, is in your data? An LLM will happily embed, index, and repeat whatever you feed it. Customer PII, health records, payment data — once they flow into embeddings, prompts, and logs, they are distributed across systems that were never in your compliance scope. HIPAA, PCI-DSS, and SOC 2 do not pause because the technology is new.

So before any index is built or any model is fine-tuned, I start with sensitive information discovery. I have implemented this with AWS Macie and Microsoft Purview across substantial data estates: automated classification that establishes what sensitive data exists, where it lives, and who can reach it — before a single byte of it reaches an AI pipeline. The findings routinely surprise the data's own custodians.

This discipline comes from years of building systems that had to pass audits, not just demos — work aligned with ISO 27001, SOC 2, HIPAA, and PCI-DSS 4.0. That experience shapes how I scope AI projects: the governance perimeter is drawn first, and the AI architecture is designed inside it, not retrofitted to it after an incident.

The deliverable is an AI roadmap grounded in what your data actually permits — which is worth considerably more than one grounded in what a vendor's slide deck promises.

Analytics Platform: From Hand-Coded Dashboards to Self-Service

Engagement: platform architecture Sector: utility Stack: Apache Superset / Preset, Snowflake, Cortex Outcome: dashboards became configuration; data answers plain-English questions

The platform I inherited had a pattern I have seen many times: every dashboard was a hand-built React page with its own charts. Adding a series, changing a grouping, adjusting a filter — each was a programming job, phrased as a feature, queued in the backlog, and released on the engineering cycle. The analytics the business saw was always weeks behind the questions it was asking.

The geospatial requirements made it harder. This was utility data: the solution had to render multiple layers on a map — the utility network itself as a graph of nodes and branches with their operating characteristics, plus area-based groupings and regional overlays. That is well beyond what a typical chart library, or a typical BI tool, handles gracefully.

We evaluated the field methodically — from the famous (Power BI, Tableau) to the obscure (Omni) — against the criteria that actually mattered: geospatial layering, embedding, licensing economics at scale, and how much of the old React investment could be retired. The selection was Apache Superset (with Preset as the managed option) on top of Snowflake. Open, SQL-native, no per-viewer license tax, and map layering capable of carrying the network graph.

The consequence was structural: dashboards became configuration instead of code, analysts compose their own views, and engineering went back to building what is unique to the business. Then we added the layer that changes the relationship with data entirely — Snowflake Cortex, wired directly into the dashboards, so the dashboards answer back. A manager does not hunt through filters; she asks, in plain English, "which branches in the northern district ran closest to their limits last week?" and receives a governed, warehouse-grade answer — not a chatbot's guess.

This is my broader thesis about enterprise AI: it succeeds when it disappears into the tools people already use. Nobody on that platform "uses AI." They just ask their questions — and the data answers.