Linter

La inspiración para Linter nació al observar una crisis invisible pero crítica en el sistema educativo: el colapso del back-office administrativo . Mientras la mayoría de las herramientas de tecnología educativa (EdTech) se centran en crear chatbots para que los alumnos estudien, los docentes y administradores dedican hasta el 27% de su jornada laboral a tareas burocráticas y de cumplimiento normativo, lo que genera un agotamiento extremo y costos millonarios . Nos dimos cuenta de que la revisión del cumplimiento normativo (acreditaciones como CONEAU o ABET, cargas horarias, correlatividades) se hace cruzando a mano cientos de PDFs y planillas . Esto nos llevó a una pregunta técnica: ¿Por qué los programadores tenemos "linters" que auditan automáticamente nuestro código en milisegundos, pero las universidades tardan meses en auditar un plan de estudios? Así nació Linter, una plataforma B2B que convierte reglamentos educativos en reglas ejecutables . ⚙️ Cómo desarrolle el proyecto El desarrollo de Linter se basó en un paradigma híbrido aprovechando al máximo Codex y GPT-5.6 Terra. El rol de Codex: Utilizamos Codex como nuestro motor principal de ingeniería. Le dimos instrucciones arquitectónicas en lenguaje natural y nos generó todo el código fundacional. Programó el backend en Python (usando FastAPI/Flask) y construyó el frontend como una Single Page Application (SPA) con un diseño moderno estilo Glassmorphism sin dependencias complejas. Ingesta de Datos: Integramos la librería pdfplumber en el backend para extraer el texto de los programas de cátedra (Syllabi) directamente de los PDFs, evitando modelos OCR pesados que ralentizan el sistema . El rol de GPT-5.6: Utilizamos el modelo de razonamiento para mapear semánticamente los estándares obligatorios contra los textos extraídos . Para representar esta auditoría de forma lógica, el sistema detecta los huecos normativos o "brechas" calculando la diferencia entre lo que exige la regla y lo que el documento realmente prueba. Matemáticamente, este vacío curricular (B curr ​ ) se puede modelar como: B curr ​ =C declaradas ​ ∖(I ense n ˜ adas ​ ∩E evaluadas ​ ) Donde C declaradas ​ representa las reglas o competencias obligatorias por ley, I ense n ˜ adas ​ son los contenidos efectivamente detectados en el plan de estudios, y E evaluadas ​ son los criterios de evaluación . Linter detecta matemáticamente ese vacío y lo reporta. 🚧 Desafíos que enfrentamos El caos de los datos no estructurados: Los planes de estudio en PDF son notoriamente difíciles de leer. El principal desafío fue evitar que la IA alucinara con formatos extraños. Lo resolvimos limitando el alcance del MVP: el backend rechaza explícitamente PDFs escaneados sin capa de texto y requiere OCR previo, lo que mantiene el sistema rápido y confiable. Determinismo en las respuestas: Un panel de diagnóstico web no puede funcionar si la IA devuelve respuestas en lenguaje natural impredecible . Solucionamos este gran desafío arquitectónico utilizando Structured Outputs de OpenAI . Esto forzó a GPT-5.6 a devolver un esquema JSON estricto (overall_status, rules, disclaimer), permitiendo que nuestro frontend renderice las alertas rojas y verdes de forma determinista y sin fallos. 🧠 Qué aprendimos Codex como acelerador exponencial: Aprendimos que Codex no solo escribe código, sino que toma decisiones de arquitectura viables si el prompt es lo suficientemente claro. Nos ahorró horas de configuración y nos permitió concentrarnos en la lógica de negocio. El poder de Structured Outputs: Comprendimos que para construir productos B2B empresariales, la IA no debe ser un "chatbot", sino un motor de clasificación y validación de datos. El valor del Back-Office: Descubrimos que la mayor oportunidad de negocio en la educación hoy en día no está en las aulas virtuales, sino en automatizar los flujos de auditoría y gobernanza invisibles que mantienen a flote a las instituciones

Built With

• codex
• css3
• fastapi
• gpt-5.6
• html5
• javascript
• json
• openai
• pdfplumber
• python
• structured-outputs