本站提供正體中文版。切換到正體中文本站提供简体中文版。切换到简体中文This site is available in English.View in Englishこのサイトには日本語版があります。日本語で表示이 사이트는 한국어로도 제공됩니다.한국어로 보기Diese Website ist auch auf Deutsch verfügbar.Auf Deutsch ansehenQuesto sito è disponibile anche in italiano.Visualizza in italianoCe site est également disponible en français.Afficher en françaisEste site também está disponível em português.Ver em portuguêsDeze website is ook beschikbaar in het Nederlands.In het Nederlands bekijkenЭтот сайт также доступен на русском языке.Смотреть на русскомयह वेबसाइट हिन्दी में भी उपलब्ध है।हिन्दी में देखेंهذا الموقع متاح أيضًا باللغة العربية.عرض بالعربيةSitus ini juga tersedia dalam bahasa Indonesia.Lihat dalam bahasa IndonesiaBu site Türkçe olarak da mevcut.Türkçe görüntüleTa strona jest dostępna także po polsku.Wyświetl po polskuTrang web này cũng có phiên bản tiếng Việt.Xem bằng tiếng Việtاین وب‌سایت به فارسی هم در دسترس است.مشاهده به فارسی

De «con que funcione basta» a «con confianza para cambiarlo»: el diario de un mes programando de un novato

IA2026.04

Antes de nada, una aclaración: no soy ingeniero de software, y todo lo que cuento aquí sobre programación es, en realidad, lo que llaman Vibe Coding, esa forma de ir dejándose llevar por la intuición.

Un portátil sobre el escritorio muestra código; al lado hay notas adhesivas, una pequeña pizarra con el flujo de los cambios anotado, un temporizador pomodoro, un diario de programación escrito a mano y una taza con un gato

Últimamente, para que el trabajo fluya un poco mejor, llevo un tiempo desarrollando mis propias herramientas pequeñas. En estos dos días hice tres cosas: empecé a hacer copias de seguridad con Git, corregí unos cuantos bugs en la lógica del programa y conecté un nuevo modelo de IA.

Lo más difícil no es la sintaxis, sino «convertir lo que quieres en código»

Tras un mes, mi mayor conclusión es esta: lo más difícil de programar no es, en realidad, la sintaxis, sino convertir «qué es lo que uno quiere en el fondo» en «código concreto».

Por ejemplo, «corregir un bug» se dice en dos palabras, pero antes de ponerte manos a la obra tienes que hacerte un montón de preguntas:

  • ¿Guardo primero?
  • ¿Abro una rama nueva?
  • ¿Cuándo pruebo? Y ¿cómo pruebo?
  • Una vez hecho el cambio, ¿qué cuenta como «terminado»?
  • ¿Marco de paso un número de versión?

En realidad, ninguna de estas es una cuestión de programación, sino de «hábitos de trabajo». Puede que este flujo sea de lo más común en el sector, pero para un principiante en programación es, sencillamente, una pesadilla.

Unas cuantas cosillas que aprendí

En este mes aprendí unas cuantas cosillas, que comparto con los principiantes como yo:

  1. Levanta primero el escudo protector y luego ponte a trastear. Con Git para el control de versiones, aunque lo estropees todo, en treinta segundos puedes volver al pasado: tan tranquilizador como un punto de guardado en un videojuego.
  2. Haz solo una cosa cada vez. Nunca «ya que estoy, cambio una línea más»: eso es justo la clase de cosa que hará que tu yo futuro quiera darse cabezazos contra la pared.
  3. Ir lento es lo normal. ¿Toda una tarde para sacar adelante una sola función pequeña? Sí, eso es el día a día. Esos tutoriales exprés casi siempre te están engañando.
  4. Deja notas para tu yo futuro. Si no, la próxima vez que vuelvas creerás que ese programa lo escribió otra persona. (Vale, sí: este programa lo escribió de verdad una IA.)

De «con que funcione basta» a «con confianza para cambiarlo», lo que se interpone en medio son, probablemente, justo estos hábitos de trabajo que parecen insignificantes y que, sin embargo, hay que ir añadiendo uno a uno.