DEV Community: Carlos Eduardo Sotelo Pinto

VitaeForge: Breaking the ATS Barrier

Carlos Eduardo Sotelo Pinto — Fri, 29 May 2026 17:00:00 +0000

Open-source ATS Optimization Framework | GitHub Repository

Abstract

VitaeForge is an open-source CLI tool that optimizes resumes for Applicant Tracking Systems (ATS). It takes a single career data file (cv.yaml) and a job description. It returns a tailored PDF with an ATS score, updated keywords, and CAR-formatted experience bullets.

The tool solves a specific problem: qualified candidates are filtered out by ATS before a human ever reads their resume. The cause is usually keyword mismatch and poor formatting — not a lack of qualifications.

VitaeForge addresses this through four mechanisms:

Job description analysis — extracts required and preferred keywords
ATS scoring — estimates keyword match before and after tailoring
CAR formatting — rewrites experience bullets in Challenge-Action-Result structure
Hexagonal architecture — supports multiple AI providers via a single interface

This paper documents the problem, the architecture, the development methodology, and the honest results from personal use.

Executive Summary

75% of resumes are rejected by ATS before a human reads them[^1]. The reason is rarely lack of qualifications. It is keyword mismatch, bad formatting, and bullets that don't communicate impact clearly.

VitaeForge automates the fix:

Analyzes the job description and extracts required keywords
Scores the CV against the JD before and after tailoring
Rewrites experience bullets in CAR format (Challenge-Action-Result)
Generates a tailored PDF in under 2 minutes

It is open-source (MIT license). One command. One data file. Works with OpenAI, Anthropic, Google, Groq, and local Ollama models.

1. Introduction: The ATS Barrier

1.1 The Problem

98% of Fortune 500 companies use ATS[^3]. These systems filter resumes automatically before a recruiter sees them. Most candidates never know they were rejected by a machine.

I am a Python Developer with experience in cloud and data engineering. In early 2026, I was applying for jobs and getting no responses. My skills matched the job descriptions. But my resume scored below 60/100 on ATS tools like Jobscan.

The problem was not my qualifications. It was three things:

Problem	Cause	Example
Keyword mismatch	ATS matches exact terms, not synonyms	"Docker Swarm" ≠ "Kubernetes"
Bad formatting	Tables and columns break ATS parsers	Multi-column layout renders as garbled text
Weak bullets	Generic statements don’t signal impact	"Led a team" vs. CAR-formatted bullet

1.2 Why I Built VitaeForge

I built VitaeForge to solve my own problem. I wanted a tool that would:

Read a job description and extract what the ATS is looking for
Score my CV against those requirements
Rewrite my experience bullets in CAR format
Generate a tailored PDF in minutes, not hours

As a developer, I also used this project to practice Product Owner and Technical PM skills. I wrote user stories with Gherkin acceptance criteria, organized work into sprints, and used AI agents in role-specific modes (BA, Architect, QA, Engineer).

"I wasn’t just competing with other candidates — I was competing against algorithms designed to filter me out before a human ever saw my resume."

2. How ATS Works — and Why Resumes Fail

2.1 The Numbers

Statistic	Value	Source
Resumes rejected by ATS before human review	75%	Jobscan
Fortune 500 companies using ATS	98%	Capterra
Time a recruiter spends on initial resume review	7 seconds	Ladders
ATS pass rate improvement with CAR format	+38%	The Muse

3 out of 4 resumes never reach a human. When they do, the reviewer spends 7 seconds.

2.2 How ATS Screens Resumes

ATS systems filter candidates in three ways:

1. Keyword matching — exact terms, not synonyms.

JD requires:  "Kubernetes"
Resume says:  "Orchestrated containers using Docker Swarm"
ATS result:   ❌ Skill mismatch

2. Format parsing — complex layouts break the parser.

Resume table:   | Company | Role | Dates |
ATS output:     "Company Role Dates Acme Engineer 2020-2022"

3. Impact scoring — generic bullets don't signal value.

Generic bullet	CAR-formatted bullet
"Led a team of engineers."	Challenge: Missed deadlines due to unclear priorities. Action: Implemented Agile sprints. Result: Improved delivery time by 30%.

A JD requiring "Python, Django, AWS" will reject a resume that says "Backend Development, REST APIs, Cloud" — even if the candidate is qualified.

2.3 What VitaeForge Changes

Metric	Without VitaeForge	With VitaeForge
ATS Score (observed)	< 60	75–90
Time per application	20–40 minutes	< 2 minutes
Keyword alignment	Manual	Automated from JD
Bullet format	Generic	CAR (Challenge-Action-Result)

3. Building VitaeForge: A Product Owner’s Journey

3.1 Methodology

Two disciplines shaped the development process:

ATDD (Acceptance Test-Driven Development)
I used the ATDD skill for Claude Code — not the full framework. It gave me the Gherkin/INVEST vocabulary and a role-switching discipline. Each feature started with acceptance criteria. The AI wrote code against those criteria. This reduced ambiguity and kept each session focused.

Hexagonal Architecture (Ports & Adapters)
Domain logic has zero external dependencies. AI providers, file I/O, and the PDF renderer are all infrastructure. The domain only knows about the AIPort interface. This made it trivial to swap models and test business logic in isolation.

3.2 Development Workflow

VitaeForge was built by one developer with AI assistants in role-specific modes. This is not an automated pipeline. It is deliberate context switching — each role gets its own session with its own constraints:

Role	AI Tool	Primary Focus
Business Analyst	Claude Sonnet (claude.ai)	User stories, Gherkin acceptance criteria
Software Architect	Claude Sonnet (Claude Code)	Hexagonal architecture, domain boundaries
QA Engineer / Tester	Mistral via OpenCode	Test case generation, edge case review
Software Engineer	Claude Sonnet (Claude Code)	Implementation, code quality

Each role had its own prompt constraints:

Role	Key constraint
BA	Gherkin only. No technical stack language. INVEST compliance.
Architect	Domain-first. No infrastructure imports in domain layer.
QA	Edge cases and failure paths only. No implementation suggestions.
Engineer	Architecture-compliant code only. Approved dependencies. No scope additions.

Keeping roles separate prevented the model from drifting into solving adjacent problems. One long session with no role boundaries consistently produced worse results than shorter, focused sessions.

3.3 Process

Work was organized in short cycles. Each feature followed this sequence:

Write acceptance criteria in Gherkin
Get architect review of the approach
Implement with the engineer role
Test and review output manually

Definition of Ready (before starting a story):

Acceptance criteria written in Gherkin
Architecture approach agreed
Test scenarios defined

Definition of Done (before closing a story):

Acceptance criteria pass
CAR format verified on output
PDF renders correctly

Example acceptance test:

Feature: Job Description Analysis
  Scenario: Extract keywords from a Python developer JD
    Given a job description for "Senior Python Developer" containing:
      """
      Must have: Python, Django, REST APIs.
      Preferred: Kubernetes, AWS, TDD.
      """
    When VitaeForge analyzes the job description
    Then it should return required keywords: ["Python", "Django", "REST APIs"]
    And preferred keywords: ["Kubernetes", "AWS", "TDD"]

Testing:

Level	Tool	What is tested
Unit	pytest	Domain models, use case logic, YAML generation
Integration	pytest	cv_writer upsert/append, CLI modes
Manual	Human review	AI-generated content before acceptance

The project ships with 68 tests total.

3.4 Model Selection

Models were selected based on personal experience during development and practical trade-offs between cost, quality, and availability. The project supports all models through a registry-based adapter pattern — any model can be swapped via the VITAEFORGE_MODEL environment variable without code changes.

Alias	Provider	Used For	Personal Assessment
`claude-opus`	Anthropic	Development — all roles	Best overall. Handles any task complexity well — BA, architecture, coding. First choice when quality matters.
`claude-sonnet`	Anthropic	Development — coding + BA	Strong for coding and requirements work. Good balance of speed and quality.
`gpt-4o-mini`	OpenAI	Production default — final choice	Reliable for structured output. Cost-effective, consistent JSON. Tested for VitaeForge CV generation and stayed with this.
`gemini-flash`	Google	Production alternative — tested	Works well for VitaeForge tasks. Fast and free-tier friendly. Tested for CV generation; both GPT and Gemini performed well.
`groq-llama`	Groq	Testing / free-tier	Acceptable for simple tasks. Free and fast, but not suited to complex generation.
`ollama-mistral`	Ollama (local)	Small scoped tasks	Only for narrow, simple tasks. Struggles with multi-step reasoning or complex prompts.
`ollama-llama3`	Ollama (local)	Local/offline use	No API key required.
BigPickle (OpenCode Zen)	OpenCode Zen	ATDD dev role — specific tasks	Limited use only. Worked for very specific, well-scoped tasks when given detailed prompts and descriptions. Used as the developer agent in ATDD. Not suitable for open-ended or complex generation.
Nemotron 2 (OpenCode Zen, free)	NVIDIA via OpenCode Zen	ATDD dev role — attempted	Not recommended. Did not produce usable output for development tasks. Free tier but not worth the tradeoff in quality.

Author's note: claude-opus was the best model across the board for development — BA, architecture, and implementation. claude-sonnet was the sweet spot for day-to-day coding and specification work. For production use of VitaeForge itself (generating CVs), both gpt-4o-mini and gemini-flash worked well; gpt-4o-mini was the final choice. BigPickle (OpenCode Zen) served for very specific, well-configured dev tasks; Nemotron 2 was not usable.

The registry (src/infrastructure/ai/registry.py) auto-detects the best available model from the environment if VITAEFORGE_MODEL is not set, using a priority order: gpt-4o-mini → groq-llama → gemini-flash → claude-haiku → ollama-llama3.

3.5 Technical Challenges and Solutions

The key challenges encountered during development are documented in Section 6. A brief summary here:

Challenge	Root Cause	Solution Applied
AI hallucination	Under-constrained prompts	Strict CONSTRAINT clauses + human review gates
Prompt scope creep	Open-ended sessions	Role-specific prompt contexts with explicit "DO NOT" clauses
ATS formatting fragility	Complex PDF layouts	Delegated to rendercv — VitaeForge only controls content
Multi-language consistency	Free-form translation	`LocalizedString` value object as core data primitive; lang passed explicitly in all prompts
CAR format compliance	Unstructured source bullets	Structured JSON output with separate `challenge`/`action`/`result` fields

3.6 Lessons Learned

1. Prompt quality beats model quality.
A well-constrained prompt on gemini-flash produced better output than an open prompt on claude-sonnet. The most effective elements were explicit "DO NOT" clauses, a required output format, and source anchoring. Start there before upgrading the model.

2. Choose the right model for the task.

Model	Verdict
Claude Opus	Best overall. Handles BA, architecture, and coding well. Use when quality matters.
Claude Sonnet	Strong for coding and requirements work. Good daily driver.
GPT-4o-mini	Reliable for structured JSON output. Final choice for VitaeForge production.
Gemini Flash	Fast and free-tier friendly. Works well for CV generation.
Mistral (Ollama)	Only for narrow, simple tasks. Fails on multi-step reasoning.
BigPickle (OpenCode Zen)	Limited use. Needs very detailed prompts and narrow scope.
Nemotron 2 (OpenCode Zen)	Not recommended. Did not produce usable output.

Start with a capable model. Downgrading to save cost is rational. Starting cheap to later upgrade wastes more time than it saves.

3. Separate roles = less drift.
One long session accumulates context and the model starts solving adjacent problems. Short sessions with one role per context produced consistently better results.

4. Hexagonal architecture made model switching free.
Changing AI provider required only a .env change. No code touched. This paid off every time an API limit was hit or a model underperformed.

5. Human review is not optional for resume content.
No prompt constraint fully eliminates hallucination. The --jd confirmation gate and --edit YAML preview exist so the author reviews every AI output before it is accepted.

6. Delegate rendering, own content.
Building a PDF renderer from scratch would have been a detour. Delegating to rendercv kept the focus on the real problem: content generation and ATS alignment.

4. Technical Implementation: Hexagonal Architecture and Core Components

4.1 Hexagonal Architecture Implementation

VitaeForge uses hexagonal architecture (Ports & Adapters). Domain logic has no external dependencies. Infrastructure adapters connect to AI providers, files, and the renderer. The three layers are:

Domain Layer (src/domain/)

Core Characteristics: Complete isolation from external dependencies — no provider SDK imports, no file I/O, no rendering logic.
Key Models (Pydantic v2 BaseModel throughout):

 # src/domain/models.py (actual)
 class LocalizedString(BaseModel):
     es: str
     en: str
     def get(self, lang: Lang) -> str:
         return self.es if lang == Lang.ES else self.en

 class Experience(BaseModel):
     company: str
     location: LocalizedString
     role: LocalizedString
     start_date: str
     end_date: str
     description: Optional[LocalizedString] = None
     aptitudes: List[str] = Field(default_factory=list)
     is_entrepreneurship: bool = False
     bullets: List[LocalizedString]

 class CVData(BaseModel):
     name: str
     lastname: str
     email: str
     phone: str
     location: LocalizedString
     experience: List[Experience]
     skills: List[SkillTag]
     education: List[Education]
     # ... certifications, courses, projects, languages, achievements

Use Cases (src/domain/use_cases/):
- jd_analyzer.py: Extracts role title, seniority, required/preferred keywords, responsibilities from raw JD text
- ats_scorer.py: Scores CV against JD via AI prompt, returns ATSResult with score + keyword gaps
- experience_enricher.py: Rewrites experience bullets in CAR format, returns enriched CVData
- profile_generator.py: Generates role-specific profile summary and per-entry summaries
- cv_editor.py: Interactive menu-driven editor — brain dump → AI extraction → cv.yaml upsert

Application Layer (src/application/cv_generator.py)
- Contains a single function generate_rendercv_yaml() that assembles domain objects into rendercv's YAML schema. It applies theme config (section selection, max_entries, one-page vs multi-page behavior) and produces a string ready for rendercv to consume.
- No business logic lives here — it is pure assembly and serialization.
Infrastructure Layer (src/infrastructure/)
- AI adapters (src/infrastructure/ai/): One class per provider, all implementing AIPort.complete(prompt, system) -> str. Providers: OpenAI, Anthropic, Google, Ollama, plus an OpenAI-compatible base used for Groq, DeepSeek.
- Persistence (src/infrastructure/persistence/): loaders.py reads cv.yaml, profile.yaml, theme.yaml. cv_writer.py handles upsert/append write-back for --edit mode.
- Renderer (src/infrastructure/renderer/rendercv_runner.py): Shells out to the rendercv CLI to convert the generated YAML to PDF.

The hexagonal architecture enables several critical capabilities:

Technology independence: Core domain logic remains unchanged when upgrading AI models
Testability: Each component can be tested in isolation
Adaptability: New features can be added without modifying existing code
Maintainability: Clear separation of concerns reduces cognitive load

4.2 Core Technical Features

The --jd mode end-to-end flow:

4.2.1 ATS Scoring System (`ats_scorer.py`)

The ATS scorer delegates evaluation entirely to the AI model. Rather than implementing local NLP (TF-IDF, cosine similarity), it sends a structured prompt containing CV facts and JD requirements, and receives back a JSON with score, matched keywords, missing keywords, and an optimized headline and summary. This design keeps the scoring logic in a single, swappable AI call rather than a brittle local pipeline:

# src/domain/use_cases/ats_scorer.py (actual implementation)
class ATSScorer:
    def __init__(self, ai: AIPort) -> None:
        self._ai = ai

    def score(self, cv: CVData, jd: JDAnalysis, lang: Lang) -> ATSResult:
        prompt = _PROMPT_TEMPLATE.format(
            lang=lang.value,
            cv_facts=_summarize_cv(cv),
            role_title=jd.role_title,
            seniority=jd.seniority,
            required_keywords=", ".join(jd.required_keywords),
            preferred_keywords=", ".join(jd.preferred_keywords),
            responsibilities="\n".join(f"- {r}" for r in jd.responsibilities),
        )
        raw = self._ai.complete(prompt, system=_SYSTEM)
        data = _parse_json(raw)
        return ATSResult(
            headline=data["headline"],
            summary=data["summary"],
            ats_keywords=tuple(data.get("ats_keywords", [])),
            score=int(data.get("score", 0)),
            matched_keywords=tuple(data.get("matched_keywords", [])),
            missing_keywords=tuple(data.get("missing_keywords", [])),
        )

The AI model returns:

score — an integer 0–100 estimating ATS compatibility before tailoring
matched_keywords — keywords present in both the CV and the JD
missing_keywords — important JD keywords absent from the CV
headline and summary — role-tailored replacements for the CV header

Design rationale: Using the language model as the scoring engine means the same model that understands natural language can also judge keyword semantic equivalence (e.g., "serverless" ≈ "AWS Lambda") without hand-crafted synonym maps. The trade-off is that the score is an estimate, not a deterministic calculation — which is honest, since real ATS scoring algorithms are also opaque.

4.2.2 CAR Bullet Generation Engine (`experience_enricher.py`)

The ExperienceEnricher use case transforms experience bullets into Challenge-Action-Result format. It sends each bullet to the AI model with a structured prompt that requires JSON output with separate challenge, action, and result fields, then assembles them into a single coherent bullet string. The prompt includes the JD's required keywords so the model prioritizes relevant terminology in the result.

The CAR structure is:

Component	Description	Example
Challenge	The business problem or context	"ETL pipeline had a 40% failure rate due to schema drift"
Action	Specific action taken	"Implemented schema validation layer with automated alerting"
Result	Measurable outcome	"Reduced pipeline failures by 35% and cut incident response time from 4h to 30min"

The key prompt constraint is that the model must use only information present in the original bullet. It cannot invent metrics, extend timelines, or add skills not mentioned in the source. Human confirmation is required before any enriched output is accepted.

4.2.3 Theme-Based Formatting (`cv_generator.py`)

cv_generator.py in the application layer maps domain objects to rendercv's YAML schema. The output format depends on the active theme's one_page flag:

# themes/harmony/theme.yaml (actual)
theme_name: harmony
one_page: true
sections:
  - key: experience
    name: Employment History
    max_entries: 8      # AI-ranked by ATS relevance in one_page mode
    max_bullets: 1      # ignored in one_page mode — only summary shown
  - key: projects
    name: Projects
    optional: true
    max_entries: 3

One-page mode (harmony): experience entries show only the AI-generated summary paragraph. Projects show only name + URL. The experience pool is ranked by ATS relevance score and capped at max_entries.

Multi-page mode (moderncv, globant): full bullets, descriptions, tools line, and project details are included.

The cv_generator.py function generate_rendercv_yaml() handles all section rendering — there is no separate LayoutEngine class.

4.3 Incremental Regeneration

VitaeForge avoids unnecessary AI calls through a hash-based invalidation strategy. Every time vitaeforge --role runs, it computes a SHA hash of cv.yaml and stores it in the profile's _meta.cv_hash field. On subsequent runs, if the hash hasn't changed, the cached profile summary and per-entry profile_summaries are reused — no AI call is made.

# people/carlos_sotelo/profiles/data_engineer__python_aws.yaml
_meta:
  cv_hash: abc123def456       # updated automatically on each run
profile_summaries:            # per-entry AI summaries, keyed by (company, start_date)
  en:
    - company: Acme Corp
      start_date: "2024-01"
      ats_score: 90
      text: "Migrated a web app and database to AWS..."

This means:

First run for a role: AI generates profile summary + per-entry summaries. Typical wall-clock time depends on the configured model and number of experience entries.
Subsequent runs (unchanged cv.yaml): Zero AI calls. Output is regenerated from cached YAML in under a second.
After editing cv.yaml: Only changed or new entries trigger AI regeneration; existing cached summaries are preserved.

The --refresh flag bypasses the hash check and forces full regeneration when needed.

4.4 AI Adapter Architecture

VitaeForge uses a registry-and-factory pattern to decouple model selection from business logic. Every AI call in the domain layer goes through AIPort — an abstract interface. The infrastructure layer resolves the concrete adapter at startup from a central registry:

# src/infrastructure/ai/factory.py (actual implementation)
def build_ai_adapter(model_alias: str | None = None) -> AIPort:
    alias = model_alias or DEFAULT_MODEL
    entry = REGISTRY.get(alias)           # ModelEntry: provider, model_id, env_key
    api_key = os.getenv(entry.env_key) if entry.env_key else None
    # Dispatch to the correct adapter class by provider
    if entry.provider == "anthropic":
        return AnthropicAdapter(entry.model_id, api_key)
    if entry.provider in ("openai", "openai_compat"):
        return OpenAICompatibleAdapter(entry.model_id, api_key, entry.base_url)
    if entry.provider == "google":
        return GoogleAdapter(entry.model_id, api_key)
    if entry.provider == "ollama":
        return OllamaAdapter(entry.model_id)

Adding a new AI provider requires only a new entry in registry.py and an adapter class — zero changes to domain or application code. This is the Open/Closed Principle applied directly to AI model management.

Auto-detection fallback: if VITAEFORGE_MODEL is not set, the factory iterates a priority list and selects the first model whose API key is present in the environment:

5. Observed Results

5.1 What the Tool Produces

This is a v1.0 release. Controlled empirical studies with statistical significance testing are outside the scope of this paper. What follows are honest observations from the author's personal use during the development period.

ATS score behavior (observed using Jobscan on personal applications):

Resumes generated without VitaeForge (--role mode, generic tailoring) typically scored in the 55–70 range against specific JDs when tested on Jobscan.
Resumes generated with --jd mode — which extracts required and preferred keywords from the JD and rebuilds the ATS keyword list and headline — consistently scored higher on the same tool, generally in the 75–90 range for roles that matched the candidate's actual background.
The gap is expected: --jd mode explicitly targets the JD's terminology, while generic resumes use role-level positioning not tuned to a specific posting.

Time per application:

Manual tailoring (editing bullets, rewriting summary, updating keywords for each posting): 20–40 minutes.
VitaeForge --jd mode (one command, confirmation prompt, PDF output): under 2 minutes for a cached profile, slightly longer on first run depending on model response time.

What the score actually measures: VitaeForge's ATS score is the AI model's estimate of keyword overlap and alignment — not a Jobscan score, not access to any real ATS. It is a relative signal, useful for comparing two tailored versions of the same CV, not an absolute guarantee of ATS pass rate.

5.2 Personal Context

VitaeForge was built to solve a problem I was actively experiencing: my resume consistently scored below 60 on Jobscan for roles where I met the stated requirements. The gap was keyword terminology — I described my experience in general engineering language while job descriptions used stack-specific vocabulary (e.g., "Apache Airflow" vs "workflow orchestration", "Terraform" vs "infrastructure as code").

Building the tool changed how I approach applications:

Targeted submissions: I now check the ATS score before submitting. If the gap between my profile and the JD is large on missing keywords I genuinely have, --jd mode closes most of it automatically.
Faster iteration: What used to take 30 minutes per application (manual rewriting) now takes under 2 minutes, leaving time to write a better cover letter or research the company.
Single source of truth: All career data lives in cv.yaml. I edit once; every role variant regenerates from the same facts. No more copy-paste divergence between CV versions.

"The problem wasn't my qualifications — it was that my resume spoke human and the ATS was listening for keywords."

This is a v1.0 tool. Broader empirical validation — tracking application outcomes across a larger sample, comparing ATS platforms, measuring interview conversion rates — is planned as the project matures and data accumulates.

6. Technical Challenges and Solutions

This section documents the real challenges encountered during development and the solutions actually implemented in the codebase.

6.1 AI Hallucination Control

Challenge: Language models occasionally invented non-existent skills, extended employment dates beyond what cv.yaml contained, or added achievements with no basis in the source data.

Solution: Strict constraint prompts with explicit "DO NOT" clauses and mandatory source anchoring. Every prompt that generates experience content includes:

# Actual constraint pattern used throughout use_cases/
CONSTRAINTS = """
CONSTRAINTS:
- Use ONLY information contained in the provided CV data
- Do NOT invent skills, dates, companies, or metrics not present in the source
- Do NOT add achievements not supported by the input
- Return ONLY valid JSON — no explanation, no markdown wrapper
"""

Verification: Human review before accepting generated output. The --jd mode shows the ATS score and asks for confirmation before writing the PDF. The --edit mode shows a YAML preview before writing to cv.yaml. Both gates ensure a human sees the AI output before it becomes permanent.

6.2 ATS Formatting — Delegated to rendercv

Challenge: Resume formatting is one of the most common ATS failure points. Tables, multi-column layouts, embedded graphics, and non-standard fonts cause parsing errors in many ATS platforms.

Solution: VitaeForge does not generate PDF directly. It produces a structured YAML file consumed by rendercv, which handles Typst-based PDF generation with ATS-compatible output. This delegation means VitaeForge inherits rendercv's formatting guarantees without reimplementing them.

The cv_generator.py application layer maps domain objects to rendercv's YAML schema. The only formatting decision VitaeForge makes is content selection and ordering — not layout rendering.

6.3 Domain-Infrastructure Decoupling

Challenge: AI providers change APIs, pricing, and availability. Hardcoding any provider into domain logic would make the system brittle and expensive to maintain.

Solution: The AIPort abstract interface in src/domain/ports/ defines a single method: complete(prompt, system) -> str. Every use case depends only on this port. The concrete adapter (OpenAI, Anthropic, Google, Ollama) is resolved at startup by the factory and injected — the domain never imports any provider SDK.

This was validated in practice: switching the default model from gpt-4o-mini to groq-llama or gemini-flash requires only a .env change, with no code modification.

6.4 Multilingual Consistency

Challenge: Generating CV content in both English and Spanish from the same cv.yaml source requires consistent terminology and register across languages, particularly for technical terms.

Solution: The LocalizedString value object is the core data primitive — every user-visible string in the domain carries both en and es variants. AI generation prompts include the target language explicitly. Technical terms (stack names, tool names) are passed through unchanged since they don't translate (e.g., "Python", "Docker", "AWS" remain the same in both languages).

Human review remains the final quality gate — the author reviews both language outputs before submitting any application.

6.5 CAR Format Compliance

Challenge: Getting consistent Challenge-Action-Result format across all generated experience bullets, especially when the source material (cv.yaml bullets) is written in plain descriptive language.

Solution: The ExperienceEnricher use case uses a structured prompt that explicitly defines the CAR format and requires JSON output with separate challenge, action, and result fields. The application layer assembles these into a single coherent bullet. This forces the model to decompose the experience before composing the output, which produces more consistent results than asking for a free-form CAR bullet in one shot.

The --edit mode's "Review bullets" option (option 9) applies this same enrichment interactively, showing original and improved versions side-by-side for human acceptance.

7. Next Steps

