DEV Community: Leo Pessoa

How Much Is AI Integration Actually Costing Your Team?

Leo Pessoa — Sat, 30 May 2026 15:02:50 +0000

Not the API costs. The development costs.

Every time your team ships an AI feature, something happens before the first real line of product logic: you build infrastructure. Prompt templates. Response parsers. Validation logic. Retry handlers. Intent routers. All of it written by hand, for every object that needs to talk to an LLM.

Nobody plans for this work. It shows up in the sprint as "a few integration tasks" and leaves three weeks later with its own file structure.

Let's make it concrete

Say you want to add AI to your CRM. Lead is already a Pydantic model — it has name, company, email, score, notes. The ask is simple: "given this email from a prospect, auto-fill the lead."

Here's what the implementation actually costs:

# Step 1: build the prompt
LEAD_PROMPT = """
You are a CRM assistant. Extract lead information from the following email.
Return a JSON object with these fields: name, company, email, score (0-100), notes.
Do not include any explanation. Return only valid JSON.

Email:
{email_text}
"""

# Step 2: call the API
def extract_lead_from_email(email_text: str) -> dict:
    response = client.chat.completions.create(
        model="gpt-4",
        messages=[{"role": "user", "content": LEAD_PROMPT.format(email_text=email_text)}],
        response_format={"type": "json_object"}
    )
    return json.loads(response.choices[0].message.content)

# Step 3: validate
def parse_lead_response(data: dict) -> Lead:
    required_fields = ["name", "company", "email", "score", "notes"]
    for field in required_fields:
        if field not in data:
            raise ValueError(f"Missing field: {field}")
    if not isinstance(data["score"], (int, float)) or not 0 <= data["score"] <= 100:
        raise ValueError("Invalid score")
    return Lead(**data)

# Step 4: retry
def create_lead_from_email(email_text: str, retries: int = 3) -> Lead:
    for attempt in range(retries):
        try:
            raw = extract_lead_from_email(email_text)
            return parse_lead_response(raw)
        except (json.JSONDecodeError, ValueError, KeyError):
            if attempt == retries - 1:
                raise

lead = create_lead_from_email(email_body)

Four functions, a prompt template, JSON parsing, field validation, type coercion, retry logic. About 60 lines if you're disciplined.

You haven't written a single line of CRM logic yet.

Now multiply by every entity

That was Lead. Your system also has Deal, Contact, Company, Activity, Proposal, Invoice.

Each one needs the same tax:

Component	Lines (avg)
Prompt template	8–15
API wrapper	10–20
Response validator	15–30
Retry handler	10–15
Error handling + logging	10–20
Total per entity	~50–100 lines

Seven entities. Seven prompts. Seven parsers. Seven retry stacks.

That's 350–700 lines of infrastructure that breaks when the model changes, needs updating when the schema evolves, and lives outside your domain model where no one expects to maintain it.

The hidden cost isn't lines — it's coupling

Every piece of that infrastructure is coupled to three things at once: the object schema, the LLM provider, and the output format. Change one, touch all three.

Upgrade the model? Audit every prompt for compatibility. Add a field to Lead? Update the prompt, the validator, and the retry logic. Switch providers? Rewrite the API wrappers.

This is the integration tax in full. It doesn't show up on the sprint board as "tech debt" because it looks like product work while you're building it. It shows up six months later as a maintenance burden nobody owns.

What the bill looks like

Rough estimate for a mid-sized product team:

Initial integration per entity: 1–2 days
Maintenance per model update or provider change: 2–4 hours per entity
Debugging malformed LLM responses in production: 1–2 hours/week across the system
Onboarding a new developer to the AI layer: half a day to a full day

Across a system with 5–10 AI-enabled entities, you're looking at a week of upfront work and a quiet ongoing tax of several hours per sprint — indefinitely.

Nobody budgeted for it. It was just the cost of shipping AI features.

The integration tax exists for one reason

Your object is passive.

The prompt has to know about the object: its fields, its constraints, the format it expects. The object knows nothing about the LLM. That asymmetry is what creates the adapter layer — and it scales with every entity you add.

Flip the responsibility:

from exomodel import ExoModel

class Lead(ExoModel):
    name: str = ""
    company: str = ""
    email: str = ""
    score: int = 0
    notes: str = ""

lead = Lead.create(email_body)

No prompt. No parser. No retry stack. The schema is the contract — the object reads the intent and fills itself.

The integration tax doesn't get reduced. It gets eliminated.

What you get back

Not just hours. The more important return is cognitive clarity:

Your domain model is the source of truth again — not a prompt string
Adding a field means updating the class, not hunting across three files
Switching providers is a one-line .env change, not a refactor
A new developer reads the class definition and understands the system — the same way they always have

