Já havia algum tempo que essa ideia estava na gaveta: tirar as coisas da cabeça e registrá-las. Principalmente para geração de conteúdo, pela forma como vejo as coisas e vou aprendendo.

Essa é a história de como criei meu blog com 50 commits em menos de 4h.

Motivação

Depois de ver a live do Mano Deyvin com Lucas Montano e Akita, coloquei um pouco mais de fé em AI e queria deixar ela escrever todo o código. O fato de o Akita ter criado 7 projetos pessoais relevantes em dois meses e meio começou a me empolgar com a utilização dos modelos de AI mais recentes (Claude Opus 4.6 e GPT Codex 5.3). Essa empolgação foi o que me conduziu a criar esse blog, assim como o meu editor de Markdown, sobre o qual falarei em outro post.

Fundação

Na live, o Akita disse que uma das coisas mais relevantes ao trabalhar com o Claude Opus 4.6 foi criar a definição do projeto, ou seja:

• Para que serve o projeto?
• O que ele resolve?
• Quais são as funcionalidades?

E a outra coisa mais importante era:

• Quais ferramentas ou tecnologias vou usar?

Pensar nisso é pensar em Engenharia de Software. É se questionar: “Por que usar a ferramenta X e não a Y para fazer isso?”.

Isso me levou a criar um documento com as definições do que seria esse blog post. Usei o ChatGPT para facilitar o esquema (😄) e cheguei em algo razoável como:

Funcionalidades:

• Blog com sistema de posts em Markdown
• Suporte para idiomas em Inglês e Português do Brasil
• Busca indexada de cada post usando tags e título
• Sitemap para SEO
• Tema Light e Dark

Tecnologias:

• Astro -> para lidar com o conteúdo
• React -> biblioteca para componentes
• TypeScript -> para facilitar o trabalho com IA
• Shadcn -> para padronizar os componentes e já usar alguns recursos
• Vitest -> para escrever os testes

Caso queira consultar o chat, segue o link.

Tudo que um blog precisaria ter de forma simples, com escopo bem fechado e usando as mesmas tecnologias com TypeScript/JavaScript.
Também pedi para gerar essa documentação de forma fraseada, pensando em entregas e em como eu direcionaria isso para um júnior. Para isso, precisaria de descrições e regras de negócio bem definidas, assim como as tecnologias.

Nada contra júnior, porém o fato de falar dessa forma faz com que as definições fiquem mais claras, inclusive na descrição da tarefa, um ponto bem importante para uma IA entender.

Copilot com Opus 4.6

Com o documento gerado em mãos, criei um novo projeto para o GitHub Pages e, no final do formulário, há uma opção “Dê um impulso ao seu projeto com o Copilot”.

Esse post está sendo escrito depois de já ter criado o blog, por isso o print de um novo repositório 😉

E preenchi com o primeiro épico da tarefa que gerei com o ChatGPT.

Fundação com Astro + shadcn

Como já tinha usado o Opus 4.6 para fazer o editor de texto Markdown, ele já passa a usar esse modelo por padrão.

Você pode consultar e acompanhar o resultado do seu prompt na aba Agents do seu projeto. Também pode consultar o uso do Copilot em Avatar -> Copilot Settings.

Ele teve facilidade em criar a fundação do projeto com Astro + shadcn, assim como pedido, nada de novo aqui.
Foi criado o pull request e fiz a avaliação na minha máquina, testando se estava tudo ok.
Então fiz o merge e segui para o próximo prompt.

Workflow do CI quebrando

O CI, após o merge do primeiro prompt, quebrou e então pedi para corrigi-lo.
Um fato legal é que dá para passar o erro para o agente (como fiz) ou então pedir para ele consultar, que também dá certo. Algo como:

Deu erro no CI, corrija por favor.

Voltando ao prompt:

• Ele leu todos os meus arquivos e conseguiu levantar uma análise do repositório indicando que não havia o diretório de workflow para rodar o CI.
• Criou o arquivo para o workflow do CI e validou se os arquivos de código funcionavam, ou seja, não quebrou nada aqui.
• Relatou o problema e ainda deu uma sugestão do que deveria ser feito para não quebrar novamente.

Por fim, realizei a modificação manual que ele sugeriu no GitHub Action e tudo ocorreu bem.

Layout Global e Header

O objetivo central era centralizar a estrutura global do site em um layout reutilizável, ou seja:

• Header fixo no topo globalmente
• À esquerda, o meu nome com link clicável para o meu portfólio (que posteriormente foi trocado para o próprio blog)
• Campo de busca
• Seletor de idioma
• Botão para troca de tema Light e Dark
• Com idioma e tema salvos no localStorage

