Criando um app para Mac com Claude Code

• Lançou um app macOS inteiro com mais de 20 mil linhas de código gerado quase totalmente pelo Claude Code, com menos de 1.000 linhas escritas manualmente
• Com a chegada dos agentes de codificação com IA, a experiência de desenvolvimento passa a ser centrada em prompts, e não em IDEs tradicionais
• A geração de código em Swift e SwiftUI ainda tem algumas limitações, mas a qualidade pode ser elevada com priming, engenharia de contexto e design de loops de feedback
• Automação, deploy, documentação e testes também foram em sua maioria tratados pelo Claude, reduzindo drasticamente trabalho manual repetitivo e tempo gasto
• O IDE do futuro deve evoluir para uma nova UX centrada em uso de agentes e gestão de contexto, em vez de um editor de código

---

A experiência de lançar um app macOS usando apenas Claude Code

Visão geral do projeto

• Recentemente, lançou um app nativo para macOS chamado Context. É uma ferramenta para desenvolvedores voltada à depuração de servidores MCP
• Esse app foi feito quase 100% com Claude Code. De cerca de 20 mil linhas, menos de 1.000 foram escritas diretamente por ele
• Criar software com Claude ainda exige habilidade do desenvolvedor, trabalho iterativo e capacidade de escrever bons prompts
• Este texto explica em detalhes todo o processo de criação do app com Claude Code, a escolha de ferramentas, os prós e contras e maneiras de gerar código de alta qualidade

1. Do Copilot ao Claude Code, e a mudança no ambiente de desenvolvimento

• A primeira ferramenta de codificação com IA usada foi o GitHub Copilot, e mesmo apenas com autocompletar simples já foi possível perceber um grande aumento de produtividade
• Depois vieram o modo agente do Cursor, o Windsurf e outras ferramentas agentic que coletam contexto da base de código e automatizam até os ciclos de build e teste
• O Claude Code, ao contrário de editores tradicionais como o VS Code, busca um ambiente puramente agentic, só de terminal e centrado em prompts
• É uma UX simples que remove a maior parte dos recursos de IDE e mostra apenas uma caixa de prompt e os resultados
• Em vez de apenas complementar a IDE tradicional, o agente de código tenta efetivamente substituí-la
• Havia ceticismo em relação à UX por ela ser diferente das ferramentas existentes, mas a nova abordagem pareceu atraente o bastante para experimentar

2. Retomando projetos paralelos

• Como acontece com muitos desenvolvedores que conciliam trabalho fixo, os side projects inacabados só se acumulam
• Protótipos são feitos rapidamente, mas falta tempo e energia naquela fase final dos 20% restantes, o que impede o lançamento real
• Ao testar servidores MCP, surgiu a ideia de que era necessário um app nativo, e por isso foi decidido criar um diretamente
• Nesse processo, o Claude Code passou a ser usado de forma mais séria, e ficou claro o quanto um agente de IA pode ajudar na prática

3. A excelente capacidade de geração de código do Claude Code

• O Claude Code, usando os modelos mais recentes Sonnet 4 e Opus 4, realmente produz código bom com rapidez
• Ele lê o contexto do projeto, entende o estilo de código, consulta documentação e specs relacionadas para implementar funcionalidades, e até escreve testes automaticamente
• Build, ciclos de teste, análise de logs de console e screenshots, e correção de bugs ficam quase todos automatizados
• Na prática, ele gera resultados de alta qualidade com apenas uma fração do tempo que um desenvolvedor levaria escrevendo código
• É como colocar um júnior em um projeto sem contexto algum e ainda assim ver uma funcionalidade pronta em poucos minutos

4. A qualidade real do suporte a Swift e SwiftUI

• Uso de Swift 6.1, macOS 15.5 e o SwiftUI mais recente
• O Claude lida bem com Swift até a versão 5.5 na maior parte, mas é mais fraco em mudanças recentes, como concorrência
• Às vezes ele mistura APIs modernas e legadas, Objective-C e SwiftUI, e acaba cometendo erros
• No caso de código SwiftUI, o rascunho inicial pode parecer incompleto ou grosseiro, mas com instruções iterativas ele é refinado o suficiente
• Quando o código de UI fica complexo, surgem erros do compilador, como falhas de inferência de tipo, e o Claude consegue refatorar isso automaticamente em funções menores
• Se as instruções forem explicitadas no arquivo CLAUDE.md, a qualidade do código gerado pelo Claude sobe mais um nível
  • Ex.: priorizar SwiftUI, seguir as Apple Human Interface Guidelines, usar ativamente recursos recentes de macOS e Swift6 etc.