This is v1.0. No formal roadmap exists. Two concrete improvements are planned.

7.1 Docker Image

Problem: Setup requires pyenv, Python 3.12, a virtualenv, pip install, and a .env file. That is five steps before running a single command.

Goal: One docker run that mounts cv.yaml, a JD file, and a .env, and produces a PDF.

# Target workflow
docker run --rm \
  -v $(pwd)/people:/app/people \
  -v $(pwd)/jobs:/app/jobs \
  -v $(pwd)/generated:/app/generated \
  --env-file .env \
  csotelo/vitaeforge --jd /app/jobs/my_jd.txt --lang en

What this enables:

No local Python setup required
Run on any machine or CI pipeline
Consistent environment — no version mismatches
Easier to share with non-technical users

The hexagonal architecture makes this straightforward. There are no database connections, no persistent state, and no background services. The container reads files, calls an AI API, and writes a PDF.

7.2 JD Scraping with Playwright

Problem: --jd currently accepts a local text file or a URL that returns plain text. Most real job postings are JavaScript-rendered pages (LinkedIn, Indeed, Greenhouse). Copy-pasting the JD manually is the current workaround.

Goal: Pass a job posting URL directly. VitaeForge fetches and extracts the description automatically.

# Current — manual copy-paste required
vitaeforge --jd jobs/my_jd.txt --lang en

# Planned — URL passed directly
vitaeforge --jd https://linkedin.com/jobs/view/12345 --lang en

How it fits the architecture: The --jd input is already abstracted in the CLI layer. A Playwright-based scraper would be a new infrastructure adapter — a JDFetcherPort in the domain, with a PlaywrightAdapter in infrastructure. The rest of the pipeline (JD analysis, ATS scoring, enrichment, PDF generation) stays unchanged.

Key constraints for this feature:

Respect robots.txt and platform terms of service
Fallback gracefully if a page cannot be scraped (prompt user to paste manually)
Keep Playwright as an optional dependency — users who don't need scraping should not be required to install a browser

No timeline. No code written yet.

8. Conclusion

8.1 What VitaeForge Does

VitaeForge is a CLI tool. It takes a CV data file and a job description. It returns a tailored PDF with an ATS score and CAR-formatted bullets. It runs in under 2 minutes. It is open-source.

The core contributions of this v1.0 release:

Contribution	Description
Hexagonal architecture for AI tools	Domain logic is fully isolated from AI providers. Swap models via `.env`.
Prompt-based ATS scoring	No local NLP. The AI estimates keyword gaps and generates tailored output in one call.
CAR bullet generation	Structured JSON prompt forces decomposition before composition. Consistent results.
cv.yaml as single source of truth	One file. Multiple role variants. Bilingual output. Hash-based caching.
ATDD methodology for solo AI development	Role-specific prompt sessions with explicit constraints. Documented and repeatable.

8.2 Key Takeaways

ATS filters 75% of resumes before a human reads them. The fix is keyword alignment and CAR formatting — not rewriting your career.
Prompt engineering matters more than model selection. Constraints beat creativity.
Hexagonal architecture pays off immediately when you need to swap AI providers.
Human review is not optional. Always read what the AI generates before it goes on your CV.
v1.0 is a working tool used in real job searches. It is not a prototype.

8.3 Try It

For job seekers: Copy a job description to a text file. Run vitaeforge --jd jobs/my_jd.txt --lang en. Check the ATS score. Submit the applications that score above 75.

For developers: Fork it. Add a provider adapter in 20 lines. Build a new theme. The architecture is designed for extension without modifying existing code.

"If ATS is the gatekeeper, VitaeForge is the key. Try it, fork it, or build on it — just don’t let algorithms decide your career."

🔗 GitHub: github.com/csotelo/vitaeforge

Appendix

A. ATS Statistics

Statistic	Source
75% of resumes are rejected by ATS	Jobscan
98% of Fortune 500 companies use ATS	Capterra
CVs with CAR format have 38% higher ATS pass rates	The Muse

B. License (MIT)

VitaeForge is licensed under the MIT License. Full text in LICENSE.

C. CLI Quick Reference

# Install
git clone https://github.com/csotelo/vitaeforge
cd vitaeforge
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt && pip install -e .
cp .env.example .env   # add your API key

# Mode 1 — Generic CV by role
vitaeforge --role data_engineer__python_aws --lang en
vitaeforge --role software_engineer__python_django_fastapi_aws --lang es
vitaeforge --role data_engineer__python_aws --lang en --refresh   # force AI regen

# Mode 2 — Job-specific CV from a JD file
vitaeforge --jd jobs/my_jd.txt --lang en
vitaeforge --jd jobs/my_jd.txt --lang en --model gemini-flash --auto

# Interactive CV editor
vitaeforge --edit
vitaeforge --edit --person jane_doe --model gpt-4o-mini

# Scaffold a new person
vitaeforge --create-person jane_doe

All options:

Flag	Description
`--role ROLE`	Generate generic CV for a stored profile
`--jd FILE`	Generate job-specific CV from a JD text file
`--lang {en,es}`	Output language
`--person NAME`	Person folder under `people/`
`--model MODEL`	AI model alias (overrides `VITAEFORGE_MODEL`)
`--theme THEME`	Theme override (`harmony`, `moderncv`, `globant`)
`--refresh`	Force AI profile regeneration (ignores hash cache)
`--auto`	Skip confirmation prompt
`--edit`	Open interactive CV editor
`--create-person NAME`	Scaffold a new person directory

Available model aliases:

Alias	Provider	Free tier
`gpt-4o-mini`	OpenAI	No
`gpt-4o`	OpenAI	No
`claude-haiku`	Anthropic	No
`claude-sonnet`	Anthropic	No
`claude-opus`	Anthropic	No
`gemini-flash`	Google	Yes
`gemini-pro`	Google	No
`groq-llama`	Groq	Yes
`groq-mixtral`	Groq	Yes
`ollama-llama3`	Ollama (local)	Yes
`ollama-mistral`	Ollama (local)	Yes

D. Tools and Frameworks Used

Tool	Role in VitaeForge	Link
rendercv	PDF rendering engine — converts YAML to Typst PDF	github.com/sinaatalay/rendercv
Pydantic v2	Domain model validation and serialization	docs.pydantic.dev
Typer	CLI framework	typer.tiangolo.com
PyYAML	YAML read/write for `cv.yaml` and profiles	pyyaml.org
pytest	Unit and integration testing (68 tests)	pytest.org
Jobscan	ATS score validation during personal use	jobscan.co
Claude Code	Primary development environment	claude.ai/code
OpenCode Zen	Secondary development tool (BigPickle, Nemotron 2)	opencode.ai

E. Key References

Reference	Relevance
Cockburn, A. — Hexagonal Architecture	Architectural pattern used in VitaeForge
ATDD by Example — Gärtner, M.	ATDD methodology and Gherkin specification
Harvard OCS Resume Guide	Resume terminology and CAR format guidance
The Muse — How to Write Resume Bullet Points	CAR format +38% ATS pass rate source
Jobscan — ATS Statistics	75% rejection rate source
Capterra — What is an ATS?	98% Fortune 500 usage source
The Ladders — Eye Tracking Study	7-second recruiter review source
csotelo — LangGraph + ATDD Pipeline	Prior article: multi-agent ATDD methodology

Building a Multi-Agent ATDD Pipeline with Hexagonal Architecture

Carlos Eduardo Sotelo Pinto — Mon, 06 Apr 2026 20:30:48 +0000

Building a Multi-Agent ATDD Pipeline with Hexagonal Architecture

Write the spec, mark the story as ready, walk away. The agents do the rest.

The problem with solo AI development

Building a product solo is brutal.

You are the PO, the architect, the developer, and the QA — all at the same time. When AI coding agents entered the picture, I didn't see a magic button. I saw a new kind of team member that needed the same thing any team member needs: clear responsibilities, short tasks, and a verifiable definition of done.

The first thing I tried was the obvious approach: long prompts, one agent, do everything. It failed the way it always fails. The model drifted, lost context, and confidently built the wrong thing.

Then I applied something I already knew from software architecture:

Divide and conquer.

If a long prompt fails, what about a very short one with a very specific context? What if instead of one agent doing everything, you had multiple agents — each with a single role, a precise skill, and just enough context to do their job?

That question led me to build an ATDD orchestrator: a pipeline of specialized AI agents, coordinated by a state machine, that takes a user story from spec to acceptance without human intervention in the technical stages.

In this article I'll walk through the architecture, the design decisions, and — the main focus — how hexagonal architecture made it possible to support two completely different execution engines behind a single port, without touching the domain or the use cases.

What is ATDD and why does it fit AI agents perfectly?

Acceptance Test Driven Development says: write acceptance criteria first, then build until they pass. The acceptance criteria — written as Gherkin scenarios — are the only real definition of done.

This maps naturally to a multi-agent pipeline:

Architect (human + Claude): define the spec, write the acceptance criteria, refine user stories
Test engineer (autonomous): write unit and integration tests in RED — before any implementation
Developer (autonomous): make the RED tests pass — and only that
Tester (autonomous): quality gate — regressions, ruff, mypy
ATF worker (autonomous): run the Gherkin acceptance scenarios with Playwright + Behave

Each role has a single responsibility. Each transition is triggered by a status change in a file. No agent can skip a stage or self-certify completion.

story.md → status: inbox
              │
              ▼
        test_engineer  → tests in RED
              │
              ▼
          developer    → tests GREEN
              │
              ▼
            tester     → quality gate
              │
              ▼
          atf_worker   → acceptance scenarios pass
              │
              ▼
        status: done  ✓

The spec is the contract. The Gherkin scenario is the verdict.

The architecture: hexagonal all the way down

The orchestrator follows strict hexagonal architecture (ports and adapters):

domain          — pure Python, no external dependencies
application     — imports domain only (use cases)
infrastructure  — adapters only: Celery, LangGraph, git, frontmatter, opencode
__main__.py     — entry point, wires everything together

The domain defines four ports (interfaces):

class StoryRepository(ABC):
    def get(self, story_id: str) -> Story: ...
    def save_status(self, story_id: str, status: Status, note: str = "") -> None: ...
    def find_by_status(self, status: Status) -> list[str]: ...

class CodeRunner(ABC):
    def run(self, role: str, prompt: str) -> None: ...

class TaskQueue(ABC):
    """Inter-worker queue — used internally by the Celery engine."""
    def enqueue(self, task_name: str, story_id: str) -> None: ...

class PipelineExecutor(ABC):
    """Starts the full pipeline for a story in INBOX.
    Each engine (Celery, LangGraph) provides its own implementation.
    """
    def submit(self, story_id: str) -> None: ...

Each use case depends only on these ports. For example, RunDeveloper:

class RunDeveloper:
    def __init__(self, story_repo, runner, queue): ...

    def execute(self, story_id: str) -> None:
        try:
            self._runner.run("developer", _PROMPT.format(story_id=story_id))
            self._repo.save_status(story_id, Status.READY_TO_TEST)
            self._queue.enqueue("run_tester", story_id)
        except Exception as exc:
            self._repo.save_status(story_id, Status.BLOCKED, note=str(exc))
            raise

Notice: the use case doesn't know what CodeRunner is (subprocess? API call? mock?), what StoryRepository stores to (files? database?), or how TaskQueue delivers the next task (Celery? Redis? LangGraph?).

This is the key. The infrastructure is replaceable without touching the domain.

The entry point: `main.py`

In hexagonal architecture, the entry point is a driver — it wires the application together and starts the loop. It doesn't belong in infrastructure/, it belongs at the root of the package.

python -m atdd_orchestrator runs __main__.py:

def _make_executor(project_path: str) -> PipelineExecutor:
    if PIPELINE_ENGINE == "langgraph":
        from atdd_orchestrator.infrastructure.langgraph.pipeline_executor import (
            LangGraphPipelineExecutor,
        )
        return LangGraphPipelineExecutor(project_path)

    from atdd_orchestrator.infrastructure.celery.pipeline_executor import (
        CeleryPipelineExecutor,
    )
    return CeleryPipelineExecutor(project_path)


def _process_project(project_path: str) -> None:
    git_adapter.configure(project_path)
    git_adapter.pull(project_path)

    repo     = FrontmatterStoryRepository(project_path)
    executor = _make_executor(project_path)
    DispatchStories(repo, executor).execute()

    if git_adapter.has_changes(project_path):
        git_adapter.commit_and_push(project_path)

__main__.py depends on the PipelineExecutor port — it never imports Celery or LangGraph directly. The engine is a deployment detail selected by PIPELINE_ENGINE env var.

The git operations (pull, commit, push) live in infrastructure/git_adapter.py — a pure adapter with no business logic. The orchestration loop lives in __main__.py — where it belongs.

The production engine: Celery + Redis

The production implementation uses Celery with Redis as the broker. Each role has a dedicated queue and runs in its own isolated container.

# infrastructure/celery/pipeline_executor.py
class CeleryPipelineExecutor(PipelineExecutor):
    def submit(self, story_id: str) -> None:
        app.send_task("run_test_engineer",
                      args=[self._project_path, story_id],
                      queue="inbox")

# infrastructure/celery/tasks.py
@app.task(name="run_developer", queue="ready-to-dev")
def task_developer(self, project_path: str, story_id: str) -> None:
    repo, runner, queue, notifier = _deps(project_path)
    RunDeveloper(repo, runner, queue).execute(story_id)

