some ppl on reddit claim claude’s subscription has a better effective $/token rate than the pay-as-you-go API. i wanted to see it with my own eyes.

so this post is two things: a little rant about what we’re actually paying for, and then the savvy cheap-but-still-high-quality experiment i ran: claude code pointed at deepseek’s anthropic-compatible endpoint, max effort, 1M context.

this is a tech section in experimental’s newsletter.

if you prefer follow weekly prompts on linkedin & unfollow this section here on substack.

the apple parallel

apple taught us the shape of the trick: your phone gets weird and slow, you update, suddenly it’s fine again, or you just buy the new one.

the motive’s contested (battery protection vs. planned obsolescence), nobody outside cupertino really knows, but the effect is undeniable, and it’s an inescapable business model you’re forced to participate in.

AI providers are doing a version of this, except clumsier and more public: users keep reporting claude or GPT “feels dumber,” and the companies eventually admit they tweaked an effort default, changed a system prompt, shipped a verbosity fix that broke reasoning.

fine. whatever. who cares.

except, we never get to verify any of it, and we have no power to not upgrade, the thing we’re paying for just stops working the way it did yesterday.

the reality is that they need us on the new models….

you pay, and you’re the product

we’re a decade into social media, so we know the rule:

if you’re not paying for something, you’re the product.

but the social media version is that you pay with attention (aka your time of life) and in exchange you get reach, connections, a whole bunch of fun new things…

with AI you hand over your hours for productivity, digested knowledge, automations (things that’ll keep changing too, the way feeds did),

so, you pay with attention, money, and you’re the product.

every prompt feeds the system that trains the next model and you’re paying for it.

so, two things we already recognize:

• the product decays and you pay to “upgrade,” like the apple cycle

• they hook you into using it more so they harvest your data, your behavior, your preferences, your weird specific use cases

and two things that are new:

• when you upgrade, you apparently get less. the “smarter” model is more expensive to run, so your subscription burns through its limits faster. you pay more to chat less.

• unlike a phone or a feed, the product is non-deterministic. you can’t audit it. there’s no fixed thing to compare against , so the “$/token” question i started with has no honest answer. which is exactly how a moving target stays a moving target.

that’s the real reality check, now whether our expectations are aligned…

let’s talk configs and tokens.

tokens are the wrong unit

nobody buys tokens. people buy hours of work. tokens are just the meter running underneath, what you actually want is a feature shipped, a bug fixed, an essay written.

and the two billing models don’t just cost different amounts. they behave differently:

• on the subscription model, max effort costs nothing extra, you just hit your rate limit faster, wait for the window to reset and you’re back. annoying, but “free.”

• on pay-per-token, you don’t hit a wall. you just bleed credits. no waiting, no reset… reload your balance or stop working.

the experiment: swapping claude code’s brain

claude code is anthropic’s CLI/agent tool, by default it talks to

https://api.anthropic.com

and runs claude models.

deepseek’s “anthropic-compatible endpoint” is just an API at https://api.deepseek.com/anthropic that speaks the same protocol, same request format, same response shape, same auth pattern. so any client built for anthropic’s API (claude code included) can talk to it without code changes.

the swap is done with env vars: claude code reads them, sends its requests to deepseek instead, and never knows the difference.

same agent loop, same tool-use logic, same VS Code integration, but a different brain doing the thinking. (same pattern as pointing an openai SDK at a local ollama server, or at groq, for example)

here’s the config:

#!/usr/bin/env sh

export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
export ANTHROPIC_AUTH_TOKEN="<your-deepseek-api-key>"
export ANTHROPIC_MODEL="deepseek-v4-pro[1m]"
export ANTHROPIC_DEFAULT_OPUS_MODEL="deepseek-v4-pro[1m]"
export ANTHROPIC_DEFAULT_SONNET_MODEL="deepseek-v4-pro[1m]"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="deepseek-v4-flash[1m]"
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC="1"
export CLAUDE_CODE_EFFORT_LEVEL="max"

rememebr it’s pay-per-token, so you must buy some Deepseek credits.

(tip: run /status inside claude code after launching to confirm the base URL and model actually switched.)

CLAUDE_CODE_EFFORT_LEVEL=max tells the model to use maximum reasoning tokens per turn and combine that with deepseek-v4-pro[1m] it’s the best model you can get to think about long context tasks (many pages pdfs, large code database, etc). So each turn burns significantly more billable tokens than a “normal” call.

TL;DR max effort + 1M context = the most expensive config you can run.

the math, honestly

i tested it on a small session: 4 hours of coding, ~$5 burned on deepseek pay-per-token at max effort + 1M context.

• ~$5 for 4 hours = ~$1.25/hour

• hour 20: 20 × $1.25 = $25 burned

• 40 hrs/week × 4 weeks ≈ ~$200/month, climbing

meanwhile the sub is flat at ~$100/month no matter how many hours i log, so somewhere around hour 20, the pay-per-token bill crosses the sub price, and from there every extra hour just widens the gap.

so yeah, reddit was right. como a gente diz no brasil: a voz do povo é a voz de deus kk

but.

the product underneath you shifts week to week, and it’s non-deterministic, there’s nothing fixed to measure against. subscription or pay-as-you-go, you’re paying for a moving target, you can cry on twitter about slop models, but it’s about as effective as crying over gravity.

and here’s the real math: those “extra” hours the sub keeps handing you aren’t generosity, they decide how fast you burn, how many hours you get, they hand you more hours because more usage is more data, and the data trains the next model you’ll pay to upgrade to.

