La emacsificación del software
(sockpuppet.org)- Gracias a los agentes de IA, ahora es posible crear apps nativas personales en cuestión de horas, y el software se está moviendo hacia el terreno de la personalización al estilo Emacs
- MDV.app es un visor de Markdown para macOS, y en pocas horas implementó búsqueda, indexado con SQLite FTS, marcadores, tabla de contenido y memoria de posición
- El problema de que cada app de Electron cargue con su propia copia de Chromium y la dificultad de desarrollar UI nativa eran grandes, pero Claude maneja SwiftUI con soltura
- Como en la cultura de Emacs, están aumentando las herramientas hiperespecíficas para resolver molestias personales, y el valor de las ideas, las observaciones y los prompts está creciendo más que el de los productos terminados
- La programación con agentes facilita añadir una UI agradable de usar a proyectos paralelos y herramientas de terminal, y convierte la creación de UI nativa en algo divertido
Por qué hice mi propio visor de Markdown
- En el desarrollo de software, Markdown se ha usado como una lengua común desde antes de los LLM, y tras la llegada de los agentes, al volver a aumentar las herramientas TUI, la experiencia de seguir leyendo Markdown desplazándose en la terminal se volvió todavía más difícil de soportar
- Como visores TUI de Markdown existen glow de Charm y Markless creado por Josh; Markless incluso permite navegar por la tabla de contenido, pero la terminal suele usar fuentes monoespaciadas, lo que cansa en lecturas largas
- En macOS hay editores gráficos de Markdown como Obsidian, Typora y Bear, y se leen bien, pero todos son editores, así que en cuanto abres un archivo
.mdse altera tu entorno de edición y la disposición de ventanas que ya tenías - Los visores de Markdown de la App Store al principio parecen razonables, pero al usarlos de verdad aparecen problemas: no tienen búsqueda, incluyen compras dentro de la app, o no permiten copiar al portapapeles el texto seleccionado
- En 2026, en vez de seguir buscando un visor más o menos adecuado, cambié de dirección al decidir que podía generar con un agente de IA el visor de Markdown que quería
MDV.app hecho con Claude
- MDV.app se construyó en pocas horas hasta llegar a un nivel mejor que el de los visores de Markdown dedicados que encontré en la App Store, y el tiempo real de interacción fue de unos 30 minutos
- Configuré Xcode y git en una MacBook vieja, preparé el entorno de Claude, y la preparación previa —como buscar ayuda sobre Swift y diseño en macOS— ya la venía haciendo desde semanas antes
- MDV no es la mejor aplicación para macOS ni un software especialmente extraordinario, pero como visor dedicado de Markdown para macOS es suficientemente bueno y mejora mucho la calidad de vida
- Las funciones principales de MDV son seleccionar y copiar texto del documento, búsqueda de cadenas fijas, indexado SQLite FTS de todos los archivos Markdown del historial editable, marcadores con atajos de teclado y navegación por tabla de contenido
- Recuerda la posición al moverse entre documentos y continúa incluso tras reiniciar, además de ofrecer temas de color y tipografía cómoda para leer, de modo que al hacer clic en un archivo
.mdse abre de inmediato el entorno de lectura deseado
Los límites de Electron y el cambio en la UI nativa
- Cada vez que llegaba un mensaje de Signal, la pantalla parpadeaba, y no se detenía hasta ocultar explícitamente la app de Signal, así que ese sutil parpadeo continuaba hasta casi provocar migraña
- Este fenómeno ocurre porque Signal es una app de Electron: por fuera parece una app nativa de macOS, pero en realidad funciona como una copia de Chromium renderizando una página web secreta
- Casi todas las apps de UI de la última década parecen cargar cada una con su propia copia de Chromium, y Electron, aunque no es una gran opción, ha sobrevivido como una alternativa suficientemente aceptable
- Hacer UI realmente nativa históricamente ha sido difícil, y era complicado encontrar incluso personal de nivel promedio a quien encargarle ese trabajo; los desarrolladores realmente competentes de UI nativa para macOS eran escasos
- Claude no solo reemplaza a un desarrollador promedio de SwiftUI, sino que en la práctica se le puede considerar alguien que maneja SwiftUI con verdadera soltura
Cómo la cultura de Emacs se filtra hacia todo el software
- MDV, más que un producto terminado que se recomiende instalar y usar, se entiende mejor como algo del que conviene robar ideas para crear una versión mejor, igual que un usuario de Emacs mira una configuración brillante de
.emacs - En la cultura de Emacs, los usuarios de largo tiempo crean con elisp aplicaciones para resolver molestias personales que comenzaron en la edición de texto, y esas herramientas se expanden más allá de lo que razonablemente debería hacer un editor de texto
- /r/emacs se parece más a una cultura de mostrar lo que hiciste que a una promoción de productos al estilo Product Hunt; hay paquetes de elisp muy usados, pero salvo Magit, existe una fuerte tendencia a rehacerlos cada quien en una versión todavía más vistosa
- La debilidad de la cultura de Emacs era que, salvo Magit, los paquetes tendían a ser feos y lentos, y ofrecían malas experiencias de usuario que solo se descubrían después de mucho tiempo lidiando con elisp
- Los agentes de IA empujaron esta cultura fuera de Emacs, y al volverse posible crear UI nativa de forma confiable siempre que se tenga acceso a la pantalla y a la entrada, la UI nativa pasa del terreno de los programas empaquetados profesionalmente al de la personalización individual
El potencial de las herramientas nativas personales
- El software emacsificado será en su mayoría software personal útil solo para quien lo hizo, y, como los viejos programas en elisp olvidados dentro de
.emacs, habrá muchas herramientas que queden en el olvido - A veces, alguno de estos programas puede cruzar esa frontera y volverse lo bastante útil como para que varias personas lo instalen, pero incluso entonces puede que lo más importante no sea el artefacto distribuido ni el código fuente
- Si el agente escribió todo el código SwiftUI, entonces la idea y la observación de que “esto también se puede hacer y funciona bien” pasan a ser más importantes que leer el código fuente en detalle
- En este tipo de software, el prompt puede valer más que el código fuente, y para quien ya está acostumbrado a hacer funcionar software por su cuenta, todo se vuelve programable no solo en lo técnico sino también en lo práctico
- Llamar “construir” al software hecho con agentes parece exagerar el esfuerzo invertido; la sensación real se parece más a configurar sobre una plataforma que de pronto se volvió mucho más configurable
- Los desarrolladores que usan IA por fin están terminando proyectos paralelos aleatorios que llevaban años acumulando
- Ahora, esas herramientas hiperespecíficas no solo pueden completarse, sino también tener una UI agradable de usar, lo que debilita parte de la vieja justificación de tener que tolerar la UI torpe de Emacs
- Ha crecido mucho la posibilidad de mejorar apps de terminal con mucha más facilidad, y herramientas como
iostat,iostatsobre múltiples hosts, obpftrace, también pueden convertirse en formas más fáciles de entender - La complejidad que Brendan Gregg tuvo que soportar para la visualización en terminal de
bpftraceya no tiene por qué aceptarse tal cual, y de hecho también hay un ejemplo hecho directamente - Como investigador de vulnerabilidades, el avance del desarrollo de exploits basado en programación con agentes durante la primera mitad de 2026 fue interesante, pero para la mayoría fue un cambio acompañado de miedo; en cambio, que crear UI nativa se haya vuelto divertido es una noticia casi puramente buena
- Se recomienda crear herramientas excesivamente específicas para tus propios problemas, disfrutarlas un rato y luego compartirlas, o mejor aún, compartir capturas de pantalla y los prompts usados
1 comentarios
Comentarios de Hacker News
Creo que ya podemos retomar, como nerds, áreas que hoy en su mayoría se convirtieron en software especializado preempaquetado: apps de pódcasts, apps para escuchar música, lectores de feeds, clientes de Bluesky, apps de notas, apps de marcadores/leer después en escritorio, chat y mensajería, rastreadores de tiempo, gestores de recetas, etc.
Con Claude se puede conseguir fácilmente algo mejor que una alternativa existente. Tal vez no sea la mejor app ni una competitiva a nivel mundial, pero sí una que se adapte mucho mejor a tu forma rara de trabajar.
Music.app es horrible de usar, pero Apple ya separó hace mucho la funcionalidad central en MusicKit. Ahora el producto real es MusicKit, así que no sé por qué seguimos usando Music.app, y eso es un cambio nuevo.
Un experimento en esa dirección es https://github.com/dharmatech/9social.
El primer cliente lo escribí para plan9, y eso mantiene honesto el diseño. Si funciona en plan9/rc/acme, entonces tiene sentido.
El demo en video está en https://youtu.be/q6qVnlCjcAI y la implementación actual tiene menos de 3000 líneas de código.
Ya que hablamos de Emacs, 9social se inspiró mucho en el proyecto de Emacs Org Social: https://github.com/tanrax/org-social
Es una interfaz incompleta basada en hoja de cálculo para capturar tiempo. La hice para consultoría, pero nunca llegué a guardar los datos. Tiene un algoritmo simpático que puede procesar casi cualquier forma natural en que la gente anota el tiempo; la hice porque me molestaba que los rastreadores de tiempo existentes te obligaran a usar entradas estructuradas: https://stackoverflow.com/a/49185071/59087
Gestor de recetas: https://repo.autonoma.ca/repo/recipe-fiddle
En la era de los LLM va a ser mucho más fácil clasificar ingredientes y dar formato en TeX para publicar en PDF. La idea de este proyecto era tomar recetas web o escaneos manuscritos, casi con copiar/pegar, y formatearlos automáticamente.
En F-Droid no había ninguna app que cumpliera todo eso, así que simplemente hice yo mismo el APK.
Gracias a la era de los LLM, producir software se volvió tan fácil que siento que todo se convirtió en un archivo .emacs. O sea, cada persona termina con su propio capullo de software completamente personal y personalizable sin fin.
Como dijo el OP, ahora es más fácil crear tu propia solución que instalar o aprender una ya existente.
Lisp también es una buena analogía. Una vieja crítica a las macros de Lisp era que cada programador acababa transformando todo en su propio lenguaje privado, ilegible para los demás.
También me recordó el texto de Mark Tarver de 2007, "The Bipolar Lisp Programmer": https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
Él hablaba de la "brilliant bipolar mind", y curiosamente toca algo del tema de la AI psychosis del que se habla tanto hoy, en serio o en tono irónico.
En el texto de Tarver https://www.marktarver.com/bipolar.html dice que el "throw-away design" de la comunidad Lisp encaja perfecto con el BBM. Lisp hace tan fácil improvisar algo y descartarlo, que cada quien arma su propia solución y siente que basta con que le sirva a sí mismo.
En cambio, en C/C++ hacer algo significativo es tan difícil que se siente como un logro, y eso motiva a documentarlo y colaborar. Desde la perspectiva de un empleador, 10 personas que se comunican, documentan y trabajan juntas son más atractivas que 1 hacker de Lisp difícil de reemplazar.
Cuando producir se vuelve fácil, consumir pasa a ser el cuello de botella, y compartir se vuelve difícil. Los archivos .emacs son tan personales como una huella digital: puedes sacarles pedazos, pero no quieres usar entero el de otra persona.
Mientras más se personalicen esos capullos, más difícil será que otros quieran entenderlos o usarlos. El costo cognitivo es alto y también resulta incómodo, como ponerse ropa ajena. Más que AI psychosis, tal vez habría que llamarlo solipsismo de IA.
En software, la parte difícil está pasando a ser la gestión de la configuración. ¿Cómo compartimos y versionamos la fuente? ¿Qué es la fuente? ¿El prompt? El OP al final también se inclina por compartir capturas de pantalla y prompts más que código.
Incluso en Show HN ya soltaron el globo de ensayo de que el código generado dejó de ser la fuente y que habría que compartir prompts, pero recibió mucho rechazo de quienes sí saben: https://news.ycombinator.com/item?id=47213630
GitHub inevitablemente recibe presión por esta tendencia. No está claro cómo será su sucesor, pero tarde o temprano hará falta. Por ahora parece la etapa del carruaje sin caballos.
Más importante aún es el trabajo en equipo. Si todos somos BBM, o si cada uno tiene una legión maníaca de BBM generando cosas 24/7 solo para él, ¿cómo vamos a trabajar juntos? ¿Cómo se comunicarán e interoperarán esos capullos? Un equipo de solipsistas de IA suena contradictorio.
Los equipos y startups que están en la frontera del desarrollo guiado por IA y por agentes seguramente ya están viviendo esto en la práctica. Cosas como cómo combinar mi código generado con tu código generado. Es muy probable que parte de la ganancia de productividad del código generado se devuelva por esta fricción.
Lástima que todavía no se hable mucho de esto en público. Nadie quiere ser el primero en sentarse durante la ovación obligatoria, pero si fingimos que es un almuerzo gratis sin desventajas, la conversación se vuelve aburrida y la evolución se hace lenta.
Si la gente que hace el trabajo más serio y avanzado con estas herramientas nuevas no habla de sus desventajas, entonces las críticas se las queda solo el bando cínico que cree que la IA no aporta nada al desarrollo de software. Hoy parece más difícil hablar de aumento de bugs o de estancamiento de productividad que de extinción humana.
Quiero saber qué está pasando realmente, cómo responde la gente y cómo cambia esto con el tiempo. Hasta me pregunto si tendré que ir a meetups.
El título de un paper relacionado era justamente "Easier to Write, Harder to Read": https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
¿Por qué tendría que leer el resultado de una conversación específica con un LLM? Si sé el tema, puedo tener yo mismo una conversación mejor.
Con este tipo de software pasa algo parecido. Puede haber algo de gusto personal, pero en la mayoría de los casos lo importante son las ideas y la receta.
Estaría bueno hacer un hilo mensual de "Vibe HN".
Me gustaría ver un video de alguien compartiendo un WhatsApp hecho a medida en menos tiempo, sin siquiera empezar a hablar del problema de convencer a otras personas de usar un mensajero improvisado.
Ahora es más como "voy a meter este ticket en Claude, tú inténtalo con Copilot y comparemos resultados" o "yo hago el PR con mi resultado tosco y tú lo revisas con tu herramienta". Sinceramente, se siente casi sin sentido, y el pair programming está completamente muerto.
¿A quién le interesa ver a varias personas correr agentes, arreglar problemas en distintos árboles de trabajo y corregir inconsistencias en agents.md?
Estoy empujando la idea de construir pipelines cloud totalmente autónomos que se operen solos, pero parece que la gerencia prefiere mantener eso en silencio. Da la impresión de que entienden muy bien que, en el momento en que se demuestre que eso realmente puede volar, algunos van a perder puestos muy cómodos.
UNIX no era un producto, sino un entorno optimizado para crear herramientas y resolver problemas reales, y las herramientas se escribían en C. Mientras tanto, los BBM seguro andaban ocupados con Lisp en Boston.
C++ es una historia completamente distinta, y ahí sí hace falta un IDE.
Emacs tiene esa naturaleza porque usa Lisp. Esa tendencia general de que los programadores terminen construyendo todo por sí mismos ya se observó en Lisp, y se llamó The Lisp Curse.
Es una maldición porque los programadores dejan de colaborar. Todos se convierten en magos encerrados en su torre, el progreso general se detiene y llega una edad oscura.
Sí, la era de los LLM ha traído software personal.
Pero, siendo honesto, el tiempo que pasé usando Emacs no me enseñó a construir software personal. Mi configuración de Emacs era extremadamente frágil, y tratar de usarla a la vez en Windows y macOS fue una pesadilla.
Hice un proyecto universitario con una combinación rarísima de org-mode y algún workflow para producir un bonito archivo LaTeX, y hoy no podría explicar cómo compilarlo otra vez. Si lo intentara, probablemente le pediría a un LLM que lo tradujera directamente a LaTeX.
En mi vida quiero la menor cantidad de mantenimiento posible, y construir yo mismo todo no siempre encaja con ese objetivo.
Sí reescribí una aplicación de NETFX en Rust, porque me fastidiaba que instalarla tomara 20 minutos: https://github.com/bevan-philip/wlan-optimizer
El trabajo cotidiano de un programador consiste en cambiar el comportamiento de sistemas computacionales, ya sean locales, remotos, cloud o embebidos. Los requisitos cambian, el alcance se mueve, el espacio del problema evoluciona y la sedimentación es inevitable.
Hay que moverse constantemente entre stacks de lenguaje, tipos de datos, formatos, herramientas CLI y web, protocolos, paradigmas, software open source y aplicaciones privativas.
Así que hay que adaptarse continuamente, y tu propio plano de control también tiene que adaptarse al cambio. La clave es la automatización. Toda pequeña molestia se puede y se debe automatizar. Eso implica deformar tus workflows sin parar, es decir, mantenimiento continuo de herramientas, pero no el mantenimiento reactivo y doloroso.
Ser programador y no querer seguir construyendo software para uno mismo es una ilusión. Es como un chef que en el restaurante prende el fuego pero en su casa ni toca un cuchillo.
Emacs es la cocina de casa del chef. Hay un mantenimiento reactivo, que es reparar fallas y seguirle el paso al cambio, y un mantenimiento generativo, que es moldear herramientas a medida que evoluciona tu comprensión. Los programadores deberían odiar el primero y sentirse atraídos por el segundo.
Emacs es casi único en lo bien que encaja con el mantenimiento generativo, porque la herramienta y el trabajo comparten la misma disposición.
Es común quejarse de que "configurar Emacs da demasiado trabajo", pero normalmente eso significa "no quiero invertir antes de obtener valor". A largo plazo no es una estrategia inteligente. Tiene más sentido ver Emacs como una herramienta universal para reducir la carga total de mantenimiento de toda una carrera y de toda la vida.
Las configuraciones de Emacs o VIM son simples archivos de texto: se pueden abrir con un editor cualquiera y ajustar según haga falta, y sabes dónde está cada cosa. Mi configuración de VIM tiene 20 años, y hace apenas 1 o 2 años dejé la gestión manual de paquetes para pasar a un gestor de plugins.
Aquí no hay gatekeepers ni dependencias.
En cambio, la forma actual implica pagarle de 20 a 200 dólares a una empresa tercera o tener una GPU bastante potente para correrlo localmente, además de poner instrucciones en un archivo de texto y seguir corrigiéndolas hasta que salga como quieres.
Eso es agregarte dependencias a ti mismo, y si se enreda tanto que a un humano ya le cuesta revisarlo, entonces esa dependencia se vuelve una dependencia fuerte. Da igual si se trata de una GPU cara o de mandar tus datos a una empresa que tiene que mantener contentos a sus accionistas.
Hay que distinguir cómo se diferencian estas dos cosas y cuál es el costo real que estamos pagando.
La idea de software personal, o sea escribir programas para uno mismo, era la visión original de la computación doméstica en los años 60.
No se predijo exactamente la PC, pero sí existía la idea de que todos tendrían en casa una terminal de computadora y escribirían programas para hacer lo que necesitaran. Se imaginaba que programar se volvería lo bastante fácil para que cualquiera pudiera aprenderlo.
Todavía no llegamos ahí, pero con los LLM nos estamos acercando.
La idea es que gente no profesional pueda construir software interesante en un entorno de autoría con componentes bien diseñados y metáforas fáciles de entender. Las capas de complejidad accidental o sobreingenierizada tendrían que desaparecer.
Incluso en esa visión, el software sigue requiriendo pensamiento lógico cuidadoso, pero se reduce mucho la molestia de trasladar ese pensamiento a código ejecutable. Tampoco hay pesadillas de toolchains ni sistemas de build.
En cambio, nosotros construimos modelos demasiado poderosos para que repitan y recombinen por nosotros hechizos complejos. Pero la complejidad sigue ahí, y para la gente no técnica sigue siendo opaca.
Aun así, los LLM podrían ayudar a eliminar parte de esa complejidad. Sigue siendo posible una dirección donde el software generado por LLM sea fácil de entender y modificar por personas individuales, y además eso puede complementar bien al mundo LLM.
No es una cuestión de si va a pasar, sino de cuándo: a lo mucho en 10 años, y probablemente mucho antes. Ya tengo familiares que no saben programar y están haciendo este tipo de cosas.
Este futuro de la computación es realmente hermoso y da muchísimo poder a la gente.
Mi app actual en Swift tiene 15 mil líneas; 5000 son tests y 10 mil son implementación. Ya casi está terminada y hace lo que necesito. Me tomó 20 horas.
Nunca había hecho Swift, así que si la hubiera construido yo mismo probablemente me habría tomado 500 horas.
Como la mayoría somos flojos, probablemente no lleguemos tan lejos, pero sin duda vale la pena pensarlo.
La idea misma de "aplicación" se volverá mucho más fluida.
Si una app está hecha en un lenguaje dinámico, no hay razón para que los usuarios no reescriban el código ellos mismos y agreguen funciones totalmente nuevas.
No está relacionado directamente con el artículo principal, pero no estoy de acuerdo con la idea de que el terminal, por ser casi siempre monoespaciado, canse para leer textos largos. Personalmente, me resulta mucho más cómodo leer textos largos con tipografía monoespaciada.
El autor señaló algo interesante. Las variables que importan son la dificultad de crear la herramienta, la dificultad de publicarla, la utilidad para otros, la recompensa social por publicarla y el incentivo negativo de sumar dependencias.
Qué tan difícil sea encontrar una solución existente aumenta según el costo de que alguien la construya y el costo de que alguien descubra cómo publicarla. En cambio, mientras más útil sea para la comunidad, más fácil es encontrarla porque la gente la difunde.
Si la dificultad de crear y la dificultad de publicar difieren mucho, especialmente si crear es mucho más difícil, la gente tiende a hacer algo para sí misma y luego olvidarlo. Si publicar es barato, aparecen menos soluciones a los problemas.
Si ambas son baratas, y la utilidad para otros y la recompensa social superan el costo de las dependencias, entonces se produce una situación tipo leftpad. Muchos paquetes de NPM combinan alta utilidad y recompensa con bajo costo de dependencia.
En Emacs Lisp, antes crear era difícil pero ahora ya no, y una vez que superas la curva de aprendizaje, publicar también es fácil. La utilidad, la recompensa y el costo de dependencia tampoco son especialmente altos en ninguna dirección.
Entonces se da el escenario en el que uno simplemente lo construye antes siquiera de buscar si ya existe una herramienta. VSCode o el viejo Eclipse eran distintos porque publicar era más difícil.
Apuesto a que alguien más joven que yo va a convertir esto en tema de investigación y lanzarlo al mundo.
Este texto insinúa un cambio todavía no realizado que podría traer el coding con LLM. ¿No podríamos ya dejar atrás Electron/React Native y hacer que un LLM convierta Figma, wireframes y especificaciones de comportamiento en apps verdaderamente nativas para cada plataforma?
Para apps CRUD, con una especificación de API, mocks de UI e incluso capturas de pantalla de una plataforma ya implementada, se puede avanzar bastante. Ese tipo de trabajo bien definido es precisamente el que los LLM hacen bien. También debería poder automatizarse buena parte de las pruebas de equivalencia.
¿Todavía seguirá existiendo la excusa de "algún día quizá añadamos Android" o "no hay suficientes usuarios de Mac/Linux"? ¿Seguirá siendo justificable que una app iOS abra un WebView arbitrario para flujos menos usados como restablecer contraseña?
Incluso para apps con lógica no trivial dentro del dispositivo, los LLM ya han mostrado bastante potencial para reescribirlas en lenguajes como Go o Rust, donde la compilación cruzada es fácil.
Y para decirlo de forma más provocadora: a estas alturas, ¿por qué habría que aprender SwiftUI? Para la mayoría de los trabajos, especializarse en SwiftUI ya cae en una categoría parecida a "aprender Microsoft Word a profundidad".
Respeto a quienes invierten ese tiempo, pero lo hagas o no, la diferencia en resultados ya es casi de milímetros.
No pienso así de la programación en general. Solo creo que ahora es más complicado justificar la especialización en ciertos lenguajes.