Ricardo Coelho

Eu mesmo criei. É uma skill do Claude. O risco de alucinar realmente existe, mas você pode se proteger usando referências. Idealmente você não deve aceitar o que a IA diz cegamente. Na skill eu oriento a mostrar exatamente qual trecho da documentação analisada dá suporte à afirmação. Isso obriga o modelo a ancorar as informações que ela poderia alucinar e termina solucionando 99% dos casos sozinho. Claro que, quando alguma coisa parece off, eu termino ainda buscando o material pra confirmar. Isso tira praticamente todo o trabalho dos seus ombros, desde a pesquisa, classificação, estruturação dos dados, mapeamento cruzado das informações e conclusões. Outra técnica que está implementada nessa mesma skill é o uso de vários agentes realizando tarefas complementares. Por exemplo: 1. Uso o Opus para planejar o processo de coleta e análise com base no que foi solicitado por mim. 2. Depois, ele dispara um agente Haiku para cada endereço que vai precisar acessar para baixar o material. 3. Então entra o Sonnet catalogando as informações, criando um grafo em arquivos MD com as referências cruzadas. 4. Por fim, entram dois Opus: um para analisar o grafo e gerar o relatório final de análise com as referências e o último para revisar o relatório, usando as mesmas referências, antes de me entregar. Sei que parece overkill mas é o que garante precisão na entrega. E sempre que tiver alguma dúvida, todas as referências estão ali mesmo no relatório, facilmente pesquisáveis.

Já toquei empresa do zero e hoje sou advisor em algumas, então vou começar pelo que costuma dar mais trabalho. Antes de fluxo de caixa e de tributação, defina em que condição você entra: sócio com participação no contrato social, prestador com contrato e honorário definido, ou ajuda informal de amigo. Cada uma tem consequências diferentes lá na frente. A ambiguidade não aparece de início, mas quando o negócio começa a dar dinheiro ou prejuízo, a conversa vira sobre relação pessoal em vez de números. Outra coisa, você é funcionário de banco. Precisa ver se o código de conduta do Santander trata de conflito de interesses e de participação em outras empresas, porque normalmente isso exige uma declaração e, em alguns casos, aprovação prévia. Principalmente para cargo de administrador no contrato social. Consulta logo o compliance interno antes de assinar qualquer coisa. Vale também manter a conta PJ da borracharia fora da sua agência e da sua carteira, porque isso é o tipo de coisa que ninguém questiona até o dia em que questiona. Feito isso, eu começaria pelo básico. Regrinha chata mas que ajuda demais: conta PJ aberta antes do primeiro faturamento, pró-labore fixo pros dois sócios definido no papel desde a assinatura, mesmo que seja um valor baixo e proibição de tirar dinheiro do caixa pra despesas pessoais. O ponto é que borracharias são negócios de recebimento em dinheiro e Pix. O risco do caixa virar extensão do bolso do dono é grande. Se você resolver só isso, já justificou sua presença. Sobre a tributação, como serão dois sócios, esquece MEI e vamos de ME no Simples Nacional. Mas tem um problema a resolver... borracharia mistura serviço com venda de mercadoria. O conserto, o remendo e a montagem entram como serviço, com ISS municipal. A venda de pneus, câmaras, válvulas, etc... como comércio, com ICMS. São CNAEs e anexos diferentes do Simples e a receita precisa ser segregada na apuração. Não tente resolver isso remotamente sozinho: contrate um contador da cidade dele, que conheça a prefeitura local, o alvará, o bombeiro e as exigências de destinação de pneus inservíveis. A fiscalização ambiental adora pegar borracharia desprevenida. Antes do DRE, começa pelo fluxo de caixa semanal projetado pra 10-15 semanas. Levanta o custo fixo mensal inteiro (aluguel, energia, água, salário, encargos, pró-labore, contador, internet, seguro) e calcula quantos serviços por dia vocês precisam pra pagar essa conta. Esse é o número que o sócio dele precisa ter na cabeça todo dia de manhã. A partir dele você discute preços para a realidade dele e não comparando com o concorrente. Separe a margem de serviço da margem de produto desde o começo. Serviço tem margem alta e não imobiliza capital, já pneu tem margem baixa e o dinheiro fica parado na prateleira. Vi mais borracharia e autopeças quebrarem por estoque comprado no impulso do que por falta de cliente. Acompanhe o giro por item e resista à promoção do fornecedor que geralmente só serve pra transferir estoque parado dele pra vocês. Outro ponto importante é o prazo de recebimento. O cartão de crédito cai em 30 dias, parcelado é pior ainda e só ganha da antecipação. Já o fornecedor quer receber em 7, 14 dias. Essa diferença é o capital de giro que a maioria não imagina que vai precisar. Taxa de maquininha se negocia no início (mas esse é um assunto que você domina melhor que 99% dos donos de borracharia) e antecipação se trata como crédito ultra caro. Só deve ser aceitável em emergências e não pode jamais virar um hábito. Em cima de tudo isso, reserva de caixa equivalente a três meses de custo fixo, que tem que ser formada antes de sequer sonhar com qualquer retirada de lucro. Sobre ser remoto, não creio que atrapalha na sua parte. Qualquer ERP simples tipo Conta Azul, ou até uma planilha bem feita nos primeiros meses já resolve o lado mais crítico. O que não dá pra ser remoto é a contagem de estoque e conferência física de caixa, então precisa combinar uma rotina. Eu cobraria fechamento diário lançado por ele no fim do expediente, com conferência sua no fim da semana e fechamento do mês com um Teams/Zoom/Meet de meia hora, quarenta minutos. Eu trataria pelo menos três indicadores: faturamento por linha, margem e saldo projetado das próximas semanas. Digo isso porque se o lançamento diário não acontecer, você vai terminar tendo que escavar nota fiscal e aí a distância começa a atrapalhar bastante. Uma última coisa que vai ter ajudar bastante mais adiante: acordo de sócios entre os dois, escrito, com regra de retirada, de entrada de novo sócio, de saída e de morte. Preserve sua paz. Espero ter ajudado.

