Gustavo Cid

Hone the craft. Dial up the quality. Detach from the results. Collect clues. Decades, not months.

Christmas came early! Four from @stripepress and one that if they republished, I would buy again (👀@tamarawinter)

Tried printing reports with detailed instructions before coding but didn't like it. Claude code's solution was not great in the first iteration, but I only noticed it after printing, so I felt bad for wasting time (and a lot of paper.) Will keep iterating, though.

Actually really like this idea: x.com/geoffreylitt/s…

When I read "The Mythical Man-Month," the idea of a "software surgeon" stuck with me and I think about it periodically. I really enjoyed reading @geoffreylitt's "Code like a surgeon". I want to experiment with more things along these lines geoffreylitt.com/2025/10/24/cod…

Code for `db-migrate-helper`: github.com/gustavocidorne…

The tool is super simple and tailored to my Flask/Alembic my setup, but I learned some interesting things about CLI tools along the way. Some great resources: - Command line interface guidelines: clig.dev - How Claude code is built: newsletter.pragmaticengineer.com/p/how-claude-c… For next steps, I'll probably try to make the tool handle rebases, when the migration files might need to be rewired.

Fun little weekend project: a CLI tool that helps with db migrations between feature branches I'm often switching between feature branches that involve db migrations. Managing the state of my local db in these cases is annoying, so I built the tool to handle that for me. Behind the scenes, it constructs the migration chains in both branches, finds the common ancestor, and gives me (or runs) the commands I need to downgrade/upgrade my local db.

Mês que vem, completo 4 anos no Openlayer. Aproveitei o feriado para refletir sobre algumas das lições que aprendi até aqui: cgustavo.substack.com/p/licoes-de-4-…

We were tired of manually writing git commits for @linear issues. So I built a @raycast extension. Simply copy the Linear issue ID → hit your hotkey → paste the commit message. That's it! Why build it? We love how you can link Git commits to @linear issues. However, doing this while also following other best practices (like Conventional Commits) made writing commit messages painful. For example, for a Linear issue with ID 'ENG-123' and title 'Some bug', we'd have to: 1. Type the commit type ('fix') 2. Copy the Linear issue ID from Linear 3. Paste it with 'closes' (or some other magic word) → 'fix(closes ENG-123):' 4. Copy the Linear issue title from Linear 5. Paste it → 'fix(closes ENG-123): Some bug' 6. Lowercase the first letter → 'fix(closes ENG-123): some bug' We'd bounce between Linear and Terminal 3+ times, copying/pasting/editing until we got it right. The team was rightfully complaining that the process was annoying. We even considered changing how we name Linear issues to minimize the number of edits. That's why I built the @raycast extension! Behind the scenes, the extension fetches the Linear issue with the specified ID using Linear's API and constructs the full commit command. The conventional commit type ('fix', 'chore', 'docs', etc.) is inferred from the Linear issue label. The extension is private to the @openlayerco org, because it follows our commit message formatting, but hopefully you can build your own version of this!

I'll be in SF for the @databricks Data + AI Summit. Hit me up if you're around and want to grab a coffee! x.com/openlayerco/st…

If you know, you know

Congrats to the team @openlayerco on their $14.5M Series A! Built for enterprise teams deploying everything from traditional ML to Generative AI, Openlayer helps organizations test, monitor, and govern their AI systems with confidence. openlayer.com/blog/post/seri…

Grateful for where we are, even more excited for where we’re going. Proud of the team and what we’re building @openlayerco — this is just the beginning!

Yeah! Tbh, day-to-day, I'm not using (at least as far as I'm aware) any MCP server. However, I don't think this goes against my belief that MCPs are great (and potentially game-changing.) I believe that very soon, MCPs will be an "implementation detail" that, in most cases, will be hidden from the user. Talking about Openlayer MCP specifically: it's nice that you can use the MCP on Cursor. However, (imo) what's waaay nicer is that now, if we want to build an agent on our backend that does stuff for the user on the platform, we have an easy way to expose features and info to that agent. The Openlayer MCP is a "toolbox" that agents can use to see and do stuff on Openlayer. If we decide to implement this agent, our users don't need to know the specifics of the agent or whether it's leveraging MCP or something else. They mostly care about the end-result, the magic experience of accomplishing something useful. Right now, I feel like people are overindexing on the details. MCP is allowing us to easily define these "digital environments" that agents can interact with.

@_cgustavo You shipped MCP support for OpenLayer right? What are you personally most using MCP for?

It's hard to believe MCP launched 5 months ago. The number of open-source servers is staggering. But I wonder if end-user adoption is equally strong...

@feliparagao 🖐️

Side note: who are all these people building/using MCP? Most of my friends in tech are not.

The sources are my favorite part of OpenAI's deep research mode. Sometimes, I find hidden gems. E.g., just stumbled upon Lil'Log (by @lilianweng)

bug bashing my way to peace of mind

@feliparagao Definitely relate. Curious to see what you come up with!

This first week I'll be working on AI tools to help me tweet more 🫙 For years I've been sleeping on Twitter as a way to meet interesting people. I lurk here every day but never post anything. Lots of reasons for that, but the first to tackle is perfectionism. Even when I have something to say, I can't settle on a way to say it. Every way feels cringe Don't know how to solve that yet...