23 pontos por GN⁺ 11 일 전 | 6 comentários | Compartilhar no WhatsApp
  • Em um momento em que agentes de codificação com IA se tornaram comuns, este é o relato de uma desenvolvedora que, ao contrário da tendência, participou de um retiro de 3 meses para programar à mão, sem LLMs
  • Na 6ª semana no Recurse Center, no Brooklyn, ela está construindo um LLM do zero pela primeira vez, aprimorando suas habilidades em Python e fortalecendo ao mesmo tempo sua compreensão das várias camadas de abstração dos computadores
  • Embora agentes de codificação permitam iteração e deploy rápidos, ao escrever código manualmente acontecem ao mesmo tempo duas coisas: expressar o que se quer e aprender a codebase
  • Assim como na analogia de Cal Newport de que "escrever é como se exercitar", ela compartilha a visão de que o esforço mental de construir código é um elemento central da habilidade técnica
  • Com base na observação de que os engenheiros que melhor usam ferramentas de IA tendem a ter conhecimento profundo, ela enfatiza que mesmo na era da IA, fundamentos sólidos criam alavancagem

LLMs e a experiência de programar

  • Nos últimos dois anos, ela vem construindo agentes de IA na Aily Labs, em Barcelona
    • No início de 2024, criou um agente interno de busca na web, cerca de 6 meses antes do texto "Building Effective AI Agents" da Anthropic e aproximadamente 1 ano antes do DeepResearch da OpenAI
    • Foi usuária inicial do Cursor e também participou cedo da construção de grafos de conhecimento com LLMs
  • Liderou um journal club semanal, apresentando artigos sobre construção de LLMs open source
    • Cobriu papers como DeepSeek R1, Olmo 3 da Ai2 e Llama 3 da Meta
    • Isso ajudou a entender os trade-offs entre treinar modelos internamente e construir workflows baseados em modelos fechados SOTA
  • Desde que usou um LLM pela primeira vez em 2023, mantém interesse constante em como eles funcionam e em suas aplicações

Programar diretamente como elemento central da habilidade técnica

  • O que percebeu ao mesmo tempo em que estudava LLMs e os usava para programar
    • Ao escrever código “à mão”, faz duas coisas simultaneamente: escreve o que quer e aprende a codebase ao mesmo tempo
    • Ao usar agentes de codificação, obtém exatamente o que foi especificado no prompt; se o objetivo não estiver claro, o agente toma muitas suposições (assumptions) por conta própria
    • Nesse caso, o aprendizado diminui e a compreensão da codebase enfraquece
  • Ao mesmo tempo, agentes de codificação permitem iteração rápida, deploy confiável de software e também funcionam como excelentes tutores
  • Cita uma coluna do NYT de Cal Newport
    • "Sua escrita deve ser sua. A tensão necessária para escrever uma nota ou relatório claro é a atividade mental equivalente ao treino de um atleta na academia, e não um incômodo a ser removido, mas um elemento central da habilidade"
    • Ela considera que essa analogia se aplica da mesma forma à escrita de código
  • Os excelentes programadores com quem trabalhou na Aily em geral também eram pessoas que usavam IA muito bem, e conhecimento profundo lhes dava alavancagem sobre as ferramentas de IA

O que é um retiro de código

  • O Recurse Center (RC) é um retiro de programação autodirigido e em tempo integral, localizado no Brooklyn
    • Retreat: "um período em que você se afasta temporariamente da rotina para se concentrar em uma atividade específica"
    • A participação ocorre após candidatura e entrevista de programação, e os participantes mergulham em programação por 6 ou 12 semanas
    • Destaca-se por um ambiente colaborativo baseado em coorte com pessoas de diferentes especialidades, incluindo muitos programadores com décadas de experiência
    • É gratuito
  • Objetivos no Recurse Center
    • Aprender LLMs do zero

      • Incluindo pré-treinamento e pós-treinamento, o objetivo é escrever diretamente um Transformer em vez de apenas fazer fork de uma codebase pronta
    • Escrever Python melhor, à mão

      • Apesar de trabalhar com Python há anos, ela sente que ainda há muito a aprender e quer minimizar consultas à documentação ou a LLMs, desenvolvendo intuição sobre como estruturar projetos
    • Entender computadores mais profundamente

      • Parte da percepção de que o computador é uma máquina extremamente complexa, que opera em várias camadas de abstração
      • Como não teve formação formal em Computer Science, quer construir um modelo mental melhor de como essas camadas funcionam juntas
      • Não tem muitos planos concretos, mas considera o RC o lugar certo para isso