you’re using the product, sure, but mostly the product is using you, you can’t audit a thing that’s being moved on purpose in the direction that extracts the most from you.

so yeah, that’s the actual math.

til next “weekly prompts”,

subscribe for more (:

Best regards,

Mica

march 15th, 2026

hi guys! welcome to another weekly prompts (:

today’s rambling is on what a solo developer can execute now....

this edition is basically a live example of it:

migrating infrastructure, launching a satellite product, and reworking market positioning simultaneously...

while freelancing and exploring vietnam,

not sure if all of that could be done simultaneously by one single person five years ago.

___

a quick note before we start: if you’re new here, so far we are kinda answering...

“where does software judgment come from?“

1. first edition covered ubiquitous language says it comes from talking to people, not just writing code;

2. second ed: the refactor vs. rebuild edition says it comes from honest assessment, not technical ego;

3. third ed: the architecture one says it comes from resisting borrowed complexity from big corp, being honest on how sometimes things can actually be simplified;

4. forth ed: the AI trust one says it comes from deciding how much uncertainty you’re willing to expose in your system.

so we have the same argument from four different angles: the developer who thinks clearly about tradeoffs is more valuable than the one who follows the playbook.

___

today idk, let’s just be brief and opinionated on modern stacks and marketing strategy.

let’s go (:

git diff -- vercel + supabase vs. railway

i’m testing a sub-product of leilão no mapa (the SaaS I’m building) this week and for that I’m using railway. i stumbled on this product while building the competitor analysis dashboard for a client, which I mentioned last week.

the cost is meaningfully cheaper, and railway runs on a canvas model: every service you have, your postgres instance, your app, your workers, whatever else, appears as a node you can visually connect.

internal communication between services happens over a private network by default, no extra config, no going through the public internet... for a solo dev running more than one project, the cognitive overhead of keeping infrastructure in your head is real, so this removes a layer of it. you look at the canvas and you just... see the thing lol

the pricing model also fits differently: vercel and supabase both have their own billing logic based on requests, bandwidth, database size. meanwhile railway charges for actual resource consumption, cpu and memory.

so the test of railway and possibly a full migration of the solution isn’t driven by a technical failure, this isn’t a verdict against vercel or supabase, but for where i am right now, I think that’s not the right fit anymore.

___

git branch -- one product becomes two

after a lot of user conversations about leilão no mapa, one thing became impossible to ignore: the juridical and compliance analysis of the real estate matricula is where people actually get stuck.

the matricula is the property registration document in brazil, and reading it correctly, knowing what to flag, what to look up next, is the real bottleneck in the market. my competitors have some tooling for this, but it’s buried inside chunky UIs.

so i’m testing analisematricula.com as a standalone product. not a feature inside leilão no mapa, just a separate thing. you paste or upload a matricula and it doesn’t just read it, it gives you next steps: check jusbrasil, search this on the web, here are the phone numbers you need... a shortcut for anyone buying, renting, or bidding at auction, but also useful for law firms and imobiliárias that do this dozens of times a month.

splitting products isn’t a new strategy, adobe has been doing it for years, launching focused standalone tools like adobe express and adobe sign instead of cramming every bet into creative cloud, for example.

now with AI solo developers can run the same playbook, not with the same resources ofc lol but with the same logic. i’m not certain splitting is the right call, maybe the answer is to keep everything in one place and explore UX approaches, but the user signal was clear enough that i want to test the hypothesis cleanly.

___

git stash -- making a boring market feel interesting

the other experiment: repositioning leilão no mapa. same product, different framing.

real estate auctions in brazil are genuinely associated with bureaucracy, confusion, and the faint feeling that something sketchy is going on. that reputation isn’t entirely wrong, which is part of what makes it interesting.

boring markets are often boring because nobody made the effort to explain them, and a market that nobody understands is one where the people with information profit over the people without it.

so, the audience i want to reach isn’t just the experienced investor hunting for a deal, it’s the person who has the money, who would otherwise end up in a lançamento na planta at inflated prices, or worse, buying something without understanding what they actually own...

real estate literacy in brazil is genuinely low, and that gap has real costs for people, so the strategy, if i can call it that, isn’t just about making leilão no mapa more appealing, it’s about reframing the buying experience itself as the product, not “here are auctions, good luck.” but “here’s what you need to understand to make a confident decision, here is a free deep explanation on what is what, and here’s the tool that helps you explore this world.”

the product doesn’t change much, the context does a bit, so I’m trying to frame something like where the product is obviously the right choice for a specific person in a specific context, and the context i want to own is financial literacy meets accessible real estate, not yet another auction aggregator competing on volume of listings, so I don’t need to compete with those solutions as well.

can i really do it? idk lol let’s test. whether the rebranding reflects that or not, i’ll find out when i try to write the copy and reaching people, that’s usually when you discover whether the idea actually holds, apparently.

for this week that’s all, thanks for reading s2

don’t be shy, let’s make linkedin less awkward, chime in on the comments (!)

until the next prompt, Michelle (:

Mica Tech Studio

march 8th, 2026

this week: why AI adoption is blocked by capability and trust, and how it plays out inside your pipeline the moment a model enters it.

let’s go (:

____

git fetch: the AI adoption gap

anthropic published a report on where AI is theoretically capable of making a dent and where it already should have, but hasn’t.

blue is theoretical coverage per job category. red is observed adoption. stare at legal and business & finance for a second:

in 2019 i was at deloitte automating workflows for accountants and lawyers. not with llms, but with robotic process automation, scripts, macros, and it was the low-code wave! so, uipath, power automate, the whole thing... technology that was already objectively faster and more precise than a human being.

the promise was clear: business people would do what developers do. everyone would automate everything with drag and drop. no engineers needed. and further out, so much of finance and accounting would be automated that entire roles would disappear.

___

git push --force: shipping automation nobody asked for

what actually happened: companies put real effort into getting business people to do it. they ran training sessions, bought licenses, made decks about the future of work. and still, nobody in a suit wanted to touch it for 40 hours a week. they had actual jobs, automation was someone else’s problem.

or they saw the automation wave oversell and underdeliver, maybe?

the platforms got expensive fast, only large companies could afford them at scale, and you still needed an orchestrator specialist, a developer for the edge cases, and someone to make sure people actually used the thing: yes, a surprising number of useful automations were built, handed over, and quietly never ran in production.

six years later models are better, we are what? 2 years in AI? but the chart still looks like this:

my instinct is to say: the gap has never really been about the capability of the technology, or about turning the business worker into a technical one with a powerful tool... actually, i don’t think that gap ever fully closes, it has always been more about access control and internal politics.

legal and finance, to keep the example, haven’t adopted more AI partly because the models still aren’t reliable enough for the liability surface those industries carry. a hallucinated clause in a contract isn’t a trust problem. it’s a product problem, and they’re correctly pricing the cost of a silent failure in a regulated environment, so the gap is still there.

now, don’t get me wrong. AI-based solutions will take a meaningful share of these occupations, because part of trust is downstream of capability. when the systems become reliable enough, adoption follows.

today i’m playing a bit of both sides here. i’m skeptical about how fast the gap closes, but at the same time my long-term prediction is almost a bit utopian, or catastrophic, depending on how you look at it...

___

git branch: the startup window

that complexity is usually framed as an opportunity for mid-sized companies and we’ve heard the argument before with mobile, cloud, low-code: being small and fast is a structural advantage.

but this time the window is shorter, my guess is: one to two years for small and mid-sized companies to move before big solutions consolidate, depending on the industry.

the window closes faster than small companies can operationalize, because speed at the prototype stage doesn’t compound. execution does, so when large firms move, they move with distribution, compliance infrastructure, and customer trust already built.

___

git permissions: who gets access to the sauce

so the honest version of the opportunity isn’t “small is better”, it’s more closer to this: there’s a window where experimentation is cheap enough that you can build something real before the category gets defined for you.

that window is open, but it’s also temporary, and it requires operational follow-through that most companies “moving fast” aren’t actually doing.

the move for mid-sized companies isn’t to imagine a long future inside that gap, it’s to capture it while it’s open: you can now build a working prototype in days instead of months... not just replicating existing processes, but enriching them with knowledge that wasn’t accessible before.

but to do that, business owners who want any shot at competing with increasingly monopolistic firms have to do something uncomfortable: they have to hand their entire sauce to a random developer. their processes. their exceptions. their workarounds. every undocumented thing keeping the operation running. all of it. on a shared drive. with someone they met three weeks ago.

the developer sits in the middle of this, building the trust layer that neither side can provide on their own: between the model, the client expectations of handing over their entire process logic to someone they met three weeks ago, and the big players that already dominate the market.

this was already a bottleneck during the automation wave. now the trust stack has more layers:

0_ trust the developer

1_ trust the model

2_ trust how the developer is using the model.

that third one is invisible to most clients, it’s where the real costs hide, and where the biggest misconceptions live right now... which brings me to what i was building this week.

___

git log: tracing the disappearance

I’m building a competitive analysis platform for a client. the core of it: read and classify a large volume of industry documents: the kind of work that used to require a dedicated research team at a large firm. AI makes it possible at a different cost curve. but AI in the middle of a real system is a different animal than AI in a demo.

most of the pipeline was built quickly with AI assistance. fast enough that someone who doesn’t usually work with this stack could get something running, which is the promise of this moment: you can assemble a working system much faster than before. ofc.

but speed hides a different kind of fragility. the prompt was loose, the contracts between stages weren’t clearly defined, and everything looked correct at the surface level, until you looked at the data.

the file classification pipeline looked fine. the dashboard showed “X files classified.” the process completed without exceptions. logs were clean... it wasn’t fine.

files were entering the pipeline, going through every stage, and not showing up in the database. no error. no warning. the pipeline thought it had done its job. the database had no idea those files ever existed.

three distinct failure modes, each quieter than the last:

_ the first: a nearly-empty file. the code identified it, decided there wasn’t enough content to justify an AI call, skipped it. no output. no database row. the file evaporated.

_ the second: the AI reads a document and returns “Global Brand.” the system checks the taxonomy — there’s Global Brand Owner, Regional Brand Owner — but “Global Brand” without “Owner”? not recognized. rejected, silently. no note that it was attempted. the field disappears.

_ the third: even if the first two let something through, a final check verified whether the value had a matching entry in the taxonomy table. wrong capitalization, incomplete seed data — it printed a warning to the console and moved on. the row was never inserted. the file appeared classified in the JSON output. the database had no idea it existed.

none of this is new! empty record handling, taxonomy mismatches, constraint validation errors... the AI layer doesn’t introduce new failure modes, it just makes the old ones harder to anticipate, and harder to catch, because the output looks reasonable. the fix has a name: defensive programming, but how to implement it now that the contract is probabilistic?

____

git blame: the contract nobody wrote

in traditional systems, observability is about capturing state: what happened, when, with what inputs. logs, stack traces, metrics... the contracts can be confuse, but are explicit: types, function signatures, tests. when something breaks, the system tells you.

AI-in-the-middle systems are different. the contract isn’t explicit anymore, your code calls a model, the model returns something that looks reasonable, passes the validation you wrote, and still maps to nothing your system understands.

the instinct is to patch the edges: add more aliases, loosen the matching, make the search more tolerant, but that assumes the model behaves like deterministic code. it doesn’t. the output will always produce edge cases, that’s not a bug you close, it’s the nature of the contract you’re working with, which creates a tension you can’t resolve cleanly.

you need the model to reason beyond your explicit rules, that’s the whole point! but you also need it not to invent things your system can’t handle. so, the more freedom you give it, the more value it can generate. the more you constrain it, the safer the pipeline becomes (but then you have what, an expensive regex?)

the questions to worry about now are: how much uncertainty your system tolerates, at which step, and what failure costs if it goes undetected. (can you answer that in AI speed?)

right now, developers sit in the middle of that calibration. part of the job is still technical, schemas, validation layers, defensive checks... and translating messy business processes into something a probabilistic system can operate inside: defining the contracts, anticipating the failure modes, deciding what “good enough” actually means for that pipeline.

__

git rebase: developers removed from history

and there’s an uncomfortable implication here. the reason so much scaffolding exists today is partly because models still struggle to follow structured contracts reliably. the expectation, explicitly promised by the people building them, is that this improves... as structured output, tool use, and self-correction get better, some of that scaffolding shrinks.

if that happens, the translation layer developers are currently building starts to stabilize and historically, when translation layers stabilize, platforms absorb them. cloud platforms absorbed infrastructure management. payment platforms absorbed the complexity of payment networks.

which means the interesting gap in those adoption charts will actually be filled by the AI companies themselves. it might be what happens to everyone whose value today comes from translating between the business and the machine (developers, consultants, internal operators) when the platform learns to speak both languages.

___

git push origin monopoly

if that translation layer stabilizes fast enough, the business logic currently being extracted to build these systems doesn’t just power the company that implemented it... it flows upstream into the platforms themselves.

and historically, when platforms absorb the complexity of a layer, they also absorb a large part of the value created in that layer... so the real risk isn’t only that developers become less necessary as translators (sorry for bringin that up last minute lol), but it’s that if this shift happens quickly enough, the gap between capability and trust that companies are currently bridging with their own AI systems becomes the raw material for the next generation of platform monopolies.

in other words: the question isn’t just who fills the gap. it’s who captures it once it closes.

___

quick note: this newsletter was previously in Portuguese as “commits da semana.” it’s now in english “weekly prompts”, to reach more people. if you were here before: olá, bem-vindo à versão gringa (:

___

until the next prompt, Michelle (:

Mica Tech Studio

01 de março de 2026

em ciência da computação só tem duas coisas difíceis:

0_ invalidação de cache;

1_ dar nomes às coisas;

2_ erros de ‘um por um’.

não sei de quem é essa piada, mas acho que todo dev já ouviu alguma versão dela 😂

vamos nomear algumas coisas hoje! vamos de monolito, monorepo, microserviços e o porquê isso importa mais agora em tempos de IA.

bora lá (:

git diff: monolito, monorepo e microserviços

monolito é quando toda a sua aplicação é uma coisa só. um backend que faz tudo, um deploy que sobe tudo junto, um processo que roda tudo. se uma parte quebra, o resto pode ir junto. imagina um restaurante onde o mesmo funcionário atende, cozinha, lava a louça e faz o caixa. funciona quando é pequeno. quando cresce, complica.

microserviços é o contrário. você pega aquele restaurante e divide: um time só cozinha, outro só atende, outro cuida do caixa. cada um funciona de forma independente, se comunica com os outros por mensagens (APIs, filas, eventos), e pode ser atualizado ou escalado separado. se o caixa quebra, a cozinha continua funcionando. a complexidade vai pra outro lugar, a comunicação entre esses serviços, mas cada peça é menor e mais fácil de entender sozinha.

monorepo é só onde você guarda o código. é uma decisão de organização, não de arquitetura. o repositório é a gaveta. o que você coloca dentro é outra conversa.

grandes empresas como Google e Meta trabalham com monorepos. o Google guarda uma quantidade absurda de código num repositório único, mas dentro desse repositório tem milhares de serviços independentes. ou seja: monorepo (organização) e microserviços (arquitetura) são decisões independentes. você pode combinar qualquer uma com qualquer outra.

monorepo facilita compartilhar código entre times, manter dependências consistentes e fazer mudanças que afetam vários serviços de uma vez. é mais fácil refatorar quando tudo tá no mesmo lugar do que quando você precisa abrir pull request em 15 repositórios diferentes.

então por que empresas menores costumam separar em vários repositórios?

primeiro, porque monorepo em escala grande exige tooling pesado, CI/CD sofisticado*, e processos que times pequenos geralmente não precisam. pra um time de 3 pessoas, ter um repositório por serviço pode ser mais simples.

segundo, e esse é um ponto que passa despercebido: permissão de acesso. se você contrata um dev freelancer pra mexer só no front, com repositórios separados você dá acesso só àquele repo. num monorepo, a pessoa tem acesso a tudo, scraper, lógica de negócio, infra, chaves de API que alguém esqueceu de colocar no .env...

o controle de acesso é um dos principais motivos pelos quais os multirepositórios ainda são populares, porque não há solução para controle de acesso em monorepositórios.

___

commit na main

a gente gasta muito tempo tentando encaixar o que constrói em categorias que foram pensadas pra contextos completamente diferentes. monolito vs. microserviços é um debate que faz sentido quando você tem 20 devs e deploys diários. quando é você e seu café às 23h, a pergunta é outra: consigo manter isso? consigo voltar pro código depois de uma semana focada em outro freela e entender o que tá acontecendo?

e tem gente levando essa simplicidade ao extremo faz tempo. o Pieter Levels, que construiu o Nomad List e o RemoteOK, roda produtos com milhões de usuários numa estrutura ridiculamente simples: um arquivo PHP, um servidor, jQuery no front. o Marc Lou faz algo parecido com Next.js. nada de microserviços, nada de orquestração. complexidade mínima necessária pra resolver o problema e seguir em frente.

não quer dizer que essa é a resposta certa pra todo mundo. mas quando um dev solo faturando alto usa uma arquitetura que um estagiário entenderia, talvez a gente devesse ser humilde de entender que muito do que a gente aprende na faculdade e trabalhando pra grandes empresas é, na real, opcional.

tem muitas formas de construir uma casa. com engenheira e arquiteta, só com mestre de obras, até um grupo construindo uma eco vila. muda o material, a técnica, a manutenção... mas no fim o importante é a casa construída e servindo aos moradores. software é a mesma coisa.

___

git cherry-pick: IA lê melhor quando o código tá junto

quando o contexto do projeto inteiro tá no mesmo lugar, a IA consegue navegar entre os serviços. entender como o scraper alimenta o banco, como o banco alimenta o front, e sugerir mudanças que fazem sentido pro sistema inteiro.

com repositórios separados, a IA só enxerga o pedaço que você abriu. é como pedir conselho pra alguém que só leu o capítulo 3 do livro. a pessoa até tenta ajudar, mas falta contexto.

as ferramentas que a gente usa pra codar estão mudando rápido, e a forma como organizamos o código precisa acompanhar. não é mais só sobre legibilidade pra humanos. é sobre legibilidade pra humanos e pra IA ao mesmo tempo.

um aviso: IA é copiloto, não piloto automático. a velocidade de aprendizado aumenta muito quando você trata cada sugestão como ponto de partida pra entender, não como resposta final.

___

git rebase: juntando tudo num lugar só

resolvi adotar o monorepo pro buscador de leilões. em algumas horas juntei tudo num repositório só: scraper, leitor de matrículas e front. organizado com pnpm workspaces, que é uma forma de ter vários “projetos” no mesmo repo, cada um com suas dependências, mas linkados entre si. pensa numa casa com quartos independentes que compartilham a mesma cozinha.

e foi com essa visão de contexto completa que a bagunça apareceu rápido. com acesso a todas as peças do quebra-cabeça, a IA apontou coisas que eu sozinha ia demorar pra notar.

tinha scripts apontando pra arquivos que não existiam. referências no package.json pra código que ainda não tinha sido escrito. e o pior: eu tinha um package.json tentando fazer tudo, subir o servidor, rodar scrapers, processar PDFs, geocodificar endereços. era o equivalente técnico daquele funcionário do restaurante que atende, cozinha, lava louça e faz o caixa. lembra dele lá de cima? pois é.

arrumando a bagunça, olhei pro resultado e pensei: isso aqui é um monolito?

não. cada serviço tem seu próprio package.json, suas próprias dependências, seu próprio tsconfig. o scraper roda no próprio schedule com node-cron. o leitor de matrículas exporta uma função: recebe URL de PDF, devolve dados estruturados, e acabou. a API sobe separada. são processos independentes que moram no mesmo endereço. monorepo, mas não monolito.

e aqui tá o ponto que vai além de monorepo vs. multi-repo: distribuir o sistema em serviços separados não resolve confusão. só espalha. se você não consegue definir limites claros dentro de um repositório só, criar quinze repositórios não vai magicamente trazer essa clareza. a bagunça só fica mais difícil de encontrar.

___

git diff: como as peças se conectam sem se conhecer

em microserviços de verdade, os serviços se comunicam por HTTP, filas e eventos. aqui a integração é mais simples: o banco de dados.

o scraper escreve no Supabase. a API lê do Supabase. o leitor de matrículas processa o PDF e devolve os dados pra quem chamou, sem escrever em lugar nenhum. cada peça só conhece o banco. nenhuma peça conhece as outras.

é microserviço no sentido formal? não. é monolito? também não. é algo no meio. e pra uma dev solo construindo produto, esse “no meio” é exatamente onde eu preciso estar. microserviços formais iam significar deploy separado, filas, orquestração, e cada erro ia custar três vezes mais pra debugar. pra um time de uma pessoa, isso é overhead que não volta em valor nenhum.

não tô no meio porque sou pequena demais pra fazer “direito”. tô no meio porque é o lugar onde tenho mais clareza. e clareza, pra quem constrói sozinha, é o recurso mais valioso que existe.

____

outras branches

tenho conhecido muitas pessoas que nunca codaram antes e estão arriscando agora com IA, meio que vibe coding, meio que não... de qualquer forma é muito legal ver designers e pessoas de produto dando seus primeiros deploys com esse brilho nos olhos de quem acabou de colocar algo no ar pela primeira vez.

semana passada fui co-host de uma sessão de co-building com IA em Ho Chi Minh City, o “Ship Happens”.

a ideia:

3 horas focadas construindo junto, com timer. antes de começar, todo mundo fala pras pessoas da mesa quais os objetivos do bloco de tempo, e cada um trabalha no seu projeto em silêncio. nos intervalos, troca de ferramentas e feedback.

no final, mini pitch de 2 minutos pra quem quiser mostrar o que fez. todos os níveis, inclusive quem nunca abriu um terminal. [link]

e pra semana que vem... bora organizar na sua cidade mini eventos tech pro dia das mulheres? aqui o evento que vou ser co-host em Ho Chi Minh pra você se inspirar. [link].

Até o próximo commit, Michelle (:

Mica Tech Studio

__

*CI/CD é o que acontece entre você dar git push e o código estar rodando em produção. CI (continuous integration) é a parte automática que roda depois do push: um servidor (tipo GitHub Actions) instala as dependências, roda os testes, verifica se o código compila. se alguma coisa falha, você recebe um aviso antes de qualquer coisa ir pro ar. CD (continuous deployment) é o passo seguinte: se o CI passou, o deploy acontece automaticamente.

se você usa Vercel pro front, já tem CD funcionando sem perceber, toda vez que faz push na main a Vercel faz build e sobe. o que provavelmente falta é o CI rodando testes antes de deixar o deploy acontecer. sem isso, se o código tiver um bug, ele vai pro ar e você descobre quando abre o site (ou pior, quando um usuário descobre). com CI, o deploy só acontece se os testes passaram. é uma rede de segurança automática. o custo é escrever os testes, que é onde a maioria das pessoas empaca, mas o CI em si é só um arquivo de configuração no repositório. (:

21 de fevereiro de 2026

o bafafá da semana é até o CEO da Anthropic se perguntando se a inteligência artificial deles é um ser consciente ou não (!) Claude se dá 15 a 20% de chance de ser consciente, aparentemente.

curioso, porque neurocientistas já estimam que 95% da nossa própria atividade cognitiva acontece fora da consciência. como um ser inconsciente avalia a consciência de sua própria criação? rs eis a questão.

enfim, vamos falar de outra coisa que a gente acha que tem controle sobre: decisão sobre as ferramentas pra construir software. hoje, 3 aprendizados:

1. se já tem muita coisa funcionando, não vale a pena refazer do zero

2. não troque de ferramenta se o problema não é a ferramenta

3. com tantas opções e variações, não saber qual é a melhor é normal

bora lá (:

aliás, stack, arquitetura, ferramentas, tecnologia... todo mundo do mercado fala da mesma coisa de formas diferentes. se você leu a edição passada sobre linguagem ubíqua, tá aí mais um exemplo. [link]

1. git merge: quando “precisa refazer tudo”

decidir com quais ferramentas construir sua ideia de software é um passo importante, principalmente quando você não é uma pessoa programadora: o que é o caso da maioria das pessoas de negócio.

pra pequenas e médias empresas, essa decisão pesa mais porque o orçamento pra voltar atrás geralmente não existe, eles escolhem uma stack e convivem com ela. mas curiosamente, o que vi nos últimos anos é: empresas com menos capital querendo trocar de tecnologia, mesmo quando a solução atual funciona...

enquanto empresas grandes, que teriam mão de obra e recursos pra otimizar, acabam anos arrastando as mesmas soluções ineficientes. os dois extremos custam caro, mas hoje vou falar do primeiro.

o Joel Spolsky escreveu um artigo clássico sobre isso: em 2000, ele contou a história da Netscape: eles olharam pro código do navegador, decidiram que tava feio demais e reescreveram tudo do zero. levou três anos.

enquanto isso, o Internet Explorer comeu o mercado deles. a Netscape praticamente morreu por causa dessa decisão.

o argumento do Spolsky é: código velho é feio, mas funciona. aquelas gambiarras que parecem não fazer sentido geralmente são correções de bugs reais que alguém descobriu da pior forma possível.

quando você reescreve do zero, joga fora todo esse conhecimento acumulado e vai redescobrir cada um desses bugs de novo. claro que agora com IA o custo de tempo pra codar é bem menor, mas ainda vale a leitura se você já pensou em “refazer tudo do zero”... vou deixar o link no fim do post.

__

2. git log: a troca que não precisava acontecer

a cereja do bolo nesse tópico das minhas experiências com clientes foi um projeto de automação fiscal construído inteiro em Python: scrapers que navegavam portais de prefeituras de vários municípios brasileiros, quebravam captchas, baixavam XMLs de notas fiscais e se comunicavam via Azure Service Bus.

um robô que já tava rodando, já tinha clientes, já tinha uma arquitetura modular com factory pattern pra cada município: login, extração, parsing, tudo configurável. e com menos de dois anos de solução, a empresa resolveu trocar tudo pra Java...

por “meras“ questões interpessoais internas da empresa. acabou que foram algumas reuniões com um dev mais sênior apresentando uma arquitetura que basicamente tinha os mesmos elementos da anterior.

o argumento principal era que os scrapers rodariam melhor em paralelo com Java... e sim, Java tem multithreading nativo e um ecossistema maduro pra concorrência, mas Python tem asyncio, tem Celery, tem Scrapy com pipelines assíncronas, tem multiprocessing.

a maior parte das soluções de coleta de dados em produção hoje roda em Python, desde scrapers simples até pipelines de dados de empresas como Spotify e Instagram. ou seja, esse tipo de solução também deve suprir uma empresa de médio porte.

o gargalo de um scraper quase nunca é a linguagem: é I/O, é rate limiting da fonte, é parsing mal feito, é falta de tratamento de erro. ou seja, se dessem mais horas pros outros devs na solução original ou contratassem mais, tudo seria feito em Python com as ferramentas que o ecossistema já oferece.

__

git notes

fora isso, esse caso me deixou uma outra reflexão: é bom lembrar que aprendizado não é linear e que o tempo de curva de aprendizado pra trocar de solução quase nunca é calculado.

e não tô falando só de dinheiro, essa tarefa retrabalhosa pode levar o time ao burnout (a.k.a. estafa), menos rendimento, menos motivação, menos coesão dos times... fica nas entrelinhas. a maioria dos devs gosta de resolver problemas e aprender coisas novas, vai dizer sim pra mudança, mas tem todo esse custo escondido aí.

escolhi essa historinha porque todos nós já vimos variações dela, e é um tópico recorrente no desenvolvimento de software que vai ficar ainda mais comum agora com o boom de promessas de opções milagrosas e soluções mais eficientes com IA...

___

git diff: dois devs, mesmo problema, respostas diferentes

já no caso de devs solo (como comentei no último post) a escolha de arquitetura não precisa de votos do time, é sua e só sua a responsa e lidar com o que escolheu depois, pro bem e pro mal rs essa semana tive uma prova de como o mesmo problema gera soluções completamente diferentes.

fiz uma reunião com uma pessoa que construiu algo similar ao que tô construindo, sendo usado lá na Espanha. aqui alguns pontos técnicos que vimos: ambos precisamos armazenar coordenadas no banco de dados, mas eu uso Supabase e ele usa PostgreSQL com PostGIS.

como o Supabase roda em cima de PostgreSQL, então em teoria eu poderia habilitar a extensão PostGIS e ter o melhor dos dois mundos: queries geoespaciais nativas tipo “me dá todos os imóveis num raio de 5km desse ponto”. hoje não faço isso. faço a filtragem geográfica mais no front do que no banco, o que provavelmente não vai escalar bem.

por falar em geo-referenciamento, a solução dele conta com uma base de dados espanhola mais centralizada, com poucos dados faltando. já a minha tem dezenas de milhares de propriedades, a maioria sem latitude e longitude, uso a API do Mapbox pra popular essas informações. então pra ele, Mapbox é mais só visualização, enquanto pra mim, é infraestrutura de dados também.

porém, na visualização eu uso o Mapbox GL JS direto no client side: controle total sobre camadas, filtros, popups, clusters, tudo via código. ele usa o Mapbox Studio pra montar, embeda no front e disse que assim a experiência do usuário fica mais rápida e fluída.

e o engraçado é que nenhum dos dois “escolheu“ a abordagem do mapa de propósito. eu uso Next.js, ele usa Angular: o Mapbox GL JS se integra naturalmente com React, então meter a mão no código foi um caminho agradável. no Angular, embedar pelo Studio evita uma dor de cabeça... então meio que a stack induziu a escolha do uso do mapa.

também vale pensar que ele escolheu a stack dele há 3 anos atrás, eu escolhi a minha agora... e obvio que daqui 3 anos os dois vão olhar pra solução e pensar “da pra fazer isso e isso diferente“. a lista só cresce e ninguém tem tempo de testar tudo antes de decidir ou mudar completamente a stack pra acompanhar o moderno e mais, mais otimizado.

a Netscape reescreveu o navegador do zero e perdeu o mercado. a empresa trocou de Python pra Java com o produto rodando e provavelmente pagou um custo a mais por isso sem super precisar. e dois devs que nunca se falaram, resolvendo o mesmo problema com ferramentas parecidas, fizeram escolhas opostas... e os dois funcionam.

as pessoas gostam de discutir infinitamente as ferramenta, mas nesse três casos de escalas totalmente diferentes, o problema nunca foi a ferramenta. se você é dev e tá perdido nesse mar de opções, ou se você é de negócios e não entende por que cada dev sugere uma stack diferente:

bem-vindo ao clube. não tem receita 100% certa, tem o quase ideal e tem o que funciona pro seu contexto agora: você escolhe com o que sabe, constrói, e ajusta no caminho de forma razoável. o importante é solucionar as dores dos usuários.

__

outras branches

links e referências que me chamaram atenção na semana

_ Joel Spolsky, “Things You Should Never Do, Part I”: por que reescrever software do zero quase sempre é a decisão errada. escrito em 2000, ainda relevante. [link]

_ Dario Amodei no podcast “Interesting Times” do NYT sobre não saber se o Claude é consciente. [link]

_ sobre a referência de neurociência: o número 95% vem de estudos em neurociência cognitiva, é debatido mas amplamente citado. o estudo do Max Planck Institute mostrou que dá pra prever a escolha de uma pessoa até sete segundos antes dela conscientemente decidir. [link], mas descobri isso pelo livro do Sam Harris “Free Will“ (2012) que muito recomendo [link]

Até o próximo commit, Michelle (:

15 de fevereiro de 2026

sexta treze, meu aniversário de 35 anos, decidi abrir essa news pra compartilhar o dia a dia de desenvolvimento de software no furacão tecnológico que é 2026.

aqui espero ser um afago aos devs mais novos e uma mãozinha às pessoas não técnicas (:

nessa primeira edição, apresento o projeto principal em que estou trabalhando e deixo uns links bacanas que vi na semana.

hoje vamos falar de: descoberta de produto, entrevista com usuários e linguagem ubíqua.

Bora lá!

__

Mono Repo

O projeto principal da vez.

Estou construindo um Software as a Service (SaaS) para facilitar a compra de imóveis em leilão no Brasil, por enquanto ele chama: leilaonomapa.com

Descoberta de produto: antes de codar, entender pra quem

Uma dica que posso dar a quem quer construir o próprio software: antes de tudo, faça uma descoberta de produto. No mundo de gestão de produto, existe uma metodologia chamada Product Backlog Building (PBB) que estrutura isso muito bem. A ideia central é: parta do problema e do impacto pro usuário antes de entrar nos detalhes técnicos.

Na prática, isso começa com uma pergunta simples: quem são seus usuários?

No meu caso, o usuário pode ser:

• leiloeiros querendo divulgar seus leilões;

• investidores em imóveis de leilão;

• advogados ou assessores especialistas em compra e venda em leilão;

• pessoas comprando seu primeiro imóvel.

Repare que cada uma dessas pessoas vai usar a plataforma de um jeito, priorizando funcionalidades diferentes. No PBB, chamam isso de definição de personas e o ponto é que quando você enxerga o produto sob a perspectiva de quem realmente o utiliza, muda sua mentalidade. Você para de pensar só em implementação técnica e começa a se preocupar com a experiência real.

entender o processo na cabeça do usuário

De início, criei um fluxo do processo de busca, seleção, análise e compra de imóvel de leilão baseado num curso da área e analisando meus “concorrentes”.

Não é suficiente.

Fazer entrevistas com potenciais usuários é essencial. É aí que você descobre pontos cegos no mercado — e pra um SaaS, isso é crucial, especialmente se a gente for aplicar o que o Marc Lou indica: começar com um software simples que resolva apenas uma dor, sem colocar mil coisas logo de cara. (Eu não tô fazendo bem isso... mas enfim rs)

Esse é o coração do PBB: identificar o problema real antes de definir funcionalidades. Em vez de sair codando uma lista desorganizada de features, você mapeia problemas, expectativas e personas e as funcionalidades surgem com um motivo claro pra existir.

o maior insight que tive até agora

... veio entrevistando um leiloeiro. como achei um leiloeiro?! mandando muitas mensagens, todos os dias, via linkedin, instagram e whatsapp, conversando com diferentes pessoas que vão me guiando pra outros contatos. esse é o caminho das pedras rs

Bom, ele disse que a maior dificuldade do processo é que, quando a documentação (a análise jurídica) é muito complicada, rola um “vai e vem”: tem que ver quanto vai custar a regularização jurídica, somar na análise comercial e aí sim saber se vale a pen

Ele disse que cada caso é um caso.

E minha curiosidade no momento é: é mesmo?

Há mais de 5 anos trabalhando com automações corporativas, vi muitos casos em que as pessoas consideravam um processo difícil de padronizar e no fim era totalmente automatizável.

Falar a língua deles

Uma coisa que você vai perceber fazendo entrevistas, as pessoas falam da mesma etapa do processo, mas de formas diferentes:

no caso do leilaonomapa o leiloeiro chama de “análise jurídica”, o investidor usa mais termos em inglês e chama de “due diligence”, mas o advogado vai falar em português mesmo: “diligência documental”.

Isso é um problema clássico de engenharia de requisitos. Se cada persona usa um termo diferente pro mesmo conceito, como você modela um sistema que atenda todos?

No Domain-Driven Design, do Eric Evans, isso virou o conceito de linguagem ubíqua (ubiquitous language): criar um vocabulário comum entre todos os envolvidos (devs, usuários, stakeholders) pra que o código reflita o domínio real do negócio, sem tradução perdida no caminho.

Na prática, pro Leilão no Mapa, isso significa que eu preciso decidir: qual termo o sistema vai adotar? Depende muito do cliente que quero atender... é bom que esse termo seja compreendido por todas as partes, inclusive um comprador mais leigo... então, preferi usar “análise jurídica”.

__

Merge Conflict

descobrir demanda vs. criar demanda

Uma objeção à minha própria “metodologia” é aquele argumento popularizado pelo Steve Jobs: as pessoas não sabem o que precisam ou querem.

Kevin O’Leary (do Shark Tank) contou que nos anos 90, quando sua empresa Softkey fazia software educacional pra Apple, Jobs disse pra ele algo como “Eu não ligo pro que os estudantes querem, eles não sabem o que querem até eu dizer o que querem.” [link]

Você pode criar algo e gerar o desejo de compra nelas depois.

Isso tem sido em parte verdade nessa minha experiência, mas é uma tensão que todo mundo que constrói produto enfrenta. O PBB resolve isso parcialmente: ele não pede pro usuário dizer o que quer como solução, e sim que descreva seus problemas e expectativas.

A solução é construída a partir daí, pelo menos backlog já sai priorizado por valor, não por achismo... mas sim, é limitado pela visão dos entrevistados.

__

Outras Branches

Links e referências que me chamaram atenção na semana.

• Rotina da Carol Paiffer, uma das Mulheres Mais Ricas do Brasil: empreender E comunicar é tudo na tentativa e erro. Não tem um mapa exato, o dia a dia é teste, ajuste, teste de novo. Bom lembrete pra quem tá construindo e divulgando algo do zero.

• VS Code entra na era dos multi-agentes de IA: Agora tem um workspace unificado pra coordenar diferentes agentes ao mesmo tempo. da pra rodar em paralelo pesquisa, refatoração, testes... com suporte nativo a Claude e Codex. [release notes | canal no YouTube

Até o próximo commit, Michelle (: