DEV Community: Samuel Caetite

Code While You Take a Breath

Samuel Caetite — Fri, 25 Sep 2026 00:53:41 +0000

A few months ago, I started having this strange feeling that I was falling behind on AI.

Which is funny, because I've been developing with AI for almost four years.

It wasn't a recent discovery for me. I was already using models to learn technologies, investigate problems, write code, review solutions, organize ideas, and speed up parts of my work long before this whole conversation about how every developer now needs to learn how to work with agents.

And yet, at some point, it felt like I had missed something.

Suddenly it was RAG, embeddings, vector search, agents, tool calling, MCP, LangChain, LangGraph, and who knows how many other things I hadn't even added to the list yet. And that was the easy part, because at least those were concepts I could study.

At the same time, there was always some new model that had supposedly left Claude in the dust, followed by another one that had left that one in the dust. Then came Kimi, another Chinese model, another open-source model, a new coding tool, a new agent, OpenCode, some random GitHub repository that somehow got two billion stars in three days and that, apparently, everyone knew about except me.

Then there was the local-model crowd explaining that I didn't need to pay subscriptions to any of these companies anymore because I could run everything locally for free.

I just needed a $10,000 computer.

And, of course, if I was still paying for subscriptions, I was probably leaving money on the table.

By the way, "leaving money on the table" has to be one of the most expensive expressions of the last few years.

Somewhere in the middle of all this, software development also died a few times. Developers were done. Then we weren't. Then we came back, except now we had to "learn our place." Every once in a while, that weird little war between development and "product" would show up again, especially the version where someone discovers a tool capable of generating an application and concludes that the only reason things weren't being built before was because some developer was standing in the way.

Sometimes we were.

Probably because somebody had to make sure the whole thing didn't explode.

I was using AI every day while simultaneously starting to believe I was behind on AI.

That's when, about ten months ago, I decided to stop for a moment.

I wasn't trying to escape the hype

There's one response to this anxiety that has never really worked for me.

Every once in a while, someone shares a chart showing that a huge portion of the world's population still doesn't use LLMs directly, or that adoption is much smaller than our tech bubble makes it seem.

Maybe.

But I'm a developer, so looking at a statistic like that and deciding I can ignore what's happening because most of the planet didn't open ChatGPT today doesn't help me very much. The market I work in, the jobs I see, the people I talk to, the products I build, and the companies I work for are a much closer sample of the people already being directly affected by this technology.

I'd be using someone else's reality to reassure myself.

So this was never an attempt to deny what's happening. Quite the opposite. I wanted to accept reality without necessarily accepting all the panic that came with it.

And I ended up doing more or less the same thing I do when I leave the house.

I put on my headphones.

I recently bought a pair with ANC, active noise cancellation, and I've really enjoyed the feeling. I don't need to listen to everyone's blah blah blah and every car around me to keep walking down the street and pay attention to what actually matters, including making sure I don't get run over.

The street is still there, after all.

That's more or less what I tried to do with AI.

I needed to understand what was actually happening

Until then, my relationship with these technologies had mostly been driven by necessity.

A problem came up, I learned what I needed to solve it. If I needed to understand a particular API, I studied it. If I needed to use a model differently, I researched it. If I hit a limitation, I looked for an alternative.

That's basically how I've always learned technology.

But this time I wanted a slightly higher-level view.

I started looking at job postings that mentioned AI. I wrote down the terms that kept appearing. I asked AI itself to help me organize them. I went back to some theoretical concepts, started connecting what I was seeing in the market with things I had studied before, and gradually built a kind of map so I could look at the whole thing without constantly standing in the middle of the hurricane.

I wanted to understand what was genuinely new, what was a new application of something that already existed, what was likely to become part of my work for a long time, and what might be receiving a disproportionate amount of attention because somebody needed to sell something.

The funny part was that some things became much less intimidating once they stopped being English words repeated in posts and became concepts I actually had to understand.

Embeddings are a good example.

The word appears so often around LLMs that it's easy to treat it like some alien technology invented alongside ChatGPT. When I actually sat down and studied it, I started recognizing ideas that weren't that far removed from the AI and math foundations I had already encountered before.

