- Se comparte todo el proceso de desarrollo de la función de notificación automática de actualizaciones no intrusiva de Ghostty en macOS, creada principalmente con herramientas de codificación agéntica con IA; en 16 sesiones, con un costo de tokens de $15.98, se completó en unas 8 horas una función realmente lista para desplegar
- A partir del incidente en el que un prompt de actualización de Ghostty interrumpió una demo durante la keynote de OpenAI, se decidió cambiar a un enfoque no modal que muestra el estado de actualización mediante un pequeño elemento GUI en la barra de título o en la parte inferior de la ventana sin interrumpir el trabajo
- Antes de usar IA, primero se estableció un plan general de backend/frontend aprovechando el protocolo de UI personalizada del framework Sparkle y los controladores de accesorios de la barra de título, y luego se usó la IA como herramienta de prototipado
- Se usó un enfoque por etapas: prototipado de UI, cambio de rumbo cuando fallaba la solución de bugs y sesiones repetidas de limpieza (documentación, refactorización) para mejorar el rendimiento de futuras sesiones con IA y generar código de simulación
- Se destaca el valor de un modo de trabajo asincrónico que permite hacer otras cosas, como preparar el desayuno de la familia, mientras la IA trabaja, y se mantiene la regla de desplegar todo el código generado por IA solo después de una revisión manual exhaustiva y de no desplegar código que no se entiende
Resumen de la función
- La función terminada es una notificación de actualización no intrusiva que no tapa la ventana en macOS
- Muestra el estado de actualización dentro de la ventana de la terminal sin interrumpir el trabajo, por ejemplo creando una ventana o tomando el foco
- El incidente del prompt de actualización de Ghostty durante la keynote de OpenAI confirmó la necesidad de mejorar la UX
- Se decidió que la notificación de actualización fuera no intrusiva
- En vez de una ventana emergente, se optó por mostrar en algún lugar un pequeño elemento GUI no modal que no molestara al usuario
- La posición predeterminada de la notificación sería a la derecha de la barra de título, con alternativas como una superposición en la parte inferior de la ventana según el estilo, por ejemplo si la barra de título está oculta
- Aunque se usaron agentes de IA durante todo el proceso de desarrollo, se adoptó una estrategia de herramienta de apoyo dirigida por humanos, combinándolos con correcciones manuales, pulido y revisión final
Planificación antes de usar IA
- Antes de abrir la herramienta de IA, primero se elaboró un plan general
- Con una idea general del backend, se pasó a pensar el frontend
- Había una idea vaga de incrustar un pequeño botón en la barra de título
- Ya se sabía que macOS soporta UI personalizada en la barra de título mediante controladores de accesorios de la barra de título, pero no estaba claro el aspecto ni la experiencia exactos
- Con eso, ya había un punto de partida suficiente
- Como la IA es excelente para prototipar, basta con saber qué es lo que uno no sabe para poder empezar
- Ya había una intuición lo bastante sólida del panorama general
Primera sesión: prototipado de UI
- Prompt inicial de la primera sesión de codificación agéntica
- Personalizar
SPUUserDriver para notificaciones de actualización no intrusivas y solicitudes para activar la instalación
- Limitar el trabajo solo a la UI
- Pedir un plan para crear una vista SwiftUI capaz de mostrar los distintos estados que requiere
SPUUserDriver
- Pedir un plan para mostrarla en la esquina superior derecha de la barra de título de una ventana de macOS
- ¿Oracle? - Un subagente de solo lectura exclusivo de Amp, que usa un modelo más lento y más caro, generalmente mejor para razonar
- Se decidió enfocarse primero en el prototipo de UI
- No se envió al agente a construir toda la función completa
- Primero, porque todavía no se sabía qué forma debía tener la UI/UX, así que no se podía esperar de manera consistente que la IA resolviera eso entre otros cambios
- Segundo, porque los bloques de trabajo pequeños son más fáciles de revisar, entender e iterar
- Se pidió que escribiera solo el plan y que no escribiera código
- Como era una solicitud relativamente ambigua, era importante revisar el plan antes de que hiciera mucho trabajo (y consumiera muchos tokens)
- Tip: crear de forma interactiva un plan integral con el agente es un primer paso importante en tareas no triviales
- Normalmente se guarda en un archivo como
spec.md, y en sesiones futuras se puede pedir “consulta @spec.md y realiza alguna tarea”
- El agente presentó un plan lo bastante convincente como para permitir avanzar con la implementación
- La UI generada iba muy bien encaminada
- Había muchos temas de pulido (espaciado, colores, etc.), pero ver la UI dio el chispazo de inspiración sobre lo que se quería
- Tip: se usa la IA con mucha frecuencia para obtener inspiración; en este caso se conservó gran parte del código de UI generado (aunque no todo), pero también pasa muy seguido que se le da un prompt al agente, se descarta todo y se rehace manualmente
- La etapa creativa de “cero a uno” es muy difícil y consume mucho tiempo, y la IA funciona muy bien como musa
Chocando contra una pared
- Entre los chats 11 y 14 se entró en la zona de chapuza
- El código generado por el agente tenía bugs serios y fracasó por completo al intentar corregirlos
- Yo tampoco sabía cómo arreglarlos
- Se hicieron varios intentos desesperados para corregir los bugs
- Si el agente lo resolvía, se podía investigar y aprender
- Incluso si fallaba, el costo era casi nulo
- Si el agente lo resolvía pero no se entendía, se revertía; no se despliega código que no se entiende
- Mientras fallaba, se cambiaba de pestaña para buscar el problema e intentar resolverlo por cuenta propia
- En este punto se reconoció que había que tomar distancia, revisar lo hecho y elaborar un plan propio
- Era momento de educarse por cuenta propia y pensar críticamente
- La IA ya no era una solución, sino una deuda
Sesiones de limpieza
- Las siguientes sesiones se dedicaron a guiar al agente para ordenar el código
- Segunda sesión: mover algunos métodos a una mejor ubicación
- Se movieron y generalizaron más las funciones de fondo de relleno, primer plano y badge desde
UpdateAccessoryView.swift hacia UpdateViewModel.swift
- Tercera sesión: agregar documentación al código
- Se actualizó la documentación de
UpdateBadge.swift
- Tip: agregar documentación ayuda a reconfirmar la propia comprensión del código y a entrenar a futuros agentes que leerán y modificarán este código
- Los agentes rinden mucho mejor cuando cuentan tanto con explicaciones en lenguaje natural como con código
- Cuarta sesión: mover el view model a una ubicación de alcance global en la app
- El trabajo original lo había puesto en el ámbito de la ventana, pero la información de actualización pertenece al ámbito de la app
- En este proceso también se hicieron, como de costumbre, pequeños cambios manuales
- Importancia de la etapa de limpieza
- Para ordenar el código de forma efectiva hay que tener una comprensión bastante buena de él, por lo que esto obliga a no aceptar ciegamente el código escrito por la IA
- Un código mejor organizado y documentado ayuda a mejorar el rendimiento de futuras sesiones agénticas
- En broma, a esto lo llaman “sesiones anti-chapuza”
Frente a los bugs
- Era momento de volver al bug encontrado en la sesión inicial
- Se gastaron varias sesiones más para que el agente pudiera entenderlo
- Se empezó de forma ambigua y poco a poco se fue haciendo más específico el enfoque
- Primera sesión ambigua: en el caso de las pestañas nativas estándar, la vista accesoria de actualización no se ve; debía permanecer visible en la barra de título de la ventana - fracaso
- Segunda más específica: actualizar las restricciones de la barra de pestañas en TerminalTabsTitlebarTahoe.swift para alinear el borde derecho de la barra de pestañas con el borde izquierdo de la vista accesoria de actualización - fracaso
- Tercer intento con otro enfoque específico: ¿y si se cambia TitlebarTabsTahoeTerminalWindow.swift para que la barra de pestañas sea una vista accesoria superior en lugar de una inferior, poniendo así las pestañas en la barra de título? - fracaso
- Intento final: la vista accesoria derecha y su layout entran en conflicto con la configuración de la vista accesoria de actualización en TerminalWindow.swift; ¿se puede limitar para que la barra de pestañas aparezca siempre a la izquierda de la notificación de actualización? - fracaso
- Durante todo este proceso también se intentó resolverlo por cuenta propia con investigación manual y esfuerzo humano
- Los prompts más específicos se basaron en lo aprendido durante ese proceso
- En general, claramente no estaba funcionando
- Al concluir que no podía resolverse en solitario, se decidió cambiar de dirección
- Para el estilo de barra de título problemático, colocar la notificación de actualización en la esquina inferior derecha, superpuesta sobre la vista de contenido de la ventana en vez de la barra de título
- Ghostty tiene una configuración para ocultar por completo la barra de título, así que de todos modos esto debía soportarse
- Incluso si después se lograba resolver el problema del estilo de barra de título, este otro modo igual tendría que seguir soportándose
- La siguiente sesión avanzó con este plan y usando un prompt muy específico
- Reforzar el sistema Update para que también soporte el enfoque de superposición en TerminalView.swift
- La notificación de actualización debía aparecer en la parte inferior de la ventana y mostrarse sobre el texto (por lo tanto, sin redimensionar la vista del terminal)
- Todo el comportamiento de clics igual al de la vista accesoria
- Lo hizo realmente bien; después hubo mucho trabajo manual de pulido (mover, renombrar, etc.), pero la parte central quedó sólida
Inicio del backend
- Se sintió que la UI ya estaba lo suficientemente bien
- Se anotaron muchos temas de pulido para tratar después, pero sobre todo se quería pasar al trabajo de backend para descubrir incógnitas desconocidas que pudieran echarle una llave inglesa al plan
- Se creó manualmente un archivo scaffold con funciones incompletas y varios comentarios
TODO. Nueva sesión iniciada
- Se pidió completar UpdateDriver.swift y leer la documentación de Sparkle para entender la funcionalidad
- Tip: la AI es muy buena llenando espacios en blanco o terminando de dibujar el búho
- El patrón de crear scaffolding con nombres de funciones descriptivos, parámetros, comentarios todo, etc., es muy común y funciona bien
- En realidad hizo un muy mal trabajo, así que se descartó todo ese código
- El código generado funcionaba, pero era claramente un enfoque equivocado
- Mezclaba muchas otras preocupaciones y la forma en que guardaba estado en el driver era obviamente incorrecta
- Al estudiar lo que había hecho, quedó claro que el view model estaba estructurado de una manera no óptima
- Se cambió al modo limpieza para darle a la AI (y al humano, si se optaba por escribirlo a mano) un mejor framework
Gran relimpieza
- Por experiencia, la limpieza del frontend de UI y del backend de lógica de negocio suele estar determinada por la calidad del view model intermedio
- Se dedicó tiempo a reestructurar manualmente el view model
- Se cambió de structs con muchos optionals a tagged unions, además de renombrar y mover algunos tipos
- Por experiencia, se sabía que este pequeño trabajo manual en medio ayudaría a llevar al agente al éxito en futuras sesiones tanto de frontend como de backend
- Tras completar la reestructuración, lo primero que se hizo fue pedirle al agente una vez más que terminara de dibujar el búho
- Esta vez, inspeccionó los cambios, actualizó el código dependiente al nuevo estilo y eliminó el código anterior
- Siguió una serie de sesiones maratónicas de limpieza
Simulación
- En la primera sesión de UI, se le pidió al agente generar código de demo para poder ver realmente la UI sin verificar actualizaciones reales
- El flujo de actualización tiene varios escenarios y hasta este punto solo se había probado el happy path
- En la siguiente sesión, se extrajo el código de simulación a un archivo dedicado y se le pidió al agente generar más escenarios
- Extraer el código de simulación de actualizaciones de AppDelegate.swift a un archivo dedicado dentro de Features/Update
- Incluir varios escenarios de simulación (happy path, no encontrado, error, etc.) para poder probar fácilmente distintas demos
- Tip: el agente destaca generando pruebas y simulaciones
- El código de simulación generado aquí, siendo sinceros, es bastante terrible, pero funciona y no forma parte del binario de release, así que la calidad no importaba
- Ni siquiera se limpió más allá de lo básico visible en la sesión
- Al ejecutar varias simulaciones, se descubrieron múltiples mejoras de UX
Última milla
- En este punto ya había backend y frontend funcionando, y solo faltaba conectarlos
- En la siguiente sesión, se le dio este prompt al agente
- Crear una clase UpdateController para el tipo updater, igual que Sparkle en SPUStandardUpdaterController.m
- Se necesitó algo de ida y vuelta y pulido manual, pero se logró
- Luego se añadieron mejoras menores
- Para el estado actualizable con appcast, revisar SUAppcastItem y mostrar otros metadatos relevantes si están definidos
- Por ejemplo, el content length para el tamaño
¿Algo más?
- En cuanto al agente, el último prompt siempre debe preguntar qué faltó
- Hacer esto sin importar si el código se escribió manualmente o no
- Si hay otras mejoras que se puedan hacer en la función Features/Update, no escribir código, pedir consultoría tipo Oracle y considerar qué partes del código podrían recibir más pruebas unitarias
- Como destacó un problema real, le pidió que lo implementara
- Descubrió que es más fácil decirle al agente que "haga todo" que preguntarle por cosas específicas a realizar, ya que después puede ordenarse fácilmente en commits opcionales
- Lo divertido de esta sesión fue que el agente de verdad empezó a meterse en una madriguera de conejo totalmente loca y tuvo que intervenir para decirle que parara
- "Para, para, para. Cancela todos los elementos del actor principal"
- También encontró una mejor manera de hacerlo, después de darse cuenta de que lo había resuelto de forma algo deficiente
- En el caso de los mensajes de error, en vez de recortarlos, ¿no hay una forma estándar de SwiftUI? Hace falta agregar un elemento extra de UI para poder ver el mensaje completo
Costo y tiempo
- El trabajo se hizo en un total de 16 sesiones separadas en Amp con un gasto de $15.98 en tokens
- Normalmente no intentaría adivinar si eso es caro o barato, pero personalmente gastó más que eso en la cafetería durante los 2 días que dedicó a esta función
- Estima que el tiempo real total dedicado a esta función fue de unas 8 horas
- Aunque el primer y último commit abarcan 3 días, solo trabajó en la computadora unas 4 horas por día
- No dedicó todo ese tiempo únicamente a esta función
- Por ejemplo, mientras trabajaba en esta función también hizo el despliegue de la actualización de Ghostty, apareció como invitado durante 1 hora con ThePrimeagen y dio una presentación como invitado en el evento anual de toda la empresa de Zoo
- Tiene un niño pequeño en casa, así que el "tiempo de computadora" está muy programado y es muy limitado
- Por eso, la estimación de 8 horas probablemente es generosa
- Mucha gente en internet debate si la AI permite trabajar más rápido
- En este caso, cree que lo publicó más rápido de lo que lo habría hecho si hubiera hecho todo por su cuenta
- Sobre todo porque las iteraciones triviales de estilo en SwiftUI le resultan personalmente demasiado aburridas y consumen demasiado tiempo, y la AI es muy buena en eso
- Más que el debate de si es más rápido o más lento, lo que más le gusta: la AI puede trabajar para él mientras él se va a hacer otra cosa
- Tomó una foto de una de las sesiones de limpieza mientras preparaba el desayuno para su familia
- Hay todo tipo de objeciones del estilo "no quiero programar mientras cocino" o "deberías estar más presente"
- Está bien si quieres hacerlo así; en su caso, en este ejemplo específico, era la primera persona despierta en casa y estaba preparando el desayuno mientras todos los demás seguían dormidos
- No hace esto en cada momento en que está despierto
- Conclusión: a él le funciona
- No está tratando en absoluto de convencer a nadie
- No tiene ninguna relación financiera con ninguna empresa de AI
- Como alguien que ha tenido mucho éxito con herramientas de AI y le gusta hablar de ello, la gente siempre le pide que comparta ejemplos
- Eso es lo que está haciendo aquí
Conclusión
- La función quedó bonita y funciona muy bien, y se fusionó después de una revisión manual final
- La "revisión manual final" es muy, muy, muy importante; no publicar código escrito por AI sin una revisión manual exhaustiva
- Si eres usuario de Ghostty y usas la versión tip, ya está disponible
- Si usas versiones etiquetadas, estará disponible en Ghostty 1.3
- Es un defensor abierto de la importancia de compartir públicamente las sesiones de coding agéntico
- Una de las razones es que es una forma increíblemente poderosa de enseñar a otras personas cómo usar estas herramientas de manera efectiva
- Espera que esta publicación ayude a mostrar eso
2 comentarios
Opinión de Hacker News
Yo uso la IA con frecuencia como herramienta de inspiración; esta vez también mantuve bastante código de UI generado por IA, aunque a veces pongo a un agente a trabajar y luego tiro todo y lo reescribo yo mismo (¡a mano!). La etapa de creación de "cero a uno" siempre es muy difícil y consume mucho tiempo, así que la IA realmente destaca como mi musa. Ese es justamente el mayor beneficio de los agentes de código. Mucha gente se preocupa por el mantenimiento o el enredo de los proyectos centrados en IA, pero a mí no me preocupa. Si puedo llegar rápido al punto en que ya puedo jugar de verdad con la funcionalidad del proyecto y seguir corrigiéndolo, después de eso de verdad agarro velocidad. Hasta ese "momento dorado" está, para mí, el 80% más costoso de programar. Por eso, honestamente, no entiendo muy bien las posturas en contra de los agentes de código. Incluso si al final solo queda código para desechar, siento que eso por sí mismo tiene un valor claro. P. D.: al tocino siempre hay que pesarlo
Hace poco hablé de este tema con alguien, y yo también estoy mayormente de acuerdo. Estas herramientas son excelentes porque te permiten crear con facilidad prototipos que puedes tocar directamente para probar ideas. Pero hay dos problemas. Primero, ya de por sí es un dolor de cabeza convencer a otros de que un prototipo que parece casi terminado en realidad está muy lejos de estar listo para producción, y el código basado en LLM está todavía más lejos de producción que los prototipos que yo hacía antes. Segundo, con los prototipos que hago a mano aprendo directamente sobre el stack tecnológico y la implementación. El objetivo principal es hacer algo rápido, pero en el proceso saco muchas lecciones técnicas, y a menudo mis prototipos terminan influyendo incluso en la dirección técnica. En cambio, en los prototipos basados en LLM ese código en sí casi no sirve para nada, y si de verdad vas a empezar algo, casi tienes que volver a empezar desde cero. Validaste la idea, pero sientes que no validaste ni la tecnología ni el diseño. Aun así, sigo creyendo que es útil. Yo tengo la filosofía de que "los prototipos deben hacerse rápido", y con LLM he podido ensamblar sistemas bastante grandes casi al instante. Solo que hace falta un cambio de concepto en el proceso. Un prototipo sin LLM equivale más o menos al paso 4 o 5 de 10, pero un prototipo con LLM está más cerca del paso 2. Eso no es malo, pero sí hay que ajustar las expectativas sobre cuánto trabajo queda después del prototipo, porque ahora queda más que antes
Es importante tu forma de ver eso de que "una vez que el proyecto llega al punto en que ya puede avanzar un poco por sí mismo, entonces progresa enseguida". Para mí, al contrario, la etapa de "cero a uno" es la más gratificante y divertida. En ese momento hay muchísimas posibilidades y puedes crear algo que antes no existía. Si la IA me marca el rumbo de antemano, siento que perdería bastante de esa creatividad
Por tu opinión, parece que el miedo a la página en blanco es una preocupación importante. Entiendo que una herramienta que elimina eso aporte mucho a la productividad. Pero no todo el mundo tiene la misma preocupación. El desarrollo de software es una actividad muy personal, así que el flujo de trabajo y la experiencia de cada quien pueden ser distintos. No se trata de que una forma sea mejor que otra, sino de que cada persona necesita herramientas diferentes y es importante reconocer y confiar en la experiencia de cada quien tal como es. En la controversia sobre los LLM, ambos lados tienden a asumir que ellos y el otro son iguales
Esta semana vi una entrevista sobre el entorno de desarrollo de Mitchell, y me llamó la atención cuando, al preguntarle por qué usa neovim, respondió: "No quiero herramientas que escriban código por mí". No lo digo como crítica, pero vale la pena notar que incluso un gran desarrollador como Mitchell ve valor en los LLM, a diferencia del viejo intellisense
Yo les explico esto a mis colegas como "usar la ley de Cunningham conmigo mismo" Cunningham's Law: 'la forma más rápida de obtener la respuesta correcta en internet no es hacer una pregunta, sino publicar una respuesta incorrecta'. Si me quedo mirando una pantalla en blanco sin pensar mucho, puedo pasarme bastante rato en blanco, pero en cuanto tengo algo que criticar, de inmediato me vuelvo productivo
De verdad respeto la opinión de Mitchell ante lo de OpenAI, aunque termine siendo algo positivo para ghostty. Casi nunca he visto empresas de software que intenten reducir activamente la frustración o las molestias de los usuarios, especialmente si piensas en cosas como MS Auto Update; es un cambio muy bienvenido. Además, este texto muestra un uso responsable de la IA al programar; yo no creo que encaje para nada con la definición original de vibe coding, esa de la que tanto se exageraba
Aquí, la propia palabra "vibe coding" me parece un concepto que no encaja para nada. Ese término se ha usado de más por todos lados
Coincido con lo de "usar la IA responsablemente en programación". Esto no es vibe coding, sino vibe engineering, como lo planteó por primera vez simonw aquí. Post relacionado
Como referencia, en Ghostty hace poco volvieron obligatorio revelar cuando se usan herramientas de IA para programar enlace al PR relacionado
Este texto muestra por qué los agentes de IA son especialmente fuertes para trabajar con frameworks de UI. Yo también desarrollo apps con Rust y GTK, y mi flujo de trabajo es muy parecido. No es que yo no sepa cómo implementar algo, sino que la IA me ayuda muchísimo porque se encarga de la mayor parte de la búsqueda repetitiva, aburrida, y del ensayo y error al trabajar con frameworks de UI. Mitchell entiende el código completo durante todo el proceso. Ya sabe qué tiene que hacer, y en ese sentido no se parece en nada a lo que llaman "vibe coding". No hay atajos aparte para llegar a ser experto. Me encanta Ghostty
Gracias a los LLM, programar volvió a ser divertido. En el trabajo, los LLM me ayudan con el primer paso más difícil, el arranque, así que puedo empezar a trabajar muy rápido. También son realmente útiles para entender una base de código nueva o escribir las partes aburridas. Pero la verdadera diversión empieza con los proyectos personales. Ahora puedo materializar ideas improvisadas realmente rápido. Ya no tengo que gastar horas escribiendo código boilerplate o peleándome con el tooling. Lo que no domino se lo delego a un agente o saco una función de un solo prompt, y si no me convence el resultado, simplemente lo revierto
Pregunta un poco tangencial: no entiendo por qué casi todas las apps todavía necesitan tener su propio framework de actualización. ¿No se podría integrar esa función en la app store o en el gestor de paquetes?
En el ecosistema de macOS esto es bastante difícil
Por ejemplo, en Ubuntu esto es bastante conveniente. Si descargas e instalas directamente la versión más reciente, después sigues recibiendo actualizaciones automáticas
Al final, justo esa parte en la que admites que no eres bueno —es decir, la etapa de cero a uno—, si se la dejas a la IA, se vuelve un área que nunca podrás aprender directamente por tu cuenta. Si quieres seguir pudiendo hacerlo tú mismo en el futuro, tienes que practicarlo por tu lado
Ghostty me gustó muchísimo, y estuve a punto de dejar iTerm, pero cuando presioné cmd-f y no pasó nada, me rendí página de issues y feedback
Si hubiera tenido cmd-f desde el principio, me pregunto de qué se habría hablado en los posts sobre ghostty. Ya hasta cansa un poco escuchar esto en todas las publicaciones. En realidad podría haber discusiones mucho más interesantes sobre herramientas LLM o sobre formas de programar, pero al final todos terminan hablando de cmd-f
Curiosamente, el fin de semana pasado estuve usando Claude para implementar búsqueda en Ghostty. La búsqueda real ya tenía un código medio rudimentario funcionando, así que la mayor parte fue conectarla con la UI. En dos sesiones (unas 10 horas en total), logré que la búsqueda básica, el resaltado y el movimiento al resultado anterior/siguiente funcionaran en el frontend de Linux. Esta función de búsqueda sigue estando claramente en WIP, así que todavía no está lista para uso general. Mientras trabajaba en esto, me quedó muy claro lo complejo que es hacer que incluso una función que parece tan "básica" funcione sobre texto en streaming
A mí también me pareció que Ghostty es demasiado minimalista, así que tristemente volví rápido a Warp. Por cierto, el tamaño predeterminado del búfer de scrollback de Ghostty es de unos 10 MB, pero se puede ajustar todo lo que quieras en la configuración
Esta función de búsqueda está prevista para marzo de 2026 como objetivo de la v1.3 enlace al roadmap
Al leer la parte del artículo que dice "veamos qué llevó a agregar esta función", volví a pensar en cuántas incomodidades seguimos soportando en los sistemas operativos. Las presentaciones y el screen sharing ya existen desde hace décadas, así que sigo sin entender por qué todavía es tan difícil incluso una configuración básica que permita forzar que solo la ventana de presentación quede expuesta en pantalla
Es Ghostty, una herramienta a la que Mitchell Hashimoto, cofundador de HashiCorp, está dedicando casi todo su tiempo últimamente.
Ghostty 1.0 ya disponible - emulador de terminal rápido y multiplataforma
Llega libghostty
Mientras defiende la codificación agéntica, dice que compartir sesiones es realmente importante,
y parece que la mayoría de los enlaces apuntan a sesiones de AMP Amp - herramienta de codificación agéntica