docker compose up
  ├── redis             ← message broker
  ├── git-sync          ← python -m atdd_orchestrator (polls, dispatches)
  ├── test-engineer     ← celery worker --queues=inbox
  ├── developer         ← celery worker --queues=ready-to-dev
  ├── tester            ← celery worker --queues=ready-to-test
  └── atf-worker        ← celery worker --queues=ready-to-atf

Each role runs in its own isolated container. A slow story blocks only one worker. If a container crashes, Redis preserves the message — the worker retries when it comes back. Multiple stories and projects advance in parallel.

This is the right engine for production: resilient, isolated, horizontally scalable.

The local development engine: LangGraph

LangGraph is a library for building stateful, graph-based workflows. You define nodes (work units) and edges (transitions), compile the graph, and invoke it with an initial state.

For local development — one project, no Redis, no Docker — LangGraph is the simpler alternative.

State

class PipelineState(TypedDict):
    story_id: str
    project_path: str
    status: Status
    blocked_reason: Optional[str]
    dev_retries: int  # prevents infinite loops on repeated failures

Nodes

Each node calls the existing use case with a GraphRoutedQueue instead of a real queue adapter. The graph handles routing — the use cases don't need to know what comes next.

class GraphRoutedQueue(TaskQueue):
    """The use cases call queue.enqueue() as a side effect.
    In LangGraph, that call is intentionally ignored —
    the graph decides the next node by reading the story status.
    """
    def enqueue(self, task_name: str, story_id: str) -> None:
        pass

After executing the use case, the node reads the current status from the repository (the use case already persisted it) and returns the updated state:

def developer_node(state: PipelineState) -> PipelineState:
    repo, runner, notifier, queue = _deps(state["project_path"])
    try:
        RunDeveloper(repo, runner, queue).execute(state["story_id"])
    except Exception:
        pass  # use case already saved BLOCKED to the repo

    status, reason = _read_status(state["project_path"], state["story_id"])
    return {**state, "status": status, "blocked_reason": reason}

Graph with conditional edges

The state machine that is implicit in Celery (queue names, routing keys, scattered enqueue calls) becomes explicit Python code:

def _route_after_tester(state: PipelineState) -> str:
    if state["status"] == Status.READY_TO_ATF:
        return "atf"
    if state["status"] == Status.READY_TO_DEV:
        if state["dev_retries"] < MAX_DEV_RETRIES:
            return "developer"   # quality gate failed → retry
    return END                   # blocked or retries exhausted

def build_pipeline():
    g = StateGraph(PipelineState)
    g.add_node("test_engineer", test_engineer_node)
    g.add_node("developer",     developer_node)
    g.add_node("tester",        tester_node)
    g.add_node("atf",           atf_node)
    g.set_entry_point("test_engineer")
    g.add_conditional_edges("tester", _route_after_tester,
        {"atf": "atf", "developer": "developer", END: END})
    # ... other edges
    return g.compile()

The retry logic, the blocking conditions, the terminal states — all visible, all in one place.

LangGraph executor

# infrastructure/langgraph/pipeline_executor.py
class LangGraphPipelineExecutor(PipelineExecutor):
    def __init__(self, project_path: str) -> None:
        self._project_path = project_path
        self._pipeline = build_pipeline()

    def submit(self, story_id: str) -> None:
        self._pipeline.invoke({
            "story_id": story_id,
            "project_path": self._project_path,
            "status": Status.INBOX,
            "blocked_reason": None,
            "dev_retries": 0,
        })

No broker, no worker containers:

PIPELINE_ENGINE=langgraph python -m atdd_orchestrator

The design decisions worth discussing

Why is the state stored in files, not a database?

Each user story's state lives in a story.md file with YAML frontmatter:

---
id: US04
title: User can reset their password
status: in-progress:ready-to-test
sprint: sprint_02
---

Keeping state in the repository means:

Any agent, any tool, any human can read and update it with a text editor
The state survives restarts with no migration
Git history shows every state transition
The orchestrator doesn't own the state — the project does

Why is the Architect role never automated?

The architect (human + Claude) defines scope, acceptance criteria, and what the story means. That judgment stays human-controlled.

Automating that step is how you end up building the wrong thing perfectly. The spec is the contract — someone has to own it.

Why Celery for production and LangGraph for local development?

Celery runs each role in its own isolated container. If the tester container is slow, developer keeps working. If a container crashes, Redis holds the message — the worker picks it up when it restarts. Multiple stories across multiple projects advance simultaneously.

LangGraph runs the full pipeline in a single process. One slow story blocks the orchestrator for everything else. A mid-pipeline crash leaves the story in an intermediate state with no resume mechanism.

LangGraph is the right choice when you want to debug a single story locally without standing up the full Docker stack. Celery is the right choice when you're running multiple projects autonomously and you need the system to recover without you.

Both share the same domain and the same use cases. The engine is only an infrastructure choice.

The GraphRoutedQueue pattern

The use cases call self._queue.enqueue("run_tester", story_id) as a side effect of their execution. In the LangGraph world, that call is meaningless — the graph reads the story status and decides the next node.

Rather than modifying the use cases (which would break the Celery flow), LangGraph nodes pass a GraphRoutedQueue that absorbs enqueue calls silently. The use case's core behavior — running the agent, saving the status, raising on failure — is unchanged. Only the routing side effect is suppressed.

This is dependency injection doing exactly what it's supposed to do.

What I tested on a real project

The first project running through this pipeline is atf-ai — a CLI tool with Playwright-based acceptance tests. Five user stories, end-to-end:

Story	Status
US01 — Scaffolding CLI	`damaged` (1 failing scenario, known issue)
US02 — Docker Runner	`accepted` ✓
US03 — Screenplay Actors & Steps	`accepted` ✓
US04 — Feedback & State Tracking	`accepted` ✓
US05 — Reports Pipeline & PyPI	`accepted` ✓

Four out of five stories went from inbox to done autonomously. The fifth is blocked on a known state mismatch that requires architectural review — exactly the kind of thing that should block, not silently pass.

What's next

LangGraph checkpointing — persist graph state to disk so a local pipeline can resume after a crash without re-running completed stages
Observability — emit structured events at each node transition for unified tracing across both engines
Self-healing architect — when a story is blocked, trigger a Claude session to diagnose and propose a fix
Dynamic worker scaling — scale Celery workers per queue based on backlog depth

Repository

The full source is open:

github.com/csotelo/atdd-framework

atdd_orchestrator/
├── __main__.py      # entry point — python -m atdd_orchestrator
├── domain/          # Story, Status, ports — pure Python
├── application/     # use cases — depend only on domain
└── infrastructure/
    ├── git_adapter.py            # pure git adapter
    ├── celery/
    │   ├── pipeline_executor.py  # PipelineExecutor → send_task (production)
    │   ├── queue_adapter.py      # TaskQueue → inter-worker enqueue
    │   └── tasks.py              # thin Celery tasks → use cases
    └── langgraph/
        ├── pipeline_executor.py  # PipelineExecutor → graph.invoke (local dev)
        ├── nodes.py              # nodes → use cases (GraphRoutedQueue)
        └── graph.py              # StateGraph with conditional edges + retry logic

35 tests, 0 failures. No Redis, no OpenCode, no network required to run the test suite — all ports are stubbed.

Final thought

The thing that surprised me most about this project wasn't the AI part. It was how much the design decisions at the domain level determined what was possible later.

PipelineExecutor is a four-line abstract class. But because it exists, you can swap the execution engine with an env var, test the entire orchestration logic without Redis or Docker, and reason about Celery and LangGraph as implementation details rather than architectural constraints.

The entry point lives in __main__.py — not buried in infrastructure/. The git adapter lives in infrastructure/git_adapter.py — a pure adapter with no business logic. Every file is in the layer where it belongs.

If you're building multi-agent pipelines: get the ports right first. Put things in the right layer. The implementations will follow.

Questions, issues, or contributions: github.com/csotelo/atdd-framework

Crafting code crafting mead: Un Viaje de Paciencia y Bugs

Carlos Eduardo Sotelo Pinto — Fri, 30 Jan 2026 17:32:59 +0000

Soy Python Developer y mi vida profesional ha girado siempre en torno a la ingeniería de datos y el desarrollo de software. Sin embargo, hace cuatro años, mi curiosidad me llevó a un mundo que, a primera vista, parecía opuesto a la lógica binaria: empecé a producir hidromiel. Lo que no sabía entonces es que hacer código y fermentar miel tienen una relación mucho más estrecha de lo que cualquier manual técnico podría explicar.

Mis Inicios: Del "C" Duro a la Reflexión Activa

Recuerdo claramente cuando empecé a programar. Sentía una mezcla de fascinación y frustración. Podía pasar horas frente al ordenador, viendo cómo cada línea generaba un resultado... o un error. Han pasado más de 30 años desde mi primer programa "real": un simulador de carreras de autos en la universidad, escrito en lenguaje C.

Era un código muy ortodoxo, "duro y feo" como dirían muchos ahora, pero era mío. Hacer código en ese entonces no implicaba pruebas de integración ni pipelines de CI/CD; era compilar, rezar, corregir el error y volver a compilar. Cuando finalmente funcionó y pude presentarlo en el curso de computación gráfica, la sensación de logro fue indescriptible.

Con el tiempo, el mercado laboral me dio un golpe de realidad. Yo, que me creía un buen programador en Visual Basic, me topé con "monstruos" del código que me bajaron de mi nube. Aprendí que la vida del desarrollador es un flujo constante de retroalimentación.

Muchos dirán que sentarse a escribir líneas es aburrido, pero para mí, hacer código es un momento de reflexión activa. Es dejar rienda suelta al cerebro para que fluyan las ideas. Si la música es el lenguaje del alma, el código es el lenguaje de la mente capaz de tangibilizar las ideas: si puedes imaginarlo, puedes programarlo.

La Alquimia de la Fermentación: El "Deploy" Orgánico

Cuando empecé a hacer hidromiel, encontré ese mismo "flow". Ver a las levaduras moverse en el mosto era como ver los logs de un servidor en tiempo real. Usé una botella de 20 litros, agua, miel y... sí, levadura de pan (mi versión de "código legacy").

Conecté una manguera a una botella con agua para liberar el CO2 y ahí estaba ese sonido maravilloso: clock... clock... clock. Era el ritmo del proceso, similar al cursor parpadeando esperando tu próximo comando.

Pero al igual que en el software, tras el "desarrollo" (fermentación), venía la "refactorización" (maduración). Esperar semanas, maduración en frío... y de pronto, ahí estaba: el néctar de los dioses. Probablemente, si hoy probara esa primera tanda, diría "¿qué diablos es esto?" (igual que cuando reviso mi código de hace 5 años), pero en ese momento fue éxtasis puro.

El "Code Review" en la Feria de Hidromieleros

Mi momento de humildad llegó en una feria con otros hidromieleros. Fue como mi primer Code Review serio.
Llevé mi producto sintiéndome orgulloso, pero al probar las creaciones de mis colegas, me di cuenta de que mi "código" necesitaba optimización:

Adolfo de Cacique: Me hablaba de su hidromiel con chispas de roble. Yo, amante de las bebidas secas, solo pude pensar: "Wow, estoy en nada". Su nivel de detalle era como usar una librería avanzada que yo desconocía.
Augusto de Heimdal: Me mostró innovaciones de menta y café. Mi cerebro explotó. Fue la inspiración para luego intentar mi propia mezcla (un fork de su idea, si se quiere).
Skall: Sus sabores sutiles eran como un código limpio (Clean Code), elegante y eficiente, podías beberla una y otra vez.
Ancestro: Sus estilos buscando la receta legendaria, compilando las recetas como lo hacian los guerreros vikingos generando codigo legacy.
La Vikinga: Su hidromiel de flores de jamaica tenía un perfil semidulce que empapó mis papilas gustativas, una experiencia de usuario (UX) impecable.
El Maestro Fernando de Ragnarok: Simplemente, una explosión de sabores que no podía comprender. Era como leer el código fuente de un arquitecto principal y no entender cómo logró tal eficiencia.

Mi conclusión fue clara: no estaba a la altura de estos maestros. Tocaba volver al IDE (o al fermentador), iterar, probar y errar.

Conclusión: Crafting Code, Crafting Mead

He pasado por muchas dudas existenciales, desde si debería ser Project Manager o seguir como Python Developer, hasta si debería dejar la hidromiel. Pero disfruto demasiado el proceso. Como dijo Adolfo Galindo de Cacique: "No sabes las maravillas que hace el tiempo en la hidromiel".

Es cierto. Al igual que al hacer código, en la hidromiel no hay una regla única. Solo es imaginarlo. Si puedes imaginarlo, puedes fermentarlo. Ambos oficios requieren paciencia, conocimiento y una tolerancia alta al fracaso inicial.

Conclusión: Paciencia y Pasión

Definitivamente, hacer código o hacer hidromiel requieren paciencia y conocimiento. No hay una regla estricta, solo la imaginación y la disciplina para iterar hasta que el resultado sea elegante, limpio y funcional (o delicioso).

Crafting code, crafting mead.

Un dato curioso de mi vida para cerrar:

Mi hijo mayor nació el 13 de septiembre, el Día del Programador.
Mi hija menor nació el 20 de febrero, aniversario del lanzamiento de Python.
Mi marca de hidromiel se llama "Ojo Negro", en honor a mi abuelito con quien me crié.

Parece que el destino ya tenía el código escrito.