That happened several times.

The more I studied, the less it felt like an entirely new universe had appeared overnight. There was novelty, of course, and a lot of it. But there were also old concepts finding new applications, techniques being combined in different ways, abstractions becoming more accessible, products being built on top of them, and a considerable amount of marketing giving very big names to some relatively understandable things.

That calmed me down quite a bit.

Not because I concluded that AI was less important than I thought.

Almost the opposite.

I just started finding the hype less important.

The problem is that everything changes while you're trying to understand it

There's a particularly funny part about trying to keep up with this market: sometimes you discover that something stopped existing before you even finished understanding the previous thing.

I recently discovered, for example, that Google Bard doesn't exist anymore.

I used Bard.

At some point in my life, I opened it, talked to it, and thought, "Oh, look, Google has one of these now too."

Today, it's Gemini.

Not long ago, I had a similar experience when I tried to figure out what had happened to Windsurf and ended up going through the whole story involving Cognition and Devin.

Devin.

Not Mano Deyvin, the Brazilian YouTuber I like watching.

A different one.

At some point during this whole journey, I also discovered that I had spent a considerable amount of time pronouncing Claude wrong. It's "clawed," not "cloud," as in the thing floating in the sky.

I find it incredibly funny that you can spend months studying agent architectures, RAG, and vector search only to discover that you didn't even know how to pronounce the name of the thing you were using.

Maybe that's also a decent antidote to the feeling that you're behind.

The ecosystem changes so quickly that if your goal is to eventually reach a point where you finally know everything that's happening, I have some bad news.

By the time you get there, they've probably renamed it.

That's when "systematizing" started to mean something

When I say I've spent these months trying to systematize how I use AI, I don't mean I made a list of every technology that exists and started checking them off one by one.

For one thing, I haven't finished.

I probably never will.

What I wanted was to build a somewhat more stable and consistent modus operandi for using AI the same way I use any other technology.

After you've been working in software for a while, you start accumulating this enormous menu of things you know exist. You know different databases, caching strategies, queues, containers, architectures, protocols, frameworks, and an endless number of tools that can solve particular problems. Knowing they exist doesn't mean putting all of them into the same system.

In fact, an important part of the job is knowing what to leave out.

That's how I started looking at this new menu too.

LLMs, RAG, embeddings, vector search, tool calling, agents, MCP, and the frameworks growing around them are ingredients. Some work well together, others solve very specific problems, some introduce complexity that's absolutely worth it, and others can turn something simple into an impressive contraption that nobody actually needed.

I can know all of them without putting all of them on the plate.

If I understand, at least reasonably well, what each one does, which problems it solves, what it costs to introduce, what limitations it brings, and when it starts becoming unnecessary complexity, I can look at a solution and make a more deliberate choice about what belongs in it.

That's what systematizing has meant to me.

Learning how to use these things, when to use them, and, most importantly, when not to.

And I really like AI

It might sound strange to spend this much time talking about hype only to get here, but I'm genuinely very grateful these tools exist.

There are a lot of things I've wanted to build for myself for years and simply never built. Not always because I didn't know how. Sometimes I knew perfectly well how to do it, but I couldn't justify spending an entire Saturday building a tool that would solve one small annoyance in my life.

That equation has changed.

I've been able to build tools exactly the way I want them for my own work. I can experiment with ideas that would probably have died in a note somewhere, and I can study things that had been sitting on my list for a long time because some of the work required to get there has become smaller.

And it has gone beyond code.

I've been using AI to organize work, studies, and some very mundane parts of my life, putting order into things that used to occupy space in my head while I tried to remember everything at once.

My spending on Post-it notes has gone down quite a bit.

That might be a difficult productivity metric to put in a report, but it works for me.

When I can get some of those things out of my head, there's more room for other things. More time to study, more space to think through a solution calmly, more energy to build some tiny tool for myself simply because I want it to exist that way.

At some point, we'll probably end up paying a bigger share of the bill for those astronomical investments the LLM giants are making.

I hope it takes a little while.

For now, this is pretty nice.

Parsimony

If there's one word that keeps coming back to me through all of this, it's parsimony.

I like it because it doesn't have much to do with rejecting a technology or being afraid of it. It's more about knowing where I'm putting my foot and why.

Today, I can put an agent to work investigating a codebase, and it can read in a few minutes an amount of files that would take me hours to go through. A model might know an architectural pattern I've never used, find examples, connect ideas, and show me a possibility that would have taken me quite a while to discover on my own.

That's incredible, and I have absolutely no desire to compete with it.

But I'm on the other side of that relationship bringing a different kind of baggage. I've lived through projects catching fire, had to solve problems without the right tool available, watched requirements change halfway through, had to improvise, and seen technically beautiful solutions fail once they encountered the real world.

There's a certain feel that comes from having been through those things.

Sometimes AI helps by putting guardrails around my thinking, pointing out a possibility I hadn't considered, or bringing in technical and architectural knowledge I was missing. Other times, I'm the one who needs to put guardrails around it.

It can tell me how a particular architecture could be built. I can say that this architecture, on this project, with these people, under this deadline and in this context, might be a terrible idea.

And that combination has been working very well for me.

I have no idea how long it will continue to work exactly like this. Maybe soon the hype will be physical AI and I'll have to learn an entirely new vocabulary. Maybe some of what I'm studying today will look funny when I read this again a few years from now. Maybe some tool that feels inevitable today will simply disappear.

That would be pretty consistent, actually.

Code While You Take a Breath

Some time ago, I came across a post from a woman who returned to work after being away on maternity leave and felt like she had come back to a different reality. While she was away, generative AI had advanced, new tools had appeared, and it seemed like everyone had learned something she hadn't had the chance to learn.

I didn't go through the same thing.

I wasn't away. I kept coding, working, and using AI. And yet I immediately recognized that feeling of looking around and thinking that, at some point, without anyone telling you, everyone else had received a handbook you somehow never got.

Today, I think I was paying too much attention to the voices inside other people's heads.

There will always be a technology I haven't tried yet, a paper I haven't read, a model I haven't experimented with, a repository that gained an absurd number of stars while I was asleep, and an acronym I've seen three times this week and still have no idea what it means. Some of those things will matter a lot, which is why I keep studying.

I just don't want to confuse speed with direction anymore.

The machine can read faster than I can, research faster than I can, generate faster than I can, and write code while I'm doing something else.

Great.

I don't need to respond by becoming more rushed.

I can use that time to understand the problem better, study something, test an idea, build something that's been sitting around for months, or look at a technically impressive solution and realize that it became far too complicated for the problem it was supposed to solve.

I might even discover that I don't need AI at all for that particular thing.

I can take a breath.

The code keeps moving.

And, with a little parsimony, so do I.

Falso Retorno, ou: Quando desligamos as ranqueadas

Samuel Caetite — Sat, 14 Feb 2026 10:48:43 +0000

⚠️ Nota importante

Este não é um texto de minha autoria.

Este artigo foi originalmente publicado no antigo site brasileiro do League of Legends, escrito por Rumtumtummers, e está disponível publicamente via Wayback Machine.

Estou republicando este conteúdo no dev.to exclusivamente como referência pessoal e profissional, para manter salvo um exemplo real de como equipes técnicas lidam com incidentes críticos, tomada de decisão sob pressão e responsabilidade com usuários.

https://samuelcaetite.dev/falso-retorno

Autor original: Rumtumtummers

Fonte original: League of Legends Brasil

Todos os horários em: PDT

Ah, a pré-temporada… época de ficar ansioso sobre as novidades em League, mas também de refletir sobre as coisas que aconteceram neste ano. Jogadores ranqueados, por exemplo, devem se lembrar do bug da Riven que apareceu em julho e causou o desligamento de todas as filas ranqueadas.

A seguir temos a história desse bug e das equipes da Riot que trabalharam intensamente para encontrar uma solução.

Manhã – 15 de julho de 2015

