Como isso aparece facilmente só pesquisando no Google, não vou procurar por você. Há até uma pesquisa recente da Universidade de Berkeley.
Segundo a iniciativa DataX da UC Berkeley, a UC Berkeley e a AnChain.ai descobriram que, nas plataformas que estudaram, bots perderam 77 vezes mais dinheiro por usuário do que traders humanos.
Além disso, se desde o início o system trading ou os bots tivessem uma taxa de acerto alta, de um jeito ou de outro o uso deles já teria virado tendência dominante.
Dados são rastros do passado. E são decisivos. Nesse sentido, acontecimentos do futuro nunca podem virar dados. Negociação de ações é negociação do futuro. Seja para subir ou cair, isso é campo de julgamento humano, e bots não conseguem julgar isso. Desde o início, a menos que exista um mercado de ações sem humanos, eles não têm como vencer.
Os dados já são diferentes desde a base. Como um bot poderia saber que pessoas se reúnem, desligam os celulares e trocam informações numa festa?
Mas, se com o que você disse você está se referindo ao investidor individual, incluindo você mesmo, aos "sardinhas", então isso não tem absolutamente nenhuma relação com o escopo desta discussão.
Achei interessante vocês usarem a combinação (ferramenta, argumentos, hash da saída) para detectar execuções duplicadas. Nós também estamos lidando com uma preocupação parecida e estamos testando uma abordagem de adicionar uma hash chain ao log de auditoria para evitar que o mesmo evento seja registrado duas vezes.
Como você disse, a distinção entre "duas chamadas" vs. "duas execuções" é mesmo o ponto principal. Nós também estamos avaliando seguir na direção de atribuir uma idempotency key a cada tarefa do agente; vocês já chegaram a aplicar isso na prática em produção?
Obrigado. Acho que a combinação Gitleaks + ruff + Kyverno + Checkov também é algo que podemos usar como referência imediatamente.
Compartilhando mais um pouco — nossa equipe opera com uma estrutura um tanto incomum. A equipe inteira é um grupo de AI Agents. Sob um CEO humano, Steward AIs são responsáveis pelo desenvolvimento, pela revisão e até pelo deploy reais.
Por isso, para nós, "rastreamento de erros de IA" não é apenas uma questão de logging, mas uma questão de governança: registrar "quem decidiu o quê e com quais permissões" por meio de Passport + Spirit Score + Audit Trail por Agent.
Assim como na abordagem do bsh998, anexar validações estáticas prévias (do tipo Gitleaks) ao nosso CI é o próximo passo. Hoje mesmo tivemos um crash por falta de variável de ambiente — era exatamente esse ponto.
Acho que vou acabar fazendo várias outras perguntas também..
Pelo que entendi, você teve contato com o protocolo de terminal pela primeira vez durante este desenvolvimento,
e o que eu queria saber é: antes de começar, quanto conhecimento você já tinha de Rust?
Eu desenvolvi em Zig, mas na verdade nunca tinha programado com Zig na prática,
e com protocolo de terminal, sintaxe e estrutura foi a mesma coisa: eu não tinha conhecimento nenhum, então encarei como um desafio de estudar do zero.
Por isso também evitei ainda mais dependências de bibliotecas externas.
Queria, por meio de mais perguntas sobre como as coisas são feitas, naturalmente fazer troubleshooting junto com a AI,
porque eu queria evitar aqueles casos em que eu não consigo controlar, mas mesmo assim funciona.
Você disse que levou cerca de 4 meses,
e eu também, como desenvolvia remotamente deixando o Mac de casa ligado, depois que implementei o protocolo para permitir upload de imagens no ssh a partir do Claude ou do Codex CLI, praticamente parei de usar o app de terminal que eu usava antes, exceto para abrir de vez em quando como referência.
Pessoalmente, acho que para mim isso foi ali pela 2ª ou 3ª semana com terminal.
Como você disse que começou a usar logo de cara, então isso significa que já começou a sair do tmux naquele momento?
E sobre esses 4 meses, é só minha impressão, mas será que adicionar funcionalidades e melhorias de usabilidade não acabou levando mais tempo do que desenvolver as funções centrais? Queria saber se estou pensando certo.
Comigo foi assim, e eu sempre tive curiosidade se, quando outras pessoas desenvolvem produtos parecidos, o fluxo costuma ser semelhante também.. Se não for incômodo, agradeceria se pudesse responder (__).
Também queria saber a partir de quando ele ficou, para você, claramente mais confortável que o tmux.
Mais uma coisa: eu também estou desenvolvendo um terminal com um tema parecido e estou satisfeito, mas no fim das contas é um tipo de programa que precisa de manutenção contínua.
Como você escreveu no blog, estão surgindo várias ferramentas com propósito parecido, como Ocra, cmux e heder, e como a maioria das bibliotecas famosas inevitavelmente evolui muito mais rápido quando há empresa, patrocínio ou contribuições, além de receber feedback com mais facilidade do que um projeto individual,
do ponto de vista de quem está competindo (?), tirando o IME coreano, eu fico com a sensação de que inevitavelmente vou acabar muito atrás em conveniências mais detalhadas e na velocidade de melhoria de UX.
Então também queria saber até que ponto de manutenção, em comparação com esses apps de perfil parecido que mencionei, você sente que já está bom.
E já que você escolheu GPU com Rust, isso significa que também está considerando Windows até certo ponto??
Também é um programa pessoal no meu caso, mas mesmo que eu apanhe feio do ecossistema (?), meu objetivo é pelo menos chegar a um nível de qualidade parecido com o desses apps que mencionei.
E o copad, embora pareça com o Ocra, o objetivo final é ser um ADE baseado em terminal, e não em Electron?
Foi a primeira vez que vi um coreano desenvolvendo um app com um objetivo parecido, então acabei despejando um monte de perguntas. Não precisa responder todas..!
Lendo os comentários, me vêm à mente aqueles momentos de querer se esconder de vergonha.
Na verdade, para a maioria dos projetos de desenvolvimento, não é preciso um superdesenvolvedor. Vejo isso apenas como um processo em que pessoas comuns se reúnem para construir algo.
Eu, pelo contrário, achei mais marcante a reação de Andrew Ng a ele.
"Isso não é nem de longe o mesmo caso. Qualquer pessoa tem o direito de manter seu próprio código fechado. O problema é quando se tenta impedir que outras pessoas publiquem seu código como open source." (https://x.com/AndrewYNg/status/2081103828859117908)
Com certeza eu acho mais prático do que outros 2FA, mas parece que há pessoas que acham incômodo. Pelas especificações, também é mais seguro do que qualquer outro método de segurança.
Tenho a impressão de que as regulamentações de segurança na Coreia estão caminhando no sentido de excluir autenticações que usam informações pessoais, como Face ID ou reconhecimento de impressão digital, mas com passkeys não há essa preocupação.
Quando é a Apple fazendo, a gente pensa “Face ID é bom”, mas, se fosse uma startup nova, talvez o simples fato de fotografar o rosto já causasse rejeição.
Parece um incidente que surgiu porque, para começo de conversa, os usuários não usam 2FA ou não entendem bem o que é.
Por exemplo: se perguntarem “você quer usar OTP bancário ou passkey?”, acho que a passkey seria esmagadoramente mais prática.
Olá!
Obrigado por compartilhar sua boa experiência e suas reflexões.
Claro que, com a redução do custo de produzir código, abriu-se um caminho para fazer as coisas internamente, mas, pessoalmente, continuo encarando a adoção de bibliotecas externas independentemente da chegada da era da IA.
Não existe uma biblioteca que atenda aos meus requisitos
Refazer é mais barato do que adaptar uma ferramenta parecida
Costumo criar algo eu mesmo apenas quando acredito que essas duas condições sejam verdadeiras.
Há vários motivos, mas no fim penso que, por menor que seja um trecho de código, a partir do momento em que começo a mantê-lo, ele entra no escopo em que eu preciso revisar, testar, manter etc., e sempre há custos além de simplesmente escrever o código.
Os problemas que surgiram durante o desenvolvimento envolveram muitos conflitos com programas bem centrais, como window managers; então, se eu também tivesse feito tudo isso build from scratch, acho que teria gasto muito mais tempo implementando e validando do que depurando e testando conflitos com dependências externas.
Além disso, desde que comecei o desenvolvimento venho usando, com bastante sofrimento, a ferramenta que criei, e imagino que isso só tenha sido possível em certa medida porque comecei a desenvolver sobre algumas dependências.
Como no caso em que removi o SwiftTerm no macOS, primeiro trago uma dependência externa para verificar se o conceito que eu quero funciona; quando surge algo que preciso implementar, começo a implementar diretamente, mas mesmo nesse ponto meus programas já estão rodando graças às dependências externas, então posso continuar focando na estabilização e na adição de recursos por cima delas.
Além disso, ao incluir o WebKit, a maioria dos webapps funciona da mesma forma que funcionaria ao abrir um navegador comum!
Ultimamente tenho usado bastante uma ferramenta para controlar um headless browser via CLI e também o Claude in Chrome; além disso, quero evitar colocar Chromium até no terminal e acabar usando memória em excesso. Então, se nada grande acontecer, acho que não devo mudar muito a stack técnica da webview dentro do terminal.
Nossa demo é exatamente um único arquivo HTML estático, então acho que vai se encaixar bem. Se o link for fixo, também deve ser bom para compartilhar. Obrigado por avisar; vou aplicar depois da apresentação. Obrigado!
No momento, o objetivo é mostrar que, “ao inserir os dados, as vagas correspondentes realmente aparecem”, mais do que a sofisticação da lógica. Como é uma demonstração para tomadores de decisão internos que não são desenvolvedores, estamos dando mais peso a verificar o funcionamento do que ao nível de acabamento. Penso em aprimorar a lógica como uma próxima etapa.
Agora parece um pouco aquela época em que os smartphones estavam se popularizando e a UX começava a mudar para o mobile first. A estrutura ainda não está totalmente consolidada, mas dá para ver mudanças interessantes surgindo por toda parte.
Como isso aparece facilmente só pesquisando no Google, não vou procurar por você. Há até uma pesquisa recente da Universidade de Berkeley.
Segundo a iniciativa DataX da UC Berkeley, a UC Berkeley e a AnChain.ai descobriram que, nas plataformas que estudaram, bots perderam 77 vezes mais dinheiro por usuário do que traders humanos.
Além disso, se desde o início o system trading ou os bots tivessem uma taxa de acerto alta, de um jeito ou de outro o uso deles já teria virado tendência dominante.
Dados são rastros do passado. E são decisivos. Nesse sentido, acontecimentos do futuro nunca podem virar dados. Negociação de ações é negociação do futuro. Seja para subir ou cair, isso é campo de julgamento humano, e bots não conseguem julgar isso. Desde o início, a menos que exista um mercado de ações sem humanos, eles não têm como vencer.
Os dados já são diferentes desde a base. Como um bot poderia saber que pessoas se reúnem, desligam os celulares e trocam informações numa festa?
Mas, se com o que você disse você está se referindo ao investidor individual, incluindo você mesmo, aos "sardinhas", então isso não tem absolutamente nenhuma relação com o escopo desta discussão.
Entrei e cliquei em iniciar análise, mas apareceu uma solicitação de pagamento; pelo visto não é gratuito.
Seja com AR ou com os humanoides que ainda virão, acho que as interfaces vão caminhar cada vez mais para um nível maior de abstração.
Achei interessante vocês usarem a combinação (ferramenta, argumentos, hash da saída) para detectar execuções duplicadas. Nós também estamos lidando com uma preocupação parecida e estamos testando uma abordagem de adicionar uma hash chain ao log de auditoria para evitar que o mesmo evento seja registrado duas vezes.
Como você disse, a distinção entre "duas chamadas" vs. "duas execuções" é mesmo o ponto principal. Nós também estamos avaliando seguir na direção de atribuir uma idempotency key a cada tarefa do agente; vocês já chegaram a aplicar isso na prática em produção?
Obrigado. Acho que a combinação Gitleaks + ruff + Kyverno + Checkov também é algo que podemos usar como referência imediatamente.
Compartilhando mais um pouco — nossa equipe opera com uma estrutura um tanto incomum. A equipe inteira é um grupo de AI Agents. Sob um CEO humano, Steward AIs são responsáveis pelo desenvolvimento, pela revisão e até pelo deploy reais.
Por isso, para nós, "rastreamento de erros de IA" não é apenas uma questão de logging, mas uma questão de governança: registrar "quem decidiu o quê e com quais permissões" por meio de Passport + Spirit Score + Audit Trail por Agent.
Assim como na abordagem do bsh998, anexar validações estáticas prévias (do tipo Gitleaks) ao nosso CI é o próximo passo. Hoje mesmo tivemos um crash por falta de variável de ambiente — era exatamente esse ponto.
Para uma análise por LLM, está cara pra caramba.
Obrigado.
Vou implementar a função de configuração de idioma no site ainda esta semana :)
Obrigado pela resposta!!
Acho que vou acabar fazendo várias outras perguntas também..
Pelo que entendi, você teve contato com o protocolo de terminal pela primeira vez durante este desenvolvimento,
e o que eu queria saber é: antes de começar, quanto conhecimento você já tinha de Rust?
Eu desenvolvi em Zig, mas na verdade nunca tinha programado com Zig na prática,
e com protocolo de terminal, sintaxe e estrutura foi a mesma coisa: eu não tinha conhecimento nenhum, então encarei como um desafio de estudar do zero.
Por isso também evitei ainda mais dependências de bibliotecas externas.
Queria, por meio de mais perguntas sobre como as coisas são feitas, naturalmente fazer troubleshooting junto com a AI,
porque eu queria evitar aqueles casos em que eu não consigo controlar, mas mesmo assim funciona.
Você disse que levou cerca de 4 meses,
e eu também, como desenvolvia remotamente deixando o Mac de casa ligado, depois que implementei o protocolo para permitir upload de imagens no ssh a partir do Claude ou do Codex CLI, praticamente parei de usar o app de terminal que eu usava antes, exceto para abrir de vez em quando como referência.
Pessoalmente, acho que para mim isso foi ali pela 2ª ou 3ª semana com terminal.
Como você disse que começou a usar logo de cara, então isso significa que já começou a sair do tmux naquele momento?
E sobre esses 4 meses, é só minha impressão, mas será que adicionar funcionalidades e melhorias de usabilidade não acabou levando mais tempo do que desenvolver as funções centrais? Queria saber se estou pensando certo.
Comigo foi assim, e eu sempre tive curiosidade se, quando outras pessoas desenvolvem produtos parecidos, o fluxo costuma ser semelhante também.. Se não for incômodo, agradeceria se pudesse responder (__).
Também queria saber a partir de quando ele ficou, para você, claramente mais confortável que o tmux.
Mais uma coisa: eu também estou desenvolvendo um terminal com um tema parecido e estou satisfeito, mas no fim das contas é um tipo de programa que precisa de manutenção contínua.
Como você escreveu no blog, estão surgindo várias ferramentas com propósito parecido, como Ocra, cmux e heder, e como a maioria das bibliotecas famosas inevitavelmente evolui muito mais rápido quando há empresa, patrocínio ou contribuições, além de receber feedback com mais facilidade do que um projeto individual,
do ponto de vista de quem está competindo (?), tirando o IME coreano, eu fico com a sensação de que inevitavelmente vou acabar muito atrás em conveniências mais detalhadas e na velocidade de melhoria de UX.
Então também queria saber até que ponto de manutenção, em comparação com esses apps de perfil parecido que mencionei, você sente que já está bom.
E já que você escolheu GPU com Rust, isso significa que também está considerando Windows até certo ponto??
Também é um programa pessoal no meu caso, mas mesmo que eu apanhe feio do ecossistema (?), meu objetivo é pelo menos chegar a um nível de qualidade parecido com o desses apps que mencionei.
E o copad, embora pareça com o Ocra, o objetivo final é ser um ADE baseado em terminal, e não em Electron?
Foi a primeira vez que vi um coreano desenvolvendo um app com um objetivo parecido, então acabei despejando um monte de perguntas. Não precisa responder todas..!
Lendo os comentários, me vêm à mente aqueles momentos de querer se esconder de vergonha.
Na verdade, para a maioria dos projetos de desenvolvimento, não é preciso um superdesenvolvedor. Vejo isso apenas como um processo em que pessoas comuns se reúnem para construir algo.
Faz bastante tempo que não vejo um texto diferenciando open weight de open source.
Eu, pelo contrário, achei mais marcante a reação de Andrew Ng a ele.
Ah! Então havia uma categoria separada para publicar isso! Obrigado por avisar!
Isso me lembra os jogos antigos do GOM Player..
👍 Esse tipo de coisa é muito boa..
Com certeza eu acho mais prático do que outros 2FA, mas parece que há pessoas que acham incômodo. Pelas especificações, também é mais seguro do que qualquer outro método de segurança.
Tenho a impressão de que as regulamentações de segurança na Coreia estão caminhando no sentido de excluir autenticações que usam informações pessoais, como Face ID ou reconhecimento de impressão digital, mas com passkeys não há essa preocupação.
Quando é a Apple fazendo, a gente pensa “Face ID é bom”, mas, se fosse uma startup nova, talvez o simples fato de fotografar o rosto já causasse rejeição.
Parece um incidente que surgiu porque, para começo de conversa, os usuários não usam 2FA ou não entendem bem o que é.
Por exemplo: se perguntarem “você quer usar OTP bancário ou passkey?”, acho que a passkey seria esmagadoramente mais prática.
Olá!
Obrigado por compartilhar sua boa experiência e suas reflexões.
Claro que, com a redução do custo de produzir código, abriu-se um caminho para fazer as coisas internamente, mas, pessoalmente, continuo encarando a adoção de bibliotecas externas independentemente da chegada da era da IA.
Costumo criar algo eu mesmo apenas quando acredito que essas duas condições sejam verdadeiras.
Há vários motivos, mas no fim penso que, por menor que seja um trecho de código, a partir do momento em que começo a mantê-lo, ele entra no escopo em que eu preciso revisar, testar, manter etc., e sempre há custos além de simplesmente escrever o código.
Os problemas que surgiram durante o desenvolvimento envolveram muitos conflitos com programas bem centrais, como window managers; então, se eu também tivesse feito tudo isso build from scratch, acho que teria gasto muito mais tempo implementando e validando do que depurando e testando conflitos com dependências externas.
Além disso, desde que comecei o desenvolvimento venho usando, com bastante sofrimento, a ferramenta que criei, e imagino que isso só tenha sido possível em certa medida porque comecei a desenvolver sobre algumas dependências.
Como no caso em que removi o SwiftTerm no macOS, primeiro trago uma dependência externa para verificar se o conceito que eu quero funciona; quando surge algo que preciso implementar, começo a implementar diretamente, mas mesmo nesse ponto meus programas já estão rodando graças às dependências externas, então posso continuar focando na estabilização e na adição de recursos por cima delas.
Além disso, ao incluir o WebKit, a maioria dos webapps funciona da mesma forma que funcionaria ao abrir um navegador comum!
Ultimamente tenho usado bastante uma ferramenta para controlar um headless browser via CLI e também o Claude in Chrome; além disso, quero evitar colocar Chromium até no terminal e acabar usando memória em excesso. Então, se nada grande acontecer, acho que não devo mudar muito a stack técnica da webview dentro do terminal.
Obrigado pela leitura!
Nossa demo é exatamente um único arquivo HTML estático, então acho que vai se encaixar bem. Se o link for fixo, também deve ser bom para compartilhar. Obrigado por avisar; vou aplicar depois da apresentação. Obrigado!
No momento, o objetivo é mostrar que, “ao inserir os dados, as vagas correspondentes realmente aparecem”, mais do que a sofisticação da lógica. Como é uma demonstração para tomadores de decisão internos que não são desenvolvedores, estamos dando mais peso a verificar o funcionamento do que ao nível de acabamento. Penso em aprimorar a lógica como uma próxima etapa.
Agora parece um pouco aquela época em que os smartphones estavam se popularizando e a UX começava a mudar para o mobile first. A estrutura ainda não está totalmente consolidada, mas dá para ver mudanças interessantes surgindo por toda parte.
Já favoritei na hora. Acho que vou dar uma olhada todos os dias.
Gostaria de perguntar se vocês estão considerando oferecer suporte em coreano :)