- Apple researchers fine-tuned an open-source coding LLM to generate SwiftUI via an automated feedback pipeline.
- An iterative loop—compile, visual check with GPT-4V, and filtering—created a large, high-quality training set.
- After five rounds, the team built UICoder and nearly 996,000 SwiftUI programs, outperforming the base model and nearing GPT-4 on quality.
- Because Swift was scarce in the original corpus, gains came from the self-generated dataset; the approach likely generalizes to other UI toolkits.
Apple researchers han detallado una forma práctica de enseñar a un modelo de código abierto a escribir interfaces de usuario SwiftUI robustas. En lugar de depender de ejemplos escasos y etiquetados manualmente, el equipo creó un motor de datos que permite al modelo aprender de sus propios resultados bajo supervisión automatizada.
La idea se centra en un bucle de retroalimentación automático que genera código SwiftUI, verifica si compila y comprueba qué tan closely el resultado coincide con una descripción escrita. Se trata de una revisión neutral y medida de cómo un modelo de lenguaje grande puede mejorar progresivamente en la generación de código UI sin necesitar un corpus preexistente masivo de SwiftUI.
Cómo funcionó la canalización de autoentrenamiento
El equipo empezó con StarChat-Beta, un modelo open-source ajustado para tareas de programación, y le proporcionó descripciones concisas de interfaces. A partir de esas indicaciones, el modelo generó un flujo masivo de programas SwiftUI sintéticos diseñados para reflejar los diseños y comportamientos solicitados.
Cada candidato fue sometido a un compilador de Swift para confirmar que realmente funcionaba. Luego, un modelo de visión y lenguaje, GPT-4V, comparó la interfaz renderizada con la descripción original, actuando como un revisor automatizado de fidelidad visual y estructural. Para ampliar tu conocimiento acerca del desarrollo de interfaces, también puedes revisar cómo trabajar con controles deslizantes en SwiftUI.
Cualquier resultado que fallara en compilar, pareciera fuera de tema o duplicara resultados anteriores, era descartado. El resto conformaba un conjunto de entrenamiento de alta calidad utilizado para ajustar el modelo, alimentando la siguiente ronda con ejemplos más limpios y relevantes.
Este ciclo se repitió varias veces. Con cada pasada, el modelo mejorado producía mejores resultados en SwiftUI, lo que generaba datos más precisos para su ajuste. Después de cinco rondas, los investigadores habían recopilado cerca de un millón de programas SwiftUI (996,000) y un modelo ajustado llamado UICoder.
En evaluaciones, UICoder superó al modelo base (StarChat-Beta) en métricas automáticas y valoraciones humanas. Además, logró un mayor porcentaje de éxito en compilación, un beneficio práctico para quienes necesitan que el código funcione a la primera.
Poca presencia de SwiftUI en los datos originales
Parte de la historia radica en el corpus de entrenamiento utilizado para StarChat-Beta. Sus datos provinieron principalmente de tres fuentes, ninguna de las cuales proporcionaba mucho contenido de SwiftUI de manera natural:
- TheStack, una colección muy grande de repositorios de código con licencia permisiva.
- Páginas web rastreadas en Internet público.
- OpenAssistant-Guanaco, un conjunto de datos más pequeño de afinación por instrucciones.
Según los investigadores, los repositorios de Swift fueron excluidos accidentalmente al construir TheStack. Una revisión manual también encontró solo una respuesta con código Swift en aproximadamente diez mil ejemplos de OpenAssistant-Guanaco, con la mayor parte del código Swift que probablemente llegó mediante rastreos web, a menudo más ruidoso y menos estructurado que en los repositorios.
Esta escasez es importante: las mejoras de UICoder no provinieron de reusar ejemplos de SwiftUI ya vistos. La mejora vino del conjunto de datos auto-generado y curado mediante el ciclo de compilación y comparación, que proporcionó la cobertura de SwiftUI ausente en las fuentes originales. Para entender cómo los diferentes lenguajes se integran en la programación, revisa cómo verificar la versión de Swift en tu entorno.
Los autores mantienen que esta metodología podría aplicarse a otros lenguajes y kits de herramientas UI, no solo a SwiftUI. El documento completo—“UICoder: Fine-tuning Large Language Models to Generate User Interface Code through Automated Feedback”—está disponible en arXiv para quienes quieran profundizar en los detalles y métricas.
Este trabajo demuestra que el mayor beneficio para el modelo de Apple para SwiftUI provino de un bucle de retroalimentación automatizado que escala la calidad de los datos, en lugar de partir de un gran conjunto oculto de código Swift. Con UICoder acercándose en calidad a GPT-4 y superándolo en tasa de éxito de compilación, esta estrategia resulta ser una referencia práctica para enseñar a los modelos a generar código UI cuando no hay ejemplos claros disponibles.