Um vídeo sobe rapidamente para a página inicial do subreddit de League of Legends. Nele, um jogador mostrava um bug com a Riven: a sequência “certa” de apertos de botão fazia com que ela voltasse instantaneamente para a base, ignorando o tempo de conjuração da habilidade de retorno. À medida que as equipes na Riot começam a trabalhar, relatórios sobre bugs e seu impacto em potencial vão surgindo.

🧭 Donna Mason, Release Manager

Recebemos emails, memorando e pessoas o tempo todo.

“Meu Deus, você viu isso no Reddit?”

🎛️ Scott Hansen, Live Producer

Tinha algo no Reddit em que alguém publicou um vídeo de

“Ei, aconteceu esse negócio bizarro quando eu estava jogando de Riven”.

🎛️ Tim Isenman, Live Producer

A primeira coisa que vimos foi a publicação no Reddit e foi a partir dali que começamos a investigar. Tínhamos algumas pessoas no time de Campeões investigando o problema também.

🧩 Kacee Granke, Product Manager

O problema com a Riven levantou alertas de emergência imediatamente.

🧠 Mark Sassenrath, Associate Game Designer

Alguém vem e diz

“Ei, temos um bug na Riven que precisa ser arrumado. Podemos arrumar esse bug da Riven!”

🧭 Donna Mason, Release Manager

Então fomos investigar e começamos a tentar reproduzi-lo. Nosso objetivo quando esse tipo de coisa chega é sempre descobrir se é aleatório ou se era algo que as pessoas podiam explorar para vantagem própria.

Se há um bug no jogo, isso não é bom. Caso um bug dê uma vantagem que não seja natural a alguém, isso é muito, muito ruim.

E uma parte importante é: “Consigo fazer também?”

🧩 Kacee Granke, Product Manager

Começamos a tentar reproduzi-lo nós mesmos. Por sorte, o vídeo deixou tudo muito claro.

🎛️ Scott Hansen, Live Producer

O controle de qualidade de Release conseguiu efetuar a reprodução facilmente. Nós, da Live Production, não. Não somos tão bons no jogo. Sou prata.

🧪 Matthew Wittrock, Release QA

Estou mexendo e finalmente

“Ah, consegui”.

Depois

“Agora consigo fazer direto. Agora é fácil. Isso não é bom”.

🎛️ Tim Isenman, Live Producer

Perguntei

“Com essas informações, vamos desabilitar Riven?”

🧭 Donna Mason, Release Manager

Então olhamos as informações e vimos o quão rapidamente a publicação estava ficando popular e visível e tomamos a decisão de desabilitar Riven.

14:50 – 15 de julho

Riven é desabilitada globalmente. Enquanto os times trabalham na solução, novos relatórios aparecem interna e externamente indicando que o bug pode ser aplicado em mais Campeões.

🎛️ Tim Isenman, Live Producer

Depois de desabilitar a Riven, vários Rioters vieram me falar sobre mais vídeos de pessoas reproduzindo o bug em outros Campeões. Era no Yasuo, depois no Graves, depois mais e mais.

🧠 Mark Sassenrath, Associate Game Designer

Pessoas continuaram relatando

“Isso também acontece no Shen. E em X, Y e Z”.

🧩 Kacee Granke, Product Manager

Quase imediatamente depois disso, começamos a receber relatórios do nosso controle de qualidade informando que eles conseguiam reproduzir o bug com outros Campeões.

🧠 Mark Sassenrath, Associate Game Designer

No decorrer do dia, começamos a perceber que esse não era um bug da Riven. Era um bug geral.

🎛️ Tim Isenman, Live Producer

Quando olhamos as informações, percebemos que o problema poderia ser explorado em quase um quarto dos Campeões. Quase entramos em choque.

🧪 Matthew Wittrock, Release QA

Mesmo então, ainda estávamos subestimando o escopo do problema.

🎛️ Tim Isenman, Live Producer

Concluímos que qualquer Campeão usando Tiamat ou Hidra poderia causar o mesmo efeito.

🧠 Mark Sassenrath, Associate Game Designer

Pensei

“Qualquer Campeão pode fazer isso. Precisamos impedir que se espalhe”.

🧭 Donna Mason, Release Manager

Fica um sentimento de desespero quando você percebe que é com todos os Campeões.