O produto tá pronto. Estou exatamente na hora de ver isso. O próximo passo é registrar a startup.

Se você fosse abrir uma startup SaaS hoje, em que cidade brasileira ou estrangeira abriria o CNPJ (ou equivalente) e por quê? Já tenho outras empresas, mas agora quero decidir de forma mais estratégica. Meu negócio é digital, sem dependência de operação física ou cliente local. O que pesaria mais pra você? Tributação, incentivos, acesso a talentos, networking, burocracia, fomento, internacionalização? Quem já fez essa escolha, se arrependeu ou faria diferente? Se tivesse que começar do zero hoje, onde abriria e por quê? Estou buscando entender experiências reais e critérios que eu talvez não esteja vendo.

Trouxe de volta meu T por programar. Passei muitos anos no piloto automático, entregando sempre a mesma coisa. Biblioteca pronta, IDE azeitada, processo no automático. Confesso que já estava ficando de saco cheio. Sem tempo (ou paciência) pra aprender stack nova. A velha história do cachorro velho e do truque novo. Aí veio o Claude Code trazendo duas coisas que pra mim foram cruciais. A primeira é que eu não tenho mais que depender da minha IDE e das minhas libs / frameworks. De uma hora pra outra eu posso criar um harness inteiro pra atender qualquer coisa que eu queira fazer. A outra é que eu consigo aprender qualquer linguagem / stack / tecnologia em dias, sem precisar assistir horas de vídeos no YouTube. Faço o código, ele critica, eu conserto, ele sugere melhorias, eu discuto, ele rebate. Modernizei muita coisa que já estava pedindo revisão há anos e minha motivação foi a 1000. Não acho que a IA vai fazer tanta diferença assim na velocidade de entrega, a menos que ela chegue num estágio em que não seja mais necessário revisar. O tempo que eu gasto pra revisar o que ela faz é muito similar ao que eu levaria pra codificar sozinho. Mas a vantagem é que as coisas que eu desenvolvo sozinho eu raramente documento com o nível de detalhe que eu tenho hoje com IA. Porque eu peço pra escrever e documentar. E o nível de detalhamento da IA com a documentação é bizarro. Isso também impacta no processo como um todo. Dificilmente você vai conseguir começar direto no código, como os juniors aqui amam fazer. Pra usar IA de forma minimamente consciente você precisa começar pelo PRD, depois escrever a SPEC, depois definir uma stack, definir como vai ser feito o provisionamento... enfim, é bagunçado mas tem gerência. Esse foi o maior ganho pra mim.

