Vibe raspando e vibe codificando um aplicativo de programação para molho aberto 2025 inteiramente no meu telefone

Vibe raspando e vibe codificando um aplicativo de programação para molho aberto 2025 inteiramente no meu telefone

17 de julho de 2025

Hoje de manhã, trabalhando inteiramente no meu telefone, raspei um site da conferência e o Vibe codificou uma interface de interface do usuário alternativa para interagir com o cronograma usando uma combinação de Codex e Artefatos Claude.

Este fim de semana é o Open Molho 2025, a terceira edição da conferência da Bay Area para criadores do YouTube no espaço de ciências e engenharia. Eu tenho alguns amigos indo e eles estavam reclamando que o cronograma oficial era difícil de navegar em um telefone-ele nem está ligado da página inicial no celular e, depois de encontrar a agenda, não é particularmente compatível com dispositivos móveis.

Estávamos fora para tomar um café esta manhã, então eu só tinha meu telefone, mas decidi ver se poderia consertar de qualquer maneira.

TLDR: trabalhando inteiramente no meu iPhone, usando uma combinação de Codex OpenAI no aplicativo móvel ChatGPT e artefatos Claude através do aplicativo Claude, pude raspar a programação completa e depois construir e implantar isto: Tools.simonwillison.net/open-sauce-2025

O site oferece um carregamento mais rápido e uma visualização de agenda mais útil, mas, mais importante, inclui uma opção para “baixar o calendário (ICS)”, que permite que os usuários de telefones celulares (Android e iOS) importem facilmente os eventos de programação diretamente para o aplicativo calendário de escolha.

Aqui estão algumas notas detalhadas sobre como eu o construí.

Raspando o cronograma

O primeiro passo foi obter esse cronograma em um formato estruturado. Não tenho boas ferramentas para visualizar a fonte no meu iPhone, então adotei uma abordagem diferente para transformar o site da programação em dados estruturados.

Meu primeiro pensamento foi a exibição da programação no meu telefone e depois despejar as imagens em uma visão LLM – mas a programação foi longa o suficiente para que eu não tivesse vontade de percorrer várias páginas diferentes e costurar dezenas de imagens.

Se eu estivesse trabalhando em um laptop, eu recorriu a raspar: eu procuraria no próprio site e descobriria de onde vieram os dados, depois escrevia o código para extraí -los.

Como eu poderia fazer a mesma coisa trabalhando no meu telefone?

Eu decidi usar Openai Codex– A ferramenta hospedada, não a utilitária da CLI denominada confusa.

O Codex recentemente aumentou a capacidade de interagir com a Internet enquanto tentava resolver uma tarefa. Eu tenho um Codex “Ambiente” dedicado configurado contra um repositório do GitHub que não faz mais nada, apenas para que eu possa executar sessões habilitadas para a Internet lá que possam executar comandos arbitrários habilitados para rede.

Comecei uma nova tarefa por lá (usando a interface Codex dentro do aplicativo ChatGPT iPhone) e solicitei:

Install playwright and use it to visit https://opensauce.com/agenda/ and grab the full details of all three day schedules from the tabs - Friday and Saturday and Sunday - then save and on Data in as much detail as possible in a JSON file and submit that as a PR

O Codex é frustrante, pois você recebe apenas uma foto: ele pode desaparecer e trabalhar de forma autônoma em uma tarefa por um longo tempo, mas enquanto está funcionando, você não pode dar a ele. Você pode esperar que ele termine completamente e, em seguida, diga para tentar novamente em uma nova sessão, mas, idealmente, as instruções que você fornece são suficientes para chegar ao estado de acabamento, onde ele envia uma solicitação de tração contra o seu repositório com os resultados.

Tive sorte: meu prompt acima funcionou exatamente como pretendido.

Codex agitou para um 13 minutos! Eu estava sentado conversando em uma cafeteria, ocasionalmente verificando os troncos para ver o que estava fazendo.

