FRAN CANETE
← Notes · 5 min read

How I apply AI to product systems

How I think about applying AI inside real software products: workflow, data, integrations, UX, permissions, cost, reliability, and human judgement.

AI engineering / product systems

I do not think of AI as a novelty layer. I think of it as one part of a product system that still has to deal with real data, permissions, integrations, workflow state, UX, validation, observability, cost, and human judgement.

FocusProduct systems
PrincipleContext before model
StandardReliable leverage

The short version

The useful part of AI engineering is not calling a model.

The useful part is deciding where model reasoning belongs inside a product system, then building the software around it so it can safely improve a real workflow.

The rule: AI becomes valuable when it is attached to real product context.

That context usually means:

  • data
  • permissions
  • integrations
  • workflow state
  • UX
  • validation
  • observability
  • cost
  • human judgement

The direction I am building toward is not AI for its own sake. It is AI as part of the product system itself.

The foundation: production software and integrations

My professional work is currently focused on integrations and production software rather than direct agentic AI development.

That matters because most AI product work is not clean-room experimentation. It sits on top of messy business systems.

what real AI products must handleproduction reality
external APIs
authentication and permissions
customer-specific configuration
structured and semi-structured data
event flows and background jobs
production-only edge cases
operational workflows that do not match the ideal design
users who need the system to be predictable and explainable

This is where integration experience is valuable. If an AI feature cannot connect to the systems where the work actually happens, it remains a demo.

The model may be the visible part, but the product value usually comes from everything around it.

Leverage comes from the system. The model is only useful if the surrounding software can constrain it, validate it, and put it into the user’s actual workflow.

The product system around the model

When I think about an AI-enabled feature, I do not start with “which model should I use?”

I start with the workflow.

The questions I care about are:

  1. 01

    What is the user trying to complete? The task matters more than the model choice.

  2. 02

    What context does the system already have? Good AI features begin with the data the product can already trust.

  3. 03

    What is missing? The model should fill gaps, not guess at everything.

  4. 04

    What should the model produce? A draft, recommendation, classification, summary, structured object, or action all imply different system design.

  5. 05

    What should stay deterministic? The safest software still uses normal code for validation, routing, and enforcement.

  6. 06

    Where does a human stay in the loop? A strong feature makes it obvious who approves, corrects, or owns the result.

In practice, that means an AI product system needs more than a prompt.

It needs:

Clear product surfaceGood data boundariesContext assemblyTool and integration designStructured outputsValidation rulesLogging and observabilityCost controlsFallback behaviourHuman review pointsBusiness impact measurement

The engineering challenge is not just getting an impressive answer from a model. The challenge is making the feature reliable enough to belong inside the product.

Where I am building direct AI product proof

My current job gives me the production systems and integrations foundation.

My side projects are where I am deliberately building direct AI product experience.

Projects like Duebase and Plaudera are useful because they give me a place to explore AI as part of a real product, not as a detached chatbot.

The goal is judgement. I want to get better at knowing when AI improves the product, when normal software is better, and when the safest design is a hybrid.

The patterns I want to develop through these projects are:

  • AI-assisted workflows inside normal SaaS interfaces
  • Structured extraction from unstructured input
  • User-controlled automation rather than fully opaque automation
  • Retrieval and context design around product data
  • Agent-like flows where the system can gather context, propose actions, and ask for confirmation
  • Clear before-and-after workflows that show time saved or decisions improved
  • Practical evaluation: examples, edge cases, failure modes, and manual review

The kind of AI feature I trust

The AI features I trust usually have a few things in common.

They are narrow enough to be useful.

They have access to the right context.

They produce outputs the product can validate or constrain.

They make the user’s next action easier.

They do not hide uncertainty.

They preserve ownership: the system can assist, draft, classify, suggest, or prepare, but the product still makes it clear who is responsible for the final decision.

good feature shapeAI as leverage
assist, not obscure
constrain, not improvise
validate, not assume
surface uncertainty
keep ownership clear

That matters because many AI demos look impressive in isolation but fall apart when they meet real workflows. They lack permissions, state, auditability, recovery paths, or a clear user decision point.

A strong AI-enabled product should feel less like magic and more like leverage.

What I want to become good at

The direction I am building toward is AI-enabled product engineering.

That means being strong at normal product software and increasingly strong at the AI-specific layer around it.

The skills I want to compound are:

  • Full-stack product engineering with TypeScript, Node.js, React, SQL, and PostgreSQL
  • API and integration design
  • Workflow mapping and automation judgement
  • LLM feature design
  • Prompt and context engineering
  • Structured outputs and validation
  • Retrieval patterns
  • Agent and tool-use patterns
  • Human-in-the-loop UX
  • Observability, cost control, and failure analysis
  • Communicating technical trade-offs in product and business terms

The commercial value is not “I can use AI tools.”

The commercial value is “I can take a messy workflow, understand the real constraints, and build a reliable product system where AI creates measurable leverage.”

How I will prove it

I want my portfolio to show working systems, not vague interest.

The proof should look like:

  1. 01

    Working workflow. Screenshots or a short demo video that shows the AI-enabled flow end to end.

  2. 02

    Before and after. A clear explanation of the old process and the improved one.

  3. 03

    System design. Architecture notes showing data flow, model calls, integrations, validation, and human review points.

  4. 04

    Deterministic boundaries. Specific examples of where normal code is used instead of AI.

  5. 05

    Trade-offs. Notes on cost, latency, reliability, and failure modes.

  6. 06

    Next iteration. A short explanation of what I would improve next.

That is the kind of evidence that makes the positioning concrete.

The standard is simple: show the workflow, show the system, show the trade-offs, and show why AI made the product more useful.

That is the path I am building.