本站提供正體中文版。切換到正體中文本站提供简体中文版。切换到简体中文This site is available in English.View in Englishこのサイトには日本語版があります。日本語で表示이 사이트는 한국어로도 제공됩니다.한국어로 보기Diese Website ist auch auf Deutsch verfügbar.Auf Deutsch ansehenEste sitio web también está disponible en español.Ver en españolQuesto sito è disponibile anche in italiano.Visualizza in italianoCe site est également disponible en français.Afficher en françaisDeze 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 “basta que rode” a “ouso mudar e fazer funcionar”: o diário de um mês de programação de um novato

IA2026.04

Antes de mais nada, um aviso: eu não sou engenheiro de software, e o que conto aqui sobre programação é, na verdade, tudo aquilo que chamam de Vibe Coding, aquele tipo em que você vai seguindo o feeling.

Um notebook sobre a escrivaninha exibindo código; ao lado, notas adesivas, um pequeno quadro branco com o fluxo das alterações anotado, um timer pomodoro, um diário de programação escrito à mão e uma caneca com um gato

Ultimamente, para deixar meu trabalho um pouco mais fluido, venho desenvolvendo minhas próprias pequenas ferramentas. Nesses dois dias fiz três coisas: comecei a fazer backup com o Git, corrigi alguns bugs na lógica do programa e integrei um novo modelo de IA.

A parte mais difícil não é a sintaxe, é “transformar o que você quer em código”

Depois de um mês, a maior lição é esta: a parte mais difícil de programar não é, na verdade, a sintaxe, mas transformar “o que afinal eu quero” em “código concreto”.

Por exemplo, “corrigir um bug” são três palavras fáceis de dizer, mas, antes de realmente pôr a mão na massa, você precisa se fazer um monte de perguntas:

  • Devo salvar primeiro?
  • Devo abrir um novo branch?
  • Quando testar? E como testar?
  • Depois de terminar, o que conta como “pronto”?
  • Devo, de passagem, marcar um número de versão?

Na verdade, nenhuma dessas é uma questão de programação, e sim uma questão de “hábitos de trabalho”. Esse fluxo talvez seja comuníssimo no ramo, mas, para um iniciante em programação, é simplesmente um pesadelo.

Algumas coisinhas que aprendi

Neste um mês, aprendi algumas coisinhas, que compartilho com os iniciantes como eu:

  1. Primeiro erga o escudo de proteção, depois comece a mexer à vontade. Usando o Git para controle de versão, mesmo que você estrague tudo, em trinta segundos consegue voltar ao passado — tão tranquilizador quanto um ponto de salvamento num videogame.
  2. Faça uma coisa de cada vez. Nunca “já que estou aqui, mudo mais uma linha” — é justamente o tipo de coisa que faz o seu eu do futuro querer bater a cabeça na parede.
  3. Ir devagar é normal. Uma tarde inteira para dar conta de uma única funçãozinha? Sim, é isso mesmo o dia a dia. Aqueles tutoriais de aprendizado-relâmpago, na maioria, estão enganando você.
  4. Escreva anotações para o seu eu do futuro. Do contrário, da próxima vez que voltar a olhar, você vai achar que esse programa foi escrito por outra pessoa. (Está bem, tá: este programa foi mesmo escrito por uma IA.)

De “basta que rode” a “ouso mudar e fazer funcionar”, o que fica no meio são, provavelmente, justamente esses hábitos de trabalho de aparência insignificante que, no entanto, precisam ser preenchidos um a um.