Progresso

  • 1. Treinar um LLM do zero

    • Concluiu sem ajuda de LLMs de programação a primeira tarefa do curso CS336: Language Modeling from Scratch, de Stanford
      • Fez a tarefa de 50 páginas junto com outra pessoa do Recurse Center
      • Escreveu um tokenizer otimizado em Python e implementou em PyTorch uma arquitetura no estilo GPT-2 atualizada
      • Depois de várias ablações para ajuste de hiperparâmetros no dataset Tiny Stories, aplicou o processo a cerca de 9 bilhões de tokens do OpenWebText
      • O sweep de learning rate do modelo de 17M parâmetros que escreveu mostrou que learning rates altos causavam instabilidade. Treinou por cerca de 1 hora em uma A100
    • Próximos planos
      • Fazer o restante das tarefas do CS336: otimização de modelos de linguagem, estimativa/cálculo de scaling laws, conversão de texto bruto em dados de pré-treinamento e post-training do modelo
      • Já começou a segunda tarefa: profiling de GPU e implementação do FlashAttention2 em Triton
      • O objetivo final é ter um modelo pós-treinado por ela mesma
  • 2. Melhorar habilidades em Python

    • Tem praticado escrevendo vários pequenos agentes e redes neurais com Python e PyTorch
    • O mais útil foi o pair programming com alguém com mais de 10 anos de experiência em Python
      • Um parceiro de pair programming, quando não lembrava a sintaxe ou o comportamento de algo, abria o terminal imediatamente e digitava um exemplo simples para verificar o comportamento em menos de 1 minuto
      • Esse processo transformado em memória muscular de resolver problemas sem Google ou LLM ajudou muito a destravar impasses
    • Pretende continuar nessa direção resolvendo problemas como os do Advent of Code em pair programming
      • A colaboração em tempo real é tensa no começo, mas justamente por isso ela sente que cresce rápido
  • 3. Aprofundar a compreensão sobre computadores

    • Escreveu fizzbuzz em BASIC em um Apple IIe de 1983
      • Vivenciou diretamente o processo manual de editar e executar código, percebendo ao mesmo tempo diferenças e semelhanças entre computadores do passado e os de hoje
    • Fortaleceu habilidades em Unix/terminal participando das CTF Fridays
      • Resolveu desafios do tipo "war games", como o Bandit, no terminal, coletando senhas e avançando de nível
      • Agora consegue entender o que o Claude Code está tentando executar no próprio computador
    • Codou à mão um perceptron de camada única no Vim
      • No começo foi muito tedioso, mas melhorou com dicas e atalhos aprendidos com outra pessoa do Recurse Center
      • Isso é muito útil quando é preciso fazer ajustes de última hora em arquivos durante tarefas de treino em GPUs na nuvem
    • Participou de um workshop de Clojure (conduzido por alguém com mais de 15 anos de experiência)
      • Como tinha pouca experiência com linguagens funcionais, o tema em si já era interessante
      • Após uma introdução curta, a atividade seguiu em mob programming, com participantes contribuindo por turnos de 1 a 2 minutos para resolver o problema
    • Participou de apresentações técnicas semanais de 5 minutos
      • Houve vários temas, como "Running Rust Code", "GPUs for Dummies", "Typesafe APIs for Type B Personalities" e "Some Useless Agents" (apresentação dela)
      • Até agora, ela apresentou 2 vezes (arquitetura simples de agentes e escalabilidade eficiente de ferramentas MCP) e nesta semana vai falar sobre métodos de otimização de GPU
    • Só de ouvir sobre os projetos e carreiras das outras pessoas participantes, sua compreensão sobre os tipos de problemas que computadores podem resolver se ampliou