• Além disso, usar as diretrizes do repositório agent-rules ajuda a gerar código de qualidade ainda maior

5. Dá para pedir: "deixa mais bonito"

• Com prompts simples como "deixa mais bonito/elegante/com melhor usabilidade", é possível melhorar o design da UI pelo Claude
• Bugs e pontos de melhoria na UI podem ser ajustados imediatamente ao colar screenshots no Claude e fornecer feedback iterativo
• De forma mais estruturada, também dá para pedir primeiro algo como "sugira como a UI pode ficar mais bonita" e então aplicar apenas as mudanças desejadas

6. A importância da engenharia de contexto

• Os modelos de IA atuais entendem muito bem mesmo prompts incompletos ou com erros gramaticais
• O que realmente importa é colocar dentro da janela limitada de contexto (200k tokens) apenas a informação necessária, da forma mais eficiente possível
• Quando o contexto da conversa enche, o Claude faz automaticamente uma compactação (compaction) e reinicia o contexto, mas nesse processo existe risco de perda de detalhes ou queda de qualidade
• Por isso, extrair a maior qualidade possível dentro de um contexto limitado, ou seja, fazer “context engineering”, é uma tarefa central ao usar agentes de IA

7. Priming do agente

• Como nesse processo de compactação contextos importantes podem se perder, é eficaz resumir manualmente quando necessário ou fazer priming com informações adicionais
• Além do CLAUDE.md, a qualidade de saída melhora quando se pede ao Claude para ler e resumir previamente trechos específicos de código-fonte, documentos de spec etc.
• Mesmo conteúdos surgidos após o cutoff de conhecimento do Claude, como novas bibliotecas ou APIs recentes, podem ser convertidos com ferramentas específicas (Context7, llm.codes etc.) para que o Claude os entenda com mais facilidade
• Priming é o processo de fazer o Claude entender totalmente o contexto primeiro, com instruções como: "leia todos estes arquivos-fonte, documentos e specs e faça um resumo"

8. O agente precisa de uma spec clara

• Ao pedir ao Claude para implementar uma funcionalidade, é indispensável fornecer uma spec concreta e detalhada para obter o resultado desejado
• A ideia mostrada em demos de "criar um app com um prompt de uma frase" na prática só chega a algo no nível de protótipo
• Mesmo que a spec não esteja refinada, é suficiente explicá-la da forma mais confortável, por voz ou digitando

9. "Ultrathink and Make a Plan"

• Se o Claude parte direto para a implementação sem pensar, a qualidade da saída cai; por isso, uma estratégia eficaz é pedir primeiro que ele monte um plano em modos de raciocínio mais amplos, como think e ultrathink
• Quando ele trabalha em etapas, revisando o plano e recebendo feedback antes de implementar, a qualidade melhora
• O documento da Anthropic Claude Code: Best practices for agentic coding é recomendado como leitura obrigatória

10. Construindo loops de feedback

• A verdadeira força do Claude Code se maximiza quando ele consegue operar loops de feedback de forma independente
• Em outras palavras, o essencial é criar um ciclo automatizado em que o Claude modifica o código, faz o build, analisa a causa das falhas, coleta contexto e repete o processo
• Quanto melhor esse loop for desenhado, mais autonomia o Claude ganha para entregar código de alta qualidade
• 1. Build
  • O Claude precisa conseguir executar sozinho o processo de build (compilação) do app
  • No caso de pacotes Swift, é fácil construir com o comando swift build, e o Claude lida bem com isso naturalmente
  • Porém, no caso de targets de app macOS (por exemplo, projetos Xcode), o Claude frequentemente se confunde sobre qual comando xcodebuild usar
  • Para resolver isso, foi usada a ferramenta XcodeBuildMCP, que oferece ao Claude uma interface simplificada para facilitar o build e a execução do app
