Software maleable: bases sólidas y código personalizado
Malleable software = solid bases and custom code
Tras 22 años en el mercado de herramientas de productividad, el autor analiza el auge de la IA y su impacto en la creación de software. Sostiene que la solución ideal es combinar una base sólida (80%) con código personalizado (20%), y compara las opciones actuales: desde construir desde cero con Codex o Claude Code hasta usar herramientas maleables como Notion o Fibery. Predice que las bases sólidas más código personalizado dominarán el mercado, y que las herramientas maleables tienen ventaja por su capacidad de añadir puntos de extensión rápidamente.
Las bases sólidas cubren lo que es idéntico para cada equipo, y el código personalizado cubre lo que hace diferente al tuyo.
- watty
Gran perspectiva, ¡estoy de acuerdo con el autor! Echa un vistazo a mi [INSERT VIBE CODED GITHUB LINK] que sigue estos patrones.
- momojo
Me encanta esta visión. En el campo de la bioimagen, Napari es un gran ejemplo de esto. Una base maravillosamente sólida, pero extremadamente extensible ya que es todo Python hasta el fondo.
Hay algo maravilloso en que mi colega venga con un problema y pueda crear un plugin de Napari que resuelva exactamente su problema antes del almuerzo.
Mi orden de 'escalada de herramientas' suele ser:
- ¿Puedo resolver su problema desde la terminal integrada de napari?
- ¿Puedo resolverlo con un script de una sola vez?
- ¿Puedo resolverlo con un script de una sola vez que cree una interfaz de plugin de una sola vez?
- ¿Debería añadir el plugin a nuestro repositorio de la empresa ya que este problema parece ocurrir a menudo?
- mickael-kerjean
Ese es el camino que he seguido con mi alternativa a Dropbox [1]. El 80% es el núcleo rápido que se centra en la gestión de archivos, el 20% restante viene a través de plugins que implementan una de las interfaces del núcleo para que puedas manejar tu propio almacenamiento, autorización, autenticación, aplicaciones personalizadas para manejar tipos de archivo, ... Dato curioso, hay 10 veces más código en los diversos plugins [2] que atienden a todo que el código del núcleo que se suponía que era el 80%, sin sorpresa, todos necesitaban un 20% diferente. Además, me parece genial que el tipo que necesitaba un sistema de registro conforme a gobd con un montón de propiedades para mantener contentos a los auditores, aplicando hash encadenados firmados con rfc3161, no contribuye a empeorar el sistema para todos los demás.
[1] https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/fdrive
- genatron_ai
Tener esa base funcional que los agentes pueden personalizar después es un gran enfoque porque obtienes algunos de los beneficios de código heredado donde hay patrones establecidos que pueden seguir. Esto es a menudo mucho más rápido y predecible en comparación con empezar desde cero, donde incluso aunque el desarrollo agéntico es rápido, necesitas tener una verdadera mentalidad de desarrollador y pensar en todo.
- pavo-etc
Pi es un gran ejemplo de esto. Lo he usado como base para un ejército de agentes que estoy ejecutando en mi servidor, pero en lugar de usar la TUI de Pi lo ejecuto en modo sin cabeza y lo he extendido para usar XMPP como su capa de comunicación para poder usar cualquier dispositivo con las mismas sesiones, y para que los agentes puedan hablar entre ellos.
El arnés de Pi está construido para extenderse así, y es un placer trabajar con él.