{"id":1261,"date":"2026-09-22T04:01:34","date_gmt":"2026-09-22T07:01:34","guid":{"rendered":"https:\/\/adrianosantostreina.com.br\/blog\/type-hints-testes-propriedade-agentes-contrato-python-ia\/"},"modified":"2026-09-22T04:01:44","modified_gmt":"2026-09-22T07:01:44","slug":"type-hints-testes-propriedade-agentes-contrato-python-ia","status":"publish","type":"post","link":"https:\/\/adrianosantostreina.com.br\/blog\/type-hints-testes-propriedade-agentes-contrato-python-ia\/","title":{"rendered":"Type Hints, Testes de Propriedade e Agentes: O Novo Contrato entre Voc\u00ea e o Python que a IA Escreve"},"content":{"rendered":"

Voc\u00ea pede para o agente implementar uma fun\u00e7\u00e3o de parsing de datas em formato livre. Ele entrega algo que passa nos tr\u00eas exemplos que voc\u00ea deu no prompt, com docstring bonita, type hints aparentemente corretos e at\u00e9 um bloco de testes unit\u00e1rios que passam de primeira. Duas semanas depois, em produ\u00e7\u00e3o, a fun\u00e7\u00e3o recebe uma string com fuso hor\u00e1rio impl\u00edcito e retorna um datetime<\/code> naive silenciosamente deslocado em tr\u00eas horas. Ningu\u00e9m percebeu porque o mypy n\u00e3o reclamou \u2014 afinal, datetime<\/code> naive e aware t\u00eam a mesma assinatura de tipo em Python, e o agente nunca soube que essa distin\u00e7\u00e3o importava para o seu dom\u00ednio.<\/p>\n

Esse \u00e9 o tipo de falha que n\u00e3o aparece em nenhum benchmark de “IA gerando c\u00f3digo Python”. \u00c9 sutil, contextual e nasce exatamente do ponto cego que a linguagem sempre teve: tipagem gradual, duck typing e uma cultura de “funciona at\u00e9 n\u00e3o funcionar”. Python foi, durante anos, a linguagem da produtividade r\u00e1pida \u2014 e agora, segundo a an\u00e1lise da HubSpot sobre o papel do Python em 2026<\/a>, tornou-se tamb\u00e9m a linguagem padr\u00e3o para os pr\u00f3prios sistemas de IA que escrevem c\u00f3digo. Isso cria um ciclo curioso: a linguagem mais permissiva do mercado \u00e9 a que mais se beneficia \u2014 e mais sofre \u2014 quando um agente aut\u00f4nomo assume parte da autoria.<\/p>\n

Neste artigo, voc\u00ea vai ver como reestruturar seu fluxo de trabalho Python para que a IA deixe de ser uma fonte de c\u00f3digo plaus\u00edvel e passe a produzir c\u00f3digo verific\u00e1vel. Isso passa por tr\u00eas decis\u00f5es de arquitetura: tipagem estrita como contrato execut\u00e1vel, testes de propriedade como rede de seguran\u00e7a sem\u00e2ntica, e um protocolo de revis\u00e3o que trata o agente como um colaborador j\u00fanior com acesso root \u2014 nunca como um or\u00e1culo.<\/p>\n

O problema estrutural: Python nunca teve um compilador que discordasse de voc\u00ea<\/h2>\n

Em linguagens com verifica\u00e7\u00e3o est\u00e1tica forte, o compilador \u00e9 o primeiro revisor de c\u00f3digo do agente. Um LLM que gera Rust ou TypeScript com tipos estritos recebe feedback imediato e mec\u00e2nico: “isso n\u00e3o compila”. Em Python, esse mecanismo simplesmente n\u00e3o existe por padr\u00e3o. O interpretador aceita quase tudo, e o erro s\u00f3 aparece em runtime \u2014 muitas vezes em um caminho de c\u00f3digo que seu conjunto de testes nunca exercitou.<\/p>\n

Isso significa que, ao delegar a um agente, voc\u00ea est\u00e1 removendo a \u00fanica barreira autom\u00e1tica de corre\u00e7\u00e3o que a linguagem oferece nativamente, a menos que voc\u00ea a construa deliberadamente. \u00c9 exatamente o que discuss\u00f5es recorrentes na comunidade apontam: desenvolvedores relatam usar IA menos para “escrever c\u00f3digo do zero” e mais para explicar, revisar e preencher lacunas em um fluxo que ainda depende fortemente de julgamento humano, como aparece em uma discuss\u00e3o no r\/learnpython sobre o papel da IA no aprendizado e uso pr\u00e1tico de Python<\/a>. O padr\u00e3o que emerge n\u00e3o \u00e9 “a IA substitui o desenvolvedor”, mas “a IA amplia a superf\u00edcie de decis\u00f5es que precisam de verifica\u00e7\u00e3o”.<\/p>\n

Por que isso n\u00e3o \u00e9 um problema de “prompt melhor”<\/h3>\n

Existe uma tenta\u00e7\u00e3o de resolver isso com instru\u00e7\u00f5es mais detalhadas: “gere com type hints completos, use Optional<\/code> corretamente, trate timezone explicitamente”. Isso ajuda, mas n\u00e3o resolve o problema de fundo, porque a instru\u00e7\u00e3o em linguagem natural n\u00e3o \u00e9 verific\u00e1vel mecanicamente. Voc\u00ea est\u00e1 pedindo ao modelo para lembrar de uma regra; o que voc\u00ea precisa \u00e9 de um sistema que rejeite o c\u00f3digo quando a regra for violada, independentemente de o modelo ter “lembrado” ou n\u00e3o.<\/p>\n

\u00c9 a diferen\u00e7a entre pedir para algu\u00e9m dirigir com cuidado e instalar um cinto de seguran\u00e7a que trava sozinho. A primeira abordagem depende de disciplina; a segunda, de engenharia.<\/p>\n

Camada 1: tipagem estrita como contrato execut\u00e1vel<\/h2>\n

O primeiro ajuste estrutural \u00e9 parar de tratar type hints como documenta\u00e7\u00e3o opcional e come\u00e7ar a trat\u00e1-los como especifica\u00e7\u00e3o verificada por m\u00e1quina. Isso significa rodar Python<\/a> com mypy --strict<\/code> ou equivalente (pyright<\/code> em modo estrito) como parte do pr\u00f3prio ciclo de gera\u00e7\u00e3o \u2014 n\u00e3o como uma etapa de CI que roda depois que o c\u00f3digo j\u00e1 foi “aceito” mentalmente por voc\u00ea.<\/p>\n

# pyproject.toml\n[tool.mypy]\npython_version = \"3.12\"\nstrict = true\ndisallow_untyped_defs = true\ndisallow_any_generics = true\nwarn_return_any = true\nno_implicit_optional = true\n<\/code><\/pre>\n
O ponto pr\u00e1tico aqui \u00e9 que, quando voc\u00ea configura o ambiente com esse n\u00edvel de rigor antes<\/em> de pedir ao agente para gerar c\u00f3digo, o pr\u00f3prio agente \u2014 se estiver operando dentro de um harness que executa o linter e devolve o erro como feedback \u2014 corrige a si mesmo. Isso muda completamente a din\u00e2mica: em vez de voc\u00ea revisar visualmente se o tipo est\u00e1 certo, o mypy vira um interlocutor autom\u00e1tico que rejeita ambiguidade.<\/p>\n
Veja o caso do parsing de datas. Sem tipagem estrita, isto passa despercebido:<\/p>\n
from datetime import datetime\n\ndef parse_event_time(raw: str) -> datetime:\n    return datetime.fromisoformat(raw)\n<\/code><\/pre>\n
Com um contrato de tipos que distingue explicitamente aware de naive \u2014 usando um alias de tipo ou um NewType<\/code> \u2014 o problema vira vis\u00edvel na assinatura, n\u00e3o apenas em produ\u00e7\u00e3o:<\/p>\n
from datetime import datetime, timezone\nfrom typing import NewType\n\nAwareDatetime = NewType(\"AwareDatetime\", datetime)\n\ndef parse_event_time(raw: str) -> AwareDatetime:\n    dt = datetime.fromisoformat(raw)\n    if dt.tzinfo is None:\n        raise ValueError(f\"timestamp sem timezone expl\u00edcito: {raw!r}\")\n    return AwareDatetime(dt)\n<\/code><\/pre>\n
A diferen\u00e7a n\u00e3o \u00e9 sint\u00e1tica, \u00e9 sem\u00e2ntica: voc\u00ea transformou uma invariante de dom\u00ednio (“todo hor\u00e1rio de evento precisa ter timezone”) em algo que o type checker consegue propagar por toda a base de c\u00f3digo. Qualquer fun\u00e7\u00e3o que receber um datetime<\/code> comum onde se espera AwareDatetime<\/code> quebra a an\u00e1lise est\u00e1tica \u2014 e, se o agente estiver integrado a um harness que roda o mypy antes de considerar a tarefa conclu\u00edda, ele nunca chega a te entregar o bug.<\/p>\n
\ud83d\udca1 Dica do Mestre:<\/strong> pense em type hints estritos n\u00e3o como “documenta\u00e7\u00e3o para humanos”, mas como testes que rodam antes mesmo de o c\u00f3digo ser executado. Quanto mais preciso o tipo \u2014 NewType<\/code>, Literal<\/code>, TypedDict<\/code> com campos obrigat\u00f3rios \u2014 menor o espa\u00e7o de ambiguidade que o agente tem para preencher com uma suposi\u00e7\u00e3o errada.<\/p><\/blockquote>\n
Camada 2: testes de propriedade contra o vi\u00e9s de exemplo \u00fanico<\/h2>\n
Modelos de linguagem t\u00eam um vi\u00e9s estrutural: eles otimizam para satisfazer os exemplos que voc\u00ea forneceu, n\u00e3o para satisfazer a especifica\u00e7\u00e3o impl\u00edcita por tr\u00e1s deles. Isso \u00e9 conhecido como overfitting ao exemplo, e em Python ele se manifesta de forma particularmente trai\u00e7oeira porque a linguagem n\u00e3o for\u00e7a voc\u00ea a declarar pr\u00e9-condi\u00e7\u00f5es e p\u00f3s-condi\u00e7\u00f5es \u2014 voc\u00ea precisa escolher test\u00e1-las.<\/p>\n
Testes unit\u00e1rios tradicionais, do tipo “dado esse input, espero essa sa\u00edda”, s\u00e3o vulner\u00e1veis a esse vi\u00e9s porque o agente muitas vezes gera o teste e a implementa\u00e7\u00e3o na mesma passada, inconscientemente calibrando um para o outro. A sa\u00edda \u00e9 testes de propriedade, onde voc\u00ea especifica invariantes gerais e deixa uma biblioteca gerar centenas de casos, incluindo os extremos que nem voc\u00ea nem o agente pensariam em escrever manualmente.<\/p>\n
from hypothesis import given, strategies as st\nfrom decimal import Decimal\nfrom myapp.pricing import apply_discount\n\n@given(\n    price=st.decimals(min_value=\"0.01\", max_value=\"100000\", places=2),\n    discount_pct=st.integers(min_value=0, max_value=100),\n)\ndef test_discounted_price_never_negative_or_above_original(price, discount_pct):\n    result = apply_discount(price, discount_pct)\n    assert result >= Decimal(\"0\")\n    assert result <= price\n<\/code><\/pre>\n
Esse teste n\u00e3o descreve um caso, descreve uma lei que qualquer implementa\u00e7\u00e3o correta precisa obedecer. Se o agente reescrever apply_discount<\/code> usando float<\/code> em vez de Decimal<\/code> por conveni\u00eancia \u2014 um erro cl\u00e1ssico de LLM em c\u00f3digo financeiro, porque float<\/code> “parece” funcionar nos exemplos simples \u2014 o Hypothesis<\/a> encontra o caso de borda em segundos, tipicamente um valor com d\u00edzima que exp\u00f5e erro de arredondamento bin\u00e1rio.<\/p>\n
Onde testes de propriedade n\u00e3o substituem julgamento humano<\/h3>\n
\u00c9 importante ser honesto sobre o limite dessa t\u00e9cnica: testes de propriedade verificam invariantes que voc\u00ea j\u00e1 soube articular. Eles n\u00e3o descobrem sozinhos que “desconto n\u00e3o pode ultrapassar pre\u00e7o original” \u00e9 uma regra de neg\u00f3cio relevante \u2014 isso ainda vem da sua modelagem de dom\u00ednio. O que eles fazem \u00e9 garantir que, uma vez articulada a regra, nenhuma implementa\u00e7\u00e3o gerada por IA (ou por humano, ali\u00e1s) escape dela silenciosamente. A propriedade emergente da automa\u00e7\u00e3o de agentes \u00e9 justamente essa: segundo reportagem do TI Inside sobre estudos de refatora\u00e7\u00e3o aut\u00f4noma por agentes<\/a>, agentes alteram estrutura de c\u00f3digo de forma intencional \u2014 o que refor\u00e7a que a verifica\u00e7\u00e3o precisa ser estrutural tamb\u00e9m, n\u00e3o apenas pontual.<\/p>\n
Camada 3: o agente como colaborador com acesso root, n\u00e3o como or\u00e1culo<\/h2>\n
A conversa sobre IA substituir programadores costuma ser mal colocada. V\u00eddeos como “The FAILURE of AI to replace programmers”<\/a> capturam bem um ponto que se confirma na pr\u00e1tica di\u00e1ria: o gargalo n\u00e3o \u00e9 gerar c\u00f3digo, \u00e9 decidir se o c\u00f3digo gerado \u00e9 correto no contexto certo. Em Python, onde o custo de detectar erro em runtime \u00e9 mais alto do que em linguagens com verifica\u00e7\u00e3o est\u00e1tica robusta, esse gargalo d\u00f3i mais r\u00e1pido.<\/p>\n
O modelo mental produtivo \u00e9 tratar o agente como um desenvolvedor j\u00fanior extremamente r\u00e1pido, com acesso de escrita ao reposit\u00f3rio, mas sem contexto t\u00e1cito sobre por que certas decis\u00f5es de arquitetura foram tomadas. Isso muda a pergunta de “o c\u00f3digo est\u00e1 certo?” para “o processo que produziu esse c\u00f3digo tem os checkpoints certos?”.<\/p>\n
# exemplo de harness m\u00ednimo em CI para gates autom\u00e1ticos\n# .github\/workflows\/ai-generated-check.yml\nname: verify-ai-code\non: [pull_request]\njobs:\n  verify:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v4\n      - run: pip install mypy hypothesis pytest ruff\n      - run: mypy --strict src\/\n      - run: ruff check src\/\n      - run: pytest --hypothesis-seed=random -q\n<\/code><\/pre>\n
Um detalhe que costuma passar despercebido: --hypothesis-seed=random<\/code> for\u00e7a reexecu\u00e7\u00e3o com sementes diferentes a cada build, em vez de fixar sempre a mesma sequ\u00eancia de casos gerados. Isso evita que o pipeline crie uma falsa sensa\u00e7\u00e3o de estabilidade \u2014 o c\u00f3digo passou hoje porque a semente de ontem n\u00e3o cobriu o caso ruim, n\u00e3o porque o caso ruim deixou de existir.<\/p>\n
O custo real dessa abordagem, sem ret\u00f3rica de venda<\/h3>\n
\u00c9 preciso ser transparente sobre o trade-off: configurar mypy estrito, escrever propriedades de Hypothesis e manter gates de CI tem custo de setup e de manuten\u00e7\u00e3o cont\u00ednua. Em prot\u00f3tipos descart\u00e1veis, esse investimento n\u00e3o se paga. A decis\u00e3o de arquitetura correta \u00e9 escalonar o rigor conforme o raio de explos\u00e3o do c\u00f3digo: um script de an\u00e1lise ad-hoc n\u00e3o precisa do mesmo tratamento que um m\u00f3dulo de precifica\u00e7\u00e3o que roda em produ\u00e7\u00e3o. O erro comum \u00e9 aplicar rigor m\u00e1ximo em tudo \u2014 o que gera atrito e leva equipes a abandonar a pr\u00e1tica \u2014 ou rigor m\u00ednimo em tudo, o que \u00e9 exatamente o cen\u00e1rio que abre espa\u00e7o para o bug de timezone silencioso do in\u00edcio deste artigo.<\/p>\n
Vale notar tamb\u00e9m que nenhuma dessas camadas resolve o problema de julgamento sobre requisitos amb\u00edguos. Se a especifica\u00e7\u00e3o de neg\u00f3cio est\u00e1 errada ou incompleta, o agente vai implementar fielmente a ambiguidade \u2014 com tipos corretos e testes de propriedade passando. Tipagem e testes de propriedade blindam contra erro de implementa\u00e7\u00e3o, n\u00e3o contra erro de entendimento do problema. Essa distin\u00e7\u00e3o evita a armadilha de achar que “colocar mais ferramentas de verifica\u00e7\u00e3o” substitui a conversa de esclarecimento com quem pediu a funcionalidade.<\/p>\n
\ud83d\udca1 Dica do Mestre:<\/strong> uma pergunta recorrente em debates p\u00fablicos \u00e9 se ainda vale a pena aprender profundamente uma linguagem como Python num mundo de agentes aut\u00f4nomos. O contraponto pr\u00e1tico aparece em um v\u00eddeo sobre programar sem IA em 2026<\/a>: quem entende profundamente a linguagem \u00e9 justamente quem consegue montar esses gates de verifica\u00e7\u00e3o \u2014 o conhecimento de linguagem n\u00e3o virou obsoleto, virou infraestrutura de confian\u00e7a.<\/p><\/blockquote>\n
Integrando as tr\u00eas camadas num fluxo real<\/h2>\n
Na pr\u00e1tica, o fluxo que funciona bem em equipes que trabalham com agentes de IA integrados ao editor ou ao terminal segue uma sequ\u00eancia espec\u00edfica: primeiro, a especifica\u00e7\u00e3o de tipos e invariantes \u00e9 escrita \u2014 por voc\u00ea ou em conjunto com o agente, mas revisada por voc\u00ea \u2014 antes de qualquer implementa\u00e7\u00e3o. Depois, o agente gera a implementa\u00e7\u00e3o tendo esses tipos e testes de propriedade como alvo fixo, n\u00e3o como algo a ser inventado junto. Por fim, o harness de CI roda de forma determin\u00edstica e bloqueia merge se qualquer camada falhar.<\/p>\n
# exemplo de estrutura de projeto que for\u00e7a esse fluxo\nsrc\/\n  domain\/\n    types.py       # NewType, TypedDict, Literal \u2014 contrato imut\u00e1vel\n  services\/\n    pricing.py     # implementa\u00e7\u00e3o, gerada ou revisada com IA\ntests\/\n  properties\/\n    test_pricing_properties.py   # Hypothesis, escrito antes da implementa\u00e7\u00e3o\n  unit\/\n    test_pricing_examples.py     # casos concretos de regress\u00e3o\n<\/code><\/pre>\n
Essa ordem \u2014 tipos e propriedades antes da implementa\u00e7\u00e3o \u2014 \u00e9 o que separa “IA acelerando entrega” de “IA acelerando retrabalho”. Quando o agente recebe o contrato pronto, ele para de precisar adivinhar a inten\u00e7\u00e3o e passa a ter um alvo mensur\u00e1vel para convergir. \u00c9 a mesma l\u00f3gica por tr\u00e1s de pr\u00e1ticas de especifica\u00e7\u00e3o formal antes da gera\u00e7\u00e3o de c\u00f3digo, s\u00f3 que aplicada no n\u00edvel mais barato poss\u00edvel: tipos e propriedades, n\u00e3o um documento de design de trinta p\u00e1ginas.<\/p>\n
Aprofunde essa discuss\u00e3o na Comunidade Dev’s AI<\/h2>\n
Esses tr\u00eas ajustes \u2014 tipagem estrita como contrato, testes de propriedade como rede sem\u00e2ntica e harness de CI como gate autom\u00e1tico \u2014 n\u00e3o s\u00e3o regras fixas, s\u00e3o heur\u00edsticas que precisam ser calibradas ao seu dom\u00ednio, ao seu time e ao raio de explos\u00e3o de cada m\u00f3dulo. Se voc\u00ea quer trocar experi\u00eancias reais sobre como outros times s\u00eaniores est\u00e3o configurando esses gates, quais bibliotecas de tipagem avan\u00e7ada valem o investimento e como lidar com os casos em que o agente insiste em contornar a verifica\u00e7\u00e3o em vez de corrigir a causa raiz, entre para a Comunidade Dev’s AI<\/a>. \u00c9 um espa\u00e7o de discuss\u00e3o t\u00e9cnica entre profissionais que est\u00e3o de fato colocando esses fluxos em produ\u00e7\u00e3o, n\u00e3o apenas testando em projetos de brinquedo.<\/p>\n
Conclus\u00e3o<\/h2>\n
A mudan\u00e7a real que a IA trouxe para o desenvolvimento em Python n\u00e3o \u00e9 a velocidade de digita\u00e7\u00e3o \u2014 isso \u00e9 o efeito mais superficial e o mais f\u00e1cil de medir errado. A mudan\u00e7a estrutural \u00e9 que a aus\u00eancia hist\u00f3rica de verifica\u00e7\u00e3o est\u00e1tica forte, que sempre foi toler\u00e1vel quando o c\u00f3digo era escrito e revisado linha a linha por um humano com contexto t\u00e1cito, deixou de ser toler\u00e1vel quando parte da autoria passa a um agente que n\u00e3o compartilha esse contexto. O trabalho s\u00e9rio, ent\u00e3o, n\u00e3o \u00e9 escrever prompts mais espertos \u2014 \u00e9 reconstruir, deliberadamente, os mecanismos de verifica\u00e7\u00e3o que a linguagem nunca ofereceu de gra\u00e7a: tipos que funcionam como contrato, propriedades que capturam invariantes de dom\u00ednio, e um pipeline que trata qualquer c\u00f3digo, humano ou gerado, com o mesmo n\u00edvel de ceticismo estrutural. Quem monta essa infraestrutura antes de escalar o uso de agentes colhe produtividade real; quem pula essa etapa est\u00e1 apenas trocando bugs de digita\u00e7\u00e3o por bugs de suposi\u00e7\u00e3o \u2014 mais raros, por\u00e9m mais caros de encontrar.<\/p>\n","protected":false},"excerpt":{"rendered":"
Voc\u00ea pede para o agente implementar uma fun\u00e7\u00e3o de parsing de datas em formato livre. Ele entrega algo que passa nos tr\u00eas exemplos que voc\u00ea deu no prompt, com docstring bonita, type hints aparentemente corretos e at\u00e9 um bloco de testes unit\u00e1rios que passam de primeira. Duas semanas depois, em produ\u00e7\u00e3o, a fun\u00e7\u00e3o recebe uma […]<\/p>\n","protected":false},"author":127,"featured_media":1262,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1261","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts\/1261","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/users\/127"}],"replies":[{"embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1261"}],"version-history":[{"count":1,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts\/1261\/revisions"}],"predecessor-version":[{"id":1263,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts\/1261\/revisions\/1263"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/media\/1262"}],"wp:attachment":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1261"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1261"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1261"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}