🧪 Matthew Wittrock, Release QA

Estava claro que não existia lado ruim no abuso desse bug.

Tarde – 15 de julho de 2015

O bug cresce rapidamente. Times começam a discutir como mitigar o dano potencial.

🎛️ Scott Hansen, Live Producer

Precisamos considerar desabilitar as ranqueadas.

🎛️ Tim Isenman, Live Producer

Desabilitar um quarto do jogo seria pior do que desligar as ranqueadas.

🧪 Matthew Wittrock, Release QA

Não adiantava só desligar um Campeão ou item.

🧩 Kacee Granke, Product Manager

A pergunta era

“O que podemos fazer?”

🧭 Donna Mason, Release Manager

Era uma espada de dois gumes. Informação boa, visibilidade ruim.

🧩 Kacee Granke, Product Manager

Precisávamos desligar as ranqueadas agora.

17:30 – 15 de julho

As filas ranqueadas são oficialmente desabilitadas. O trabalho de correção começa em ritmo máximo.

🎛️ Scott Hansen, Live Producer

Estamos informando jogadores em mais de 20 idiomas e tentando resolver o problema.

🧩 Kacee Granke, Product Manager

Levou horas até passar pelo primeiro teste.

🧠 Mark Sassenrath, Associate Game Designer

O escopo ficava cada vez maior.

🧭 Donna Mason, Release Manager

Sabíamos que estávamos com problemas após várias iterações falharem.

2:00 – 16 de julho de 2015

A solução falha nos testes destrutivos. Todos são chamados de volta.

🧭 Donna Mason, Release Manager

Acordamos engenheiros, designers, todo mundo.

🧠 Mark Sassenrath, Associate Game Designer

Você sabe que algo deu errado quando o telefone toca de madrugada.

Tarde – 16 de julho de 2015

As ranqueadas seguem desligadas há quase 24 horas.

🎛️ Tim Isenman, Live Producer

Era difícil comunicar progresso sem saber o prazo.

17:00 – 16 de julho

A solução é validada para todos os Campeões.

🎛️ Tim Isenman, Live Producer

Recebemos a confirmação de que funcionava 100%.

🧭 Donna Mason, Release Manager

O trem de lançamento estava pronto.

🧪 Matthew Wittrock, Release QA

Todos estavam prontos.

20:00 – 16 de julho

As ranqueadas são reativadas após 28 horas desligadas.

🎛️ Tim Isenman, Live Producer

O demônio foi derrotado.

🧪 Matthew Wittrock, Release QA

O trem continua seu curso.

🧭 Donna Mason, Release Manager

Pensei

“Vou jogar uma ranqueadinha”.

🧩 Kacee Granke, Product Manager

E voltamos ao trabalho.

🧠 Mark Sassenrath, Associate Game Designer

Ainda há muito trabalho a fazer.

Ninguém gosta de bugs em jogos complexos, mas quando eles surgem, equipes inteiras trabalham juntas para preservar a integridade da experiência. No caso do grande bug de volta à base de 2015, várias pessoas contribuíram incansavelmente para devolver as ranqueadas aos jogadores.

Fonte original e snapshot

URL original: https://br.leagueoflegends.com/pt/news/riot-games/editorial/falso-retorno-ou-quando-desligamos-ranqueadas
Snapshot (Wayback Machine): https://web.archive.org/web/20160225005605/http://br.leagueoflegends.com/pt/news/riot-games/editorial/falso-retorno-ou-quando-desligamos-ranqueadas

Data e hora do snapshot: 25 de fevereiro de 2016, 00:56:05 (UTC)

I spent 3 months building a static website and it says more about me than any stack

Samuel Caetite — Thu, 05 Feb 2026 00:28:09 +0000

For a long time, I was a web developer without a personal website.

Not because I never built one. I had several. Some were decent, some were quick experiments, some died with expired domains. Back in 2019 I even made a simple one just to land my first internship. It worked.

What I did not have was a site that actually represented who I am now.

And that felt weird.

If you build software for a living but you have no space that reflects your own criteria, it is like being a chef who lives on delivery. Functional, sure. But something does not add up.

The first versions were pretty and empty