As 6 semanas restantes

  • Depois do retiro, pretende voltar ao trabalho de colocar agentes em produção e rodar evals, agora com novas tecnologias e habilidades
  • Há preocupação de que seja difícil concluir todos os itens da lista nas 6 semanas restantes
  • Mas o verdadeiro valor do RC não está em completar tudo, e sim em dedicar tempo ao próprio ato de programar

6 comentários

 
nemorize 11 일 전

O código para trabalho eu simplesmente deixo todo por conta de agentes de IA, tentando manter o loop o mais longo possível.
Projetos pessoais por hobby eu desenvolvo diretamente, sem usar assistentes de IA nem autocompletar com IA (...)

 
hhcrux 10 일 전

Isso me lembrou um post de humor que vi há pouco tempo
A pessoa escreveu o código manualmente e depois pediu para a IA melhorar,
aí apareceu
Phase 1: excluir código lixo
kakakaka

 
savvykang 11 일 전

Desativei os recursos de IA do VSCode e estou usando o Claude Code; com certeza a experiência fica bem mais confortável.

 
loblue 11 일 전

Troquei o vim pelo vscode por causa da IA,
mas senti que tinha perdido a alegria de programar, então voltei para o vim.
tenho usado a IA como assistente, e com certeza parece que recuperei a alegria de desenvolver.

 
overthinker1127 10 일 전

