Apunte de estudio
Diseñar en la era de la IA generativa
Esta semana no empezamos eligiendo un framework ni escribiendo código. Empezamos por una pregunta más importante: ¿qué problema estamos resolviendo y con qué criterio vamos a tomar decisiones?
La IA puede acelerar artefactos; la responsabilidad de formular, decidir y verificar una solución sigue siendo humana.
01
Antes de diseñar: una pregunta
Diseñar software no es elegir la tecnología más reciente. Es transformar una necesidad en una solución que pueda comprenderse, evolucionar y verificarse. Para eso primero necesitamos conocer el problema, sus límites y las consecuencias de cada alternativa.
Situación que afecta a personas u organizaciones y que se busca mejorar.
Condición que limita una solución: tiempo, datos sensibles, reglas o recursos.
Propiedad que indica cómo debe comportarse la solución, además de lo que hace.
Elección justificada entre alternativas, con consecuencias conocidas.
Para pensar: si dos soluciones cumplen la misma función, ¿cuál elegirías y con qué evidencia?
02
IA generativa y criterio profesional
Un asistente puede sugerir nombres, generar casos de prueba o redactar un borrador de arquitectura. Eso no convierte su salida en una decisión correcta para nuestro contexto. Una propuesta puede ser técnicamente posible y, al mismo tiempo, desproporcionada, insegura o difícil de mantener.
Una respuesta generada no reemplaza el análisis de requisitos, contratos, riesgos ni pruebas. Si usás IA en un entregable, registrá qué pediste, qué aceptaste o descartaste y cómo lo verificaste.
03
Conocer el caso: SATE
Durante la cursada trabajaremos con el Sistema de Acompañamiento de Trayectorias Estudiantiles. Hoy las solicitudes de tutoría, la disponibilidad de tutores y los seguimientos se distribuyen entre mensajes, planillas y canales no integrados. Esto dificulta evitar superposiciones, conocer el estado de las intervenciones y obtener información agregada para la coordinación.
Solicita ayuda y consulta el estado de sus tutorías.
Declara disponibilidad y registra un seguimiento breve.
Asigna tutorías, resuelve conflictos y consulta indicadores.
Mantiene roles, usuarios y parámetros básicos.
Primera versión: sí
- Solicitudes y franjas de disponibilidad.
- Asignación compatible de tutorías.
- Estados e historial mínimo.
- Indicadores agregados.
Por ahora: no
- Calendario, correo o mensajería reales.
- Chat, videollamadas o documentos personales.
- Analítica predictiva o recomendaciones por IA.
04
Atributos de calidad: cómo debe ser la solución
Decir “queremos seguridad” o “el sistema debe ser mantenible” no alcanza. Un atributo útil se formula como un escenario: cuando ocurra un estímulo, el sistema debe responder de una manera que podamos comprobar.
Cuando cambie una regla de asignación, el equipo debe poder modificarla sin reescribir la interfaz ni la persistencia.
Separar responsabilidades y mantener contratos claros.
Las reglas de asignación y los cambios de estado deben poder verificarse sin una interfaz ni una base de datos real.
Conservar la lógica de negocio desacoplada de detalles externos.
Un estudiante sólo accede a sus solicitudes; los indicadores no exponen seguimientos individuales.
Definir límites de acceso y respuestas con los datos mínimos.
En el futuro podría agregarse un calendario externo sin alterar las reglas centrales.
Pensar contratos y adaptadores sin implementar todavía la integración.
La primera versión debe poder comprenderse y realizarse dentro de la cursada.
Evitar tecnologías o patrones que no respondan a una necesidad concreta.
Regla práctica: para cada atributo, anotá qué evidencia demostraría que se cumple y qué costo o tensión acepta el equipo.
05
Leer propuestas críticamente
En diseño, el problema rara vez es una alternativa “obviamente mala”. Frecuentemente tenemos ideas plausibles que omiten contexto, costos o riesgos. Observá estos dos borradores para SATE.
Borrador A · “Escalable desde el primer día”
Microservicios para todo
Cinco servicios independientes, bases de datos separadas, eventos, gateway, colas y contenedores desde la primera versión.Preguntá:¿Qué necesidad actual compensa ese costo operativo?
Borrador B · “Rápido de construir”
Todo en controladores
Una única pantalla y controladores que acceden directamente a datos; el coordinador ve toda la información.Preguntá:¿Qué límites de privacidad, evolución y pruebas quedan sin resolver?
- ¿Qué necesidad concreta atiende cada propuesta?
- ¿Qué atributo protege y cuál pone en riesgo?
- ¿Qué supuesto no fue declarado?
- ¿Qué debería probarse o investigarse antes de implementar?
06
Tu carta de diseño inicial
La carta de diseño es el primer artefacto del equipo. No es un diseño terminado: es una evidencia de que empezaron por comprender el problema antes de proponer una solución.
- 01Problema
Describan la situación, quién se ve afectado y qué mejora se espera. No mencionen tecnologías todavía.
- 02Actores y necesidades
Identifiquen quién usa el sistema, qué necesita y qué restricciones son relevantes.
- 03Alcance inicial
Separen con claridad qué se incluirá y qué queda fuera de la primera versión.
- 04Tres atributos priorizados
Para cada uno escriban un escenario verificable, una evidencia y una tensión aceptada.
- 05Preguntas abiertas y regla de IA
Declaren una decisión pendiente, la información necesaria y cómo usarán IA de forma responsable.
Ejemplo de escenario
“Cuando coordinación asigne una tutoría, el sistema debe impedir una franja que se superponga con otra tutoría confirmada del mismo tutor.”La evidencia puede ser una prueba automatizada de la regla de compatibilidad.07
Recorrido de la semana y entrega
¿Qué decide un diseñador?
Clasificá tareas, compará los dos borradores y registrá preguntas que ninguna IA podría responder sin más contexto.
Carta de diseño inicial
Priorizá atributos, completá la ficha en equipo, intercambiá devoluciones y ajustá la carta antes de entregarla.