Olá, João. Você começa de uma posição bem melhor do que imagina, porque já tem o que falta pra muita gente no início da carreira de programação: problemas concretos pra resolver. Mas preciso fazer um alerta. Cuidado para não transformar "aprender a programar" no seu objetivo final. Seu objetivo não deveria ser dominar Python, JavaScript, frontend ou backend por dominar. Essas coisas são ferramentas. O que eu entendi é que você quer construir a sua presença profissional e, mais adiante, resolver problemas reais de nutricionistas e pacientes. Para colocar no ar um site com o seu currículo, os seus certificados, a sua formação, os seus projetos e tudo o mais você não precisa esperar aprender a programar. Dá para começar com WordPress, Framer, Wix ou outra ferramenta visual. Até mesmo o Lovable, que já vai te dar grandes poderes, com os quais virão grandes responsabilidades. Escolha uma plataforma e publique a primeira versão e aprenda, no processo, sobre domínio, hospedagem, conteúdo e posicionamento profissional. Depois, se quiser entender melhor como tudo funciona por dentro, você estuda HTML, CSS e JavaScript e vai reconstruindo partes do site. Só não gaste meses ou anos estudando para só então publicar algo que poderia estar pronto em dias. O código serve ao projeto, e não o inverso. Senão, estudar vira uma desculpa sem fim pra não fazer. Acredite, é mais comum do que parece. A ideia do agente de WhatsApp também é viável, mas é bem mais complexa do que se imagina. Não seria só "colocar uma IA no WhatsApp". Além de toda a instrumentação, que hoje em dia já está embutida em várias plataformas prontas (e caras), o sistema teria que interpretar alimentos, quantidades e preparações, consultar bases nutricionais, lidar com informação incompleta, calcular valores aproximados, proteger os dados dos usuários e reconhecer quando não tem informação suficiente para responder. "Comi dois pedaços de pizza", por exemplo, não diz o tamanho, a massa, o recheio, os ingredientes nem a quantidade de cada item. O sistema até pode apresentar uma estimativa, mas teria que comunicar a margem de incerteza com muita clareza, pra não correr o risco de ter um palpite sendo interpretado como se fosse uma informação precisa. Tem ainda um cuidado profissional que você não pode ignorar. Você pode estudar, programar e criar protótipos durante a faculdade, mas precisa ter atenção ao que disponibiliza ao público como orientação nutricional individualizada. Você já deve saber que o CFN considera a prescrição dietética e o plano alimentar atividades privativas do nutricionista. Mesmo a telenutrição é regulamentada como prestação de serviços de alimentação e nutrição por meio de tecnologias, mas sempre feita por nutricionista habilitado. Repare no texto: feita por nutricionista. Antes de usar um agente com pacientes ou oferecer recomendações personalizadas, você vai precisar verificar os limites profissionais e as exigências do CFN e do seu CRN. E mesmo depois de formado, a IA não vai poder funcionar como um "nutricionista automático". Pelo menos por enquanto. Não por conta da tecnologia, mas da burocracia. Eu sugeriria tratá-la como uma ferramenta sob a sua supervisão para: coletar informação, organizar registros, consultar dados, produzir estimativas, lembrar tarefas e facilitar a comunicação. Mas a decisão profissional e a orientação individualizada continuariam sendo suas. A ordem que eu seguiria começa por colocar o site no ar com uma ferramenta visual, depois aprender lógica de programação e os conceitos básicos, em seguida HTML, CSS e JavaScript, então pequenas ferramentas ligadas à nutrição e só então entrar no tortuoso mundo do backend, banco de dados e APIs. Daí você poderia elaborar um protótipo simples de consulta de alimentos para então incluir a integração com WhatsApp e agentes de IA. Várias plataformas de IA podem acelerar isso pra você, mas eu não entraria cegamente nisso. Acredito que a única forma realmente segura de pular algumas etapas e tentar antecipar alguns resultados é se você tiver alguém da área com você. Um amigo, sócio, enfim, um parceiro de negócios. Existem várias ideias mais simples que você pode construir como protótipos pra validar seu aprendizado. Você pode fazer uma calculadora de necessidades energéticas, uma consulta a uma tabela de composição de alimentos, um diário alimentar ou um sistema simples para organizar refeições. São projetos pequenos, mas que ensinam quase todos os fundamentos necessários para chegar ao agente que você imaginou. Como referências gratuitas, você encontra muita coisa no YouTube. Praticamente tudo que você precisa já está lá. Mas como é bem difícil fazer a curadoria disso, eu sugeriria cursos como freeCodeCamp e outros similares. Se eu puder deixar um último conselho sobre isso, eu tomaria cuidado pra não caiar na armadilha de assistir a dezenas de vídeos ou cursos sem construir nada. Escolha uma trilha e faça um projeto pequeno em paralelo. Aprendeu alguma coisa, vai pro código. Seu maior diferencial ao competir com programadores profissionais vai ser entender de nutrição bem o suficiente para enxergar problemas que muitos programadores não veem. E entender de tecnologia bem o suficiente para construir, prototipar ou liderar a criação das soluções. Então, ao invés de partir para o que todo estudante de TI pensa, que é "quero aprender a programar para um dia descobrir o que fazer com isso", adote o "Quero resolver este problema. Qual é a menor quantidade de tecnologia que preciso aprender para construir a primeira versão da solução?". Isso vai te poupar anos de estudo sem direção e te permitir colher frutos muito antes dos seus concorrentes. Espero ter ajudado.

