Product  ·  How I Work

How I Build
with AI

"I use AI" is the most useless line in a 2026 portfolio. Everyone says it. The interesting question is where you let it touch the work, and where you deliberately don't. Here's my actual line, and why I keep the LLM out of the decisions.

AI-Augmented Build Product How I Work Personal
7 min read

Every product role now lists "AI-augmented" as a requirement, and every candidate now claims it. So the phrase has stopped meaning anything. Saying "I build with AI" in 2026 is like saying "I use a computer" in 2005. True, but completely uninformative.

What's actually worth knowing is the judgment underneath it: which parts of the work I hand to AI, which parts I keep, and (the line most people skip) whether I let an LLM make the decisions the user relies on. My answer to that one is no, and that's a deliberate decision, not a limitation. This is how I actually work.

The Distinction

Two completely different questions

People collapse "AI" into one thing. In practice there are two separate questions, and confusing them is where most of the muddle comes from.

AI in the build
How fast and how well I research, scaffold, generate data, and debug.

Here I lean on AI heavily. It's a force multiplier on the parts of building that are about coverage and speed.
AI in the product
Whether the thing the user interacts with has an LLM making decisions at runtime.

Here I'm conservative. For a scoring or advice product, a non-deterministic black box is usually the wrong call, and I'll explain why.

A lot of "AI products" in 2026 are really the first thing dressed up as the second, an LLM bolted onto a problem that didn't need one, because "AI-powered" sells. I'd rather be precise: AI changed how I build. It rarely belongs in what I ship.

In the Build

Where AI genuinely earns its place

As a solo builder, my constraint is never ideas. It's hours. AI gives me the leverage of a small team on the parts of building that are about breadth and momentum. Here's how that plays out across my projects.

Research at scale
For TryCareerMatch I needed to understand what 85+ roles actually require, across ten sectors. AI compressed weeks of reading job descriptions into days of structured first drafts I could then verify and refine. It didn't decide the answer; it got me to a reviewable starting point fast.
Scaffolding code
For Portugal Data Intelligence, AI scaffolded the repetitive shape of the ETL modules and drafted DAX measures, the boilerplate that's slow to type and easy to get subtly wrong. I owned the architecture and the statistics; AI typed the first pass.
Generating structured data
Drafting the initial role-skill importance matrices, or calibrating modelled series to published trends, is exactly the kind of high-volume, rules-bound work AI accelerates, provided every output passes back through my judgment before it counts.
Debugging & rubber-ducking
Explaining a bug to an attentive model often surfaces the cause before it answers. And when it does answer, it's a second pair of eyes on a stack trace at 1am. This site you're reading was built the same way: AI as a fast pair, me as the one deciding.
The pattern is the same every time: AI gets me to a reviewable draft fast. The value I add is the review, the judgment about what's right, what's wrong, and what to keep. The draft is cheap now; the judgment is the job.
The Line

Why there's no LLM in the decisions

Both products I've built make this choice explicitly, for the same reasons. TryCareerMatch scores your profile against roles with a rule-based engine, deterministic and explainable, and no LLM ever touches the scoring or ranking. A newer paid report tier can add a Claude-written narrative on top, but it only describes the deterministic scores, never changes them. Portugal Data Intelligence makes the same split: its analysis runs on real statistical models, and an LLM is an optional layer that only writes prose, with the numbers it describes always the deterministic ones.

Determinism
The same input must always produce the same result. A career-fit score or an economic figure that changes between runs isn't a feature. It's a bug the user can feel. Rule-based engines are reproducible by construction.
Explainability
When TryCareerMatch ranks a role, it can show exactly why: which skills carried weight, where the gaps are. "The model said so" is not an answer a user can act on. Every score traces back to a rule I can point to.
Trust & honesty
An advice product earns trust by being right and being legible. Hiding a black box behind a confident sentence is the opposite of that. If I can't explain how a result was produced, I shouldn't be shipping it as guidance.
Cost & latency
A rule-based score returns instantly and for free. An LLM call adds cost, latency, and a dependency on someone else's uptime, a bad trade when a deterministic engine does the job better.

This isn't anti-AI. It's knowing what the technology is good at. An LLM is a brilliant tool for building a rules engine: researching the rules, drafting them, stress-testing them. It's often the wrong tool for being the rules engine at runtime. Telling those two apart is most of the skill.

The Method

How I actually work with it

Using AI well is a skill, and it's not the one people assume. It's not about writing clever prompts. It's about being a good editor and a relentless verifier of work you didn't write yourself.

01
Treat it as a fast junior, not an oracle
AI produces a confident first draft of almost anything. I read it the way I'd read a junior's work: useful, fast, and assumed wrong until checked. The confidence of the output is not evidence of its correctness.
02
Verify everything that matters
Every role requirement, every generated figure, every line of scaffolded logic gets checked against a real source or a real test before it's allowed to count. AI hallucinates plausibly; the only defence is verification, and it's non-negotiable.
03
Keep the judgment calls mine
Architecture, scoring weights, what's in scope, what to ship all stay with me. AI informs them and accelerates the work around them, but the decisions that define the product are the part I refuse to outsource.
AI didn't lower my standards. It raised my velocity. The bar for what's correct, explainable, and honest is exactly where it was. I just get to it faster, and I get to spend the saved time on the judgment that actually differentiates the work.
Why It Matters

What this says about how I'd build on a team

For an early-stage team, the useful version of "AI-augmented" isn't someone who pipes everything through an LLM and hopes. It's someone who ships faster and knows when not to reach for it, who can tell the difference between AI as an accelerant and AI as a liability you'll be debugging in production for months.

That's the judgment I've built by actually shipping with these tools: use AI to move fast on research, scaffolding, and iteration; keep the product deterministic and explainable where users need to trust it; and own every decision that defines what the thing actually is. The speed is the easy part now. The discipline is the differentiator.

See it in the work

Both case studies show the line in practice: an AI-accelerated build, a deterministic product.