• 2. Test
  • Depois de fazer o build do código, o Claude precisa ser capaz de executar testes automaticamente e analisar os resultados
  • Em pacotes Swift, os testes rodam naturalmente com swift test, e o Claude também lida bem com esse fluxo
  • Ainda não foi testado fazer o Claude rodar por conta própria testes completos do app ou testes de UI, mas a expectativa é que isso também exija uma ferramenta como o XcodeBuildMCP
  • Com base no resultado dos testes, como logs de sucesso ou falha, o loop de correção do código continua
• 3. Fix Bugs
  • O Claude consegue rastrear problemas adicionando logs para fins de depuração
  • Porém, ele não consegue operar o app diretamente para gerar esses logs
  • Por isso, é necessário que o usuário interaja manualmente com o app e depois copie os logs do console para colar no Claude
  • Essa abordagem funciona bem na prática, mas sem testes unitários ou de UI bem preparados de antemão, é difícil alcançar correção de bugs totalmente automatizada
  • No caso de apps web, existem soluções de automação de navegador como o playwright-mcp, mas para apps nativos ainda faltam alternativas consolidadas
• 4. Fix UX Issues
  • Para melhorar problemas de UI/UX, é possível colar screenshots diretamente no Claude e dar feedback iterativo
  • Ferramentas como Peekaboo podem automatizar screenshots, mas ainda existe a limitação de que o app precisa ser levado manualmente até o estado desejado antes da captura
  • Ou seja, a automação de UX ainda continua exigindo intervenção do usuário

11. Claude Code faz mais do que escrever código

• Como o Claude Code funciona com base em um LLM de uso geral, ele pode ser usado para diversas tarefas não técnicas além de programação
• Por exemplo, é natural pedir ao Claude coisas como editar textos do app, montar um plano de release ou sugerir direções de melhoria de funcionalidades
• Um dos pontos mais úteis em especial foi a geração automática de dados mock em estágios iniciais, quando ainda não existiam dados reais
  • Durante o desenvolvimento do app Context, ainda não havia uma biblioteca cliente MCP para Swift concluída, mas mesmo assim havia a vontade de avançar no protótipo da UI
  • Normalmente, criar manualmente dados mock com aparência realista seria um trabalho extremamente incômodo e demorado, a ponto de provavelmente nem ser tentado
  • Mas o Claude gerou em segundos dados mock muito convincentes, criando um estado de UI quase indistinguível do real
  • Na prática, quando screenshots da UI foram compartilhadas com amigos, usaram-se imagens baseadas nesses mocks, e a impressão passada era a mesma de um serviço real
  • No caso de servidores MCP, naquela época muitas implementações cobriam apenas parte da spec oficial, então obter dados reais era algo difícil
  • Ainda assim, com os dados mock gerados pelo Claude, foi possível validar todo o fluxo da UI e o funcionamento das funcionalidades

12. A era em que automação de alta qualidade ficou (quase) gratuita

• Um dos pontos mais dolorosos nos 20% finais do lançamento de software é a automação do processo de release do app
• Especialmente em apps macOS, há muitos passos complexos de distribuição, como assinatura de código, notarização e empacotamento (geração de DMG), o que frequentemente atrasava lançamentos por depender de trabalho manual ou scripts frágeis
• Antes, era comum forçar a configuração de ferramentas de automação como fastlane ou escrever manualmente scripts mínimos em Python
• Neste projeto, com algumas horas de prompts iterativos e debugging, o Claude gerou um script completo de automação de release
• Principais tarefas cobertas por esse script:
  • Verificação do setup do ambiente: checa se as ferramentas necessárias estão instaladas corretamente
  • Geração automática de changelog: extrai histórico de mudanças de commits git e o combina com itens escritos manualmente para criar release notes em HTML
  • Build e empacotamento do app: automatiza todo o processo de build → assinatura de código → notarização → empacotamento em DMG
  • Geração do feed de atualização do Sparkle (appcast): entrega atualizações automáticas para usuários existentes
  • Tag e publicação da release: adiciona tags no GitHub e publica a release
  • Upload de símbolos para o Sentry: envia automaticamente símbolos de debug para análise de crash reports