Ele tentou várias abordagens, todas envolvendo a execução da biblioteca do dramaturgo Python para interagir com o site. Você pode ver a transcrição completa aqui. Inclui notas como “Parece que o XXD não está instalado. Vou pegar “vim-common” ou “xxd” para corrigi-lo.“.

Eventualmente, baixou um enorme pedaço ofuscado de JavaScript chamado cronograma-overview-MAIN-1752724893152.js (316kb) e depois executou uma sequência complexa de comandos grep, grep, sed, strings, xxd e dd contra a localização dos dados da programação bruta, para extrair.

Aqui está o eventual extract_schedule.py python script que escreveu, que usa dramaturgo para salvar isso schedule-overview-main-1752724893152.js Arquive e depois extrai os dados brutos usando o seguinte código (que chama Node.js dentro do Python, sem motivo aparente):

node_script = (
    "const fs=require('fs');"
    f"const d=fs.readFileSync('{tmp_path}','utf8');"
    "const m=d.match(/var oo=(\\{.*?\\});/s);"
    "if(!m){throw new Error('not found');}"
    "const obj=eval('(' + m(1) + ')');"
    f"fs.writeFileSync('{OUTPUT_FILE}', JSON.stringify(obj, null, 2));"
)
subprocess.run(('node', '-e', node_script), check=True)

Conforme instruído, ele apresentou um PR contra meu repo. Ele incluiu o script de dramaturgo do Python, mas, mais importante, também incluía o arquivo completo Schedule.json extraído. Isso significava que agora eu tinha os dados do cronograma, com um raw.githubusercontent.com URL com cabeçalhos Open CORS que podem ser buscados por um aplicativo da web!

Construindo o aplicativo da web

Agora que eu tinha os dados, a próxima etapa era criar um aplicativo da Web para visualizá -los e servir em um formato mais útil.

Decidi que queria duas coisas: uma boa interface amigável para dispositivos móveis para navegar na programação e mecanismo para importar esse cronograma para um aplicativo de calendário, como Apple ou Google Calendar.

Levei várias partidas falsas para fazer isso funcionar. O maior desafio foi obter esses 63kb de dados JSON do cronograma no aplicativo. Eu tentei algumas abordagens aqui, tudo no meu iPhone enquanto estava sentado no café e depois dirigia com um amigo para deixá -los na estação Bart mais próxima.

1. Usando o ChatGPT Canvas e O3, pois, diferentemente dos artefatos de Claude, uma tela pode buscar dados de URLs remotos se você permitir a lista desse domínio. Mais tarde, descobri que isso funcionou quando o vi no meu laptop, mas no meu telefone ele lançou erros, então desisti.
2. Enviando o JSON para Claude e pedir para criar um artefato que leia o arquivo diretamente – isso falhou com um erro “indefinido não é um objeto (avaliando ‘window.fs.readfile’). O prompt de sistema Claude 4 me levou a esperar que isso funcione, não sei por que não funcionou.
3. Tendo Claude copiar o JSON completo no artefato. Isso demorou muito – dar 63 kb de JSON não é um uso sensato de tokens LLM, e ele se apagou quando minha conexão foi intermitente dirigindo através de um túnel.
4. Dizendo a Claude para buscar o URL para esse cronograma JSON. Este foi o meu último recurso, porque o Claude Artifacts bloqueia o acesso a URLs externos, então você precisa copiar e colar o código em uma interface separada (em um iPhone, que ainda não possui um botão “selecione tudo”), por isso é um processo frustrante.

Essa opção final funcionou! Aqui está a sequência completa de avisos que usei com Claude para chegar a uma implementação funcional – transcrição cheia aqui:

Use your analyst tool to read this JSON file and show me the top level keys

Isso era para o Prime Claude – eu queria lembrá -lo sobre o seu window.fs.readFile Funcionar e peça a ele o suficiente do JSON para entender a estrutura.

Build an artifact with no react that turns the schedule into a nice mobile friendly webpage - there are three days Friday, Saturday and Sunday, which corresponded to the 25th and 26th and 27th of July 2025

Don’t copy the raw JSON over to the artifact - use your fs function to read it instead

Also include a button to download ICS at the top of the page which downloads a ICS version of the schedule

