DEV Community: Raul Andrade

Como construí um ASCII Art Converter cyberpunk usando apenas prompts

Raul Andrade — Mon, 04 May 2026 13:46:32 +0000

Nos últimos meses me afundei no universo cyberpunk. Li Neuromancer. Ainda estou no meio de Count Zero. Zerei Cyberpunk 2077. Revi Akira, Ghost in the Shell e Cyberpunk Edgerunners. Tem algo nessa estética (neon, interfaces cruas, informação como matéria-prima) que não sai da cabeça.

Foi nesse estado que me deparei com um vídeo no Instagram de uma garota mostrando uma aplicação que convertia a câmera ao vivo em arte ASCII em tempo real, com análise de IA integrada. Fui no link. Estava offline.

Dois pensamentos na hora: eu consigo construir isso e vou deixar qualquer pessoa usar com a própria key de IA. E um terceiro: vou construir sem escrever uma linha de código manualmente.

Por que essa regra

Eu já usava Cursor faz um tempo, inclusive no modo agente. Mas por ser uma IDE, ficava tentado a meter a mão no código direto. Quando assinei o Claude Code, quis testar o que acontece quando você remove essa tentação completamente e força a delegação de verdade.

A regra foi simples: tudo via prompt. Sem abrir arquivos pra editar. As únicas exceções foram mudanças de uma linha, 'upload' virou 'upload' as const, um ajuste de cor no CSS.

O código pode ser gerado, a direção não

Antes de qualquer prompt, a feature precisa estar estruturada na cabeça. Quais são as entradas, quais são as saídas, o que muda no estado, o que não muda. No fim, isso é muito próximo do que bons desenvolvedores já fazem antes de começar a escrever código. A diferença é que, quando você deixa de implementar diretamente, a clareza do pensamento vira o principal mecanismo de controle durante o processo.

O mesmo vale pra contexto. Ter decisões arquiteturais documentadas e um glossário claro do domínio ajuda muito durante o processo. Sem isso, fica bem mais difícil manter consistência conforme o projeto cresce. O Claude não lembra o raciocínio da semana passada. Eu mantive um CONTEXT.md com os termos do domínio e um docs/adr/ com as decisões importantes: por que o canvas oculto existe separado do canvas visível, por que o loop de webcam roda na main thread. Sem isso, cada prompt novo começa do zero.

Skills funcionam como atalhos de contexto. Em vez de descrever o que você quer numa revisão de segurança toda vez, você invoca /security-review e o agente já sabe o que checar. Eu usei as skills do Matt Pocock como base e adaptei algumas pro meu fluxo.

Quebrar o problema em partes menores continuou sendo uma das coisas mais importantes durante o projeto. Quanto menor e mais bem definido era o escopo de cada etapa, menos a IA se perdia, mais previsível o resultado ficava e mais fácil era iterar em cima do que tinha sido gerado.

A faca de dois gumes

A velocidade de geração de código é real. E é exatamente onde o negócio pode dar errado.

Em um ponto do projeto, o Claude tinha construído o componente de upload com useState espalhado por todo lado, com dependências claras entre eles. Olhei pra aquilo e o padrão estava errado: precisava de useReducer. Não abri o arquivo. Mandei um prompt pedindo pra extrair a lógica pra um hook com useReducer. Ficou limpo.

Em outro momento, o Claude entrou num loop tentando resolver um problema de testes. Cada tentativa criava um problema novo. Parei, reverti tudo, e reescrevi o prompt do zero com o contexto de como os testes são estruturados nessa aplicação. Resolveu na primeira tentativa.

A velocidade não substitui o julgamento. E isso ficou claro pra mim nesses dois momentos. O modelo escreve rápido e errado da mesma forma que escreve rápido e certo, e sem o julgamento de quem conhece o domínio, você só acumula dívida técnica mais rápido do que antes.

O resultado

O ASCII Art Converter tem webcam ao vivo, análise de IA com Anthropic, OpenAI ou Gemini, export em PNG e TXT, e um design system cyberpunk que ficou exatamente do jeito que eu queria e foi estranhamente satisfatório ver tudo montado sem ter aberto um arquivo pra editar. Zero features escritas com as mãos.

Se você já tem o hábito de pensar antes de codar, documentar decisões e quebrar trabalho em partes pequenas, você tem o pré-requisito pra tentar isso. Não precisa de um projeto grande, um side project já é suficiente pra entender onde essa abordagem funciona e onde ela ainda patina.

Se ficou curioso sobre como organizei o projeto, alguma decisão específica ou quer ver como os prompts ficaram, deixa um comentário.

Referências

