El código ya es barato; el verdadero cuello de botella es decidir qué no construir
When Anyone Can Build Software, Who Decides What Not to Build?
Cuando generar software deja de ser costoso, lo que se vuelve escaso es el juicio antes del compromiso. El artículo sostiene que el código es desechable, pero el estado —datos, integraciones, obligaciones regulatorias y procesos— persiste durante años. La incoherencia empresarial no nace de malas decisiones locales, sino de decisiones locales buenas tomadas de forma independiente. El autor defiende una función de arquitectura que arbitre antes de comprometer capital, datos y comportamiento organizativo.
Cuanto más barato resulta crear software, más caro se vuelve lo incoherente.
- deminature
Construir software de calidad con LLMs sigue llevando mucho tiempo. La gran mayoría de la gente no se va a molestar, sin importar lo bajo que sea el umbral de entrada, porque el tiempo no es gratis. Eso y que hacer software no le interesa a la mayoría de la gente, por la misma razón por la que ensamblar electrónica no le interesa a la mayoría. Es un interés de nicho con un atractivo masivo limitado. Por esas dos razones, la profesión del software sobrevivirá a la IA.
- OakNinja
Este problema no es nuevo. Lo nuevo es que cualquiera puede entender el problema central que intenta resolver sin involucrar a un equipo de desarrollo mediante ideación rápida y prototipado veloz.
Como siempre, luego depende de la empresa priorizar en qué enfocarse, tal como ha sido siempre.
* No te aferres a una idea o a la salida de un prompt solo porque le dedicaste tiempo.
* Escribir código es fácil. Mantenerlo es difícil.
* Si no ahorra tiempo o genera ingresos, es solo un gasto.
* La producción no equivale al valor.
- anonzzzies
Nosotros (mi empresa) tenemos una 'base' corporativa de LoB que, acumulada a lo largo de unos 40 años, contiene cualquier proceso que puedas imaginar y, usándola, simplemente miramos a las grandes corporaciones y sus procesos y ofrecemos automatizarlos, a nivel departamental para que no necesiten aprobación del consejo ni del departamento de IT para pagarlo. La IA de última generación puede hacer esto en uno o dos días con nuestra base, casi por sí sola, y cobramos justo por debajo de los presupuestos departamentales. Tenemos que enviar a desagradables y sarcásticos 'project managers/vendedores' a las muchas reuniones, ya que, por supuesto, estos mandos intermedios quieren parecer útiles, así que esas reuniones son objetivamente inútiles para nosotros pero una miseria necesaria de todos modos. Ellas (las reuniones en el mundo físico) son, por supuesto, ahora mucho más caras que la parte (solo) técnica, incluso si valoras el framework en algún costo de licencia y SLA.
Estas corporaciones, y son mayormente multinacionales, en su mayoría propiedad de dueños estadounidenses, indios o chinos, y literalmente todos sus departamentos de IT apestan; atascados en Java o C# de hace 20 años con 0 incentivo para mejorar o aprender nada; han oído hablar de la IA pero no la usan para nada.
Esto es un tren de dinero fácil, vale miles de millones en cualquier región si logras entrar en el nivel correcto. No estoy seguro de que dure, porque, en mi experiencia, la mayoría de estas personas en esos departamentos pueden ser reemplazadas por un LLM corriendo en un iPhone hoy mismo, y las aplicaciones de LoB son bastante aburridas si tienes un consultor sólido con unas décadas de conocimiento; ¿deben estar entrenando LLMs para hacer justo eso?
- CurleighBraces
Siento que es más matizado que esto, al menos por ahora.
Es cierto decir que cualquiera puede construir software, pero eso no hace que el software sea bueno y no es cierto decir que eso depende específicamente del gusto.
Como ejemplo, estoy trabajando con un emprendedor que no tiene experiencia en programación pero ha creado con éxito un producto que además ya vendió a una empresa mediana.
Sin embargo, sin mi participación y sin conocer las palancas correctas para moldear la IA, el software simplemente no rendía como necesitaba, a pesar de que los últimos modelos frontera se esforzaban al máximo por lograr lo que él decía.
Al menos por ahora sigue habiendo necesidad de desarrolladores experimentados.
- ma2kx
Estoy algo confundido. Es una publicación interesante, pero no estoy seguro de haber entendido exactamente a dónde iba con su "policy as code". Concluye que "policy-as-code produce coherencia empresarial sin una función de arquitectura central", con lo que estaría de acuerdo, pero argumentaría que pasa por alto que hoy hay una falta de infraestructura / empresa como código. Al menos si quieres que un agente sea capaz de resolver o al menos estar al tanto de los problemas con los que empezó. Como que las políticas definen los límites de nuestro entorno de trabajo, pero no el trabajo en sí. Este "know how" es mayormente implícito para las personas pero invisible para los LLMs y limita el marco de contexto en el que opera el agente a su prompt dado (y quizás restringido por las políticas si están en el contexto).
Como si tomo su ejemplo:
"El personal de primera línea puede estar saltándose campos obligatorios porque el proceso añade quince minutos de fricción a cada interacción con el cliente".
Primero, no está claro cuál es la política para esos campos cuando son obligatorios y también se pueden saltar. Luego, ¿por qué son obligatorios si saltarlos parece solo reducir la fricción sin otras consecuencias? ¿Cómo debería decidir un modelo si debe hacer cumplir la política para esos campos, codificar una automatización o simplemente hacerlos voluntarios?