Oi @Amanda Viana Neves, posso te ajudar com a automação. Tenho muito conteúdo sobre isso no meu site (que está no meu perfil). Se preferir, posso te enviar o link como mensagem direta. Sucesso!

Fiz o upgrade para o Fable 5. Sério... usem.

Hoje é o Dia Mundial da Sociedade da Informação, e a UIT escolheu pra 2026 o tema "Linhas de vida digitais: fortalecendo a resiliência num mundo conectado". A escolha da palavra não é à toa. Uma linha de vida é, por definição, algo que não pode falhar. A data nasceu de uma cúpula da ONU, num tempo em que o problema da tecnologia ainda era de acesso: conectar, distribuir, levar informação pra onde ela não chegava. Boa parte desse problema foi resolvida, e o que sobrou é de outra natureza. O futuro da sociedade da informação não pertence mais a quem produz a tecnologia, mas a quem entende quais partes dela não podem falhar. Na sociedade da informação que de fato construímos, o software deixou de ser uma ferramenta de produtividade pra se tornar a infraestrutura da vida cotidiana. Os pagamentos, a saúde, a educação, a identidade, o governo e o trabalho passam hoje por camadas digitais que rodam em segundo plano, quase invisíveis. E essa invisibilidade mudou o impacto de suas falhas. Quando essa infraestrutura quebra, o sistema não cai fazendo barulho. Ele continua rodando, mas respondendo errado, negando um direito ou embutindo um viés sem que nada no comportamento dele denuncie o problema. E a IA, que hoje escreve boa parte desse software, só aumenta a chance da falha passar em silêncio. A pergunta que sempre ouço é se a IA vai substituir programadores. Não é essa a que me preocupa. Produzimos hoje mais software do que conseguimos auditar, e o código gerado por máquina é especialmente bom em parecer correto. Addy Osmani chamou isso de dívida de compreensão: o custo de produzir despencou pra perto de zero, mas o custo de entender o que foi produzido continua o mesmo, e a distância entre os dois não para de crescer. Osmani enxerga o problema dentro do código, como uma questão de manutenção e de engenharia. Só que esse software não é mais só código. É a infraestrutura da nossa vida. A dívida de compreensão deixou de ser técnica e virou cívica, e boa parte da indústria segue chamando esse abismo de progresso. Os anos que virão, os anos dos criadores silenciosos, talvez sejam mais curtos do que imagino. Neles, o nosso trabalho vai passar de produzir mais informação e mais software pra reconhecer a criticidade do que já existe: distinguir o que precisa ser determinístico, auditável e reversível, do que pode falhar sem causar danos graves, e do que jamais deveria falhar em silêncio. Só que esse julgamento ainda não é o cargo de ninguém. Terceirizamos para o software quase todas as nossas decisões cotidianas sem nos preocuparmos em verificar o que está falhando sem alerta. E agora terceirizamos também a produção desse mesmo software, sem capacidade de verificar o que está sendo entregue. Já que o código virou uma commodity, é o nosso discernimento que precisa se tornar a infraestrutura. A ideia de sociedade da informação tem que ser reescrita: o que a define não é mais o volume que produzimos, mas quem ainda entende como nasce aquilo de que dependemos. A UIT pede resiliência este ano, e uma linha de vida digital só é resiliente enquanto alguém for capaz de dizer o que nela não pode falhar. Sem isso, num 17 de maio qualquer, vamos acabar celebrando uma sociedade da informação inteiramente produzida por IA, e que ninguém mais entende.

Estou usando Claude Code massivamente. Não para sugestão de carteira, mas para análise dos documentos do RI e cruzamento de outras informações públicas. É absurdo.

