Ex-Disney · Ex-Globant · Freelance desde 2014
Contratá un desarrollador senior Python — backends modernos, capas LLM, pipelines de datos.
Envío Python que es tipado, testeado y listo para producción. FastAPI para APIs modernas, Django cuando el panel admin se paga solo, capas de integración LLM para Claude / OpenAI / modelos locales, y pipelines de datos que no se rompen cuando alguien cambia el nombre de una columna.
Empezar un proyectoPython moderno, no scripts legacy
Python 3.12+, type hints en todos lados, Pydantic para validación, dataclasses para estructura, pytest con fixtures como corresponde, pre-commit hooks corriendo black + ruff + mypy. Si heredaste un codebase Python con tipos implícitos y sin tests, esto es lo que puede volverse.
FastAPI o Django — elegidos bien
FastAPI es mi default para backends API-only nuevos (type-safe, rápido, docs OpenAPI gratis). Django cuando necesitás el panel admin, la madurez del ORM y auth out-of-the-box — sigue siendo el mejor para apps pesadas en contenido con flujo editorial. Flask rara vez, solo para legacy o cuando la simplicidad realmente supera las features.
Capas de integración LLM hechas bien
Python es el primer idioma del ecosistema LLM — el SDK de Anthropic, SDK de OpenAI, LangChain, LlamaIndex, Instructor viven ahí primero. Construyo capas LLM en Python cuando el proyecto ya vive en Python, con la misma disciplina que cualquier backend de producción — retries, observabilidad, logging estructurado, tracking de costos.
Pipelines de datos que sobreviven la realidad
Celery para tareas async, Prefect / Airflow para orquestación, Pandas para trabajo de datos clásico, Polars cuando la performance importa, SQLAlchemy 2.0 para acceso DB tipado. Los pipelines de datos se rompen en los bordes — construyo defensivo con validación de schema y manejo explícito de errores, no asunciones happy-path.
El stack Python con el que trabajo
- Python 3.12+Python moderno — type hints, pattern matching, asyncio
- FastAPIBackend API-first — docs OpenAPI gratis, validación Pydantic
- DjangoApps pesadas en contenido con panel admin, ORM, auth out of the box
- FlaskMantenimiento legacy o servicios deliberadamente mínimos
- PydanticValidación, serialización, settings — type-checked end to end
- SQLAlchemyORM 2.0 tipado — async-capable, sin magia
- CeleryJobs en background, tareas programadas, trabajo distribuido
- Poetry / uvDependencias determinísticas, lock files, instalaciones rápidas (uv-first)
- pytestFixtures, parametrize, tests de integración — todo
- Pandas / PolarsData clásica vs performance — elegí según tamaño
- LLM toolingAnthropic SDK, OpenAI SDK, LangChain, LlamaIndex, Instructor
- DockerDeploys containerizados con multi-stage builds correctos
Cuándo Python es la elección correcta para backend
Python tiene sentido cuando el proyecto vive en un ecosistema donde Python tiene el mejor tooling: trabajo LLM y IA (los SDKs, los frameworks de eval, los notebooks viven en Python primero), pipelines de datos y analítica (ecosistema Pandas / Polars / DuckDB), computación científica (NumPy / SciPy), ML / serving de inferencia (PyTorch / TensorFlow / Hugging Face). Para esos dominios, Python no es una opción — es el default.
Donde Python deja de ser la elección obvia: APIs de alto throughput donde la latencia importa a nivel milisegundo (Go o Rust ganan), trabajo frontend (nada hace Python ahí, es un problema del browser), o composición del equipo que ya conoce TypeScript profundamente (usá NestJS y mantené un solo idioma entre frontend y backend). Te digo si tu equipo debería usar NestJS en vez de Python — aunque ofrezca trabajo Python — porque elegir la herramienta correcta importa más que elegir mi herramienta.
Sobre tipado: Python moderno con type hints estrictos, mypy en CI, y validación Pydantic cierra el 80% de la brecha entre Python y TypeScript en seguridad. No es lo mismo que Rust — nada lo es — pero alcanza para que backends de producción atrapen bugs reales al commit. Los type hints son innegociables en el Python que envío.
He trabajado en codebases Python abarcando capas de orquestación LLM en FastAPI, migraciones de CMS Django para sitios pesados en contenido, pipelines de datos para analítica y reportes, y scripts de automatización para workflows de ops. El hilo común es tratar Python como un lenguaje de producción — tests, tipos, observabilidad, gestión de dependencias con Poetry o uv — no como una herramienta de prototipado que de alguna manera llegó a producción sin madurar.
Preguntas frecuentes
FastAPI para backends API-only nuevos — moderno, rápido, gran DX. Django cuando necesitás el admin, ORM, auth y flujo de contenido built-in. Flask solo para mantenimiento legacy o servicios genuinamente mínimos donde Django es overkill. Recomiendo según las necesidades de tu proyecto, no por lealtad de framework.
uv para proyectos nuevos — es 10-100x más rápido que Poetry/pip y el formato de lock file es compatible. Poetry para proyectos existentes que están profundamente invertidos en él. Ambos son mejores que requirements.txt plano; si todavía estás ahí, migrar es una quick win.
Sí — es parte core de mi trabajo ahora. SDK oficial de Anthropic, SDK de OpenAI, LangChain cuando la estructura realmente ayuda, Instructor para output estructurado. Construí capas LLM en producción en Python manejando prompt caching, tool use, retrieval RAG y loops de agentes con observabilidad correcta.
Celery para colas de tareas async, Prefect o Airflow para orquestación, Pandas para manipulación de datos estándar, Polars cuando trabajás con datasets grandes donde la performance importa. ORM tipado SQLAlchemy 2.0 para acceso a base de datos. Para scripts one-off lo mantengo simple; para pipelines recurrentes invierto en manejo de errores y monitoreo correctos.
Integro con servicios ML existentes (Hugging Face, APIs de vendors, modelos self-hosted) y construyo capas de serving alrededor de modelos entrenados, pero no entreno modelos desde cero ni hago investigación de data science. Si necesitás alguien para entrenar un modelo custom, querés un data scientist o ML engineer — me asocio con ellos pero no seré el principal en ese trabajo.
Sí, es trabajo común. El camino de migración depende de lo que hay: Python 2 a 3 requiere más trabajo que Python 3.6 a 3.12, Django 1.x a 5.x es un upgrade multi-paso, agregar type hints a un codebase de 50K líneas es un proyecto de 2-4 semanas dependiendo del alcance. Audito primero, después propongo un plan incremental.
¿Necesitás un ingeniero Python senior para backends de producción o capas LLM?
FastAPI, Django, typing moderno, pipelines de datos, integración LLM. Respuesta en 24 horas.
Empezar la conversación