• Depois que o script ficou pronto, até melhorias na UI da CLI foram implementadas com um prompt de uma única linha: "deixa a saída da CLI mais bonita"
• O resultado final foi um código Python de cerca de 2.000 linhas; se fosse feito manualmente, provavelmente só as funções essenciais seriam implementadas, mas com Claude o acabamento ficou em alto nível
• Graças a esse script de automação, foi possível economizar dezenas de minutos de trabalho repetitivo a cada release
• Basta explicar a spec em linguagem natural e depois dar feedback ao Claude apenas sobre os erros encontrados durante a execução para que a maior parte do trabalho seja concluída

13. O IDE do futuro será completamente diferente

• Ao longo deste projeto, as únicas ferramentas realmente usadas do começo ao fim foram Claude Code e GitHub Desktop (para ver diffs)
• Recursos centrais de IDEs tradicionais, como árvore de arquivos, editor de código, extensões e plugins, quase não foram necessários
• Em raras ocasiões, o Xcode foi aberto para corrigir algo manualmente, mas até recursos típicos dele, como SwiftUI Previews e View Debugger, quase não foram usados
• Justamente por este ser ainda o ponto mais fraco das capacidades dos agentes de codificação com IA, a sensação é de que os IDEs vão evoluir para algo totalmente novo daqui para frente

• Copilot, Cursor e Windsurf partiram todos do VS Code e foram adicionando funções, mas o próprio VS Code não é tão diferente de IDEs da JetBrains de 20 anos atrás
• Projetos como o Warp tentam modernizar o terminal e transformá-lo em um ambiente de desenvolvimento para agentes, mas a avaliação é que uma UX centrada no terminal também não será a resposta final do futuro

• O ponto central do IDE do futuro será permitir que o desenvolvedor prepare de forma eficaz o contexto do agente (priming) e projete/gerencie loops de feedback
• Em outras palavras, a perspectiva é de uma grande mudança: em vez do editor de código ser o centro, a UX será centrada no uso de agentes e na gestão de contexto

14. Voltar a lançar side projects tornou-se possível

• O ponto mais marcante dessa jornada não foi apenas o fato de ter criado um app impressionante, mas o de ter voltado a conseguir lançar side projects de verdade
• Foi como ganhar 5 horas extras por dia, e tudo isso por apenas US$ 200 por mês
• Graças a agentes de codificação com IA como o Claude Code, voltou a existir energia e confiança para transformar em realidade ideias que estavam engavetadas havia muito tempo

[geek12356]

Faça muito isso

[GN⁺]

Comentários do Hacker News

