Georgia Tech AI Hackathon: realidade de construção de 3 horas
Assisti a um clipe de um hackathon de sábado no Georgia Tech esta semana e ficou na minha cabeça por dois dias. Não por causa da energia na sala – embora houvesse muita energia – mas por causa de um momento específico. Uma câmera capturou uma equipe nos últimos vinte minutos. Três estudantes debruçados em torno de um único laptop. O aplicativo deles estava quase funcionando. Quase. O tipo de “quase” onde o AI tinha montado tudo na primeira hora, e eles passaram as duas horas restantes tentando fazer com que ele não quebrasse quando um humano de verdade o cutucasse.
Essa expressão em seus rostos é a coisa mais honesta que já vi alguém filmar sobre o desenvolvimento assistido por AI este ano.
O evento foi o hackathon Claude Builder Club, realizado no campus do Georgia Tech e patrocinado pela Anthropic. O desafio era grande: construir um aplicativo móvel ou web que ajudasse as pessoas a manter hábitos saudáveis usando o design baseado em AI. Três horas. Prompt revelado no início. Equipes de até três pessoas. Laptops fechados ao toque da campainha, depois apresentações para um painel de jurados. A equipe vencedora criou um aplicativo gamificado de rastreamento de refeições que sugeria combinações nutricionais e recompensava os usuários por hábitos saudáveis.
Essa é a história superficial. A história abaixo - aquela que continuo lendo - é o que essas três horas revelam sobre como o software de remessa realmente funciona quando AI digita.
Porque aqui está o que ninguém lhe diz quando você assiste a uma demonstração do Claude no Twitter e vê um aplicativo completo rodando em seis minutos: a demonstração é a parte fácil. A parte difícil é tudo entre “o protótipo parece ótimo” e “um ser humano de verdade pode confiar nisso para algo que importa”. Um hackathon é um microcosmo perfeito dessa lacuna, e os alunos do Georgia Tech viveram isso diante das câmeras em três horas.
Fique comigo. A razão pela qual isso importa não é o hackathon. É o que o hackathon prova sobre os próximos doze meses de cada produto construído pelo AI que chega à App Store.
Como é realmente um hackathon AI de três horas
Deixe-me definir o cenário com os números, porque o enquadramento é importante.
A Faculdade de Computação do Georgia Tech matriculou 4.621 alunos de graduação e 16.910 alunos de pós-graduação em cursos de computação no ciclo do outono de 2024, tornando-o um dos maiores programas de computação do país. Ciência da Computação é a área de especialização mais popular no campus. Quando o Claude Builder Club da Anthropic realiza um evento lá, o nível de talentos é alto - esses não são alunos iniciantes em ciência da computação esbarrando em seu primeiro API. Muitos deles lançaram projetos reais, contribuíram para o código aberto e já usaram o Claude Code ou o Anthropic SDK em sua pilha pessoal.
Agora coloque-os em um contêiner de três horas com um prompt novo e diga-lhes para criar um aplicativo de saúde funcional com AI como autor principal. O que acontece?
O que acontece é exatamente o que aconteceu no vídeo: um andaime rápido, depois um rastejamento lento e frustrante em direção a algo que não cai no primeiro contato com a realidade.
Os primeiros trinta minutos são geralmente os mais mágicos. Uma equipe escolhe um ângulo – monitoramento de refeições, hidratação, sono, o que quer que seja – e começa a solicitar. Claude Opus 4.7 (lançado em 16 de abril de 2026, o modelo Antrópico mais capaz quando este hackathon foi executado) pode criar um aplicativo nativo Next.js ou React completo com autenticação, ganchos de banco de dados e um UI funcional em uma única conversa. Eu mesmo fiz isso para projetos pessoais. Você observa a árvore de arquivos ser preenchida, os componentes serem compostos, o servidor de desenvolvimento inicializar e você sente algo próximo à vertigem. Já estamos 60% prontos. Ainda temos duas horas e meia. Isso vai ser fácil.
Então você abre o aplicativo e toca no primeiro botão.
É aí que começa o hackathon de cada equipe.
A lacuna entre o andaime e o navio é onde os engenheiros vivem
Quando penso em como uso o AI em meu próprio trabalho, é para essa lacuna que vai 90% do meu tempo - e acho que essa é a parte que a maioria das pessoas subestima quando prevêem o que o AI fará com os trabalhos de software.
Aqui está um exemplo concreto da minha própria semana. Eu estava construindo uma pequena ferramenta interna – um ingeridor de CSV que se conecta a um fluxo de trabalho de marcação. O Claude Code 2.1 organizou todo o projeto em cerca de seis minutos. Estrutura de pastas, lógica do analisador, acessórios de teste, uma interface CLI limpa. A primeira execução funcionou nos dados de teste que forneci ao Claude. A segunda execução, em um CSV real de um cliente, quebrou em três lugares: um caractere BOM perdido no início do arquivo, uma coluna com codificações mistas e uma linha de cabeçalho que incluía uma célula de espaço em branco fantasma devido à forma como a exportação original do Excel a escreveu.
Nenhum desses bugs estava no prompt. Nenhum deles está em nenhum tutorial. Eles aparecem porque os dados reais são confusos, os usuários reais fazem coisas imprevisíveis e a única maneira de encontrar esses modos de falha é realmente comparar a coisa com a realidade.
Essa lacuna – entre “AI criou um protótipo funcional” e “isso pode sobreviver a usuários reais” – é exatamente a lacuna que um hackathon faz você viver em tempo real. Os alunos do Georgia Tech não ficaram para trás porque o Claude era lento. Eles estavam atrasados porque encontrar os dezessete casos extremos que quebram um aplicativo real de rastreamento de refeições leva mais de três horas, não importa quão rápido seja seu AI.
O Reitor Associado da Faculdade de Computação do Georgia Tech disse isso de forma clara no vídeo: os humanos precisam permanecer "informados" para testar, refinar e garantir que os resultados gerados pelo AI sejam utilizáveis e confiáveis. Isso não é uma proteção educada. Essa é a descrição real do trabalho para engenheiros de software em 2026.
Por que a compressão de tempo revela o que a escala esconde
Há uma razão pela qual um hackathon de três horas é mais revelador do que um projeto corporativo AI de três meses.
Quando você tem três meses e doze engenheiros, pode esconder a lacuna. Você pode ter um engenheiro solicitando Claude o dia todo, mais dois limpando casos extremos, mais três testes de escrita e um designer polindo o UX. A equipe envia um “aplicativo criado por Claude”, mas, na realidade, Claude escreveu o primeiro rascunho e um pequeno exército de humanos o transformou em algo em que os usuários podiam confiar. A história que você conta no LinkedIn é “nós construímos isso com AI”. A história que seu log git conta é mais honesta.
Comprima o mesmo fluxo de trabalho em três horas, com três pessoas, e você não poderá esconder nada. Ou o AI colocou você na linha ou não. Ou você encontrou os bugs ou sua demo trava na frente dos jurados.
É por isso que os hackathons continuam sendo o teste mais claro de como o AI realmente muda o ritmo da construção. Conferências do setor e vídeos de demonstração mostram momentos mágicos. Hackathons mostram o que acontece entre os momentos mágicos - o trecho silencioso de trinta minutos em que alguém está vasculhando um rastreamento de pilha porque o AI chamou com segurança uma função que não existe na versão do SDK que está usando.
Aprendi mais sobre meu próprio fluxo de trabalho AI fazendo compilações pessoais 24 horas por dia do que em qualquer postagem de blog. A disciplina de "enviar algo funcionando em um prazo fixo" força você a confrontar quais partes da sua pilha realmente economizam tempo e quais partes parecem que economizam tempo.
Há um padrão sutil aqui que continuo vendo em meu próprio trabalho e vi claramente nas filmagens do hackathon. Voltarei a isso depois de vermos por que o time vencedor venceu.
O que o aplicativo vencedor de rastreamento de refeições acertou
A equipe que conquistou o primeiro lugar neste hackathon Georgia Tech AI não construiu nada tecnicamente impressionante. Eles construíram a coisa certa. Essa distinção é tudo em uma construção com limite de tempo.
Seu aplicativo combinava rastreamento de refeições com gamificação – faixas para alimentação saudável, sugestões de combinações nutricionais (proteínas com carboidratos, esse tipo de coisa) e recompensas por consistência. No papel, isso parece simples. Abaixo, é um exemplo clássico do que funciona em aplicativos mHealth no momento.
Os aplicativos de dieta e nutrição têm um problema brutal de retenção. Dados da indústria mostram que cerca de 30% dos usuários mudam no primeiro mês. Cerca de 70% dos usuários abandonam um aplicativo de nutrição em duas semanas se ele parecer muito complexo ou demorado. O registro de refeições é um dos comportamentos diários mais exigentes do usuário em software de consumo, assim como o registro no diário – ele pede ao usuário que faça um trabalho consciente antes de ser recompensado.
Mas aqui está o dado que faz a escolha da equipe vencedora clicar: aplicativos de saúde gamificados mostram engajamento e retenção aproximadamente 50% maiores do que equivalentes não gamificados. Somente os selos de conquista aumentam o engajamento em cerca de 40%. A mecânica de sequência – a mesma primitiva que alimenta a retenção do MyFitnessPal – funciona porque sequestra a aversão à perda. Você não quer quebrar a corrente.
A equipe vencedora não inventou a gamificação para aplicativos de nutrição. Eles escolheram um padrão de retenção conhecido e deixaram o Claude estruturar a implementação em torno dele. Essa é a mudança. Num contêiner de três horas, a equipe que vence não é aquela com a arquitetura mais inovadora. É a equipe que reconhece qual padrão já tem evidências por trás dele e usa AI para enviar esse padrão com mais rapidez.
É exatamente assim que penso sobre minhas próprias construções agora. Não tento inventar novas mecânicas. Eu leio os dados de retenção, identifico quais mecânicos têm provas e uso o Claude para armazená-los em uma tarde. A largura de banda criativa não está em inventar novas rodas – está em escolher qual roda é importante e apertá-la para meu usuário específico.
Os cinco modos de falha do Hackathon que vejo repetidamente
Se você assistir hackathons suficientes – ou executar builds pessoais suficientes de três horas – os mesmos cinco modos de falha se repetirão. A filmagem Georgia Tech mostra pelo menos três deles. Aqui estão eles, na ordem em que tendem a morder.
Modo de falha um: aumento do escopo nos primeiros trinta minutos. Uma equipe recebe o aviso e começa a fazer riffs. Eles vão de "rastreador de refeições" a "rastreador de refeições mais feed social, além de nutricionista AI e leitor de código de barras". O AI está tão disposto que a equipe confunde “Claude pode montar isso” com “podemos enviar isso”. Duas horas depois, eles têm seis recursos incompletos e zero fluxos de trabalho. A cura é brutal: escolha um usuário, uma tela, uma interação e envie isso. Não adicione nada até que o núcleo funcione.
Modo de falha dois: confiar no primeiro UI gerado por AI. A saída nativa React ou React padrão de Claude é competente, mas genérica. A primeira tela do herói sempre tem os mesmos gradientes roxos, os mesmos ícones genéricos, a mesma cópia do CTA. As equipes que enviam algo memorável gastam pelo menos 20 minutos ajustando manualmente a identidade visual — não porque a saída do AI seja ruim, mas porque o AI de todas as outras equipes está produzindo resultados semelhantes a partir de prompts semelhantes. Se você leu meu detalhamento sobre por que todos os sites gerados por AI têm a mesma aparência, este é o mesmo problema de impressão digital aplicado aos aplicativos.
Modo de falha três: zero tratamento de erros. Um caminho funcional e feliz é uma compilação de 30 minutos. Um aplicativo funcional com erros tratados é uma compilação de três dias. Hackathons comprimem isso brutalmente. A equipe que vence geralmente é aquela que agrupa cada chamada API em um try/catch, mostra estados vazios elegantes e tem pelo menos um substituto para quando o recurso AI expirar. As demos não travam no palco porque a equipe teve sorte — elas não travam porque a equipe tratou o tratamento de erros como um recurso de primeira classe, não como um passo de polimento.
Modo de falha quatro: julgar a saída do AI lendo-o em vez de executá-lo. Vejo isso em meu próprio trabalho e vi claramente nas imagens do hackathon. Uma equipe solicita Claude, verifica a saída, vê "sim, parece certo" e segue em frente. Então, no minuto 145 de 180, eles realmente executam o código e três coisas quebram. A disciplina que separa os transportadores rápidos dos transportadores lentos é executar imediatamente todas as alterações geradas pelo AI. Read-don't-run é o atalho mais caro no desenvolvimento assistido por AI.
Modo de falha cinco: esquecer que a demonstração é a entrega. Um hackathon não é uma revisão de código. É um discurso de vendas com software em execução por baixo. As equipes que constroem um caminho de demonstração limpo de dois minutos – começam na tela inicial, atingem os três momentos impressionantes e terminam com uma conclusão satisfatória – vencem as equipes com produtos mais ambiciosos que não sabem como mostrar o que construíram. O mesmo se aplica ao envio de qualquer produto AI. Os primeiros 90 segundos do usuário são a demonstração. Projete esses 90 segundos intencionalmente.
Se você estiver usando Claude Code para construir qualquer coisa em um período de tempo restrito, vale a pena imprimir e fixar esses cinco modos de falha em seu monitor.
A questão do ser humano já foi resolvida - aqui está o que realmente está mudando
O vídeo enquadrou a discussão humana como se ainda fosse uma questão em aberto. O AI substituirá os desenvolvedores ou os humanos continuarão essenciais? Quero recuar nesse enquadramento porque acho que é a pergunta errada, e o próprio hackathon provou isso.
Essa questão foi resolvida no momento em que a Anthropic lançou o Claude Code 2.0 e os desenvolvedores começaram a executá-lo como um loop de agente com pontos de verificação humanos. A resposta é que os humanos permanecem informados. A questão interessante — aquela que realmente muda mês a mês — é aonde pertencem os pontos de controle humanos.
Em 2024, o posto de controle humano estava no nível da linha. Você pediria uma função ao AI e leria cada linha antes de colá-la. Em 2025, o ponto de verificação mudou para o nível de arquivo ou módulo – Claude poderia gravar um arquivo inteiro e você revisaria a comparação. Em abril de 2026, com o Opus 4.7, o ponto de verificação mudou para o nível de recurso. Claude pode construir, testar e autocorrigir um recurso inteiro, e o revisor humano verifica o comportamento do recurso, não suas linhas.
Isso é o que o Reitor Associado estava realmente apontando – e o que o hackathon demonstrou de forma compactada. Os alunos não estavam escrevendo todas as linhas. Eles estavam executando, testando, solicitando e solicitando novamente até que o comportamento correspondesse ao que eles queriam. O papel humano subiu um nível de abstração, mas não desapareceu. Na verdade, ficou mais difícil, porque revisar o comportamento exige mais habilidade do que revisar a sintaxe.
A propósito, é exatamente por isso que continuo dizendo que “alfabetização AI” é um enquadramento ruim para o que os alunos precisam agora. A alfabetização AI implica habilidades de leitura. O que você realmente precisa é de julgamento AI: saber quando confiar na saída, quando solicitar novamente, quando jogá-la fora e escrevê-la você mesmo e quando o AI está confiantemente errado. Isso é um ofício, não uma alfabetização. E como todo ofício, ele só se desenvolve construindo coisas que realmente precisam funcionar.
Um hackathon de três horas em uma escola de computação de ponta é um dos campos de treinamento mais limpos que posso imaginar para o julgamento do AI. Você não pode fingir. A campainha não se importa.
O que estou roubando do Hackathon para minhas próprias construções
Assistir a este vídeo mudou três coisas em como estou executando minhas próprias compilações AI este mês. Não porque aprendi exatamente algo novo - mas porque o hackathon esclareceu coisas que eu vinha fazendo intuitivamente.
Primeiro: estou estabelecendo prazos mais difíceis. Eu costumava me dar uma semana para enviar uma pequena ferramenta. Agora me dou uma noite. Não porque eu seja mais rápido (Claude é mais rápido, não sou), mas porque intervalos de tempo mais curtos forçam a disciplina a pular recursos que não importam. A restrição de três horas em Georgia Tech não foi cruel – foi esclarecedora. A maior parte do que é cortado sob pressão de tempo nunca seria enviado de qualquer maneira.
Dois: estou antecipando o caminho da demonstração. Antes de escrever uma linha, escrevo a demonstração de dois minutos que quero fazer. Clique aqui, veja isto, toque ali, observe o incremento do contador de sequências, veja a animação da recompensa. Então eu trabalho de trás para frente e construo apenas o que é necessário para fazer aquela demonstração funcionar. Todo o resto é uma meta extensa. Essa única mudança quase dobrou minha taxa de conclusão em projetos paralelos.
Três: estou executando todas as alterações do AI imediatamente. Eu costumava ler a saída do Claude, acenar com a cabeça e seguir em frente. Agora eu corro. Toda vez. Se Claude adicionou uma função, eu a chamo com entrada real. Se Claude estruturar um componente, eu o renderizo com dados reais. O atrito é pequeno. A taxa de descoberta de bugs é enorme. A maioria das falhas que eu costumava encontrar no final de uma compilação, agora encontro noventa segundos após a alteração ser feita.
Se você usa Claude Code ou qualquer ferramenta de codificação de agente casualmente e deseja subir de nível, essas três alterações por si só valem mais do que qualquer modelo de prompt que compartilhei.
O teto não é a capacidade do AI - é a confiança
Esta é a parte do hackathon à qual sempre volto. O aplicativo vencedor de monitoramento de refeições foi inteligente. A apresentação foi apertada. Os jurados adoraram. E quase certamente nenhum desses juízes usaria esse aplicativo para gerenciar sua própria dieta.
Isso não é um golpe para a equipe – é o teto fundamental para os aplicativos de consumo desenvolvidos pelo AI no momento. A capacidade não é mais o gargalo. Claude Opus 4.7 pode criar um aplicativo de saúde inteiro em uma hora com melhor ergonomia padrão do que o aplicativo médio na App Store. O gargalo é a confiança. Será que os utilizadores reais entregarão os seus dados alimentares, os seus dados de sono, os seus dados de saúde a uma aplicação cujo criador não conhecem, cuja política de privacidade não leram, cujo comportamento de retenção de dados não podem verificar?
Essa lacuna de confiança é exatamente onde reside a próxima onda de vantagem competitiva. Qualquer um pode criar um aplicativo AI. Quase ninguém consegue construir uma infraestrutura de confiança em torno disso – manipulação clara de dados, comportamento previsível em casos extremos, acessibilidade para usuários que não se enquadram no caminho feliz, estados de erro que não fazem o usuário se sentir estúpido e uma marca que sinaliza “isso estará aqui em dezoito meses”.
É também por isso que a conversa humana é importante muito além dos hackathons. Em 2026, a questão não é o AI pode construí-lo. A questão é um humano verificou isso bem o suficiente para que alguém com pele no jogo o use. Os fluxos de trabalho híbridos AI, onde a automação é combinada com a supervisão humana na altitude certa, são o padrão de produção agora. Os observadores da indústria começaram a chamar isso de “AI verificado por humanos” como um diferencial da marca. Eles não estão errados. O mercado está começando a precificar a confiança da mesma forma que precificava a qualidade do código – como um fosso competitivo.
As equipes do hackathon que perderam não foram superadas em capacidade. Eles foram superados em julgamento – quais recursos enviar, quais cortar, qual caso extremo tratar, em qual polimento investir. Esse julgamento é o que o AI não substitui. É a coisa que AI amplifica quando o humano que o empunha o possui, e expõe brutalmente quando o humano não o possui.
O que os três alunos do minuto 145 estavam realmente fazendo
Deixe-me voltar àquele momento do vídeo que está na minha cabeça.
Três estudantes. Um laptop. Restam vinte minutos no relógio. O aplicativo deles estava quase funcionando. Eles estavam depurando, solicitando Claude, executando novamente e solicitando novamente. Tentando atualizar o contador de sequências sem travar a visualização do painel.
Essa não é uma história sobre AI substituindo desenvolvedores. Essa é a história de três jovens engenheiros aprendendo o trabalho real de um desenvolvedor da era AI em tempo real. O trabalho não é escrever código. O trabalho nem sequer está solicitando AI. O trabalho é o loop: defina o comportamento desejado, acione o AI, execute o resultado, encontre a lacuna entre o comportamento e a realidade, avise novamente, execute novamente, até que a lacuna seja fechada. Esse ciclo é toda a profissão agora.
Um hackathon de três horas no Georgia Tech não expõe os alunos ao AI. Isso lhes ensina o loop. Isso vale mais do que qualquer curso de engenharia imediata ou qualquer tutorial sobre o Anthropic SDK. Você aprende o ciclo executando-o sob pressão, não lendo sobre ele.
Se eu estivesse executando um programa de ciência da computação em 2026, faria com que cada aluno fizesse pelo menos um hackathon solo de três horas por mês. Não porque os hackathons sejam inerentemente ótimos - eles são brutais - mas porque nada mais comprime todo o ciclo de desenvolvimento da era AI em uma única tarde, como eles fazem.
Perguntas frequentes
Qual foi o prompt do hackathon Georgia Tech AI?
O hackathon Claude Builder Club no Georgia Tech desafiou os alunos a construir um aplicativo móvel ou web que ajudasse as pessoas a manter hábitos saudáveis usando o design baseado em AI, em uma janela de três horas. A indicação foi revelada apenas no início da competição, podendo competir equipes de até três alunos. A inscrição vencedora foi um aplicativo gamificado de rastreamento de refeições com recompensas consecutivas e sugestões de combinações nutricionais.
Qual modelo Claude foi usado no hackathon Georgia Tech patrocinado pela Anthropic?
Hackathons patrocinados pela Anthropic em 2026 normalmente dão aos participantes acesso aos modelos Claude mais recentes, incluindo Claude Opus 4.7 (lançado em 16 de abril de 2026) para tarefas de codificação complexas e Claude Sonnet 4.6 para iteração mais rápida. A maioria das equipes usa Claude Code ou Anthropic API diretamente durante a janela de construção. Para uma análise mais completa de como eu os uso na produção, consulte meu guia de fluxo de trabalho Claude Code.
Quão rápido o AI pode realmente construir um aplicativo funcional em 2026?
Claude Opus 4.7 pode criar um aplicativo nativo Next.js ou React completo - autenticação, banco de dados, UI - em aproximadamente seis a quinze minutos. O “andaime” não é o mesmo que o “produto pronto para envio”. Usuários reais encontram casos extremos, estados de erro e formatos de dados que o scaffold não suporta por padrão, o que normalmente leva a maior parte do tempo de construção, mesmo com a assistência do AI.
Por que a gamificação funciona tão bem em aplicativos de saúde?
A gamificação funciona porque os comportamentos de saúde exigem atrito diário (registro, rastreamento, escolha) e as recompensas de uma vida saudável demoram a se materializar. Séries, emblemas e ciclos de recompensa comprimem o cronograma de feedback para que os usuários sintam o progresso em dias, em vez de meses. Os aplicativos de saúde gamificados apresentam engajamento e retenção cerca de 50% maiores do que equivalentes não gamificados, com emblemas de conquista por si só aumentando o engajamento em cerca de 40%.
O modelo human-in-the-loop ainda é relevante quando AI é capaz?
Sim - mais, não menos. À medida que a capacidade do AI cresceu, o ponto de verificação humano no circuito evoluiu em abstração, da revisão em nível de linha para a verificação de comportamento em nível de recurso. O consenso da indústria em 2026 trata o AI verificado por humanos como o padrão de produção para qualquer sistema onde confiança, conformidade ou segurança são importantes. A questão não é se os humanos permanecem no circuito, mas em que ponto do circuito eles se situam.
A campainha não mente
A razão pela qual o vídeo Georgia Tech ficou na minha cabeça por dois dias não é a tecnologia. Foi o que a campainha revelou.
Três horas. Os melhores modelos da Antrópico. Alguns dos estudantes de computação mais talentosos do país. E a lacuna entre “AI pode construí-lo” e “os usuários podem confiar” ainda era maior do que três horas poderiam fechar. Essa lacuna é todo o trabalho agora. Essa lacuna é onde cada engenheiro, cada fundador, cada construtor individual passará os próximos cinco anos de sua carreira.
Esta noite, antes de ir para a cama, reserve uma caixa de três horas. Escolha algo pequeno. Abra Claude Code. Defina um cronômetro. Veja o que você pode enviar entre o andaime e a confiança. Você aprenderá mais sobre como o AI está realmente mudando o ritmo da construção do que em qualquer palestra deste ano.
A campainha não mente. A demonstração também não.
Vamos trabalhar juntos
Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.
- Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e marca): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
