195 lecturas Nueva Historia

Codificar puede no ser el mejor uso de tu tiempo ya

por Sidharth Raja5m2025/04/24
Read on Terminal Reader

Demasiado Largo; Para Leer

La codificación sigue siendo sólo una parte del proceso general de ingeniería de software.
featured image - Codificar puede no ser el mejor uso de tu tiempo ya
Sidharth Raja HackerNoon profile picture
0-item
1-item


He estado escribiendo código durante los últimos 18 años, y profesionalmente durante unos 8 años (incluyendo en Google, Uber) - y tengo que decir que realmente me ha gustado.


Y lo que no es amar? debo pasar la mayor parte de mi tiempo construyendo cosas divertidas, el ciclo de retroalimentación de recompensas era estrecho y mis herramientas se mejoraban bastante cada unos años.Sintax highlighting, auto-complete, IntelliSense, refactorings a nivel de proyecto, e incluso los primeros Github Copilot todos hicieron que mi experiencia de escribir código sea más alegre.Con cada generación de mejoras, se sintió que estas mejoras me ayudaron a ser un mejor codificador.


Esta última ola se siente muy, muy diferente. Con la programación de agentes (*cose* vibe-coding), no se siente como otra actualización incremental.


Entonces, cuando vi a un agente de código una vez más una pequeña pero todavía algo ambigua tarea en mi base de código, de repente se despertó sobre mí. Ya no se siente como si estuviera “codificando”, sino como si estuviera “delegando”.“Siente el tiempo”Momentos de todo tipo.

Todavía me siento como si estuviera "dirigiendo" o "programando" el sistema.Pero lo que es diferente es que ahora estoy programando una organización de codificadores de agentes para lograr el objetivo, en lugar de programar directamente el ordenador.


Una verdadera realización

El valor económico de saber cómo “codificar” ha ido a cero.El hecho es que todo el mundo ahora tiene (o pronto tendrá) acceso a un ejército de codificadores cada vez más brillantes en su bolsillo.


Es una comprensión amargamente dulce. empecé con@AmasoSu sentimiento aquí, después de un tuit en el que dice que “ya no piensa que debería aprender a codificar”.

Codificación para el beneficio del usuario Codificación para el beneficio del usuario

Codificar para divertirse es divertido. En los días de subgrado, realmente disfruté de la programación competitiva también. Mi equipo incluso fue a los regionales de ACM-ICPC Asia dos veces, y generalmente tuvimos una explosión. Hay una cierta prisa que viene de averiguar un problema, y escribir código para resolverlo. No es completamente diferente de un rompecabezas o un sudoku o un problema de matemáticas. Por supuesto, podrías obtener ayuda para hacerlo (erm. cheat!), pero eso no es el sentido de ello. Esta es una mentalidad artesanal. Codificación por el bien del arte. Para la mera diversión del juego.


Cuando trabajas en un producto, en gran parte necesitas echar esa mentalidad por la ventana. Aquí, el código existe principalmente para servir al producto y al usuario. Es un medio para un fin. El usuario final no le importa si lo escribí, o instruyó a un agente para escribirlo. El usuario sólo se preocupa de que funcione. Correctamente, de forma confiable, segura, rápida. Que puedan olvidar que existe, y continuar con su día. Así que la pregunta se convierte entonces en “¿Cuál es la forma más rápida de llegar a (buen, mantenible) código que hace eso?”


Desafortunadamente, parece que la respuesta a eso es que puedo tener que aprender a... salir del camino.Que quizás en su mayoría no debería estar escribiendo código más, porque hacerlo me haría la barrera, o peor aún - el obstáculo.


en“La media ha terminado”, Tyler Cowen habló sobre la dinámica de los equipos “humano + ordenador” en ajedrez. tales equipos (sorprendentemente) todavía tenían una ventaja incluso tan recientemente como 2013, pero la línea de tendencia de la contribución humana al equipo era clara.“Para qué son buenos los humanos”:


Es interesante observar un enfoque al punto de inflexión, donde incluso los seres humanos más talentosos se mueven de ser contribuyentes muy reales a ser producto marginal estrictamente cero.

Es interesante observar un enfoque al punto de inflexión, donde incluso los seres humanos más talentosos se mueven de ser contribuyentes muy reales a ser producto marginal estrictamente cero.


Una dinámica similar parece estar jugando aquí en la codificación. Por ahora, parece que todavía puedo agregar valor al mirar la salida de la máquina y agregar valor sobre ella, pero una vez más - por cuánto tiempo?. lo que actualmente es bueno para el prototipo rápido hoy mejorará y será el constructor de sistemas robustos mañana.


Por un lado, las cosas de bajo nivel que se abstraen no son nuevas para el campo. Ciencia de la Computación, mucho más que otros campos tiene una rica historia de compostabilidad. Las posibilidades son que no hayas escrito en código de máquina o ensamblaje en un tiempo si nunca (gracias a los compiladores!).


Por ahora, sin embargo, la codificación sigue siendo sólo una parte del proceso general de ingeniería de software.Y simplemente resulta que la forma en que puedo aportar el mayor valor a este sistema ya no es con mi capacidad de codificación, es con mi visión y capacidad de articular lo que quiero, y dirigir esta organización de agentes hacia ese objetivo.Es eliminar la ambigüedad lo más posible, y para cerrar la brecha entre la visión y la especificación.


¿A dónde vamos de aquí?

Debido a que es como la delegación, los axiomas de la gestión de la organización humana parecen aplicarse a la gestión de la organización de agentes.


  1. Conocer las limitaciones de sus agentes, y delegar en consecuencia.Ellos siempre intentarán de buena voluntad para morder más que pueden masticar.No los dejes.
  2. Configurar sistemas de cheques y balances para capturar cuando un cambio está rompiendo, y para guiar al agente hacia la escritura de buen código.
  3. Establezca un entorno donde los agentes puedan obtener la información que necesitan para tener éxito.La documentación es buena.La separación de las preocupaciones es buena.Una base de código bien organizada es buena.
  4. La paralelización es buena. No esperes a un solo agente de una sola manera, especialmente para tareas de larga duración.Hay una sólida posibilidad de que los futuros programadores de élite se parezcan a los jugadores torrenciales de alta APM Starcraft - comandando y plegando las salidas de su ejército de unidades de agentes.
  5. Y lo más importante, haz tu visión clara y comuníquela claramente, para que el agente pueda ser empoderado para tomar las decisiones correctas que se ajusten a tu marco más amplio.


Y después de todo lo dicho y hecho, cuando finalmente entregas algo, todavía lo estampas con tu sello de calidad. Tu nombre y reputación es tu marca. Como el "líder" de esos agentes, todavía eres responsable de sus resultados.


Trending Topics

blockchaincryptocurrencyhackernoon-top-storyprogrammingsoftware-developmenttechnologystartuphackernoon-booksBitcoinbooks