A Anthropic anunciou que vai consumir toda a capacidade computacional do Colossus 1 da SpaceX, mais de 300 megawatts e 220 mil GPUs NVIDIA disponíveis em um mês, e declarou intenção de desenvolver com a SpaceX gigawatts de compute orbital. O efeito imediato pra quem trabalha com Claude Code é animador: dobram os limites da janela de cinco horas nos planos Pro, Max, Team e Enterprise, e acaba a redução de limite no horário de pico pros planos Pro e Max. Trabalhar com agentes em sessões longas estava virando um exercício de orçamento (quanto contexto eu posso queimar nesta janela / quanto sobra pra próxima), e o orçamento era apertado o suficiente pra condicionar o desenho da tarefa, mesmo no Max 20x. Dobrar a janela e tirar a punição de pico é a luz no fim do túnel para o regime onde o limite de taxa decidia o que dava pra fazer com o agente. A Anthropic agora tem cinco frentes simultâneas de processamento: Amazon com até 5 GW, Google com 5 GW, Microsoft/NVIDIA com 30 bilhões em Azure, Fluidstack com 50 bilhões em infraestrutura americana, e agora SpaceX. Num mercado em que o gargalo tem sido mais e mais a entrega física de energia, silício e refrigeração, a nova parceria funciona como hedge contra a escassez energética. Na leitura da Forbes, Jon Markman aponta que a SpaceX vem sinalizando há meses que 80% da produção projetada de chips do Terafab vai pra satélites em órbita baixa, e que a empresa já protocolou licença na FCC pra lançar até um milhão de satélites de data center. Este interesse da Anthropic representa a primeira vez que um laboratório de fronteira se compromete publicamente a avaliar a infraestrutura de IA espacial como opção real de procurement, abandonando o terreno da mera curiosidade. Se um único gigawatt entrar em operação no fim desta década, a estrutura de computação da IA deve mudar para sempre. Ganhamos, portanto, uma janela operacional que muda o desenho do trabalho com agentes, e mais uma confirmação de que o capex de IA está cada vez mais sendo travado não pela pesquisa, mas pela entrega de energia. Publicado originalmente em: https://www.anthropic.com/news/higher-limits-spacex

Claude_n_dev.MP4

É exatamente o mesmo case do Paperclip. Meu azar é que eu montei meu primeiro pipeline em fev. 2025 e ele não existia ainda... 😅 Mas se eu me perceber precisando implementar alguma grande mudança eu certamente vou considerar a migração.

Meu caso de uso é muito diferente disso. Meu objetivo não é usar a IA pra automatizar rotinas. É usar a IA para gerar código que automatiza rotinas. Isso é muito diferente. Quando você citou APM e SIEM ficou claro pra mim o seu prisma, mas este é um uso muito limitado e que te deixa dependente da IA pra sempre. Nesse contexto eu concordo com a sua visão. Mas este não é nem de longe o meu uso atual. Routines pra mim funciona muito bem porque eu consigo remover todo o pipeline de controle de versão do meu workflow principal. Posso focar na geração de código e análise de qualidade (não só testes unitários, mas end-to-end, UI/UX, segurança, pra citar alguns). Eu já faço isso hoje em um VPS dedicado e por isso me empolguei com a possibilidade de delegar esta camada inteira para um serviço gerenciado. Entendo que para você talvez não faça sentido, mas para a minha dinâmica atual é algo extremamente útil e reversível. Nos meus pipelines o controle de epics, stories, tasks e issues são centrais. Eu converso com meus agentes inserindo tarefas no quadro. A atuação dos agentes é automática, disparada pela inclusão de novos itens. Em seguida, o workflow é iniciado com as análises que citei em um loop de implementação-verificação-correção, até o all-green. Todos os agentes são instruídos a trabalhar em feature-branches, submeter pull requests que são avaliados e incorporados por outros agentes criados especificamente para este fim. É como um escritório de desenvolvimento de software, mas operado por agentes, usando skills, baseados em rules, dentro de um workflow previsível. Esta pra mim é a grande beleza deste ecossistema. Eu consigo desenvolver quatro, cinco projetos em paralelo, simplesmente cuidando da especificação e avaliação. Todo o processo de geração de PRD.md, SPEC.md, STACK.md, WORKFLOW.md ocorre a "quatro mãos", mas a partir daí, tudo cabe ao pipeline automatizado. É um admirável mundo novo e as primeiras naus apenas começaram a zarpar.

Eu achei bem útil porque já tira bastante da complexidade do workflow local. Se você pode delegar isto para uma outra camada, o pipeline fica bem mais simples e o contexto demanda menos podas. É verdade que aumenta o lock-in, mas nada que não possa ser revertido facilmente ou mesmo delegado a uma instância em um VPS. Pessoalmente eu gostei muito da ideia. Quando estiver pronto de fato acho que vai ser ainda mais útil.