Django vs. FastAPI o Django + FastAPI 2026: ¿Por qué elegir si puedes tener ambos?

Carlos Eduardo Sotelo Pinto — Mon, 26 Jan 2026 00:00:00 +0000

La evolución del desarrollo web con Python ha alcanzado un punto de inflexión crítico en 2026. Durante décadas, la comunidad se ha debatido entre la exhaustividad de los marcos de trabajo monolíticos y la agilidad de los micro-frameworks. Sin embargo, la madurez de la computación en la nube, el auge de la inteligencia artificial y la consolidación de las arquitecturas de microservicios han transformado este debate en una búsqueda de sinergias. Django, el gigante de "baterías incluidas", y FastAPI, el líder de la velocidad asíncrona, ya no se perciben como herramientas mutuamente excluyentes, sino como componentes complementarios de una arquitectura moderna de alto nivel.

El estado del arte de Python Web en 2026

En el panorama tecnológico actual, Python se ha consolidado no solo como el lenguaje predilecto para la ciencia de datos, sino como el motor fundamental detrás de las API que alimentan modelos de lenguaje de gran escala (LLM) y sistemas distribuidos masivos. El lanzamiento de Python 3.12, 3.13 y la reciente 3.14 ha traído mejoras significativas en el rendimiento del intérprete y en el manejo de la concurrencia, permitiendo que marcos como Django y FastAPI operen en niveles de eficiencia que anteriormente solo se asociaban con lenguajes compilados como Go o Rust.

Django ha respondido a este cambio generacional con su versión 6.0, una actualización que redefine su identidad al integrar capacidades asíncronas profundas y un sistema de tareas nativo que reduce la dependencia de infraestructuras externas complejas.1 Por su parte, FastAPI ha capitalizado la adopción total de Pydantic v2, cuya implementación de núcleo en Rust permite validaciones de datos con una latencia casi nula, convirtiéndolo en el estándar de facto para servicios perimetrales donde cada milisegundo cuenta.

Comparativa filosófica y técnica inicial

Para comprender la propuesta de valor de 2026, es necesario desglosar las diferencias fundamentales que rigen a ambos frameworks. Mientras que Django se basa en el principio de "Convención sobre Configuración", buscando la productividad a través de decisiones preestablecidas y seguras, FastAPI se apoya en la "Explicitud y Tipado", permitiendo que el desarrollador componga su stack con libertad total bajo un contrato de datos riguroso.

Criterio	Django 6.0	FastAPI 2026
Filosofía Principal	Baterías incluidas y monolito robusto	API-first, asíncrono y modular
Rendimiento (RPS)	Moderado-Alto (Optimizado en 6.0)	Muy Alto (Líder en Python)
Validación de Datos	Django Forms / Serializers (DRF)	Pydantic v2 (Basado en Rust)
Gestión de Base de Datos	Django ORM (Síncrono/Asíncrono)	SQLModel, SQLAlchemy, Tortoise
Documentación	Manual o vía DRF Spectacular	Automática (OpenAPI/Swagger/ReDoc)
Curva de Aprendizaje	Moderada (Ecosistema extenso)	Baja (Pythonic moderno)

Esta distinción no es solo teórica; impacta directamente en el ciclo de vida de los proyectos. Las empresas que buscan estabilidad a largo plazo y una gestión administrativa interna sin fricciones gravitan hacia Django, mientras que aquellas que desarrollan infraestructuras de microservicios para IA o aplicaciones de tiempo real eligen FastAPI por su capacidad de escalado horizontal y mínima huella de memoria.

El renacimiento de Django 6.0: Más allá del monolito

Django 6.0 representa el mayor salto evolutivo en la historia reciente del framework. Lejos de quedar obsoleto, ha sabido absorber las demandas del mercado para ofrecer una experiencia de desarrollo que equilibra su tradicional robustez con las necesidades de asincronismo moderno. La introducción de un sistema de tareas nativo y mejoras en el stack asíncrono posicionan a Django como el centro de control ideal para aplicaciones complejas.

El nuevo marco de tareas en segundo plano (Django Tasks)

Históricamente, cualquier desarrollador de Django que necesitara enviar un correo electrónico sin bloquear la solicitud del usuario o procesar una imagen pesada debía recurrir a Celery o Redis Queue (RQ). Estas herramientas, aunque potentes, añadían una capa de complejidad operativa significativa. Django 6.0 soluciona esto con su módulo django.tasks, que proporciona una API estandarizada para definir y encolar trabajos fuera del ciclo de solicitud-respuesta.

Este marco no es simplemente una envoltura para hilos; es una abstracción completa que permite intercambiar backends según la necesidad. Por defecto, incluye un ImmediateBackend para desarrollo y pruebas, pero se puede configurar fácilmente con un DatabaseBackend para aplicaciones que requieren persistencia de tareas sin infraestructura adicional.

# Ejemplo de tarea nativa en Django 6.0
from django.tasks import task
from django.core.mail import send_mail

@task(priority=10, queue_name="emails")
def enviar_bienvenida_async(email_usuario, nombre):
    send_mail(
        subject=f"Bienvenido {nombre}",
        message="Gracias por unirte a nuestra plataforma.",
        from_email="noreply@empresa.com",
        recipient_list=[email_usuario]
    )

La relevancia de esta característica radica en su integración con el sistema de transacciones de la base de datos. Se puede asegurar que una tarea solo se encole si la transacción principal se confirma exitosamente, evitando inconsistencias donde un usuario recibe un correo de bienvenida aunque su registro haya fallado en la base de datos.

Seguridad nativa: Content Security Policy (CSP)

En 2026, la seguridad web es más crítica que nunca debido a la sofisticación de los ataques de inyección de código. Django 6.0 ha dado un paso al frente integrando soporte nativo para la Política de Seguridad de Contenido (CSP). A diferencia de versiones anteriores donde se dependía de middleware externo, ahora el núcleo de Django permite configurar y aplicar estas políticas de manera granular a través de diccionarios en los ajustes del proyecto.

Esta protección ayuda a mitigar ataques de Cross-Site Scripting (XSS) y Clickjacking al restringir qué recursos (scripts, estilos, imágenes) puede cargar el navegador y desde qué orígenes. La implementación soporta el uso de "nonces" (números de un solo uso), lo que permite habilitar scripts específicos en línea de forma segura sin debilitar la política global.

Componente CSP	Función en Django 6.0	Impacto en la Seguridad
SECURE_CSP	Define la política estricta aplicada	Bloquea recursos no autorizados
SECURE_CSP_REPORT_ONLY	Modo de prueba para políticas	Reporta violaciones sin bloquearlas
CSP_NONCE	Context processor para templates	Permite scripts inline verificados

Mejoras en el soporte asíncrono y ORM

Aunque Django nació en una era síncrona, su transición a ASGI ha culminado en la versión 6.0 con un soporte asíncrono mucho más robusto. El ORM ahora incluye variantes asíncronas para la mayoría de sus métodos de consulta, prefijados con a (como aget(), acreate(), aupdate()), permitiendo que las vistas asíncronas interactúen con la base de datos sin bloquear el bucle de eventos. Además, se han introducido herramientas como AsyncPaginator y AsyncPage para manejar grandes conjuntos de datos de forma no bloqueante, lo cual es esencial para dashboards de alto tráfico.

FastAPI: La velocidad de la luz en la capa de servicios

Si Django es la fortaleza, FastAPI es el interceptor. En 2026, FastAPI se mantiene como el framework de mayor crecimiento en el ecosistema Python, impulsado por su diseño centrado en el rendimiento y la experiencia del desarrollador (DX). Su capacidad para manejar miles de peticiones simultáneas con una latencia mínima lo hace imbatible en escenarios de microservicios y despliegues serverless.

La revolución de Pydantic v2 y Rust

El corazón de FastAPI en 2026 es Pydantic v2. Al mover la lógica de validación de datos a un núcleo escrito en Rust, Pydantic ha eliminado el "impuesto de Python" en el procesamiento de JSON. Para un arquitecto, esto se traduce en una reducción drástica de los costos de computación y una mejora en la densidad de solicitudes por servidor.

Los benchmarks de 2025 y 2026 muestran que FastAPI, gracias a esta integración, compite directamente con Node.js y Go en tareas de I/O bound. La validación de tipos no solo mejora el rendimiento, sino que reduce los errores inducidos por humanos en un estimado del 40%, ya que el sistema detecta inconsistencias antes de que el código llegue a ejecución.

Framework / Tecnología	Requests Per Second (RPS)	Latencia Media (ms)
FastAPI + Uvicorn	3,000 - 4,500	1.2 - 2.5
Django + ASGI (Daphne)	800 - 1,500	,8.0 - 15.0
Node.js (Express)	2,800 - 4,000	2.0 - 4.0
Go (Gin)	5,000 - 7,000	0.5 - 1.5

Nota: Los valores son aproximados basados en benchmarks de 2025 para cargas de trabajo estándar de API.

Documentación automática y estándares abiertos

Uno de los mayores atractivos de FastAPI es que la documentación no es una tarea secundaria, sino un subproducto natural del desarrollo. Al utilizar tipos de Python estándar, FastAPI genera esquemas OpenAPI y JSON Schema en tiempo real. En 2026, las interfaces de Swagger UI y ReDoc integradas han evolucionado para permitir pruebas interactivas complejas, incluyendo flujos de autenticación OAuth2 y WebSockets, lo que reduce el tiempo de integración entre equipos de frontend y backend en un 40%.

Seguridad granular con OAuth2 Scopes

A diferencia de Django, que ofrece un sistema de autenticación centralizado y a veces rígido, FastAPI proporciona herramientas para construir sistemas de seguridad altamente granulares utilizando alcances (scopes) de OAuth2. Esto permite definir permisos específicos para cada punto final (endpoint), facilitando arquitecturas donde diferentes aplicaciones o usuarios tienen niveles de acceso drásticamente distintos sobre la misma API.

# Ejemplo de seguridad por scopes en FastAPI
from fastapi import Security, Depends, FastAPI
from fastapi.security import OAuth2PasswordBearer, SecurityScopes
from pydantic import BaseModel

app = FastAPI()

class User(BaseModel):
    username: str
    scopes: list[str]

async def get_current_user(security_scopes: SecurityScopes, token: str = Depends(OAuth2PasswordBearer(tokenUrl="token"))):
    # Lógica para validar JWT y verificar que posee los scopes requeridos
    pass

@app.get("/items/", dependencies=)])
async def read_items():
    return

Este enfoque es ideal para plataformas B2B donde la seguridad debe ser auditada y restringida al nivel de acción individual.

¿Por qué elegir si puedes tener ambos? La arquitectura híbrida

La tesis central es que la competencia entre Django y FastAPI es un falso dilema. Los sistemas más robustos y escalables de la actualidad utilizan una combinación de ambos, aprovechando sus fortalezas específicas para diferentes capas de la aplicación.

Django como el "Core" de gestión y verdad

En una arquitectura de microservicios moderna, Django asume el rol de "Centro de Comando". Sus responsabilidades incluyen:

Gestión de Datos Primaria: Utilizar el ORM de Django para definir la estructura de la base de datos y manejar migraciones complejas.
Panel Administrativo: Proporcionar una interfaz de usuario inmediata para que los operadores de negocio gestionen usuarios, catálogos y configuraciones.
Autenticación Central: Actuar como el servicio de identidad que emite tokens JWT para el resto del ecosistema.
Backoffice: Manejar flujos de trabajo internos que no requieren la latencia de microsegundos de FastAPI pero sí una alta fiabilidad y seguridad integrada.

FastAPI para servicios perimetrales y alto rendimiento

FastAPI se despliega en la periferia, encargándose de las tareas intensivas en I/O y aquellas que requieren escalado masivo:

Public API: Servir datos a las aplicaciones móviles y web con la menor latencia posible.
Inferencia de IA: Exponer modelos de aprendizaje automático, aprovechando su asincronismo para no bloquear el servidor mientras se espera la respuesta del modelo.
WebSockets y Tiempo Real: Manejar conexiones persistentes para chats, notificaciones o telemetría IoT.
Microservicios de Procesamiento: Servicios ligeros que realizan transformaciones de datos rápidas o actúan como proxies inteligentes.

Ventajas de la orquestación con Docker

Al desacoplar estas responsabilidades mediante contenedores Docker, se obtienen beneficios operativos críticos para cualquier arquitectura empresarial en 2026 :

Disponibilidad Aumentada: Una falla crítica en el servicio de FastAPI (por ejemplo, por un pico de tráfico en la API pública) no afecta la capacidad de los administradores para entrar al panel de Django y gestionar la crisis.
Mantenimiento sin Downtime: Es posible actualizar el núcleo de Django sin detener los servicios de FastAPI, o viceversa. Esto permite una integración y despliegue continuos (CI/CD) mucho más ágiles.
Escalabilidad Granular: Si la API pública experimenta mucha demanda, se pueden lanzar 10 instancias adicionales del contenedor de FastAPI sin tener que replicar todo el pesado monolito de Django, optimizando el uso de recursos en la nube.

Implementación práctica: Django Models dentro de FastAPI

Uno de los mayores retos de la arquitectura híbrida es evitar la duplicación de la lógica de negocio y los modelos de datos. En 2026, la técnica recomendada es inicializar el contexto de Django dentro de la aplicación FastAPI para consumir el ORM directamente cuando sea necesario.

Estructura del proyecto híbrido

Para que esta integración funcione, el proyecto debe seguir una estructura de directorios que permita la coexistencia de ambos frameworks:

/proyecto_soberano/ 
├── core_django/ # Proyecto Django (Admin, Migrations, Models) 
│ ├── settings.py 
│ └── models.py 
├── api_fastapi/ # Microservicio FastAPI 
│ ├── main.py 
│ └── dependencies.py 
├── docker-compose.yml 
└── shared_requirements.txt

El proceso de "Bootstrapping"

Para usar los modelos de Django en FastAPI, es imperativo configurar el entorno antes de realizar cualquier importación. Esto se hace en el punto de entrada de la aplicación FastAPI :

# api_fastapi/main.py
import os
import django
from fastapi import FastAPI

# 1. Configurar el módulo de ajustes de Django
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "core_django.settings")

# 2. Inicializar Django
django.setup()

# 3. Ahora es seguro importar modelos
from core_django.models import Producto

app = FastAPI(title="Servicio de Consulta Rápida")

@app.get("/producto/{id}")
def obtener_producto(id: int):
    # Uso del ORM de Django dentro de FastAPI
    # Nota: Django ORM es síncrono por defecto, FastAPI maneja esto en hilos
    producto = Producto.objects.filter(id=id).values("nombre", "precio").first()
    return producto

Este enfoque permite que FastAPI actúe como una "capa de lectura rápida" sobre la misma base de datos que Django administra, eliminando la necesidad de sincronizar dos esquemas de base de datos diferentes.

Orquestación Profesional con Docker Compose

La validación de esta tesis arquitectónica requiere una configuración de Docker que garantice la comunicación fluida entre servicios. Se prioriza el uso de redes aisladas y volúmenes persistentes para la base de datos compartida.

Ejemplo de docker-compose.yml

Este archivo define un ecosistema donde Django gestiona la base de datos y FastAPI consume esos datos para la API pública.

version: '3.9'

services:
  database:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: soberano_db
      POSTGRES_USER: dev
      POSTGRES_PASSWORD: super_secret_password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - backend_net
    healthcheck:
      test:
      interval: 5s
      timeout: 5s
      retries: 5

  django_core:
    build: 
      context:.
      dockerfile: Dockerfile.django
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      -.:/code
    environment:
      - DATABASE_URL=postgres://dev:super_secret_password@database:5432/soberano_db
    depends_on:
      database:
        condition: service_healthy
    networks:
      - backend_net

  fastapi_edge:
    build:
      context:.
      dockerfile: Dockerfile.fastapi
    command: uvicorn api_fastapi.main:app --host 0.0.0.0 --port 8080
    environment:
      - DATABASE_URL=postgres://dev:super_secret_password@database:5432/soberano_db
      - DJANGO_SETTINGS_MODULE=core_django.settings
    depends_on:
      database:
        condition: service_healthy
    networks:
      - backend_net

networks:
  backend_net:
    driver: bridge

volumes:
  postgres_data:

Este diseño garantiza que tanto Django como FastAPI compartan la misma "fuente de verdad" (PostgreSQL), pero operen en procesos y puertos distintos (8000 para administración, 8080 para la API pública), permitiendo un escalado independiente y una seguridad de red robusta.

Seguridad y Cumplimiento: Comparativa de Enfoques

La seguridad es un área donde la elección del framework dictamina la carga de trabajo del desarrollador. Django ofrece una seguridad "pasiva" o por defecto, mientras que FastAPI requiere una seguridad "activa" o explícita.

El enfoque de Django: Protección contra el error humano

Django está diseñado para proteger al desarrollador de sí mismo. Sus protecciones contra inyección SQL, CSRF y XSS están activadas por defecto y son difíciles de desactivar por accidente. En 2026, la madurez de su middleware de autenticación lo hace ideal para aplicaciones que manejan datos sensibles, como fintech o registros de salud, donde el cumplimiento normativo es estricto.

El enfoque de FastAPI: Control total y responsabilidad

FastAPI no asume nada. Aunque proporciona utilidades de seguridad excelentes en fastapi.security, la implementación real de la lógica de autenticación (hashing de contraseñas, validación de JWT, expiración de tokens) recae en el desarrollador. Esto ofrece una flexibilidad inigualable: es sencillo integrar proveedores de identidad externos como Auth0, Clerk o Supabase, pero aumenta la superficie de ataque si el desarrollador no sigue las mejores prácticas de seguridad.

Riesgo de Seguridad	Mitigación en Django 6.0	Mitigación en FastAPI 2026
Inyección SQL	ORM con parámetros saneados por defecto	Pydantic para tipos + SQLModel/ORM
Cross-Site Scripting (XSS)	Auto-escape en templates + CSP nativo	El desarrollador debe sanear salidas HTML
Broken Authentication	Sistema de sesión y auth robusto integrado	OAuth2/JWT manual con dependencias
Broken Access Control	Decoradores permission_required y RBAC	Scopes de OAuth2 y Dependency Injection

Rendimiento y Escalabilidad: El veredicto de los datos

Para un arquitecto de software, el rendimiento no es solo una métrica de vanidad; es una cuestión de costos operativos. La eficiencia de FastAPI permite que una aplicación maneje el mismo tráfico que Django utilizando un 30-50% menos de recursos de cómputo en la nube.

Concurrencia Asíncrona vs. Multihilo

La gran diferencia radica en cómo manejan las conexiones. Django, a pesar de sus mejoras asíncronas, todavía depende en gran medida de un modelo de un hilo por petición cuando se usa WSGI. FastAPI, siendo nativo ASGI y asíncrono, utiliza un bucle de eventos (event loop) que permite pausar una tarea mientras espera a la base de datos y atender otra petición en el ínterin.

Esta característica es la que permite que FastAPI maneje miles de conexiones de WebSockets simultáneas, algo que en Django tradicional requeriría una configuración compleja con Django Channels, añadiendo una carga significativa al servidor.

Consumo de Memoria y Cold Starts

En arquitecturas serverless (como AWS Lambda o Google Cloud Run), el tiempo de inicio y la memoria base son vitales. FastAPI tiene una huella de memoria inicial de aproximadamente 15-20 MB, mientras que un proyecto Django estándar con varias aplicaciones instaladas puede superar fácilmente los 80-100 MB. Esto hace que FastAPI sea mucho más eficiente para funciones de pago por uso o microservicios que se apagan y encienden según la demanda.

Futuro del ecosistema: Hacia Python 3.15 y más allá

Mirando hacia el futuro cercano, las tendencias indican una convergencia aún mayor. Django continuará "asincronizando" sus componentes internos, mientras que FastAPI verá el surgimiento de más "baterías" comunitarias que emulen el panel de administración de Django (como el proyecto FastOpp).

IA e Integración de Modelos

El papel de Python en la IA seguirá impulsando a FastAPI como la opción preferida para servir modelos de lenguaje y agentes autónomos. La capacidad de FastAPI para manejar flujos de datos (streaming responses) es perfecta para las respuestas palabra por palabra de los chatbots modernos. Django, por su parte, se posicionará como la plataforma de gestión para estos sistemas de IA, permitiendo a los humanos supervisar, corregir y auditar los datos que alimentan a los modelos.

El rol de los desarrolladores en 2026

Para los desarrolladores Python, la especialización en un solo framework ya no es suficiente. El mercado demanda profesionales que entiendan la arquitectura de sistemas: saber cuándo usar la solidez de Django para un proceso administrativo y cuándo desplegar la velocidad de FastAPI para una API crítica. La capacidad de orquestar ambos mundos con Docker y asegurar la comunicación mediante estándares modernos es la habilidad que define al desarrollador senior en esta era.

Conclusión: La síntesis del poder y la velocidad

En 2026, la respuesta a la pregunta "¿Django o FastAPI?" es un rotundo "Ambos". La evolución de Django 6.0 ha demostrado que el framework veterano aún tiene mucho que ofrecer, especialmente con su nuevo sistema de tareas y seguridad CSP integrada. FastAPI, por su parte, ha madurado hasta convertirse en una herramienta de precisión quirúrgica para el rendimiento y la escalabilidad asíncrona.

Al adoptar una arquitectura híbrida, los desarrolladores no están haciendo un compromiso, sino una optimización estratégica:

Django proporciona la paz mental de una seguridad probada y una administración instantánea para el equipo interno.
FastAPI garantiza una experiencia de usuario fluida con latencias mínimas y la capacidad de escalar hasta el infinito en la nube.
Docker actúa como el pegamento que permite que estas dos potencias coexistan en una infraestructura limpia, mantenible y profesional.

Elegir ambos es elegir no tener que sacrificar la productividad por el rendimiento. Es, en última instancia, la marca de un arquitecto que comprende que las herramientas están al servicio de la solución, y no al revés. En el dinámico mundo de Python en 2026, la versatilidad es la verdadera clave del éxito.

Referencias

De Localhost a Escala Global: Una Estrategia de Arquitectura AWS para Emprendedores en Latinoamérica

Carlos Eduardo Sotelo Pinto — Fri, 09 Jan 2026 12:42:59 +0000

La ciudad de Arequipa, cuna de juristas y pensadores, se encuentra hoy ante una encrucijada histórica. Históricamente definida por su comercio textil, su industria minera y su agricultura de exportación, la "Ciudad Blanca" está experimentando una metamorfosis silenciosa pero tectónica hacia la economía del conocimiento. Bajo la vigilancia de los volcanes Misti, Chachani y Pichu Pichu, una nueva generación de arquitectos de software, ingenieros de datos y fundadores de startups está redefiniendo lo que significa emprender desde el sur del Perú. Sin embargo, este renacimiento digital se enfrenta a un desafío fundamental: la brecha entre la concepción de una idea en un entorno de desarrollo local ("localhost") y la realidad operativa de desplegar una aplicación capaz de escalar globalmente.

Para el emprendedor latinoamericano, y específicamente para el arequipeño, el camino hacia la nube no es simplemente una decisión técnica; es una maniobra de supervivencia económica. A diferencia de sus contrapartes en Silicon Valley o Londres, nuestros fundadores operan en un entorno caracterizado por un acceso limitado al capital de riesgo en etapas tempranas, una infraestructura física local costosa y vulnerable, y una logística de importación tecnológica que a menudo roza lo kafkiano. En este contexto, Amazon Web Services (AWS) no se presenta solo como un proveedor de servicios de infraestructura, sino como el gran nivelador que democratiza el acceso a la potencia computacional de clase mundial.

Este informe técnico, se aleja de la retórica convencional de "migrar por migrar". En su lugar, propone una tesis arquitectónica pragmática y evolutiva. Rechazamos la noción de que una startup debe iniciar con arquitecturas de microservicios complejas y costosas desde el día uno. Por el contrario, introducimos una estrategia basada en la madurez progresiva, identificando a AWS Lightsail como el "eslabón perdido" estratégico que permite a las empresas validar sus modelos de negocio con un riesgo financiero mínimo, antes de evolucionar hacia servicios más granulares y potentes como Amazon EC2, Amazon S3, Amazon RDS y AWS Lambda.

A través de un análisis profundo que abarca desde la microeconomía del hardware en Perú hasta los patrones de diseño de redes híbridas en la nube, trazaremos una hoja de ruta técnica que honra tanto la realidad de nuestros presupuestos como la ambición de nuestra ingeniería.

2. Tesis Económica para LATAM: La Muerte del CAPEX y la Tiranía de la Latencia

Para comprender por qué la arquitectura en la nube es una necesidad existencial y no una opción de lujo para las startups en regiones como Arequipa, debemos diseccionar primero la realidad económica de la infraestructura tradicional en nuestra región. La decisión de dónde y cómo ejecutar el código tiene implicaciones financieras directas que pueden determinar la solvencia de una empresa emergente en sus primeros 18 meses de vida.

2.1. La Trampa del Hardware: Anatomía de una Importación en el Perú

En los modelos de gestión financiera tradicionales, la infraestructura de Tecnologías de la Información (TI) se clasifica predominantemente como CAPEX (Capital Expenditure o Gastos de Capital). Esto implica una inversión inicial masiva para adquirir activos físicos—servidores, racks, sistemas de refrigeración, licencias perpetuas—que se deprecian contablemente a lo largo de varios años. Para una empresa establecida en mercados con cadenas de suministro maduras, esto puede ser una gestión de activos rutinaria. Para una startup en Perú, representa una barrera de entrada formidable.

Analicemos la odisea financiera y logística de importar un servidor de base de datos de nivel empresarial a Perú en el contexto actual de 2025. El proceso está plagado de costos hundidos y fricciones burocráticas que drenan la liquidez, el recurso más preciado de cualquier emprendimiento:

Valor FOB (Free On Board): El precio base del hardware en el puerto de origen (usualmente China o Estados Unidos).
Flete y Seguro Internacional: Costos logísticos que, aunque se han estabilizado tras las crisis de cadenas de suministro de años anteriores, siguen representando un porcentaje significativo del costo total, especialmente para equipos delicados de alta tecnología.
Valor CIF (Cost, Insurance, and Freight): La suma del valor FOB, el flete y el seguro, que constituye la base imponible para el cálculo de los tributos aduaneros en Perú.
Derechos Ad Valorem: Dependiendo de la subpartida nacional específica del hardware, la importación puede estar sujeta a una tasa arancelaria que varía entre el 0%, 9% y 17%. Aunque Perú cuenta con Tratados de Libre Comercio (TLC) con potencias tecnológicas como EE.UU. y China que pueden reducir este arancel a cero, la correcta acreditación del origen y la conformidad técnica requieren a menudo la intervención de agentes de aduana especializados, añadiendo costos administrativos.
Impuesto General a las Ventas (IGV) e Impuesto de Promoción Municipal (IPM): Aquí reside el golpe más duro a la caja chica de la startup. La SUNAT aplica un 16% de IGV más un 2% de IPM sobre la suma del Valor CIF y los derechos Ad Valorem. Esto significa que el emprendedor debe desembolsar un 18% adicional de efectivo antes de que el servidor haya procesado una sola transacción o generado un solo sol de ingreso.
Costos de Nacionalización y Percepción: Además de los impuestos base, existen costos de almacenaje en depósitos temporales, transporte local y, en muchos casos, el Régimen de Percepción del IGV, que obliga a un pago adelantado adicional de impuestos (generalmente 3.5% o 10% para importadores nuevos).