Repo
Demo
Claude Code
Skills for Real Engineers — Matt Pocock
Vídeo que inspirou o projeto

Como automatizar o processo de versionamento de um projeto em Javascript

Raul Andrade — Sat, 11 Jun 2022 16:00:39 +0000

Introdução

Como desenvolvedores, amamos automatizar tarefas rotineiras. Nesta publicação demonstrarei a automação do fluxo de release utilizando a biblioteca semantic-release. Esta library permite automatizar todo o oprocesso de geração de release; Determinando o número da próxima versão, criando a nova tag, gerando as novas release notes e a publicação do pacote no NPM, caso seja necessário.

Para tudo isso funcionar, a biblioteca faz uso das mensagens de commits para determinar o número da próxima versão, o Changelog e a publicação. Por padrão o semantic-release utiliza a especificação de mensagens de commits do Angular o Conventional Commits e a convenção semver para o número de versão.

Resumindo o SemVer nos diz como devem ser os números de nossas versões, como por exemplo: MAJOR.MINOR.PATCH. Já o Conventional Commits nos diz como devem ser nossos commits, para que o de/para do commit pro SemVer seja feito de forma automática.

Abaixo mostrarei uma imagem desse de/para:

No CI o semantic-release deve ser executado após o build ser feito com sucesso no branch de release, por exemplo.

Como funciona

O semantic-release verifica os commits de um branch entre a última tag gerada até o último commit deste branch, para então acionar a geração de uma nova tag. Em seguida ele cria ou atualiza o arquivo de Changelog com base nos commits entre as duas tags.

Ná prática fica da seguinte forma, como é mostrado na imagem a seguir:

Observe que no final imagem temos uma tag 1.17.1 e após realizarmos um commit novo no branch de release, o semantic-release é acionado e cria uma nova tag com a numeração 1.17.2. Em seguida, realizamos dois commits um de docs e outro de fix, quando esses commits vão para o branch de release é acionado novamente e temos uma nova tag 1.17.3. Depois disso, temos mais um commit de feat no branch de release e nossa nova tag é 1.18.0.

E nosso arquivo de Changelog fica da seguinte maneira:

É importante notar que cada tag foi associada a uma release, a tag 1.17.1 tem uma release associada e nas notas de release temos os commits que foram feitos naquela tag.

Observe que existe um commit de docs e ele não foi adicionado nos Changelogs, porém há formas de configurar para que ele apareça.

Por último, mas não menos importante é possível executar o semantic-release sem acionar a geração de uma nova release, basta executar ele como dry-run. Isso é uma salvação quando estamos no processo de configuração ou queremos ver o Changelog daquela versão.

Configuração

Nessa seção descreverei passo a passo de como configurar o semantic-release em um projeto. Uma observação é possível que as versões dos pacotes estejam diferentes, ou seja, mais atualizados após a publicação desse blog post.

Criar um repositório git e adiciona-lo ao remoto no Github ou usar um repositório já existente;

git init

Realizar as configurações necessárias do semantic-release. Note que, se for um projeto novo necessita de yarn init;

yarn init

Agora precisamos adicionar o pacote do semantic-release nas dev dependencies;

yarn add semantic-release -D

Em seguida precisamos adicionar os plugins do semantic-release;

yarn add @commitlint/cli @commitlint/config-conventional @semantic-release/changelog @semantic-release/git -D

Cada plugin tem um propósito especifico:
- @commitlint/cli: É um analisador de mensagem de commit para verificar se a mensagem do commit está segundo o padrão;
- @commitlint/config-conventional: É o configurador de um padrão a ser seguido nas mensagens de commit, como por exemplo o padrão do Angular;
- @semantic-release/changelog: Plugin que atualiza ou cria o arquivo de Changelog;
- @semantic-release/git: Plugin que realiza os commits de release e artefatos gerados;
Adicionar o pacote Husky (opcional):
- Esse passo é interessante pois com o husky evitamos de subir commits fora do padrão;
Criar um arquivo .releaserc.json exemplo disponível na doc:
- O arquivo .releaserc.json ficou da seguinte maneira;

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/github",
    "@semantic-release/changelog",
    [
      "@semantic-release/npm",
      {
        "npmPublish": false
      }
    ],
    {
      "path": "@semantic-release/git",
      "assets": ["package.json", "package-lock.json", "CHANGELOG.md"],
      "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
    }
  ],
  "branches": [
    "main"
  ]
}

Criar uma workflow para ser executado no Github action:
- Criar um .env com a seguinte key GITHUB_TOKEN e o seu access token do Github;
- Criar um diretório Github workflows com um arquivo dentro: .github/workflows/release.yml;
- Temos o arquivo .github/workflows/release.yml dessa forma;