The infrastructure didn't disappear. It moved into the library where it belongs, maintained by the framework, not by your team.

A quick audit for your own codebase

If you have a production system with AI-enabled domain objects, three questions:

How many prompt templates do you currently maintain?
How many of them have test coverage?
When was the last time a model update broke one of them?

If the answers are "more than I'd like to admit," "not many," and "recently" — that's the integration tax on the balance sheet.

Docs: https://exomodel.ai
GitHub: https://github.com/exomodel-ai/exomodel
Install: pip install "exomodel[google]"

What's the highest-friction part of your AI integration stack? Curious whether others are hitting the same maintenance walls.

You Shouldn't Need a Vector Database Just to Make Your Object Follow a Policy Document

Leo Pessoa — Wed, 20 May 2026 18:08:40 +0000

Here's the RAG tax in full:

Vector database. Embedding pipeline. Chunking logic. Retrieval tuning. Token budget management. Context injection into your prompts — carefully, so you don't blow the window.

Most tutorials cover 200 lines before reaching the part that actually matters: the output.

All of this infrastructure exists to answer one question: does this input match something in my document?

That's not a database problem. That's an object that doesn't know its own rules.

The real villain: your object is ignorant of your domain

LLMs know a lot about the world. They don't know your pricing tiers, your exclusion policies, or the compliance rules your team wrote last quarter.

Standard practice says: build a RAG pipeline to retrieve the right chunks from your docs and inject them into the prompt before calling the model.

It works. It also turns a 10-line feature into a 200-line infrastructure project — for every model that needs grounded behavior.

The problem isn't retrieval. The problem is that your domain object has no way to say: "when I'm created, consult this document."

exomodel makes that a one-method override.

Attaching a document to an object

You're building a proposal generator. Your business rules live in a markdown file:

# Proposal Rules

- Minimum project budget is $10,000.
- Every proposal must include a 10% safety margin in pricing.
- We do not work with companies in the tobacco or gambling industries.
- Timeline estimates must account for a 2-week QA buffer.

This is the document your object needs to know. Here's how it learns it:

from exomodel import ExoModel

class Proposal(ExoModel):
    client: str = ""
    project_title: str = ""
    budget: float = 0.0
    timeline_weeks: int = 0
    summary: str = ""

    @classmethod
    def get_rag_sources(cls):
        return ["proposal_rules.md"]

That's the entire integration. No pipeline. No database. No chunking code.

p = Proposal.create("Draft a proposal for Acme Corp — cloud migration project, 8 weeks")

print(p.budget)          # 45000.0  (includes 10% safety margin)
print(p.timeline_weeks)  # 10       (8 weeks + 2-week QA buffer)
print(p.summary)         # A cloud migration engagement for Acme Corp...

The object applied your rules. You wrote zero lines of prompt engineering.

What's actually happening

When get_rag_sources() is defined, exomodel runs the full RAG stack for you — internally, at call time, without external dependencies:

Reads each file listed
Chunks the content into overlapping segments
Embeds the chunks into an in-memory vector store
Retrieves the sections most relevant to the input
Injects them into the prompt alongside your schema

No external database. No embedding API to configure. No persistent state to manage. The index lives in memory for the duration of the request.

The infrastructure didn't disappear — it moved inside the object where it belongs.

The object now knows what it's not allowed to do

RAG-grounded behavior isn't just about filling fields correctly. It enforces constraints:

p = Proposal.create("Draft a 5k proposal for BetMax Casino")

print(p.run_analysis())
# → This proposal violates company policy:
#   budget is below the $10,000 minimum, and the client
#   operates in the gambling industry.

The rule came from proposal_rules.md — not from the model's training data, not from a prompt you wrote, not from a validator you coded by hand.

This is what grounded behavior looks like: traceable to a source, enforced at the object level.

Multiple sources

@classmethod
def get_rag_sources(cls):
    return [
        "proposal_rules.md",
        "pricing_tiers.md",
        "client_blacklist.md",
    ]

exomodel indexes all of them together and retrieves across the combined corpus. Add a document — the object learns it. Remove it — the object forgets it. No pipeline to rebuild.

When does this beat a dedicated vector database?

Always, when your use case is document-grounded object behavior — objects that need to act according to rules defined in files.

A dedicated vector database beats this when you have thousands of documents, need persistent indices, or need cross-session retrieval at scale. For that, use the right tool.

But if you've ever stood up a vector pipeline just to make one object respect a policy document, that was the integration tax. You don't owe it anymore.

Docs: https://exomodel.ai
GitHub: https://github.com/exomodel-ai/exomodel
Install: pip install "exomodel[google]"

What rules are your objects currently blind to — and how many lines of infrastructure did that cost you?

Every AI feature starts with the same glue: parsers, adapters, method calling. That's not product work. That's routing code. I'm building Exomodel to let your Python objects understand intent and act — no routers, no parsers. https://exomodel.ai