Más allá de los costos de adquisición, la operación de infraestructura on-premise en una geografía como Arequipa conlleva riesgos operativos existenciales. La ciudad se encuentra en una zona de alta actividad sísmica. Un sismo de magnitud moderada no solo amenaza la integridad física de los discos duros giratorios, sino que puede interrumpir el suministro eléctrico y la conectividad de fibra óptica durante horas. Para mitigar esto, se requieren inversiones adicionales en UPS (Sistemas de Alimentación Ininterrumpida), generadores diésel y sistemas de refrigeración redundantes, convirtiendo una oficina de startup en un mini centro de datos difícil de mantener.

2.2. OPEX como Instrumento de Liberación Financiera

La adopción de la nube, y específicamente de AWS, transforma radicalmente este modelo hacia el OPEX (Operational Expenditure o Gastos Operativos). Esta transición no es meramente contable; es estratégica. Al consumir infraestructura como servicio, las startups peruanas cambian grandes desembolsos de capital por costos variables que se alinean directamente con el uso y, idealmente, con los ingresos.

Para un fundador en Arequipa, las ventajas del modelo OPEX son tangibles:

Preservación de Liquidez: El capital semilla, a menudo escaso en el ecosistema local, se puede destinar a la contratación de talento, desarrollo de producto y adquisición de usuarios, en lugar de inmovilizarse en activos depreciables.
Agilidad Fiscal y Contable: Los servicios de nube se facturan mensualmente. Estos costos se registran como gastos operativos en el mismo periodo fiscal en que se incurren, lo que simplifica la gestión tributaria y permite deducir el gasto del Impuesto a la Renta de manera inmediata, a diferencia de la depreciación de activos fijos que toma años en reflejarse en los libros.
Eliminación del Riesgo Tecnológico: En un entorno on-premise, el hardware comprado hoy es obsoleto en tres años. En AWS, la responsabilidad de la actualización del hardware recae en el proveedor. La startup siempre tiene acceso a la última generación de procesadores y almacenamiento sin costo de cambio.

2.3. El Impuesto Digital 2025: Navegando la Nueva Realidad Tributaria

Es imperativo abordar con precisión el panorama tributario actual en Perú, especialmente tras las modificaciones legislativas introducidas a finales de 2024 y vigentes en 2025, conocidas coloquialmente como la "Tasa Netflix", pero que afectan a todos los servicios digitales transfronterizos, incluyendo la infraestructura en la nube.

El Decreto Legislativo N° 1623 ha establecido mecanismos para la recaudación del IGV en la utilización de servicios digitales prestados por sujetos no domiciliados. La aplicación de este impuesto varía críticamente según la naturaleza del cliente:

Escenario	Tipo de Cliente	Implicancia Tributaria con AWS
B2C (Business to Consumer)	Personas naturales sin negocio / Hobbistas	AWS, actuando como agente de percepción o retención, está obligado a cobrar el 18% de IGV directamente en la factura o a través de la tarjeta de crédito del usuario. Esto encarece el servicio en un 18% para desarrolladores individuales que no han formalizado su actividad.
B2B (Business to Business)	Startups y Empresas con RUC activo	Las empresas peruanas deben registrar su número de RUC en la consola de facturación de AWS (Tax Settings). En este escenario, bajo el mecanismo de "Inversión del Sujeto Pasivo" (Reverse Charge), AWS generalmente no cobra el IGV en la factura comercial. Es responsabilidad de la empresa peruana autoliquidar el "IGV de No Domiciliados" ante la SUNAT mediante el Formulario Virtual 617 u otros medios designados.

Insight Estratégico: Para una startup que busca escalar, la formalización (obtención del RUC y régimen tributario adecuado) es el primer paso de optimización de costos en la nube. Operar como B2B permite gestionar el IGV como crédito fiscal (dependiendo del régimen), mientras que operar como persona natural (B2C) convierte ese 18% en un costo hundido no recuperable. Además, la correcta identificación tributaria es vital para evitar la doble imposición o retenciones indebidas por parte de los bancos locales.

2.4. La Geopolítica de la Latencia: ¿Virginia, Ohio o São Paulo?

Una pregunta recurrente en los meetups del AWS User Group Arequipa es sobre la selección de la región: "Si estamos en Sudamérica, ¿por qué no desplegamos todo en la región de São Paulo (sa-east-1)?" La respuesta requiere un análisis de la infraestructura global de internet y la economía de precios de AWS.

A pesar de la proximidad geográfica, la región de São Paulo presenta dos desventajas críticas para una startup peruana en etapa temprana:

Sobrecosto Estructural: Debido a la compleja carga tributaria y los altos costos de importación y energía en Brasil, los servicios en sa-east-1 son consistentemente más caros (a menudo entre un 30% y un 50% más) que en las regiones de Estados Unidos. Para una startup que cuida cada dólar, este sobreprecio es difícil de justificar sin un requisito estricto de residencia de datos.
Topología de Red: La conectividad de internet de Perú depende en gran medida de cables submarinos como el SAm-1 y el Curie que conectan la costa del Pacífico (Lurín) hacia el norte, con puntos de aterrizaje en Panamá y Florida (Miami). El tráfico desde Arequipa hacia Brasil a menudo no cruza el continente directamente a través de la selva o los Andes; en muchos casos, viaja hasta Miami y luego "baja" a São Paulo. Esto resulta en que la latencia hacia us-east-1 (N. Virginia) suele oscilar entre 110ms y 140ms, muy competitiva e incluso a veces inferior a la ruta hacia Brasil dependiendo del ISP.

Veredicto: Para el 90% de las startups en Arequipa, la región US East (N. Virginia) us-east-1 (o sus alternativas en Ohio us-east-2 u Oregón us-west-2) ofrece el punto óptimo de equilibrio: los precios más bajos del mercado global, acceso prioritario a nuevas funcionalidades de AWS y una latencia totalmente aceptable para aplicaciones web y móviles estándar. La región de Sudamérica se debe reservar para casos de uso específicos de fintech regulada o aplicaciones de tiempo real crítico donde cada milisegundo cuenta y el presupuesto lo permite.

3. El Punto de Entrada "Sin Excusas": AWS Lightsail

En la literatura técnica y las certificaciones de arquitectura, a menudo se nos enseña el "camino purista": diseñar una Virtual Private Cloud (VPC) desde cero, segmentar subredes públicas y privadas, configurar NAT Gateways para la salida segura a internet, desplegar Application Load Balancers (ALB) y configurar Auto Scaling Groups. Si bien este diseño es robusto y escalable , presenta un defecto fatal para una startup en fase de validación: Complejidad cognitiva y costos fijos elevados.

Un solo NAT Gateway en AWS cuesta aproximadamente $0.045 por hora, más el procesamiento de datos. Esto se traduce en unos $32 USD mensuales por zona de disponibilidad, solo por tener la "capacidad" de que las instancias privadas salgan a internet. Sumando un ALB (~$16 USD + LCUs) y las instancias EC2, la factura puede superar los $100 USD mensuales antes de recibir el primer cliente.

Aquí es donde introducimos AWS Lightsail no como una herramienta para principiantes, sino como un movimiento estratégico deliberado.

3.1. Lightsail: El VPS Plug-and-Play Disruptivo

AWS Lightsail es, en esencia, un servicio de Servidor Privado Virtual (VPS) gestionado que encapsula la potencia de AWS en una experiencia simplificada. Pero su valor real para el emprendedor no es solo la simplicidad, sino la predictibilidad financiera.

A diferencia del modelo on-demand puro de EC2 donde se paga por cómputo, almacenamiento y transferencia por separado, Lightsail ofrece "paquetes" (bundles) a precio fijo. Por una tarifa mensual (ej. $3.50, $5, $10 USD), una startup obtiene :

Cómputo: Una instancia virtual (basada en la tecnología de la familia T de EC2, con capacidad de ráfaga o burst).
Almacenamiento: Un disco SSD persistente de tamaño generoso (ej. 20GB, 40GB).
Networking: Una dirección IP estática incluida y, lo más importante, una asignación masiva de transferencia de datos de salida (ej. 1 TB a 5 TB mensuales).

Esta inclusión de la transferencia de datos es el "asesino de costos". En EC2, la transferencia de salida cuesta aproximadamente $0.09 USD por GB. Un terabyte de tráfico en EC2 costaría unos $90 USD solo en red. En Lightsail, ese mismo terabyte viene incluido en un plan de $5 USD. Para una startup de contenido, streaming o e-commerce, esta diferencia es abismal.

3.2. La Estrategia del "Monolito Glorioso"

En la etapa inicial de una startup, la velocidad de iteración supera a la pureza arquitectónica. No necesitamos microservicios orquestados en Kubernetes; necesitamos validar que el mercado quiere nuestro producto. Lightsail permite desplegar un "Monolito Glorioso": toda la pila tecnológica (servidor web, lógica de negocio, base de datos) en una sola instancia.

Utilizando los Blueprints de Bitnami integrados en Lightsail, un desarrollador en Arequipa puede lanzar un stack LAMP (Linux, Apache, MySQL, PHP), MEAN, Node.js, Django o WordPress en cuestión de minutos. Esto reduce el Time-to-Market drásticamente. Además, con el Free Tier de AWS (que a menudo incluye 3 meses gratuitos en ciertos planes de Lightsail), el costo de validación es efectivamente cero.

3.3. El Eslabón Perdido: VPC Peering (La Puerta Trasera al Poder)

Muchos arquitectos descartan Lightsail porque lo ven como un "jardín vallado", aislado del ecosistema profundo de AWS. Esta es una concepción errónea que nuestra estrategia explota. Lightsail reside en una VPC gestionada por AWS "en la sombra", pero posee una capacidad crítica: el VPC Peering (Emparejamiento de VPC).

El VPC Peering permite conectar la VPC oculta de Lightsail con la VPC Por Defecto (Default VPC) de la cuenta de AWS en la misma región. Al activar esta función (un simple checkbox en la consola de Lightsail), ocurre la magia:

Visibilidad de Red: La instancia Lightsail puede "ver" y comunicarse con recursos desplegados en la Default VPC (como instancias RDS, ElastiCache o interfaces de red privadas).
Comunicación Privada: La comunicación ocurre a través de direcciones IP privadas, lo que mejora la seguridad al no exponer tráfico a la internet pública. 3- Economía de Transferencia: La transferencia de datos entre Lightsail y los recursos en la Default VPC (dentro de la misma región) es generalmente gratuita o de costo muy reducido, tratándose como tráfico interno de AWS.

Advertencia Técnica Crítica: Lightsail tiene una limitación "dura": solo puede hacer peering con la VPC Por Defecto. No se puede configurar peering con una VPC personalizada creada por el usuario. Esto es vital para la planificación. Si una startup, siguiendo un tutorial avanzado, elimina su Default VPC para "empezar de cero", perderá la capacidad de integrar Lightsail con el resto de AWS fácilmente (aunque se puede solicitar a soporte que se recree la Default VPC). La estrategia aquí es: No borren su Default VPC. Úsenla como el muelle de conexión para su flota de Lightsail.

4. Arquitectura para la Madurez: La Evolución Paso a Paso

El éxito trae consigo nuevos problemas: el tráfico aumenta, la base de datos local del monolito se satura y el disco duro se llena de uploads de usuarios. En lugar de una reingeniería total y costosa ("Big Bang"), nuestra estrategia propone una descomposición progresiva. Desmantelamos el monolito pieza por pieza, reemplazando componentes internos de Lightsail con servicios nativos de AWS, aprovechando el puente del VPC Peering que ya hemos establecido.

4.1. Fase 1: Desacoplar el Almacenamiento (Amazon S3)

El Problema: El disco SSD de una instancia Lightsail es rápido pero finito. Si nuestra aplicación (por ejemplo, una plataforma de e-commerce para artesanías de Arequipa) permite subir imágenes de alta resolución, el disco se llenará rápidamente. Además, el almacenamiento local es efímero en caso de fallo catastrófico de la instancia; si el servidor se corrompe, los datos de usuario mueren con él.

La Solución: Migrar el almacenamiento de archivos estáticos y media a Amazon S3 (Simple Storage Service). S3 ofrece durabilidad del 99.999999999% ("once nueves") y capacidad infinita teórica.

Implementación Técnica:

Refactorización Ligera: Modificamos la aplicación (en Python/Django, PHP/Laravel, Node/Express) para utilizar el AWS SDK (como Boto3). En lugar de guardar archivos en el sistema de archivos local (/var/www/html/uploads), los enviamos directamente a un bucket S3.
Gestión de Credenciales (El Reto de Seguridad): Aquí encontramos una limitación de Lightsail: a diferencia de EC2, Lightsail no soporta nativamente los "Instance Profiles" (Roles IAM) que rotan credenciales automáticamente.
Práctica Recomendada: Crear un Usuario IAM específico con una política estricta que solo permita s3:PutObject y s3:GetObject en el bucket específico de la aplicación. Generar Access Keys para este usuario y configurarlas como variables de entorno en la instancia Lightsail o mediante el archivo ~/.aws/credentials. Nunca hardcodear las claves en el código fuente.
Economía de Datos S3-Lightsail:

La transferencia de datos hacia S3 (subida) es gratuita.
La transferencia desde S3 hacia Lightsail es un punto de confusión común. Según la documentación oficial, si se utilizan IPs Privadas, la transferencia entre servicios de AWS en la misma región es gratuita. Sin embargo, S3 es un servicio público por defecto. Para maximizar la eficiencia, se debe interactuar con S3 dentro de la misma región (us-east-1 a us-east-1). Aunque S3 se accede técnicamente por endpoints públicos, AWS no cobra la transferencia de datos saliente desde S3 hacia EC2/Lightsail en la misma región.
Para servir el contenido a los usuarios finales, se puede configurar una distribución CDN de Lightsail (que usa CloudFront por debajo) apuntando al bucket S3, aprovechando la capa gratuita de CDN de Lightsail (ej. 1 año de 50GB/mes).

4.2. Fase 2: Desacoplar la Base de Datos (Amazon RDS)

El Problema: La base de datos local (MySQL/PostgreSQL) compite brutalmente por la memoria RAM y la CPU con el servidor web (Apache/Nginx) dentro de la misma instancia Lightsail. Un pico de tráfico web puede causar que el proceso de base de datos sea eliminado por el sistema operativo (OOM Killer), tirando abajo todo el servicio. Además, la gestión manual de backups y parches es un riesgo operativo inaceptable a medida que se escala.

La Solución: Migrar a Amazon RDS (Relational Database Service).

Implementación Técnica:

Despliegue Estratégico: Aunque Lightsail ofrece "Bases de Datos Gestionadas" (una versión simplificada de RDS), la recomendación estratégica es desplegar una instancia Amazon RDS nativa directamente en la Default VPC.
- ¿Por qué? RDS nativo ofrece mayor granularidad de configuración, acceso a tipos de instancias más variados (incluyendo Graviton para mejor costo/rendimiento) y, crucialmente, nos prepara para cuando abandonemos Lightsail por completo. El costo puede ser similar o ligeramente menor si se usan instancias reservadas en el futuro.
Conectividad vía Peering (El Paso Crítico):
- Asegurar que el VPC Peering esté activo entre Lightsail y la Default VPC.
- Configuración de Security Groups: Este es el punto donde la mayoría falla. En el Security Group de la instancia RDS (en la Default VPC), debemos añadir una regla de entrada (Inbound Rule) para el puerto de la base de datos (3306 para MySQL, 5432 para PostgreSQL).
- El Truco del CIDR: Como no podemos referenciar "lógicamente" el Security Group de Lightsail dentro del Security Group de la VPC, debemos autorizar la IP Privada específica de nuestra instancia Lightsail. Dado que las IPs privadas en Lightsail son estáticas durante la vida de la instancia, esto es seguro y efectivo. Alternativamente, si tenemos varias instancias, podemos autorizar el bloque CIDR completo de la VPC de Lightsail (visible en la consola de Peering), aunque esto es menos restrictivo.
Migración de Datos: Utilizamos herramientas estándar como mysqldump o pg_dump para exportar la data local e importarla en el endpoint del RDS a través de la conexión privada.
Resultado: La base de datos ahora vive en un entorno dedicado, con backups automáticos (Point-in-Time Recovery) y la capacidad de escalar verticalmente (cambiar el tamaño de instancia) o activar Multi-AZ (alta disponibilidad) con un clic, sin afectar al servidor web.

4.3. Fase 3: Desacoplar la Lógica y Tareas Programadas (AWS Lambda y EventBridge)

El Problema: Los Cron jobs (tareas programadas) en el servidor monolítico son ineficientes. Procesos como el envío masivo de correos, la generación de reportes PDF nocturnos o el redimensionamiento de imágenes consumen ciclos de CPU valiosos que deberían dedicarse a servir peticiones de usuarios. Si la instancia web se cae o se reinicia, los trabajos programados fallan silenciosamente.

La Solución: Computación Serverless con AWS Lambda orquestada por Amazon EventBridge.

Implementación Técnica:

Reemplazo del Cron: En lugar de mantener un fichero crontab en Linux, configuramos una regla en Amazon EventBridge Scheduler. Esta regla se dispara según una expresión cron (ej. cron(0 8? * MON-FRI *)) e invoca una función Lambda.

La función Lambda contiene la lógica de negocio (ej. conectarse al RDS, consultar usuarios inactivos y enviar un email a través de Amazon SES).
Ventaja Económica: Una función Lambda que corre 2 minutos al día cuesta fracciones de centavo. Un servidor EC2 dedicado para tareas batch costaría dinero las 24 horas del día, incluso cuando está inactivo.

Arquitectura Orientada a Eventos:

Para el procesamiento de imágenes, configuramos el bucket S3 para que emita una notificación de evento cada vez que se sube un objeto (s3:ObjectCreated:*).
Este evento dispara una función Lambda asíncrona que descarga la imagen, la optimiza/redimensiona y la guarda en un bucket de destino o actualiza la base de datos.
Esto elimina completamente la carga de procesamiento de medios del servidor Lightsail, permitiéndole manejar más usuarios concurrentes con la misma capacidad de CPU.

4.4. Fase 4: La Graduación (El Éxodo a EC2)

Llegará el momento en que el éxito de la startup supere las capacidades de Lightsail. Quizás se necesite Auto Scaling real para manejar picos de tráfico durante campañas como el Cyber Wow, o se requieran tipos de instancias especializadas (Familia C para cómputo intensivo, Familia R para memoria) que no existen en el menú de Lightsail.

El Camino de Salida (Upgrade Path): Aquí es donde la elección de AWS brilla sobre otros proveedores de VPS. No estamos encerrados. AWS ofrece una ruta de migración nativa y fluida.

Snapshot y Exportación: Desde la consola de Lightsail, tomamos una instantánea (Snapshot) de la instancia. Usamos la función "Export to EC2".
Creación de AMI: AWS toma ese snapshot y crea una AMI (Amazon Machine Image) y un volumen EBS en la consola de EC2.
Lanzamiento Empresarial: Usamos esa AMI para lanzar nuevas instancias EC2 dentro de una arquitectura VPC "madura": subredes privadas, Application Load Balancers (ALB), NAT Gateways y Auto Scaling Groups.
Continuidad: Como ya habíamos desacoplado la base de datos (a RDS) y el almacenamiento (a S3) en las fases anteriores, la migración del servidor web es trivial y sin pérdida de datos.

5. Análisis de Costos Comparativo

Para el emprendedor, la visualización del ahorro es vital. A continuación, presentamos una tabla comparativa de costos mensuales estimados para una arquitectura típica de inicio (Servidor Web + Base de Datos pequeña + 1TB de transferencia), contrastando el enfoque tradicional de EC2 frente a la estrategia Lightsail propuesta.

Componente	Arquitectura Tradicional (EC2 "Purista")	Arquitectura Estratégica (Lightsail + RDS)	Análisis de Impacto Económico
Cómputo Web	t3.micro (On-Demand): ~$7.60/mes	Lightsail Bundle (1GB RAM): $5.00/mes	Lightsail es más barato y predecible.
Almacenamiento	EBS gp3 (40GB): ~$3.20/mes	Incluido en el bundle (40GB SSD)	El almacenamiento está subsidiado en Lightsail.
Base de Datos	RDS db.t3.micro (Single-AZ): ~$17.00/mes	RDS db.t3.micro (en Default VPC): ~$17.00/mes	El costo de RDS es idéntico, pero ganamos robustez.
Transferencia de Datos	1 TB Salida a Internet: ~$90.00 USD	Incluido en el bundle (hasta 2 TB)	Diferencia Crítica. En EC2, la transferencia es el costo oculto más peligroso ($0.09/GB). En Lightsail, el primer TB es "gratis".
IP Estática	Gratis (si asociada)	Gratis (si asociada)	Igual.
Costo Total Estimado	~$117.80 USD / mes	~$22.00 USD / mes	Ahorro del ~81%

Nota: Los precios son estimados basados en la región us-east-1 a Enero de 2026 y pueden variar. El ahorro masivo proviene de la inclusión de la transferencia de datos en el paquete de Lightsail, lo que actúa como un "escudo financiero" para la startup en crecimiento.

6. Conclusión: Construyendo el Futuro desde Arequipa

La nube ha democratizado el acceso a la infraestructura tecnológica, pero la responsabilidad de utilizarla con sabiduría recae en nosotros. Para la comunidad tecnológica de Arequipa, el mensaje de este análisis es contundente: no existen excusas técnicas ni financieras válidas para no construir productos de clase mundial.

Hemos demostrado que:

El modelo CAPEX es obsoleto para la innovación ágil; la importación de hardware es una carga innecesaria frente a la flexibilidad del OPEX en la nube.
AWS Lightsail es el punto de partida ideal, ofreciendo una protección financiera contra los costos de transferencia de datos y una simplicidad operativa que permite enfocarse en el producto.
El VPC Peering es la herramienta secreta que permite una arquitectura híbrida, combinando la economía de Lightsail con la potencia de Amazon RDS.
La evolución es posible y necesaria, trazando un camino claro desde el monolito hacia arquitecturas desacopladas con S3, Lambda y eventualmente EC2, sin necesidad de reconstruir desde cero.

Empresas nacidas en Perú como Crehana o Chazki, y casos de éxito locales en el sur como la transformación digital de Caja Arequipa, demuestran que el talento local, potenciado por la tecnología correcta, no tiene límites.

Es hora de que los emprendedores arequipeños dejen de mirar sus servidores locales con preocupación y empiecen a mirar hacia la nube con ambición. Las herramientas están sobre la mesa; la estrategia ha sido trazada. El siguiente unicornio tecnológico puede, y debe, nacer a la sombra del Misti.

¡Manos a la obra!

DEV Community: Carlos Eduardo Sotelo Pinto

VitaeForge: Breaking the ATS Barrier

Abstract

Executive Summary

1. Introduction: The ATS Barrier

1.1 The Problem

1.2 Why I Built VitaeForge

2. How ATS Works — and Why Resumes Fail

2.1 The Numbers

2.2 How ATS Screens Resumes

2.3 What VitaeForge Changes

3. Building VitaeForge: A Product Owner’s Journey

3.1 Methodology

3.2 Development Workflow

3.3 Process

3.4 Model Selection

3.5 Technical Challenges and Solutions

3.6 Lessons Learned

4. Technical Implementation: Hexagonal Architecture and Core Components

4.1 Hexagonal Architecture Implementation

4.2 Core Technical Features

4.2.1 ATS Scoring System (ats_scorer.py)

4.2.2 CAR Bullet Generation Engine (experience_enricher.py)

4.2.3 Theme-Based Formatting (cv_generator.py)

4.3 Incremental Regeneration

4.4 AI Adapter Architecture

5. Observed Results

5.1 What the Tool Produces

5.2 Personal Context

6. Technical Challenges and Solutions

6.1 AI Hallucination Control

6.2 ATS Formatting — Delegated to rendercv

6.3 Domain-Infrastructure Decoupling

6.4 Multilingual Consistency

6.5 CAR Format Compliance

7. Next Steps

7.1 Docker Image

7.2 JD Scraping with Playwright

8. Conclusion

8.1 What VitaeForge Does

8.2 Key Takeaways

8.3 Try It

Appendix

A. ATS Statistics

B. License (MIT)

C. CLI Quick Reference

D. Tools and Frameworks Used

E. Key References

Building a Multi-Agent ATDD Pipeline with Hexagonal Architecture

Building a Multi-Agent ATDD Pipeline with Hexagonal Architecture

The problem with solo AI development

What is ATDD and why does it fit AI agents perfectly?

The architecture: hexagonal all the way down

The entry point: __main__.py

The production engine: Celery + Redis

The local development engine: LangGraph

State

Nodes

Graph with conditional edges

LangGraph executor

The design decisions worth discussing

Why is the state stored in files, not a database?

Why is the Architect role never automated?

Why Celery for production and LangGraph for local development?

The GraphRoutedQueue pattern

What I tested on a real project

What's next

Repository

Final thought

Crafting code crafting mead: Un Viaje de Paciencia y Bugs

Mis Inicios: Del "C" Duro a la Reflexión Activa

La Alquimia de la Fermentación: El "Deploy" Orgánico

El "Code Review" en la Feria de Hidromieleros

Conclusión: Crafting Code, Crafting Mead

Conclusión: Paciencia y Pasión

Django vs. FastAPI o Django + FastAPI 2026: ¿Por qué elegir si puedes tener ambos?

El estado del arte de Python Web en 2026

Comparativa filosófica y técnica inicial

El renacimiento de Django 6.0: Más allá del monolito

El nuevo marco de tareas en segundo plano (Django Tasks)

4.2.1 ATS Scoring System (`ats_scorer.py`)

4.2.2 CAR Bullet Generation Engine (`experience_enricher.py`)

4.2.3 Theme-Based Formatting (`cv_generator.py`)

The entry point: `main.py`