name: Release
on:
  push:
    branches:
      - main

jobs:
  release:
    name: Release

    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 'lts/*'

      - name: Install dependencies
        run: yarn install

      - name: Release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: yarn release

Adicionar o comando do semantic-release nos scripts do package.json:
- Por último o package.json está assim;

{
  "name": "poc-release",
  "version": "0.1.0",
  "main": "index.js",
  "repository": {
    "type": "git",
    "url": "git@github.com:andraderaul/poc-release.git"
  },
  "author": "Raul Andrade",
  "license": "MIT",
  "scripts": {
    "test": "jest",
    "release": "semantic-release",
    "release:dry": "semantic-release --dry-run",
  },
  "devDependencies": {
    "@commitlint/cli": "^16.2.3",
    "@commitlint/config-conventional": "^16.2.1",
    "@semantic-release/changelog": "^6.0.1",
    "@semantic-release/git": "^10.0.1",
    "husky": "^7.0.4",
    "jest": "^27.5.1",
    "semantic-release": "^19.0.2"
  }
}

Repositórios

Para ver o código de configuração na íntegra, acesse o repositório no github.
As imagens utilizadas nos exemplos são de outro repositório.

Referências

semantic-release
Semantic Versioning 2.0.0
Conventional Commits

Como criei um Web App utilizando dados do Spotify

Raul Andrade — Wed, 13 Apr 2022 01:59:08 +0000

Idealização

Há um tempo eu estava pensando como seria criar um Web App utilizando os dados do Spotify, após refletir por alguns dias cheguei na ideia de uma aplicação. Por gostar de sempre escutar música enquanto realizo tarefas, pensei em uma aplicação que me ajudasse a conhecer novas musicas, obviamente dentro do Spotify já existem diversas maneiras de conhecer novas musicas, mas eu queria conhecer do meu próprio jeito.

Portanto, criei o Randomfy, uma aplicação que me permite ouvir a prévia de uma música e decidir se gosto ou não dela por meio de likes e dislikes, muito similar ao Tinder. Quando o usuário logado no Randomfy decide que gosta da musica e aperta o botão de like, e o Randomfy recomenda uma nova musica com base na musica curtida.

Processo burocrático

Legal, mas e o processo para criar a aplicação? O processo para a criação de um App no Spotify é bastante simples, você precisa ter uma conta no Spotify, acessar o Spotify para desenvolvedores com essa mesma conta e preencher um formulário. Após isso você consegue criar quantos Apps desejar clicando em um botão “create an app”.

Quando você clica no botão é necessário colocar o nome e descrição da aplicação, após isso você consegue ter acesso a sua Dashboard. Com o App criado é possível observar que ele ainda está em modo desenvolvedor e somente 25 pessoas que você deve cadastrar no App podem fazer uso dele, e para aumentar o limite de usuários é necessário submeter extensão de quota. Essa extensão o Spotify pode ou não recusar, pois é necessário informar o motivo da criação do App e como você vai utilizar os dados do Spotify. Minha recomendação é solicitar a extensão somente quando você tiver uma primeira versão pronta, pois no momento da solicitação é necessário enviar printscreen da aplicação e um link para acessa-la.

Um ponto importante a levar em consideração ao solicitar uma extensão de quota, é se atentar aos termos de serviço do desenvolvedor e diretrizes de branding, pois quando usamos conteúdo de terceiros precisamos seguir as normas deles. No caso do Randomfy, eu arredondei algumas imagens, e no processo de desenvolvimento acabei esquecendo que havia feito isso, então quando solicitei para o Spotify deixar meu App público eles o rejeitaram algumas vezes, até eu observar que este era o problema. Nos emails enviados pelo Spotify eles eram bem específicos, me informando que não estava seguindo as diretrizes de branding, mas na minha cabeça eu estava, e até descobrir isso foram dois dias.

Ainda sobre a solicitação de extensão de quota, o tempo médio que levava de uma solicitação e a sua resposta é menos de um dia, geralmente eu solicitava a noite e logo pela manha recebia um e-mail me informando se eles haviam ou não aceitado.

Considerações

Com o App criado você pode acessar a documentação e entender como os endpoints funcionam e criar algo incrível. Possui uma parte na documentação do Spotify, onde eles mostram apps maravilhosos criados pela comunidade.

Por fim, eu particularmente gostei bastante da documentação da API do Spotify, é muito boa e com bastante exemplos de como utilizar. Se você ficou curioso sobre como foi feita a parte técnica do Randomfy deixe um comentário para que eu possa saber se devo escrever sobre.

Referências

Api Spotify
Readme do Randomfy
Créditos da imagem de capa