01 — The Problem
Blink's thesis was that the bottleneck in Web3 development was not creativity — it was the gap between a developer's idea and a deployable smart contract. The average developer spent hours navigating fragmented documentation, incompatible frameworks, and brittle boilerplate before writing a single line of meaningful code.
The product we built used an LLM pipeline to generate dApp code from natural language intent, grounded against a curated library of verified smart contract patterns. The challenge was not just getting the model to produce code — it was making the output trustworthy enough that a developer would actually deploy it.
That required a different kind of product thinking: one where the model's behaviour, its failure modes, and its latency were all first-class design concerns.
02 — The Work
Most of the interesting product decisions at Blink happened at the intersection of model behaviour, developer trust, and UX. Here is how the key pieces came together.
03 — Outcome
We took the product from concept through prototype to functional iterations across the full AI-driven code generation workflow. The validation came through a combination of developer research and live market exposure.
EthDenver 2024 was the forcing function. Live demos with real developers under conference conditions gave us signal that existing benchmark-led evaluation could not — which parts of the UX held up, where developers hesitated, and what they actually needed from an AI coding tool.
04 — How I Think About AI Products
Building with LLMs changed how I think about product work. The usual levers — spec the feature, ship the feature, measure the feature — do not transfer cleanly when the output is probabilistic and the failure mode is subtle rather than binary.
These principles came out of work at Blink, and have since been applied to other contexts — including a support automation project at Laguna, where the same questions around model behaviour, prompt design, evaluation and AI UX came up in a different product domain.
05 — Applied Context · Laguna
At Laguna I built a support agent, now in closed beta, to reduce repetitive query volume. Different domain — conversational AI vs code generation — same core work: prompt design, model evaluation, and UX decisions around how the AI handles uncertainty. I built a 50-case golden dataset by clustering historical tickets, then ran shadow evaluations replaying live support messages through the bot, grading first-response quality and tone against a 70% acceptable bar. Most of the work went into the negative flows — confirming that out-of-scope queries escalate to a human ticket rather than getting answered anyway. Trust failure in support costs differently than in code generation, which sharpened how I think about calibrating model behaviour to context.
The second applied context is orchestration. I built and deployed a six-agent content pipeline — research, editorial scoring, SEO brief, two routed writers, and an editor gate — producing Laguna's blog behind a human approval gate. Brand voice, readability targets and citation rules are encoded as prompt constraints, with recycle limits and human escalation for failure cases. Two decisions mattered most: keeping topic routing deterministic rather than spending a model call on it, which cut both cost and failure surface, and benchmarking local models against frontier ones so that long-form writing routes to frontier while cheaper steps stay local.
06 — What's Next
The next layer of interesting AI product problems sits at the edge of agentic behaviour — where the model is not just generating output but taking actions, coordinating across tools, and operating within real business workflows.