My first attempts were purely aesthetic.

I tried glassmorphism. It looked modern and polished. I shipped it fast, with help from AI, and for a brief moment it felt done.

Then the discomfort kicked in.

It was a résumé wearing a costume. Same content as the PDF, just with blur and shine. Good looking, low truth.

Then I tried neumorphism. Even prettier. I let AI drive most of it. It nailed the vibe. Still, after a while I realized I liked the style more than the message.

I was optimizing surface, not meaning.

A side project quietly changed everything

While I was stuck with the portfolio, I started a personal project called TrueStreak. The idea was simple: track gym consistency and make habits visible.

But it became a lab.

I dove into performance, accessibility, analytics, SEO, domain modeling, cloud, serverless. Not as theory. As decisions that had to hold up in a real product.

That is when I made a choice that looked odd from the outside.

I built it with HTML, SCSS, and vanilla JavaScript.

No framework. No TypeScript.

Not out of nostalgia. Out of fit.

A static product with simple flows does not need a cruise ship. It needs clarity, speed, and tolerance for iteration.

The stack served the problem. Not the other way around.

The site stopped being a site and became a tool

As the project grew, the usual friction showed up:

compiling SCSS
reusing shared structure across pages
cache busting assets
optimizing images
generating metadata and structured data
avoiding regressions and broken builds
making deploy predictable

So I started solving one pain at a time.

Scripts became a pipeline. The pipeline became a builder. The builder became a small system.

I eventually packaged the idea into my own static generator:

SiteForge.

It is not a “framework replacement”. It is a way to eliminate unnecessary complexity while keeping full control over what gets shipped.

If you are curious:

Portfolio: https://samuelcaetite.dev
SiteForge demo page: https://samuelcaetite.dev/site-forge
SiteForge repo: https://github.com/osamucadev/site-forge

The real problem was narrative, not design

When I finished TrueStreak and looked at it running, something clicked.

I had a real product. Something I use. Something that does not depend on context or hype.

Then I revisited my portfolio and noticed a mismatch.

My LinkedIn told the story of someone who has dealt with critical systems, production pressure, real responsibility, and the boring parts that keep products alive.

My website looked like a nice template.

Two different people.

At that moment it became obvious: the problem was not visual. It was narrative.

I did not need another place listing technologies and job titles. I needed a space that shows how I think, how I decide, and what I refuse to compromise.

I changed how I used AI

I stopped asking AI for solutions.

I started asking it for questions.

I shared the HTML and CSS. I explained the discomfort. I asked for critiques, alternatives, and tradeoffs. I used AI as an assistant that accelerates iteration, not as an author that replaces judgment.

That is the key difference.

AI can speed up execution. It cannot replace criteria.

What the current portfolio actually demonstrates

Yes, it is a static website. But it is not a static decision.

This repo exists to demonstrate engineering habits:

full control over generated HTML, CSS, and JS
a custom build pipeline focused on real performance metrics
SEO that is not just “meta tags”, but structure and intent
cache busting and predictable deploy
security headers and basic hardening
separation between source and production output

The goal was not to impress with complexity.

The goal was to ship something fast, quiet, readable, and durable.

In other words, the exact way I like to build software.

Why it took 3 months

Because the hard part was not typing code.

The hard part was deciding:

what should exist
what should not exist
what is noise
what actually communicates value
what stays stable as the site evolves

A strong portfolio is not a list. It is a narrative system.

Each section has its own intention. Some need tension. Some need calm. Some need structure. Some need humanity.

The site does not try to prove seniority. It lets you feel it.

The takeaway

I spent 3 months building a static website.

And I would do it again the same way.

Not because it is “hard” or “impressive”, but because it forced me to be honest about what I value:

clarity over noise
responsibility over aesthetics
fit over trend
maintainability over cleverness
narrative over buzzwords

If you are building your own portfolio, here is my suggestion:

Do not start with visuals.

Start with what you want to be true about you when someone closes the tab.

Everything else is implementation.

If you want to see the code and the build approach:

Repo: https://github.com/osamucadev/frontsamuelcaetite
Site: https://samuelcaetite.dev