Na verdade, foi depois de usar um AI Agent que eu passei para o nvim.
Porque é muito mais confortável ver o código-fonte no nvim...

 
GN⁺ 11 일 전
Comentários no Hacker News
  • Neste semestre, estou ensinando assembly 6502 para alunos de 18 anos usando um Apple II Plus emulado
    Eles já tinham aprendido Python, estruturas de dados e orientação a objetos em um ambiente moderno
    Com cerca de 10 horas de aula e prática, aprenderam registradores, instruções, modos de endereçamento, mapa de memória e rotinas do monitor do Apple, e depois implementamos juntos um programa de desenho, uma bola quicando, sprites feitos por eles mesmos e até detecção de colisão simples com gráficos de baixa resolução 40x40
    Como tarefa, pedi que criassem e apresentassem jogos simples como Snake ou Tetris, explicando depois como funcionavam
    No começo, eles odiavam o editor de linha, mas logo passaram a planejar e discutir antes de escrever código
    Um hábito que eu sempre enfatizava nas aulas anteriores sem muito sucesso acabou surgindo naturalmente quando eles ficaram sem ferramentas poderosas
    Depois, alguns disseram que o código já estava na cabeça deles mesmo sem precisar vê-lo inteiro na tela
    No fim, eles vão voltar às ferramentas modernas, mas sinto que essa experiência teve um valor enorme

    • O que percebi ensinando programação é que Python é uma primeira linguagem meio problemática
      O principal motivo é que você precisa estar sempre consciente dos tipos, e o Python às vezes acaba obscurecendo justamente isso
      O espaço em branco também é obrigatório em alguns momentos e em outros não; para quem já está acostumado isso parece tão natural quanto respirar, mas para iniciantes pode ser confuso
    • Também fiz uma disciplina quase igual há 9 anos, e foi uma das experiências mais úteis de toda a minha graduação em CS
      O ambiente de baixo nível e as ferramentas limitadas me ensinaram a pensar antes de escrever código
      Até hoje, quando começo algo greenfield, pego caneta e papel quadriculado e desenho possíveis funções ou classes como um grafo solto, ligando tudo com setas
      Claro que, se levado longe demais, isso vira só outra forma de planejamento waterfall, então moderação importa
      Mesmo algumas horas pensando na estrutura antes já reduzem bastante o tempo real de codificação
      Quase nunca o resultado final ficou idêntico ao projeto no papel, mas o processo de pensar primeiro no quadro geral em si já aumenta a produtividade
      Quando você faz scaffolding dentro do editor, cai muito rápido na implementação real; no papel, como depois vai ter que digitar tudo de novo, fica mais fácil se desligar de distrações como nomes de variáveis ou escolha de métodos
      Em algumas ocasiões em que fiz vibe coding, esse método foi especialmente útil e me ajudou a dar prompts muito mais específicos e focados
    • No começo eu pensava: por que obrigar o uso de um editor de linha, com certeza existe um plugin de VS Code com destaque de sintaxe
      Mas mudei de ideia ao ler a parte em que os alunos diziam que o código tinha se fixado na cabeça deles
      Também me lembrei de Zed Shaw dizendo algo parecido, que o código escrito sem IDE de algum jeito parecia melhor
      Na mesma linha, estudei com livros como "From Nand to Tetris", que realmente me ajudaram muito a entender como computador, assembler e compilador funcionam
    • Uma das experiências mais marcantes do começo da minha carreira como engenheiro foi trabalhar com um engenheiro extremamente sênior
      Quando recebia um problema, ele não começava a digitar na hora: primeiro pensava, rabiscava um pouco no papel e até dava uma caminhada antes de sentar no computador
      Depois digitava quase tudo de uma vez e no final só compilava, e normalmente funcionava mesmo
      Quase não cometia nem erros de digitação
      Isso me fez sentir com muita força o quanto é importante construir primeiro na cabeça o espaço do problema e o programa, e raciocinar sobre eles
      Assim, o resultado esperado fica mais claro, e também fica mais fácil perceber rápido quando algo sai do previsto
    • Toda vez que tentei incluir uma disciplina de linguagem assembly na graduação, sempre foi uma luta difícil
      A chefia dizia que era difícil demais, que ninguém mais usava isso, e acabava cortando a matéria
      Mesmo assim, eu conseguia encaixar um pouco do conteúdo às escondidas em outras aulas, como programação de sistemas, linguagens de computador e arquitetura de computadores
      Quando eu estava crescendo, assembly fazia parte da formação e servia como ponte entre linguagens de alto nível como C/C++ e o hardware
      Isso ajudava a entender por que certos recursos de linguagem existem e como muitos componentes das linguagens realmente funcionam
      Acima de tudo, como os comentários acima já disseram, era excelente como treino para pensar acompanhando a CPU linha por linha
      A disciplina formal quase sempre perdia a disputa, mas espero ao menos ter plantado uma semente nos alunos
      Acredito que todo mundo deveria aprender ao menos um tipo de assembly alguma vez
  • Eu gostaria que tivesse havido mais investimento em fluxos de trabalho com autocompletar por AI
    Aquilo era um meio-termo bem interessante
    O que agora chamam de modo antigo, num quadro mais amplo, ainda me parece bastante competitivo em comparação com fluxos de trabalho agentic
    Digitando diretamente, você preserva muito melhor o conhecimento da base de código e aprofunda mais o entendimento dos conceitos graças ao processo ativo de lembrar e verificar

    • Ultimamente tenho gostado bastante de invertir o fluxo agentic
      Eu mesmo escrevo o código, e deixo o agente fazer a revisão
      Assim mantenho meu faro de programação e meu entendimento da base de código, e ainda pego bugs antes do commit
    • Tive exatamente a mesma sensação
      O Cursor do começo foi realmente impressionante, mas depois disso o autocompletar ficou com cara de quase estagnação, e até o Cursor mais recente, como outras ferramentas, vem se inclinando cada vez mais para o lado dos agentes
      Espero que, se os modelos de diffusion ganharem mais tração, volte a haver energia nos fluxos de trabalho próximos do autocompletar
      O modelo Mercury da Inception Labs responde quase instantaneamente e ainda parece meio mágico
      Só é uma pena que ainda falte o nível de refinamento e a integração profunda com o editor que o Cursor oferece
      E os modelos da linha diffusion parecem ótimos para uso local, então também acho uma pena quase não existirem modelos open-weight relevantes
    • Minha experiência foi parecida
      Quando eu mesmo escrevo o glue code tedioso, acabo formando um mapa do projeto na cabeça
      Já quando um agente cria estrutura demais, até funciona na hora, mas uma semana depois, ao tentar fazer uma alteração pequena, começo tendo que procurar onde ele colocou cada coisa
    • Eu achei o autocompletar com AI bem fraco
      Existia um motivo para todo mundo migrar tão rápido para outra direção; no fim, aquilo não era uma interface útil
    • Entendo a lógica da codificação manual, mas para mim isso parece atravessar um continente de carro em vez de avião
      Depois que você pega um avião uma vez, é realmente difícil voltar
  • Esse título me pareceu um dos mais deprimentes que já vi aqui

    • Achei engraçado que esse comentário também pode ser lido do jeito oposto
      Pode querer dizer que é deprimente que programar à mão tenha se tornado algo tão incomum a ponto de render post de blog, ou pode ser um maximalista de AI zombando de programação humana
      Pelo histórico do autor, a primeira interpretação parece a mais provável
    • Fiquei pensando se agora dizer escrevo Python na mão já quer dizer escrever sem LLM
      Parece tipo wild swimming, aquela expressão da moda; dá a sensação de que fomos longe demais
      Realmente parece um caso de jumped the shark
    • Sempre achei que o Hacker News fosse um lugar para compartilhar ideias e debater com outras pessoas, mas vendo reações desse tipo dá até uma sensação de seção de comentários do Facebook
      Ainda assim, achei uma contribuição muito marcante
    • Eu também entrei só para confirmar se era piada
      Depois de ver, achei realmente absurdo
    • Sinto que isso é só o começo
      Já dá até para imaginar, em tom de piada, um mundo em que alguém é mandado para o hospício por falar de codificação manual
  • Passei os primeiros anos da carreira escrevendo principalmente código Perl em SPARC Solaris com vi, e vi mesmo, não vim
    O Perl Cookbook da O’Reilly era praticamente minha única referência, havia poucos fóruns na internet e os mecanismos de busca eram primitivos, então conseguir ajuda quando eu travava era bem mais difícil
    Em compensação, aquele ambiente me fez aprender profundamente a sintaxe de Perl, as ferramentas de terminal e especialmente os atalhos do vi
    Não havia destaque de sintaxe nem IntelliSense, e por isso mesmo muita coisa ficou mais gravada
    Olhando para trás, havia muito menos distração e ruído naquela época
    Claro que parte disso pode ser porque as expectativas eram menores no início da carreira, mas hoje sinto que tudo ficou excessivamente empilhado e complexo

    • No meu caso, o começo foi com GW-BASIC, e quase não havia editores no sentido em que entendemos hoje
      Era uma experiência bem pura, de recompensa imediata, desenvolvimento rápido e sem camadas desnecessárias, e foi exatamente isso que me puxou para essa área
      Ironicamente, o agentic coding devolveu um pouco daquela empolgação
      Porque eu não preciso mais brigar pessoalmente com todas as complexidades enterprise, e a ligação entre pensamento e resultado voltou a ficar mais próxima
  • A mudança no setor é realmente impressionante
    Até dois anos atrás isso seria algo que quase qualquer desenvolvedor diria, mas agora quem fala que codifica à mão parece quase uma espécie em extinção

    • O que mais me preocupa é a perda da memória muscular
      Principalmente nas tecnologias e linguagens novas com que lidei no último ano, sinto que, justamente por ser fácil demais produzir resultado agora, estou acumulando uma dívida de conhecimento dentro de mim
      Fico muito preocupado com como a próxima geração de engenheiros de software vai adquirir um entendimento profundo dessas coisas, ou se simplesmente não vai adquirir
    • Para mim, o escrever à mão de dois anos atrás parece o equivalente atual a programar sem LLM
      Na geração anterior, seria algo parecido com programar sem IDE, e isso de fato já era raro
  • Sou bastante favorável à AI no geral, especialmente GenAI, mas ainda passo bastante tempo codificando manualmente
    No máximo deixo um Copilot como apoio
    Às vezes faço spec-driven development com ferramentas como SpecKit + OpenCode, ou simplesmente faço vibe code
    Mesmo assim, não pretendo abrir mão da responsabilidade de entender o código nem da capacidade de escrevê-lo eu mesmo
    Por isso comprei recentemente alguns livros novos de LISP e Java, e antes disso também comprei livros de Forth
    Pelo menos por um bom tempo, talvez para sempre, não penso em parar totalmente de programar

    • Para mim, minha responsabilidade não é verificar pessoalmente o código linha por linha, e sim garantir que ele satisfaça os requisitos funcionais e não funcionais
      O ponto central não é a implementação, e sim o entendimento do comportamento
      Essa verificação vem de testes unitários automatizados, testes de integração e testes de carga
      Alguém achou ingênuo eu dizer que fiz vibe coding de um site administrativo interno e, mesmo sem olhar uma linha do código, ele atendia aos requisitos de segurança
      Mas os requisitos eram que qualquer pessoa com acesso ao site pudesse fazer qualquer coisa, e o acesso era protegido por credenciais do Amazon Cognito, enquanto a Lambda que fornecia isso tinha um papel de privilégio mínimo
      Se qualquer uma dessas duas invariantes tivesse sido quebrada, então isso significaria que o Claude encontrou uma vulnerabilidade gigantesca na AWS
  • Eu uso AI ao máximo para construir bastante coisa, mas ao mesmo tempo sempre reservo tempo para revisar se o código gerado pela AI passa no meu critério de carga cognitiva
    Esse processo inclui polimento do código e documentação, e venho facilitando bastante isso com base neste exemplo de AGENTS.md
    Mesmo assim, consigo perceber quando as coisas começam a ir numa direção estranha, e nesse momento retomo o controle
    E quando os créditos acabam, aí chega a minha vez de verdade
    Como o código já vem bem organizado, com abstrações razoáveis e comentários úteis, fica bom continuar dali com codificação humana orgânica
    Hoje em dia, quanto mais perto do limite eu estou, mais peço para a AI deixar o palco montado antes
    Antes, quando os créditos acabavam, eu ficava preso a código que exigia estudo para ser entendido; agora eu quase fico esperando o próximo brain time hand-out
    Pode soar estranho, mas para mim isso também parece uma espécie de trabalho em equipe
    Eu até poderia usar um plano mais caro, mas quero continuar mantendo meu cérebro ativo

    • Achei interessante o princípio citado de não abusar do DRY
      Concordo com a ideia, mas pelo menos no caso do Claude sinto que ele copia lógica com frequência demais, então às vezes o empurrão precisa ser no sentido oposto
    • Eu tenho dificuldade de ver isso como trabalho em equipe
      Quando um LLM escreve código no meu lugar, aquele código parece quase uma caixa-preta intocável para mim
      Se funciona, eu uso, mas não confio; se quebra, só me frustro
      No fim, o jeito que funciona para mim é eu sempre ficar ao volante, com o LLM no papel de assistente: respondendo perguntas, fazendo brainstorming comigo e ajudando a expressar em sintaxe de uma linguagem conceitos que eu já entendo
      Na verdade, sempre achei mais difícil justamente traduzir para sintaxe do que entender o conceito em si
    • Obrigado por compartilhar
      Também venho pensando em delegar parte das coisas ao agente, mas deixar de propósito algumas tarefas para mim, para continuar exercitando o cérebro
      Talvez eu devesse criar alguma skill ou hook para o Claude Code
  • Poder passar 3 meses numa jornada autodirigida de aprendizado profundo parece algo realmente incrível
    Esse tipo de tecnologia profunda parece ter valor de longo prazo, e ainda não tenho certeza se a mudança atual é exatamente o mesmo tipo de abstração que foi a passagem de assembly para C
    Hoje a maior parte do meu código é gerada por LLM, e no fim do dia, sinceramente, quase não sinto prazer, realização nem satisfação
    Ao mesmo tempo, porém, percebi que a parte de programar que eu realmente gostava era só uns 5 a 10%, e o resto era trabalho tedioso e semi-mecânico sustentando o núcleo interessante
    Na escala de toda a história humana, o período em que trabalhamos com computadores é um instante muito curto, e fico curioso sobre como a era da codificação manual será vista daqui a 100 anos
    Talvez vire só uma nota de rodapé, ou talvez acabe agrupada junto com todo o período anterior ao momento em que as máquinas passaram a se automatizar sozinhas

    • Acho que a mudança atual pode ser parecida com a transição de assembly para linguagens compiladas no passado
      Antes se escrevia assembly diretamente, mas depois houve a migração para linguagens compiladas como C, e assembly continuou útil, mas nichado
      Do mesmo modo que hoje deixamos o compilador cuidar do código e quase nunca olhamos sua saída interna, talvez no futuro a maioria do desenvolvimento migre para a camada de abstração dos LLMs
      As competências centrais também podem migrar para coisas como escrever bons prompts, gerenciar a janela de contexto e operar agentes e memória
      Alguns desenvolvedores ainda poderão ler o código gerado por LLM e encontrar problemas, mas a maioria talvez não consiga
      Tenho sentimentos mistos em relação a isso
      Desde que o ChatGPT surgiu até poucos meses atrás, eu era bastante cético em relação à programação com LLM, e mesmo quando saía um modelo novo tudo me parecia só uma variação de saídas ruins parecidas
      Mas recentemente os modelos parecem ter passado de algum limiar, e eu mesmo, embora ainda use o Claude com cautela, de fato recebi ajuda para acelerar bastante a implementação de funcionalidades ou encontrar a origem de bugs só olhando logs
      Ainda não concordo com os exageros do tipo coding is solved, mas tenho a sensação de que estamos vendo uma das maiores mudanças desde a adoção das linguagens de alto nível
  • Como meio-termo, comecei a usar o Zed
    Daqui para frente quero usar AI mais para planejamento e sugestão de etapas do que para a implementação em si
    Hoje já dá para ver pessoas de áreas não técnicas começando a criar apps com Claude, e olhando para o Openclaw e essa obsessão por agentes, sinto que continuar seguindo o caminho do hype em torno de AI não é algo tão prático
    Em outras áreas da vida, sempre fui valorizado por me importar com os detalhes internos e por meter a mão em problemas novos para resolvê-los diretamente
    Fico curioso sobre como o mercado vai se adaptar e como as pessoas vão transmitir e demonstrar essa capacidade de lidar com nuances

  • No site do Recurse Center, vi a frase “sem professores nem currículo fixo; só exigimos dedicação em tempo integral durante o retiro” e fiquei curioso
    Queria saber como alguém que trabalha em tempo integral normalmente participa desse tipo de retiro de programação
    Também queria saber se o programa é voltado principalmente para quem está entrando no setor ou está entre empregos
    O texto em si falava sobre o que a pessoa construiu no retiro, mas acabou me dando mais vontade ainda de ir pessoalmente

    • Respondendo como cofundador do Recurse Center: a maioria participa entre empregos
      É comum gente pedir demissão de propósito para fazer o RC, ou se inscrever depois de perder o emprego
      Também é frequente usar um sabático formal, garden leave, ou as férias de verão de estudantes de graduação e pós-graduação
      Também aparecem bastante freelancers, contratados independentes e aposentados
      Algumas pessoas vão para entrar no setor, mas muitos participantes já trabalharam como programadores antes
      A faixa etária vai de 12 anos até o começo dos 70, embora a maior concentração fique entre os 20 e os 40
    • Sim, em geral muita gente vai entre uma vaga e outra
      Dá para ver informações mais detalhadas sobre os participantes na página de apresentação do Recurse Center
      Caso contrário, na prática você precisaria conseguir tirar algo como 6 semanas de sabático com possibilidade de voltar ao emprego atual