Que foram até que “meio” atendidas. Pois posteriormente precisei dar algumas dicas mais claras, como:

• Usar o tema Neutral do Shadcn para Light e Dark
• Visualmente ele não via que o espaçamento interno no seletor de idioma não estava legal
• Scroll da página ainda aparecia mesmo sem ter conteúdo relevante
• Testes unitários para garantir as mudanças

Uma das coisas interessantes que notei é que ele foi adicionando um i18n para lidar com idiomas. Validando tudo, segui para o próximo prompt.

Sistema de Conteúdo (Markdown)

Todo blog precisa de um sistema de organização e essa tarefa era justamente isso. Passando o épico 3, ele precisaria lidar com o template do frontmatter:

title: <string>
draft: <boolean>
slug: <string>
date: <Date> // YYYY/MM/DD
lang: <string> // "pt" | "en"
tags: [<string>]

Então ele criou a pasta de conteúdos para salvar os posts, realizou as configurações necessárias, incluindo a instalação do zod para validação do schema do frontmatter.

Além disso, em um dado momento ele começa a usar recursos em paralelo, como leitura/criação de arquivos e subagents:

Até esse ponto já há ferramentas que usam esses recursos de subagents, porém trabalho em paralelo vi quando estava construindo o editor de texto Markdown.

Usar o Copilot no VS Code é um nível de uso de IA legal, mas usar de fato uma IA para realizar ações e conduzir o processo é um nível totalmente diferente. Já mudou a forma como escrever código hoje.

Home do Blog

O que precisava aqui era algo simples: uma listagem de posts, agrupados por ano e mês, alternando entre idiomas, com um menu âncora para fácil navegação e um scroll para o topo.

E aqui, claramente ele fez isso com um único prompt, coisa que foi se repetindo ao longo das tarefas.

Aqui já comecei a notar como agora tivemos um salto de fato para usar um modelo que realmente faz o que deve ser feito, se bem instruído. Bem instruído é o ponto mais importante aqui.

Sugiro ver como foi o épico 4, porque foram 3 tarefas, descrições curtas do que deveria ser feito e o resultado foi bem agradável.

Página de Post Individual

Todo blog precisa de páginas dinâmicas, e aqui era o objetivo do épico. Rotas baseadas em slug e data, renderização de Markdown corretamente, computação do tempo estimado de leitura.

E aqui ele fez absolutamente tudo! Maaas, por questões de layout, foram necessárias modificações como: título, data e tempo deveriam ficar centralizados, a navegação dentro do blog post com menu lateral, adicionar rodapé de link (adicional, algo que achei interessante) e alguns espaçamentos.

Assim ele fez, como também os testes unitários para essas mudanças.

Busca de Posts

Uma das coisas mais legais é conseguir fazer a busca de posts, porque às vezes queremos ir para algo relacionado, e assim era o objetivo desse épico. No começo pedi para fazer por index, levando em consideração o frontmatter e o conteúdo.

Mas posteriormente vi que, por conteúdo, à medida que o blog cresce teríamos um problema de memória que não seria legal. Inclusive essa foi a única melhoria que pedi que era de fato relevante para modificações.

SEO e Acessibilidade

Blog tem que ter acessibilidade e SEO. Deixei essa parte para o final e ele fez em uma tacada só. O sitemap é criado no build para que a cada post novo seja adicionado. Isso tem prós e contras de sempre mudar o sitemap, mas por enquanto atende o que precisava.

Refinamentos

Esse foi o último prompt relevante que orientei para o agente. Refinamentos para mobile, desktop, header, alguns espaçamentos de conteúdo do post, como centralização do post, remoção das bandeiras de nacionalidade que ele tinha incorporado em commits anteriores, campo de busca agora tinha um “X” para remover toda a busca de uma vez.

Readme

Por fim, atualização do Readme do projeto por questões de estética mesmo. Encerrando o fluxo de criação do blog.

Considerações finais

OBS: Se você entrar no log de commits, vai ver que subi manualmente uma modificação para adicionar o favicon.ico correto do meu portfólio ao blog. Os serviços que rodam dentro do Github Copilot não deixam fazer download de imagens e arquivos externos (eu tentei 😄).

Na tabela abaixo vocês verão os tempos de cada prompt e quanto tempo cada tarefa levou para ser executada. Isso não leva em consideração o tempo que tive que baixar a branch localmente, testar e ver se tudo estava ok. Considera apenas o tempo de execução.

Prompt	Tempo
#1	13:22
#2	03:56
#3	29:21
#4	09:07
#5	13:38
#6	55:42
#7	32:01
#8	13:32
#9	26:21
#10	08:29
Total	03:25:29