Leo Pessoa — Sat, 16 May 2026 23:33:19 +0000

exomodel.ai

The Schema IS the Prompt: Rethinking AI-Native Software Design

Leo Pessoa — Mon, 11 May 2026 23:24:21 +0000

Every few years, a new abstraction arrives that makes the previous one feel embarrassing in retrospect.

Raw SQL gave way to ORMs. Callback hell gave way to async/await. Manual memory management gave way to garbage collection. Each shift wasn't just about writing less code — it was about thinking differently about the problem.

We're at one of those moments with AI.

The way we learned to talk to LLMs

Most AI-powered applications today follow the same pattern:

Write a prompt string
Interpolate some variables into it
Call the API
Parse the response (pray it's valid JSON)
Map it to your data model
Validate
Handle the cases where it isn't valid
Retry

This is prompt-centric thinking. The prompt is the program. The data model is just a container waiting at the end of a pipeline.

It works. But it's the callback hell of AI development — functional, verbose, and fragile in ways that only show up in production.

What if we inverted the relationship?

Here's the question that changes everything:

What if the data model declared its own intent — and the prompt was just an implementation detail?

Instead of:

prompt → LLM → parse → validate → object

What if it was:

object schema + natural language → typed instance

This is the inversion. The schema is the prompt. The structure of your data model encodes what you're asking the LLM to produce. You stop writing instructions about what you want and start defining the shape of what you need.

Why this matters architecturally

In prompt-centric design, the prompt is the source of truth. It lives in a string, often scattered across the codebase, version-controlled poorly, and duplicated whenever a new model needs similar behavior.

In schema-centric design, the source of truth is the data model — the same artifact that drives your validation, your database schema, your API contracts. The LLM becomes a filling mechanism, not an oracle you interrogate with carefully crafted language.

When requirements change, you update the schema. The prompt adapts automatically. There's no string to hunt down across three files.

Malformed responses don't propagate — Pydantic catches them at the boundary before they reach your application logic. A new developer reading the codebase understands what the system produces just by reading the class definition, the same way they always have.

And because the schema is the interface, switching providers is a one-line environment change — not a prompt rewrite.

The analogy that makes it click

Think about what ORMs did for databases.

Before SQLAlchemy, you wrote SQL strings. You interpolated variables, concatenated conditions, and hoped the output was valid. The database schema lived in migration files; the queries lived in strings scattered across your application.

ORMs moved the source of truth to the Python class. The class is the contract. Queries become method calls. The database is still there, doing its job — but you stopped thinking in SQL and started thinking in objects.

exomodel does the same thing for LLMs.

The class is the contract. The LLM is still there, doing its job — but you stop thinking in prompt strings and start thinking in schemas.

from exomodel import ExoModel

class Proposal(ExoModel):
    client: str = ""
    project_title: str = ""
    budget: float = 0.0
    timeline_weeks: int = 0
    summary: str = ""

p = Proposal.create("Draft a proposal for Tesla — AI dashboard integration, 6 weeks")

No prompt string. No JSON parsing. No retry logic. The model knows what it needs to produce because you've already described it — in Python, with types, the way you always define data.

What this means for AI-native software

We're still in the early phase where most AI applications are built around the LLM call. The prompt is the center of gravity. Everything else orbits it.

The next phase looks different. The data model is the center of gravity. The LLM is infrastructure — powerful, essential, but abstracted away behind an interface that speaks the language of your application, not the language of tokens and completions.

This isn't a prediction. It's a design choice you can make today.

Define your schemas. Let the objects fill themselves.

How are you structuring LLM output in your projects? Drop a comment — I'm curious whether others are moving away from prompt-centric patterns.

Try it

pip install "exomodel[google]"

Docs: https://exomodel.ai
GitHub: https://github.com/exomodel-ai/exomodel

If exomodel saves you from writing a prompt string today, a ⭐ on GitHub goes a long way.

From Pydantic Model to AI Agent in 10 Lines of Python

Leo Pessoa — Sun, 10 May 2026 13:18:35 +0000

You've been doing this for a while now:

response = client.chat.completions.create(
    model="gemini-2.0-flash",
    messages=[{"role": "user", "content": f"Extract the following fields from this text: {fields}. Text: {text}"}]
)
data = json.loads(response.choices[0].message.content)
proposal = Proposal(**data)

Parse the response. Hope the JSON is valid. Add a retry. Add a fallback. Add validation. Repeat for every model in your app.

There's a better way.

Meet exomodel

exomodel is an open-source Python framework that turns your Pydantic models into autonomous agents. Instead of writing prompts that produce objects, you define the object — and it fills itself.

The paradigm shift:

Old way	exomodel way
Write prompt → parse response → validate	Define schema → call `.create()`
Manual JSON extraction	Native Pydantic validation
One prompt per model	Provider-agnostic, reusable
Fragile string parsing	Structured output, always

Let's build something.

Prerequisites

Python 3.9+
An API key from any supported provider (Google, Anthropic, OpenAI, Cohere)

Install

pip install "exomodel[google]"
# or: exomodel[anthropic] | exomodel[openai] | exomodel[cohere] | exomodel[all]

Create a .env file:

MY_LLM_MODEL=google:gemini-2.0-flash
GOOGLE_API_KEY=your-key-here

The 10 lines

from exomodel import ExoModel

class Proposal(ExoModel):
    client: str = ""
    project_title: str = ""
    budget: float = 0.0
    timeline_weeks: int = 0
    summary: str = ""

p = Proposal.create("Draft a proposal for Tesla — AI dashboard integration, 6 weeks, $45,000 budget")

print(p.to_ui(format="markdown"))

That's it. Run it.

## Proposal

**Client:** Tesla
**Project Title:** AI Dashboard Integration
**Budget:** 45000.0
**Timeline (weeks):** 6
**Summary:** A 6-week engagement to design and integrate an AI-powered...

exomodel sent your natural language input to the LLM, mapped the response to your schema, validated it with Pydantic, and returned a typed Python object. No prompt engineering. No JSON parsing.

Add business rules with RAG

What if your proposals need to follow company rules — minimum budget, forbidden industries, mandatory margins?

Create a proposal_rules.md file:

# Proposal Rules

- Minimum project budget is $10,000.
- Every proposal must include a 10% safety margin in pricing.
- We do not work with companies in the tobacco industry.

Now attach it to your model:

class Proposal(ExoModel):
    client: str = ""
    project_title: str = ""
    budget: float = 0.0
    timeline_weeks: int = 0
    summary: str = ""

    @classmethod
    def get_rag_sources(cls):
        return ["proposal_rules.md"]

The model now has context. You can validate against your own rules:

p = Proposal.create("Draft a 5k proposal for Philip Morris")

print(p.run_analysis())
# → This proposal violates company policy: budget below $10,000 minimum
#   and client operates in the tobacco industry.

The LLM grounded its reasoning in your document, not its training data.

Update fields with natural language

Already created a proposal but the client changed the scope?

p.update_object("Increase the budget by 20% and extend the timeline to 8 weeks")

print(p.budget)          # 54000.0
print(p.timeline_weeks)  # 8

Or update a single field:

p.update_field("summary", "Make it more formal and concise")

Bulk creation with ExoModelList

Need to generate multiple structured objects at once?

from exomodel import ExoModel, ExoModelList

class LineItem(ExoModel):
    name: str = ""
    quantity: int = 0
    unit_price: float = 0.0

class Invoice(ExoModelList[LineItem]):
    pass

invoice = Invoice()
invoice.create_list("10 MacBook Pros at 2499, 5 Dell monitors at 599, 3 mechanical keyboards at 189")

print(invoice.to_csv())

name,quantity,unit_price
MacBook Pro,10,2499.0
Dell Monitor,5,599.0
Mechanical Keyboard,3,189.0

How it works under the hood

When you call .create(), exomodel:

Introspects your Pydantic schema (field names, types, defaults)
If get_rag_sources() is defined, chunks and indexes those documents into an in-memory vector store
Builds a structured prompt with your schema and any RAG context
Sends it to your configured LLM provider
Validates the response against your Pydantic model
Returns a typed instance — with usage tracking built in

Everything goes through LangChain under the hood, so provider-switching is a one-line .env change.

Expose methods as agent tools

Need the LLM to call methods on your object, not just fill fields? Use @llm_function:

from exomodel import ExoModel, llm_function

class Proposal(ExoModel):
    client: str = ""
    budget: float = 0.0
    discount: float = 0.0

    @llm_function
    def apply_discount(self, percentage: float):
        """Apply a percentage discount to the budget."""
        self.discount = percentage
        self.budget = self.budget * (1 - percentage / 100)

p = Proposal.create("Draft a 50k proposal for Tesla")
p.master_prompt("Apply a 15% discount for a long-term partnership")

print(p.budget)    # 42500.0
print(p.discount)  # 15.0

master_prompt lets the LLM autonomously decide which tool to call — no routing logic needed.

Token usage

print(p.get_usage())
# {'prompt_tokens': 312, 'completion_tokens': 87, 'total_tokens': 399}

What's next

Docs: https://exomodel.ai
GitHub: https://github.com/exomodel-ai/exomodel
PyPI: pip install exomodel

If this saved you from writing another prompt parser, give the repo a star — it helps more developers find it.

Have a use case you'd like to see covered? Drop it in the comments.