• Até dois anos atrás eu tinha certeza de que era um engenheiro Python realmente excelente, e agora consigo criar apps móveis nativos, apps desktop que se comunicam com o Slack, APIs escritas em Go e até um app web completo em React em poucos dias ou até horas
  É como se eu tivesse ganhado um superpoder, com produtividade, velocidade e criatividade transbordando, mas ao mesmo tempo sinto uma tristeza estranha
  Minha profissão, minha paixão, tudo em que investi tanto tempo para aprender e pelo qual até me sacrifiquei, agora está sendo em grande parte substituído por máquinas
  As empresas que fazem esse tipo de ferramenta ainda estão só no ponto de partida
  Fico me perguntando o que isso vai significar para a próxima geração de engenheiros e até onde esse movimento vai chegar
  Queria saber se mais alguém sente a mesma coisa

  • O fato de eu agora lidar de forma eficiente com ferramentas variadas como nativo, mobile, Go e React em várias plataformas vem da minha experiência em desenvolvimento de software como engenheiro Python
    O que o LLM substitui é a necessidade de decorar detalhes triviais específicos de cada plataforma
    Mesmo sem decorar a sintaxe de um for em Go, consigo escrever código útil em Go na hora
    Continua sendo necessário entender os princípios básicos, como loops, conceitos de Go, programação estruturada, compiladores, scripts de build e de teste
    Quem não tem bagagem em programação ainda fica muito carente nessa parte
    Tenho sentido que o LLM é um amplificador e acelerador que torna imediatamente aplicável, em várias linguagens e plataformas, o conhecimento difuso que acumulei ao longo da minha carreira
    Antes eu resolvia tudo só com Python, JavaScript e SQL porque reaprender as diferenças triviais de novas linguagens e plataformas era desgastante
    Agora uso Go, Bash, AppleScript, jq, ffmpeg etc. de bom grado e até estou pensando em um projeto em Swift

  • Já vi pessoas sem formação técnica usando LLM para construir coisas, e em geral elas são muito mais lentas ou quase sempre fracassam
    No fim, habilidade técnica talvez não seja obrigatória, mas a capacidade de se comunicar com clareza é indispensável
    Mesmo só entender HTML já ajuda a encaixar o texto de forma limpa para o LLM entender melhor
    Ainda acho que bagagem técnica continua sendo uma vantagem

  • Acho que os trabalhadores artesanais de antes da Revolução Industrial devem ter sentido algo parecido
    Mas vale lembrar que a maioria deles mal tinha educação formal, que 1 ou 2 filhos morriam antes dos 10 anos por doenças simples e que viviam sem eletricidade, água encanada, encanamento interno e geladeira
    Fazer ferramentas à mão é algo romântico (como escrever código Python manualmente), mas acho que, conforme a época avança, viver em uma camada mais abstrata acaba sendo melhor até para os nossos ancestrais
    Ninguém está impedindo você de escrever Python com as próprias mãos, e imagino que isso certamente vá virar hobby para algumas pessoas, como marcenaria em grafite

  • Tenho dificuldade em concordar com a ideia de que a profissão, a paixão e as habilidades que construí agora estão sendo substituídas por máquinas
    Máquinas apenas seguem instruções, sem experiência, previsão, reflexão, capacidade de planejar ou criatividade
    Só pessoas têm ideias, criatividade, objetivos e empatia, conseguem persuadir outras pessoas com boas ideias e considerar o contexto de acordo com a situação
    Em vez de a profissão de programador desaparecer, acho que ela está migrando para um nível de abstração muito mais alto
    No passado já era possível ser desenvolvedor sem conhecer bits, bytes ou uma linha de assembly, embora tenha existido uma época em que assembly era obrigatório
    Agora estamos entrando numa era em que dá para criar programas mesmo sem conhecer a linguagem de programação em si, desde que você entenda bem inglês e requisitos
    Ainda assim, quem entende layout de memória, assembly e conceitos de baixo nível continua compreendendo melhor o que acontece por trás e, se necessário, consegue fazer isso “melhor”
    Mas não acho que isso torne inúteis ou faça desaparecer as camadas de abstração superiores

  • Sinto exatamente a mesma coisa
    Desenvolvo software profissionalmente há mais de 20 anos e sempre adorei isso
    Hoje uso Claude Code a 100% e minha produtividade claramente aumentou, mas enquanto o processo antigo parecia arte, agora parece produção em massa industrializada
    Quero reencontrar, nessa nova realidade, algo que me permitia mergulhar profundamente em software, e é certo que muita da diversão diminuiu

• O texto está muito bem escrito e só de ler já dá prazer
  A IDE do futuro será totalmente diferente da atual
  Eu também comecei com Cursor, depois usei IDEs turbinadas em cima do VS Code e acabei migrando para Claude Code
  Com isso, a importância do terminal cresceu, e meu fluxo foi para iTerm com Ghostty (rápido, leve e moderno), Tmux, Tmuxinator e NeoVim
  Uso cat ou bat para verificar arquivos, às vezes só edito texto, e quase todo o trabalho pesado fica com o Claude Code
  É um esquema em que eu só escrevo especificações e prompts no NeoVim ou no Emacs, e gosto muito desse workflow
  Não só para gerar código, mas também para modificar arquivos de configuração do zsh, neovim, ghostty etc., eu atribuo tarefas ao Claude Code
  Até refatorar arquivos de configuração leva só alguns minutos
  Também deixo com ele perguntas sobre o codebase, refatoração, documentação de código, geração de mensagem de commit e tudo mais — puro espetáculo

  • No fim você comentou sobre perguntas sobre o codebase, refatoração, documentação de código e até commits significativos; eu também já tive a experiência de gerar ótimas mensagens de commit com o CC e deixar informações e exemplos de Conventional Commits no arquivo CLAUDE.md

  • Fiquei curioso se o CC faz backup automático de arquivos de configuração pessoais como .zshrc antes de modificá-los