Eu tinha notado que os dados da programação tinham chaves para “sexta -feira” e “sábado” e “domingo”, mas nenhuma indicação das datas, então eu disse isso. Aconteceu mais tarde que eu entendi errado!

Isso me deu uma versão da página que falhou com um erro, porque isso fs.readFile() Não foi possível carregar os dados do artefato por algum motivo. Então eu consertei isso com:

Change it so instead of using the readFile thing it fetches the same JSON from https://raw.githubusercontent.com/simonw/.github/f671bf57f7c20a4a7a5b0642837811e37c557499/schedule.json

… então copiou o html para uma essência e visualizou -o com gistpreview.github.io – aqui está essa visualização.

Então nós o checamos, já que existem tantas maneiras Isso poderia ter dado errado. Felizmente, o próprio cronograma JSON nunca passou por um LLM, então não precisávamos nos preocupar com detalhes de sessão alucinados, mas isso era quase pura codificação de vibração, então havia um grande risco de se esgueirar.

Eu me estabeleceria um prazo de “quando largamos meu amigo na estação Bart” e atingi esse prazo com apenas segundos para sobrar. Eu colei o HTML resultante no meu repo Simonw/Tools Github usando a interface da Web móvel do Github que o implantou nessas ferramentas finais.simonwillison.net/open-sauce-2025 URL.

… então percebemos que nós tive Perdi um bug: eu havia dado as datas de “25 e 26 e 27 de julho de 2025”, mas na verdade era uma semana tarde demais, as datas corretas eram de 18 a 20 de julho.

Felizmente eu tenho Codex configurado contra o meu simonw/tools Repo também, portanto, corrigindo esse caso de solicitar uma nova sessão do Codex com:

The open sauce schedule got the dates wrong - Friday is 18 July 2025 and Saturday is 19 and Sunday is 20 - fix it

Aqui está a transcrição do Codex, que resultou nesse PR que eu desembarcei e implantei, novamente usando a interface da Web móvel do Github.

O que tudo isso demonstra

Portanto, para recapitular: pude raspar um site (sem sequer uma fonte de visualização também), transformar os dados JSON resultantes em um site para dispositivos móveis, adicionar um recurso de exportação de ICS e implantar os resultados a uma plataforma de hospedagem estática (páginas do GitHub) trabalhando inteiramente no meu telefone.

Se eu tivesse um laptop, esse projeto teria sido mais rápido, mas honestamente, além de um pouco mais de depuração prática, não teria feito isso de uma maneira particularmente diferente.

Consegui fazer outras coisas ao mesmo tempo – o projeto de raspagem do Codex foi executado totalmente autonomamente, e a construção do aplicativo estava mais envolvida apenas porque tive que contornar as limitações das ferramentas que eu estava usando em termos de busca de dados de fontes externas.

Como de costume com esse material, meus mais de 25 anos de experiência anterior em desenvolvimento da Web foram essenciais para poder executar o projeto. Eu sabia sobre o Codex, e artefatos, e github, dramaturgos e cabeçalhos da CORS e limitações de sandbox e os recursos de arquivos de ICS em telefones celulares.

Essa coisa toda era Muito divertido! Ser capaz de aumentar vários agentes de codificação diretamente do meu telefone e resolver problemas bastante complexos, enquanto apenas prestar atenção parcial aos detalhes é uma demonstração sólida de por que continuo gostando de explorar as bordas da programação assistida por A A.

ATUALIZAÇÃO: Eu removi os avatares do alto -falante

Aqui está uma bela história de advertência sobre os perigos da codificação de vibração em um telefone sem acesso a ferramentas de perfil de desempenho. Um comentarista sobre o Hacker News apontou:

O aplicativo da web faz 176 solicitações e downloads 130 megabytes.

E sim, foi! Acontece que as imagens de avatar do alto -falante não foram otimizadas e havia mais de 170 delas.

Eu disse a uma instância do Codex fresca “Remova as imagens de avatar do alto-falante do Open-Sauce-2025.html” e agora a página pesa 93,58 kb.