Una clínica dental funciona con esto. Lo construyó un ingeniero con una flota de agentes.
Diecinueve meses, 922 commits, 715 tickets, un solo autor. Un sistema de gestión de clínicas dentales que maneja citas, historia clínica, facturación, laboratorios y expedientes de pacientes para clínicas en América Latina — Django 5.2, PostgreSQL 17 e información médica protegida en producción.
El sistema
Diecisiete apps, un solo expediente clínico
Radiant Dental es un SaaS multi-inquilino: una clínica tiene sucursales, las sucursales tienen especialidades y servicios, y el personal — odontólogos, higienistas, asistentes, recepcionistas, gerentes — se asigna por sucursal. Sobre eso se apoyan las citas y listas de espera, los expedientes de pacientes y sus cuestionarios de salud, la historia clínica, los planes de tratamiento, la facturación y los pagos, la gestión de casos de laboratorio, los programas de lealtad, los prospectos de marketing y una superficie pública de agendamiento en línea.
Lo interesante no es la lista de funcionalidades. Es que todas esas superficies tocan el mismo expediente del paciente, y ese expediente es información médica protegida.
Modelado de dominio
La parte difícil nunca fue el CRUD
Un diente no es un registro. Los dientes se numeran con el estándar FDI de dos dígitos, y una condición aplica a un conjunto de superficies del diente — mesial, oclusal, distal, vestibular, lingual, incisal — o al diente completo, que es mutuamente excluyente con el resto. El modelo lo almacena como una cadena validada: cada carácter es un código de superficie, sin repeticiones, o el literal FULL.
Un odontograma es una instantánea, no un estado actual. Varios odontogramas por paciente permiten comparar en el tiempo, y un odontograma puede bloquearse con un motivo registrado, porque un registro clínico firmado debe dejar de cambiar. El periodontograma agrega seis sitios de medición por diente; los ítems del plan de tratamiento llevan códigos de procedimiento CDT.
Los conflictos de agenda son advertencias, no errores. El verificador de conflictos ejecuta siete comprobaciones independientes — feriados de la sucursal, horario de atención, agenda del profesional, permisos aprobados, bloqueos personales, citas superpuestas y duración del servicio — y devuelve una lista de advertencias categorizadas en lugar de rechazar la cita.
Las recepcionistas sobreagendan a propósito. Un sistema que se los impide termina esquivado en una semana; uno que les dice exactamente qué están pasando por alto termina usado.
Criterio
El documento de diseño que dice "todavía no construyas esto"
El registro clínico por voz — que el odontólogo dicte las mediciones en vez de escribirlas — es la funcionalidad que el producto más obviamente pide. Está especificada en tres documentos de diseño dentro del repositorio, y nada de eso está en INSTALLED_APPS.
La razón está en la especificación. La salida de voz es provisional hasta que un profesional la firma, así que la capa de captura es una app separada que escribe hacia los modelos clínicos solo al confirmar. El audio y las transcripciones nunca cuelgan del expediente clínico: eso mezclaría la procedencia con el registro y obligaría a cada consulta clínica a esquivarla. Los límites de bloqueo y borrador que ya existen se convierten en el destino de la confirmación, en vez de reinventarse.
Escribir eso antes de escribir código es lo que evita que una base de código asistida por IA acumule estructura plausible. También es la razón por la que la funcionalidad no está construida a medias.
Seguridad
Hice una revisión de caja blanca contra mi propio producto
En mayo de 2026 realicé una revisión de seguridad a nivel de código fuente, con alcance en configuración y secretos, autenticación y control de acceso, inyección y manejo de entradas, y protección de información médica. Trece hallazgos, calificados para un sistema con obligaciones tipo HIPAA, cada uno rastreado a código específico y contrastado contra el ruteo de URLs para separar los problemas realmente alcanzables de los inseguros pero no enrutados.
Después los corregí. La concentración estaba exactamente donde uno esperaría: la superficie pública sin autenticar y el servido de archivos estáticos.
| Área | Corrección | Estado |
|---|---|---|
| Archivos de pacientes | Todo el contenido con información médica pasó a servirse tras vistas autenticadas; almacenamiento de objetos conmutable por entorno, con alias privados y públicos separados | Cerrado |
| Registros clínicos | Acceso a la historia clínica acotado por clínica; auditoría de acceso a información médica en las superficies de expediente y citas | Cerrado |
| Agendamiento público | La API pública de citas insegura se eliminó en vez de parchearse; redirecciones de login protegidas | Cerrado |
| Carga de archivos | Validadores de subida y redacción de datos sensibles en logs | Cerrado |
| Superficie del navegador | Content-Security-Policy aplicada con django-csp; orígenes de bucket permitidos solo cuando el almacenamiento de objetos está activo | Cerrado |
| Formularios públicos | Honeypot y tiempo mínimo de llenado contra bots; registro de la IP real del cliente detrás del proxy; log de intentos fallidos | Cerrado |
Dos cosas que me gustaría que un revisor se lleve de aquí. Los viewsets inseguros sin enrutar se eliminaron, no se corrigieron — código muerto que habría sido peligroso el día que alguien lo conectara. Y la corrección incluye una prueba que verifica que el router público exponga únicamente los endpoints previstos, porque la falla nunca estuvo en el código sino en el ruteo.
Método
Qué hace que el código construido con agentes se sostenga
Cada commit de este repositorio es mío, y la mayor parte del código se escribió con agentes de IA. Con 922 commits eso solo funciona con andamiaje, y el andamiaje es la habilidad real.
Un archivo de convenciones que los agentes sí respetan
El CLAUDE.md del repositorio abre con la única regla que rompe todo si se viola: los comandos de Django se ejecutan dentro de Docker, nunca en el host. No son preferencias de estilo — es la restricción que produce fallas silenciosas y difíciles de diagnosticar.
Subagentes hechos a medida
Un revisor de código, un arquitecto de dominio dental y un arquitecto Django/React, cada uno con su propio encargo. Revisar el dominio e implementar son trabajos distintos y reciben agentes distintos.
Una capa de servicios, exigida
Diez apps tienen un paquete services/. La lógica de negocio vive ahí, no en los modelos ni en las vistas — el límite que evita que el código generado se desparrame a la capa equivocada.
Las pruebas como criterio de aceptación
416 módulos de prueba más 77 suites end-to-end de Playwright, con datos sembrados y un subconjunto de ruta crítica. El código generado es barato; la suite es lo que hace seguro aceptarlo.
Diseño documentado antes de implementar
Especificaciones escritas, contrastadas contra los modelos existentes y marcadas explícitamente como aún no construidas. La capa de registro por voz tiene tres y cero migraciones.
Una pasada adversarial sobre mi propio trabajo
La revisión de seguridad existe porque el código que uno no tecleó a mano merece más escrutinio, no menos. Trece hallazgos sobre una base de código propia son el argumento a favor de la práctica.
Stack
Sobre qué corre
| Backend | Django 5.2, Django REST Framework 3.15, drf-spectacular para OpenAPI |
| Datos | PostgreSQL 17, llaves primarias UUID, borrado lógico con espejo de auditoría |
| Asíncrono | Celery + Redis — recordatorios, recitas, solicitudes de reseña, sincronización de calendario |
| Autenticación | Sesiones de Django, tokens Knox, acceso sin contraseña para pacientes por enlace mágico y OTP por SMS, bloqueo con django-axes, SSO de Google para el personal |
| Frontend | Stimulus.js + TypeScript como mejora progresiva sobre plantillas de Django; Jest |
| Integraciones | Google Calendar, SMS por Twilio, WhatsApp Business API y un puente Baileys de WhatsApp Web corriendo como su propio servicio Node |
| Operación | Docker Compose, nginx, respaldos nocturnos del volumen de archivos con rotación, PgHero, Sentry con depurador de datos sensibles |
| Idiomas | Español, inglés y portugués de Brasil |
En resumen
Qué demuestra esto
- Django a profundidad de producción — no una demo CRUD: multi-inquilino, un expediente clínico con semántica de bloqueo, detección de conflictos de agenda por siete vías, manejo y auditoría de información médica.
- El modelado de dominio como el trabajo real — notación FDI, validación por superficie, seis sitios de medición periodontal, códigos CDT. El esquema tenía que estar bien antes que cualquier otra cosa.
- Entrega asistida por IA con las barreras que la hacen creíble — un archivo de convenciones, subagentes a medida, una capa de servicios exigida, 493 módulos y suites de prueba, y especificaciones escritas antes del código.
- El criterio para dejar cosas sin construir — y para auditar, y borrar, mi propio trabajo.