• Terminal + Claude Code + pasta do projeto
  Só isso já basta de verdade, e só agora percebi
  Eu já não gostava de setups completos de IDE porque davam trabalho, e para cross-compilar por sistema operacional a configuração do QT também era complicada, então sempre achei que a combinação de editor com terminal era a mais lógica
  Agora, com o Claude Code ajudando a processar pedidos em mais uma janela de terminal aberta, parece que subi de nível de desenvolvedor para líder de projeto
  Sem o estresse de gerenciar funcionários
  Hoje consigo concluir em poucos meses todos os side projects que queria fazer havia muito tempo, desde que o Claude apareceu em março

• Há 1 ou 2 anos eu pensei o seguinte: LLM é um assistente excelente para desenvolvedores experientes, é péssimo quando tenta substituir desenvolvedores experientes, e é um assistente perigoso para desenvolvedores inexperientes
  Na experiência prática, essa impressão em geral se confirma
  Hoje acho até que LLM pode virar um bom mentor para desenvolvedores inexperientes, mas na prática o que mais vejo é gente alterando coisas aleatoriamente sem entender por que o código funciona, só repetindo tentativas até algo mais ou menos funcionar
  No fim, isso só reforçou minha visão inicial de que, nessa situação, o LLM é um assistente perigoso
  Nesses casos, bugs e problemas sutis acabam ficando ocultos no código sem ninguém perceber, e mesmo quando são notados, é comum que a causa não seja entendida

• Achei especialmente marcante a conclusão de que os assistentes com LLM reduziram drasticamente o esforço para fechar os 20% finais de side projects
  Para mim, a parte mais interessante dessa jornada não são os novos apps, mas o fato de hoje eu conseguir matar a vontade de programar e voltar a lançar side projects limpos e bem acabados
  É como se eu tivesse ganhado 5 horas por dia, e 200 dólares por mês bastam para isso

• Eu uso principalmente para criar pequenos utilitários, e funciona de forma fantástica
  Com Claude, em poucas horas implementei exatamente do jeito que eu queria um utilitário que mostra o estado de tarefas launchctl/launchd (rodando/descarregada/falhou etc.) como o ícone de menu do OrbStack

  • Eu também criei um app para iOS e um plugin de Wordpress para meu próprio uso e fiquei realmente satisfeito
    Acho que cada vez mais gente vai fazer isso, e me pergunto se todos não deveriam compartilhar o código no github

• Acho que quem faz software para Mac desde 2008 teria percebido rapidamente onde o Claude errou e corrigido isso na hora

  • Ferramentas como Claude Code amplificam habilidades e experiência já existentes
    Elas nunca substituem especialização

  • No fim, lá no final do texto fica claro que esse trabalho custa 200 dólares por mês, e eu já acho caro até pagar 50 dólares no Autodesk, que é essencial para meu principal hobby
    Essas empresas de IA nem dão lucro, e quando os investidores começarem a cobrar retorno, acho inevitável que os custos disparem ou que a qualidade do serviço caia
    Se esses modelos acabarem perdendo processos por fornecer código treinado sem autorização, a capacidade do Claude de gerar Swift também vai cair imediatamente
    Será mesmo que dá para esperar que a Disney perca nos processos contra IA?
    Sinceramente, meu comentário talvez não signifique nada, mas meu cansaço com IA está realmente sério
    Acho que, neste momento, posts assim deveriam até ser proibidos no HN e em outros fóruns de tecnologia
    Se alguém postasse dizendo que conseguiu programar facilmente com Google ou StackOverflow, todo mundo ironizaria por ser algo banal, e acho que esse tipo de post no fundo é a mesma coisa
    Estou de saco cheio desse papo de “pegar carona” em hobby ou profissão com IA

• Ficou muito mais fácil do que antes criar minhas próprias ferramentas personalizadas com ferramentas como Windsurf e ferramentas de CLI
  É um momento realmente interessante

• Tenho a sensação de que logo alguém vai usar LLM para replicar o próprio macOS

• Algumas semanas atrás consegui, com tooling de LLM, fazer um renderizador wireframe 6DOF rodar em um app para System 6 (Mac clássico) usando retro68 e c++