Dá para aprender bastante coisa observando esse modelo do Opus 4.6 sendo usado no Copilot. Principalmente pelo fato de que eles rodam subagentes, executam processos em paralelo e, em alguns casos, tarefas de um mesmo épico foram realizadas simultaneamente. Saber orientar o modelo e estruturar bem as instruções acaba se tornando algo muito importante.

Outro ponto bem interessante é que pude fazer outras coisas enquanto ele executava as tarefas. Em teoria, dava para estudar ou trabalhar em outras coisas enquanto o processo acontecia. Porém, na maior parte do tempo eu fiquei observando como ele trabalhava: os comentários que trazia, as sugestões que fazia a partir do que eu dizia e como ele inferia algumas decisões, sempre retornando com um resumo do que havia sido feito. No fim das contas, todo o processo levou cerca de 7 horas, desde o acompanhamento inicial até a conclusão.

Agora as coisas realmente mudaram, e a forma como escrevemos código acredito que já mudou.

Saber orientar agentes já é uma forma de escrever código mais rápido hoje. Não tem como escrever código mais rápido que uma máquina, e isso só mudou por causa desse novo modelo.

Acredito que todos deveriam testar, principalmente sem encostar a mão no código. Vejo que hoje o que realmente faz a diferença é saber fazer pair programming, onde você direciona e o agente escreve o código.

This idea had been sitting in the drawer for some time: taking things out of my head and registering them. Mainly for content generation, based on how I see things and how I keep learning.

This is the story of how I created my blog with 50 commits in less than 4 hours.

Motivation

After watching the live stream from Mano Deyvin with Lucas Montano and Akita, I started to put a little more faith in AI and wanted it to write all the code.

The fact that Akita created 7 relevant personal projects in two and a half months made me excited about using the latest AI models (Claude Opus 4.6 and GPT Codex 5.3). That excitement is what led me to create this blog, as well as my Markdown editor, which I will talk about in another post.

Foundation

During the live stream, Akita said that one of the most important things when working with Claude Opus 4.6 was defining the project, meaning:

• What is the project for?
• What problem does it solve?
• What are the features?

And the other most important thing was:

• Which tools or technologies will I use?

Thinking about this is thinking about Software Engineering. It means asking yourself: “Why use tool X instead of tool Y to do this?”

That led me to create a document defining what this blog project would be. I used ChatGPT to help structure it (😄) and ended up with something reasonable like:

Features:

• Blog with a Markdown-based post system
• Support for English and Brazilian Portuguese
• Indexed search for each post using tags and title
• Sitemap for SEO
• Light and Dark theme

Technologies:

• Astro -> to handle the content
• React -> component library
• TypeScript -> to make working with AI easier
• Shadcn -> to standardize components and reuse some built-in resources
• Vitest -> to write tests

If you want to check the chat, here is the link.

Everything a blog would need in a simple way, with a well-defined scope and using the same technologies with TypeScript/JavaScript.
I also asked for this documentation to be generated in a task-oriented format, thinking about deliverables and how I would guide a junior developer. For that, I needed clear descriptions, business rules, and defined technologies.

Nothing against juniors, but describing tasks this way makes definitions clearer, especially in the task descriptions, which is very important for an AI to understand.

Copilot with Opus 4.6

With the generated document in hand, I created a new project for GitHub Pages and, at the end of the form, there is an option called “Boost your project with Copilot”.

This post is being written after the blog was already created, which is why the screenshot shows a new repository 😉

I filled it with the first epic of the task that I generated with ChatGPT.

Foundation with Astro + shadcn

Since I had already used Opus 4.6 to build my Markdown editor, it already defaults to using this model.

You can check and follow the result of your prompt in the Agents tab of your project.
You can also check Copilot usage at Avatar -> Copilot Settings.

It had no problem creating the foundation of the project with Astro + shadcn, exactly as requested, nothing new here.
A pull request was created and I evaluated it locally on my machine to make sure everything was working.
Then I merged it and moved on to the next prompt.

CI Workflow Breaking

After merging the first prompt, the CI broke and I asked it to fix it.
A nice thing is that you can either provide the error to the agent (as I did) or ask it to investigate, which also works. Something like:

The CI failed, please fix it.

Going back to the prompt:

• It read all my files and analyzed the repository, identifying that there was no workflow directory to run CI.
• It created the CI workflow file and validated that the code files still worked, meaning nothing was broken.
• It reported the problem and even suggested what should be done to prevent it from breaking again.

Finally, I manually applied the modification it suggested in GitHub Actions and everything worked fine.

Global Layout and Header

