Experimentando Starlette 1.0 com habilidades de Claude

Experimentando Starlette 1.0 com habilidades de Claude

22 de março de 2026

Starlette 1.0 foi lançada! Isso é realmente um grande negócio. Acho que Starlette pode ser a estrutura Python com mais uso em comparação com seu reconhecimento de marca relativamente baixo, porque Starlette é a base do FastAPI, que atraiu uma grande quantidade de buzz que parece ter ofuscado a própria Starlette.

Kim Christie começou a trabalhar no Starlette em 2018 e rapidamente se tornou meu favorito na nova geração de estruturas Python ASGI. A única razão pela qual não o usei como base para meu próprio projeto Datasette foi que ele ainda não prometia estabilidade, e eu estava determinado a fornecer uma API estável para os próprios plug-ins do Datasette… embora ainda não tenha sido corajoso o suficiente para lançar minha própria versão 1.0 (depois de 26 alfas e contando)!

Então, em setembro de 2025, Marcelo Trylesinski anunciou que Starlette e Uvicorn estavam transferindo para suas contas do GitHub, em reconhecimento aos seus muitos anos de contribuições e para facilitar o recebimento de patrocínio para esses projetos.

A versão 1.0 tem algumas alterações importantes em comparação com a série 0.x, descritas nas notas de versão 1.0.0rc1 lançadas em fevereiro.

A mais notável delas é uma mudança na forma como o código é executado na inicialização e no desligamento. Anteriormente isso era tratado por on_startup e on_shutdown parâmetros, mas o novo sistema usa um mecanismo de vida útil baseado em um gerenciador de contexto assíncrono:

@contextlib.asynccontextmanager
async def lifespan(app):
    async with some_async_resource():
        print("Run at startup!")
        yield
        print("Run on shutdown!")

app = Starlette(
    routes=routes,
    lifespan=lifespan
)

Se você nunca experimentou o Starlette antes, parece-me um cruzamento assíncio-nativo entre Flask e Django, não é surpreendente, já que o criador Kim Christie também é responsável pelo Django REST Framework. Crucialmente, isso significa que você pode escrever a maioria dos aplicativos como um único arquivo Python, estilo Flask.

Isso faz com que realmente é fácil para os LLMs cuspir um aplicativo Starlette funcional a partir de um único prompt.

Há apenas um problema aí: se o 1.0 quebra a compatibilidade com o código Starlette no qual os modelos foram treinados, como podemos fazer com que eles gerem um código que funcione com o 1.0?

Decidi ver se conseguia fazer isso funcionar com uma habilidade.

Desenvolvendo uma habilidade com Claude

O bate-papo regular de Claude em claude.ai possui habilidades, e uma dessas habilidades padrão é a habilidade de criador de habilidades. Isso significa que Claude sabe como desenvolver suas próprias habilidades.

Então comecei uma sessão de chat e disse:

Clone Starlette do GitHub – ele acaba de lançar sua versão 1.0. Crie um documento de redução de habilidades para esta versão que inclua exemplos de código de cada recurso.

Eu nem disse onde encontrar o repositório, Starlette é amplamente conhecido e eu esperava que pudesse encontrá-lo por conta própria.

Correu git clone https://github.com/encode/starlette.git que na verdade é o nome antigo do repositório, mas o GitHub lida com redirecionamentos automaticamente, então funcionou perfeitamente.

O documento de habilidade resultante me pareceu muito completo… e então notei um novo botão no topo que eu não tinha visto antes chamado “Copiar para suas habilidades”. Então cliquei:

E agora meu chat regular com Claude tem acesso a essa habilidade!

Um aplicativo de demonstração de gerenciamento de tarefas

Iniciei uma nova conversa e perguntei:

Crie um aplicativo de gerenciamento de tarefas com Starlette, ele deve ter projetos e tarefas e comentários e rótulos

E Claude fez exatamente isso, produzindo um clone simples do GitHub Issues usando Starlette 1.0, um banco de dados SQLite (via aiosqlite) e um modelo Jinja2.

Claude até testou o aplicativo manualmente assim:

cd /home/claude/taskflow && timeout 5 python -c "
import asyncio
from database import init_db
asyncio.run(init_db())
print('DB initialized successfully')
" 2>&1

pip install httpx --break-system-packages -q \
  && cd /home/claude/taskflow && \
  python -c "
from starlette.testclient import TestClient
from main import app

client = TestClient(app)

r = client.get('/api/stats')
print('Stats:', r.json())

r = client.get('/api/projects')
print('Projects:', len(r.json()), 'found')

r = client.get('/api/tasks')
print('Tasks:', len(r.json()), 'found')

r = client.get('/api/labels')
print('Labels:', len(r.json()), 'found')

r = client.get('/api/tasks/1')
t = r.json()
print(f'Task 1: \"{t(\"title\")}\" - {len(t(\"comments\"))} comments, {len(t(\"labels\"))} labels')

r = client.post('/api/tasks', json={'title':'Test task','project_id':1,'priority':'high','label_ids':(1,2)})
print('Created task:', r.status_code, r.json()('title'))

r = client.post('/api/comments', json={'task_id':1,'content':'Test comment'})
print('Created comment:', r.status_code)

r = client.get("https://simonwillison.net/")
print('Homepage:', r.status_code, '- length:', len(r.text))

print('\nAll tests passed!')
"

Apesar de todo o burburinho sobre Claude Code, é fácil ignorar que o próprio Claude agora conta como um agente de codificação, totalmente capaz de escrever e testar o código que está escrevendo.

Esta é a aparência do aplicativo resultante. O código está aqui no meu repositório de pesquisa.