The main goal was to centralize the global structure of the site in a reusable layout:

• Fixed header at the top globally
• On the left, my name with a clickable link to my portfolio (which was later changed to link to the blog itself)
• Search field
• Language selector
• Button to toggle between Light and Dark themes
• Language and theme saved in localStorage

These were only “partially” fulfilled.

Later I had to give some clearer hints such as:

• Use the Shadcn Neutral theme for Light and Dark
• Visually it didn’t notice that the internal spacing of the language selector was not good
• Page scroll was still appearing even without relevant content
• Unit tests to ensure the changes

One interesting thing I noticed is that it started adding i18n to handle languages.

After validating everything, I moved on to the next prompt.

Content System (Markdown)

Every blog needs an organization system and this task was exactly about that. In epic 3, it needed to handle the frontmatter template:

title: <string>
draft: <boolean>
slug: <string>
date: <Date> // YYYY/MM/DD
lang: <string> // "pt" | "en"
tags: [<string>]

So it created the content folder to store posts and performed the necessary configurations, including installing zod to validate the frontmatter schema.

At some point it also started using parallel resources such as file reading/creation and subagents:

At this point there are already tools using subagents, but I had only seen parallel work like this while building my Markdown editor.

Using Copilot in VS Code is already a nice level of AI usage, but actually using an AI to perform actions and drive the process is a completely different level. It has already changed the way we write code today.

Blog Home

What was needed here was something simple: a list of posts grouped by year and month, switching between languages, with an anchor menu for easy navigation and a scroll-to-top.

And here it clearly did everything with a single prompt, which kept happening throughout the tasks.

This is where I started noticing that we really had a leap toward using a model that actually does what it is supposed to do, if it is well instructed.

Being well instructed is the most important point here.

I suggest checking epic 4: it had 3 tasks, short descriptions of what needed to be done, and the result was quite good.

Individual Post Page

Every blog needs dynamic pages, and that was the goal of this epic. Slug- and date-based routes, correct Markdown rendering, and computing estimated reading time.

And here it did absolutely everything! But due to layout reasons, some adjustments were needed: title, date, and reading time needed to be centered; navigation inside the blog post with a side menu; adding a link footer (an extra that I actually found interesting); and some spacing tweaks.

It handled all of that, including unit tests for the changes.

Post Search

One of the coolest things is being able to search posts, because sometimes we want to find something related, and that was the goal of this epic.

Initially I asked for indexing based on frontmatter and content.

Later I realized that indexing content itself could become a memory issue as the blog grows. That ended up being the only improvement I asked for that was actually relevant in terms of architectural change.

SEO and Accessibility

A blog needs accessibility and SEO. I left this part for the end and it did everything in one go.

The sitemap is generated during the build so that every new post is automatically added. This has pros and cons because the sitemap always changes, but for now it meets the needs.

Refinements

This was the last relevant prompt I gave to the agent.

Refinements for mobile and desktop, header adjustments, spacing improvements in the post content, centering the post, removing nationality flags that it had added in previous commits, and adding an “X” button to clear the search field.

Readme

Finally, updating the project Readme just for aesthetics.

That concludes the blog creation flow.

Final Thoughts

NOTE: If you check the commit log, you’ll see that I manually pushed a modification to add the correct favicon.ico from my portfolio to the blog.
The services running inside GitHub Copilot do not allow downloading images or external files (I tried 😄).

In the table below you can see the time taken by each prompt and how long each task ran. This does not include the time I spent pulling the branch locally, testing, and verifying everything. It only considers execution time.

Prompt	Time
#1	13:22
#2	03:56
#3	29:21
#4	09:07
#5	13:38
#6	55:42
#7	32:01
#8	13:32
#9	26:21
#10	08:29
Total	03:25:29

You can learn a lot by observing this Opus 4.6 model being used inside Copilot. Especially because it runs subagents, executes processes in parallel, and in some cases tasks from the same epic were executed simultaneously. Knowing how to guide the model and structure instructions becomes very important.

Another interesting point is that I was able to do other things while it executed the tasks. In theory, I could study or work on other things during the process. However, most of the time I was observing how it worked: the comments it generated, the suggestions it made based on my instructions, and how it inferred decisions, always returning with a summary of what had been done. In the end, the whole process took about 7 hours, from the initial monitoring to the final completion.

Now things have really changed, and I believe the way we write code has already changed.

Knowing how to guide agents is already a way to write code faster today. There is no way to write code faster than a machine, and this shift only happened because of this new generation of models.

I believe everyone should try it, especially without touching the code. Today, what really makes the difference is knowing how to do pair programming, where you guide the agent and it writes the code.