DEV Community: Mateus Medeiros

I didn't love coding. I loved building.

Mateus Medeiros — Sat, 03 Oct 2026 12:20:59 +0000

Modesty aside, I considered myself an excellent developer, and I imagine most people reading this do too. I cared about clean code, SOLID, architecture, performance, and all the supposed best practices we've studied over the past few decades. I was proud of putting something into production and watching people use it, something I'd made with my own hands. I saw myself as a craftsman: someone who read a diff the way others read prose and lost sleep over a badly named variable. Even if only 30% to 50% of my day was actually spent with VS Code open, it was, without a doubt, the best part of it. Picking good names for classes and functions, laying out a clean folder structure, solving an architectural problem by fitting in the right design pattern, finding the one line behind a production bug after an hour of digging.

I loved coding!

Or did I? At the end of the day, when I closed VS Code, did my satisfaction come from having written code, or from having solved a problem? Today I know the answer. But back when AI started writing the code, I didn't, and that gave me a few identity crises.

The sentence that slipped by

Let me go back to a sentence from above:

I was proud of putting something into production and watching people use it, something I'd made with my own hands.

That's it. That was the reward. Code was the means; the goal was always to solve a problem, to build something.

Think of a feature you spent weeks, or months, on before the AI era, and it got cancelled. Or worse: it shipped and nobody used it. How did that feel? Did the pride in well-named classes make up for it? If your answer is "no", or "only a little", then you, like me, are a builder.

Source code became a commodity

"Source code is a commodity." You've probably read that sentence dozens of times in recent months. And after the latest frontier models, it's hard to argue that code written entirely by AI is inherently worse than code written by a developer. In my experience, the inflection point was Opus 4.8; some will say it came a bit earlier, a bit later, or never. This post isn't about that debate, which is covered plenty elsewhere.

The point is a different one: code became a commodity, engineering didn't. Writing code was always just one part of the job, maybe a third of it. The rest is understanding the problem, deciding what's worth building, knowing it works, and keeping it running.

A pot of gold for builders

For people who build, the AI era is a pot of gold. I've lost count of how many shelved projects, blocked by the bottleneck of writing the code, I brought to life. Projects I'd never have had a chance of finishing before.

Astrodoro. One of my main hobbies is astrophotography. No software on the market fit my setup (a Mac plus a Dobsonian telescope), and the ones that covered part of my needs weren't cheap. So I built my own: with what was good in the existing tools, plus what I needed and couldn't find. It's a complex piece of software, with tracking, live stacking and camera SDK integration. I now use it at least twice a week on my observing nights.

Drawdoro. A whiteboard drawing tool in the spirit of Excalidraw. I've always liked whiteboards: sketching flows and diagrams before getting my hands dirty. Same story: options exist, but none had the set of features I wanted. Drawdoro has real-time collaboration, per-diagram documentation and an MCP server, so AI agents can read, comment on and edit diagrams alongside us. We also run an adapted version internally at my company, without paying for a SaaS license.

Engineering Pulse. An internal tool to manage all engineering metrics in one place: DORA metrics, team KPIs and KRs, and, beyond those, the people side, with PDIs and 1:1 tracking. What used to be scattered across spreadsheets, dashboards and loose notes now lives in a single system, built exactly the way our engineering works.

There are others. Astrodoro and Drawdoro are open source on my GitHub.

There's a satisfaction that's hard to explain in using, every day, a tool that didn't exist a few weeks ago and that I put into the world myself. Setting up the telescope, opening Astrodoro and watching the image form on the screen. Opening a diagram and seeing someone on the team drawing on it at the same time. Watching the team check Engineering Pulse without me asking. It's the same reward as always, just arriving much faster.

"But what about code quality?"

I have to admit: it's still hard for me to fully let go of the code being generated. But reviewing everything AI writes is impossible, and AI loves adding lines, not removing them.

What I'm learning to do is stop trusting the code and start trusting the pipeline. On every PR, before it reaches production:

Boot smoke test: the application actually starts and answers on /health and /ready.
import-linter: architecture contracts that AI can't violate without CI complaining.
mutmut (mutation testing): deliberately breaks the code to prove the tests actually test something.
Quality Report: a single comment per PR summarizing everything.

And, of course, the usual quality tools running alongside: ruff (lint and formatting), mypy (types), bandit (security), vulture (dead code, great against AI's tendency to only add) and xenon (cyclomatic complexity).

All of it lives in my template (py-awesome-template) and is inherited by each project. If an agent writes a thousand lines, the pipeline decides whether they get in.

All of this was fast. And that has a price.

The projects above became usable in days, some (like Drawdoro) in two nights. I've been refining them since: fast to first use is not the same as finished.

I think SaaS companies should start getting worried. Not only because competitors will appear (that will happen too), but because the more likely scenario is each company building its own version in-house, tailored to its taste, and no longer paying licenses for tools it only partly uses.

Here at my company, after Drawdoro, Engineering Pulse and other tools, we've already talked about having our own versions of bigger tools, like GitHub and Jira. Would we need a 1:1 clone? Of course not, and I'm not naive: even with AI, that would take months. The point is to build only what we use day to day.

The honest counterpoint: a tool you own is a tool you maintain, secure and document. If the one person who understands the system leaves the company, the gain turns into debt. Building got cheap; maintaining didn't.

Conclusion

Code is no longer the bottleneck. What remains, and always was the essential part, is knowing what's worth building and how to be sure it works. Maybe the market will need fewer developers in the near future, but it will keep needing builders.

I didn't lose the craft; I lost the middleman between the idea and the product. And I found out that what I loved was never the typing. It was seeing the problem solved, live, in someone's hands.

The Banking System Is Not Ready for AI-Powered Attacks

Mateus Medeiros — Tue, 21 Jul 2026 10:56:38 +0000

Over the past two months, I experienced three security incidents at the fintech where I work as a tech lead.

I won't go into which company it is, the exact amounts involved, or which partners failed. But I'll share what happened with the honesty of someone who was in the middle of the fire, and what it made me think about what's coming.

There's a silent pattern in mid-sized fintechs: engineering grows fast, the product is good, developers are skilled, and security keeps getting pushed to later. Not out of negligence, but because the cost of ignoring it feels abstract until the day it isn't.

How a Real Attack Actually Happens

The popular image of a hacker involves someone furiously typing in a black terminal, trying passwords until one works. Reality is far less cinematic, and far more unsettling.

Of the three incidents I experienced, none involved brute force.

In one of them, a partner of ours had their credential database leaked. The attacker arrived with a copy of the house keys, no need to break in. They managed to move a significant amount of money across accounts before we could stop them.

In another, it was pure social engineering. The attacker somehow obtained a client's credentials, logged in, realized they didn't have the transactional PIN, and opened a support ticket pretending to be the client, even sending a photo holding an ID document. Our support team processed the request. The phone number used was different from the one on file. Nobody noticed.

The weakest link in any system is always human. The best encryption in the world doesn't matter if someone answers the wrong phone call.

Why Our Current Defenses Aren't Enough

After each incident, we asked the right questions: what failed? what could have prevented this?

We reached some uncomfortable conclusions.

The government reversal mechanism doesn't work for this type of attack. Brazil has a special mechanism designed to trace and reverse fraudulent transactions. In theory, it's the financial system's shield against fraud. In practice, it takes days, weeks, sometimes months to act. A competent attacker pulverizes the stolen balance across dozens of mule accounts, which forward to others, which forward to others. Within hours, the trail is nearly untraceable. We filed the request more out of procedure than genuine hope of recovering the money.

Partners' fraud detection is too generic. Our banking partner blocked roughly half the amount transacted in one of the incidents. That helped, and I'm grateful, but the half that wasn't blocked was enough to cause real damage. The problem isn't partner incompetence: it's that a fraud system built to serve thousands of different clients tends to be conservative and generic. It doesn't know the specific transactional pattern of your business.

Condominiums, for example, have extremely predictable financial behavior. Payments happen in specific windows of the month, to corporate accounts, in amounts that follow a historical pattern. A transfer to an individual, outside business hours, above the historical amount for that account is trivially suspicious to someone who knows the domain. To a generic fraud system, it's just another transaction.

What Changes With AI

Recently, major AI labs announced they're working on models capable of autonomously finding vulnerabilities in software systems. There's obvious market interest in those statements, FOMO sells, but there's also genuine truth to them.

A human attacker has limits. They sleep. They make mistakes. They have a finite set of technical knowledge. They need time to analyze a system, identify attack surfaces, test hypotheses.

An AI-powered attacker has none of those limitations.

The speed of exploitation is going to shift by an order of magnitude. What today takes days of manual analysis could take minutes of automated scanning. And the systems that are exposed, APIs without IP validation, forgotten old endpoints still running on the internet, credentials that have never been rotated, are going to be found much faster than any security team can react.

I'm not speculating about a distant future. I'm describing the present with one new variable added.

What You Can Do Right Now

I'm not writing this to cause panic. I'm writing it because most effective defenses are relatively simple to implement, and most companies still haven't done them.

Eliminate long-lived exposed credentials. Production credentials shouldn't exist in .env files on developer machines or be injected as environment variables in Kubernetes pods. They should be fetched at runtime from a secrets manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault). The overhead is small. The gain is enormous.

Add mutual TLS (mTLS) to your B2B APIs. If you have an API that partners integrate with, mTLS is the proper long-term solution: both sides present certificates, so the connection is authenticated at the transport layer regardless of what's in the payload. IP allowlisting is a valid quick win (it's what we did after our incident, and it stopped the immediate bleeding), but it's not a substitute. IPs rotate, VPNs exist, and cloud-native architectures make stable IP ranges increasingly rare. mTLS doesn't have those weaknesses.

Build your own fraud detection, even if simple. You know the transactional behavior of your domain better than any partner does. Basic rules based on historical pattern, time of day, beneficiary type, and amount already capture most obvious anomalies.

Implement credential rotation. Credentials that never expire are credentials that may have been leaked years ago without your knowledge. A periodic rotation process, even semi-manual, drastically reduces the impact of a past breach.

Audit access for former employees. It sounds obvious. Most companies don't do it systematically. Make it a mandatory step in your offboarding process.

Define security protocols for your support team. Social engineering works because support teams prioritize resolving the customer's problem over verifying who the customer actually is. Write down what your team is and isn't allowed to change without additional verification, and what that verification looks like. A checklist isn't glamorous, but it closes the gap that cost us tens of thousands of dollars.

Monitor actively, not passively. Logs exist to be read. If you're discovering incidents because a client complained, you're already late. Invest in alerts, dashboards, and if possible, automation that catches anomalies before they become incidents.

A Question I Can't Stop Asking

I've thought about what would have happened if the attacker we faced had an AI on their side. Not for phishing at scale, but to systematically scan our APIs for unauthenticated endpoints. To test payload variations against our routes. To identify patterns in error responses that reveal internal structure. To do in minutes what took weeks of manual analysis.

The honest answer is: I don't know if we would have held.

And if that's true for us, with all the attention we've dedicated to security over these two months, it's true for the vast majority of fintechs operating today.

The ground is shifting. The question isn't whether you'll be attacked. It's whether you'll be ready when it happens.

If you've been through something similar or have a different perspective, I'd love to hear it in the comments.

I Turned Claude Code Into a Personal AI Butler That Runs My Life

Mateus Medeiros — Mon, 08 Jun 2026 13:21:13 +0000

Not another chatbot wrapper: a proactive assistant that runs on Claude Code headless, wired into my whole life through MCP.

Introduction

Most generic AI assistants are smart but forgetful. They know a lot about the world and nothing about you. Every conversation starts from scratch. Every question is answered generically. Ask them to help you plan your week and they'll give you a productivity framework from 2019.

I wanted something different. I wanted an assistant that knows I lead engineering at a fintech, that I'm working through a GTD backlog, that I've been putting off a specific task for three weeks, that I go to sleep around midnight, and that I absolutely hate soup for dinner.

So I built Jarvis.

This isn't a tutorial. It's a walkthrough of what I built, how I built it, and why the combination of context, MCP, and Claude Code changed how I think about personal tooling.

Part 1: What Jarvis Does

Let me give you a concrete example before I list anything.

Ten minutes before a call with my CTO, I hadn't opened Slack, hadn't reviewed my notes, hadn't done anything. Then, across the room, my Alexa spoke up in Jarvis's voice. It had pulled the last three technical decisions we had open, flagged an unread DM that was likely to come up, and surfaced something I'd written in my diary two days earlier that was directly relevant. I walked into that call better prepared than I would have been after an hour of manual review, and I hadn't asked for any of it. And it doesn't stop when the call ends: afterward, Jarvis reads back through the meeting, the calendar entry, the notes, what was discussed, picks out the loose ends that landed on me, and files them as tasks in my GTD. By the time I'm back at my desk, the follow-ups are already waiting, categorized and prioritized, without me writing a single one of them down.

That's what "useful" looks like in practice. Not "it can do X," but "it showed up before I even knew I needed it."

But "useful" is only half the story. The other half still catches me off guard: Jarvis improves itself.

A few weekends ago I was driving to the mall with my wife. I wanted to hand a couple of things off to Jarvis, but I wasn't about to type paragraphs into Telegram from behind the wheel, and at that point it only understood text. So, stopped at a red light, I told it to fix exactly that: add support for receiving voice messages on Telegram. It delegated the work to Claude Code, which branched, wired up the transcription pipeline, and opened a pull request. I merged it right there, still in the car, and my very next message to Jarvis was a voice note.

Read that back: I used the assistant to give the assistant a new way for me to use it. It didn't just run a task; it extended its own surface area, on request, while I kept my hands on the wheel.

Here's what makes that possible. Jarvis is connected, via MCP (Model Context Protocol), to everything I actually use:

Productivity & Work
Google Calendar, Gmail (two accounts: personal and professional), Google Drive and Docs, Slack. Full GTD task management with categories, priorities, due dates, and statuses. The assistant doesn't just read these; it can act on them, create events, search emails, list tasks by energy level, or find a document buried in a folder I haven't opened in months.

Personal life
A reading list, a games backlog, a watchlist for films and series, a link library. And the watchlist isn't just a place things sit: every Saturday evening, based on how my week went and what I've already watched, Jarvis suggests something new to add. A personal finance module connected to real bank data, not manual entries. A diary with structured entry types (personal, work, technical, idea, meeting, learning). And a shopping list, because even butlers deal with groceries.

Memory: the part that changes everything
Jarvis has two memory layers. Structured facts, the things I've explicitly told it to remember: my name, my wife's name, the football team I support, the birthdays that matter, the company I work for, and that I hate soup for dinner. And semantic memory, a Pinecone vector store that indexes conversations, diary entries, and patterns over time. Before answering anything contextual, it queries that store. When I mention "that infrastructure decision from last week," it knows what I mean. When I ask about someone by name, it already has context.

Automated Routines
This is where it stops feeling like a tool and starts feeling like an actual assistant. Jarvis has 31 scheduled routines running throughout the week. The ones that matter most:

Morning briefing: before I open anything, I already have the day: calendar, tasks, messages worth knowing, how my investments did overnight, and what's going on in the world. The day starts contextualized.
Pre-meeting briefing: what you just read above. Polls the calendar every 15 minutes, fires exactly once per meeting, 10 to 25 minutes before it starts.
Finance report: weekly summary of spending, investments, and outstanding debts. Finds me; I don't chase it.
Weekly review: once a week it walks my GTD with me, what moved, what stalled, what's been sitting in 'waiting' too long, and helps me reset for the week ahead.
Deadline alerts: tasks approaching their due date surface automatically.

The assistant also has a persona: a dry British wit that occasionally points out when you're repeating yourself. It's not neutral, and that's on purpose.

Part 2: How It's Built

The Stack

The backend is a FastAPI application on Python 3.14, running on a Compute Engine VM on GCP behind Nginx. Data lives in Google Cloud Datastore, a managed NoSQL document database.

MCP as the Integration Layer

MCP (Model Context Protocol) is what makes this scale without becoming a mess. Each domain is its own MCP server: Google Workspace, Slack, GTD, Finance, Diary, Memory, Alexa, and more. Twelve servers in total, exposing 35+ tools to the agent.

The agent stays clean. Adding a new integration means writing a new MCP server, not touching the orchestration logic.

Claude as the Brain

The agent is a Python runner, but it doesn't call the Anthropic API directly. Instead, it shells out to Claude Code running headless (claude -p), handing it the persona and system instructions, the MCP server config, and an allow-list of tools. Claude Code does the heavy lifting: it builds the context window, connects to every active MCP server, and drives the tool-calling loop. The runner just feeds it the user message and parses the structured JSON ({response, actions}) that streams back. The neat part: the same Claude Code that writes Jarvis's code is also the engine that runs it. The assistant doesn't just get built by an agent; it is one.

A Persona, On Purpose

Jarvis's personality lives in its own file, persona.md, kept deliberately separate from the operational instructions that tell the runner how to behave (output format, channel rules, when to delegate to Claude Code). The mechanics change often; the identity shouldn't. Splitting them means I can rewrite how Jarvis works without ever touching who Jarvis is, and the character stays consistent across every channel, whether it's answering on Telegram or speaking through an Echo.

And it's a real persona, not a one-line "be friendly and concise." It's a full character brief: an impeccable British butler who happens to run complex systems, dry wit by default, always first person, never the telemarketing enthusiasm of "Great question!" The file even ships with calibration examples so the tone stays sharp:

"Meeting tomorrow at 2pm. I've filed it under 'this time he actually shows up.'"

"The bug is on line 47. The real cause is an architecture decision from two weeks ago, but let's pretend we didn't see that for now."

That's the difference between an assistant that answers and one you'd actually want around. Generic is a choice, and I chose against it.

OpenAI as a Supporting Layer

While Claude drives conversations, OpenAI handles specific tasks: Whisper transcribes the voice messages I send over Telegram, and DALL-E 3 handles image generation (when I asked Jarvis what it thought it looked like, it drew its own self-portrait).

Channels

Telegram for async. The voice side started from a constraint I'd built for myself: I have six Echo devices around the house, one per room, and I wanted to actually put them to use, just not as Alexa. I wanted them to speak as Jarvis. So for voice, the pipeline goes: response text → ElevenLabs → custom audio file → Alexa device. Jarvis speaks in its own voice, not Amazon's default TTS.

But the proactive side is where it gets technically unusual.

Amazon's official Alexa Skills Kit is reactive: it waits to be called. If you want the assistant to speak up on its own, whether a morning briefing, a deadline alert, or a pre-meeting summary, the Skills Kit won't help you. So I reverse-engineered the internal Amazon API. It's undocumented. It's unofficial. Amazon could break it tomorrow. But it's the only path to an assistant with genuine initiative, and to me, that tradeoff was obvious. The fragility is a feature, not a bug: it means I had to care enough to go find it.

Semantic Memory

Conversations, diary entries, and pattern analyses get turned into vectors with OpenAI's text-embedding-3-small and upserted into a Pinecone index, each one tagged with a timestamp and type. Before responding to anything contextual, Jarvis embeds the incoming message and runs a top-k similarity search, pulling back the handful of past moments closest to what I'm asking about right now. A separate nightly routine does the heavier lifting: it reads back over the last day, distills behavioral patterns, and writes those summaries back into the same store, tagged as pattern_analysis, so the next morning's briefing can reference them. The result is what makes it feel continuous: not a chatbot that resets, but something that was paying attention yesterday too.

Routines via Cloud Scheduler

31 cron jobs, fired as HTTP calls from Cloud Scheduler to internal Nginx routes. Each job fetches context (diary, tasks, semantic memory, calendar, Slack), builds a prompt, calls Claude, and sends the result via Telegram or Alexa.

Built with Claude Code

Here's the part that still surprises me every time: I built almost all of this using Claude Code, Anthropic's agentic coding tool that runs in the terminal.

The workflow: I describe what I want, Claude Code creates a branch, implements it, commits, and opens a PR. I review and merge. For most features, I never write a line of code manually. The agent understands the codebase, follows the established patterns, and usually makes the call I would have.

This creates a feedback loop that's genuinely strange to describe. The assistant I'm building is also my development partner. When I ask Jarvis via Telegram to add a feature, it delegates to Claude Code, which opens a PR. The system extends itself.

What It Costs to Run

I expected a system this involved to be expensive. It isn't.

Claude, the brain: $20/month. Jarvis runs on a Claude Pro subscription through Claude Code, not the metered API, so there's no per-token bill no matter how much I talk to it. It even routes models by task: Haiku for everyday conversation, Opus when it's writing code.
GCE e2-small VM: ~$13/month. A single small Compute Engine instance hosts the whole backend.
ElevenLabs voice: $6/month on the Starter plan, and even that is optional: there are free TTS options if you don't mind dropping the custom voice.
OpenAI (Whisper, DALL·E, embeddings): under $2/month. Usage is low and these are cheap per call.
Pinecone, Pluggy, and the rest of GCP (Datastore, Cloud Scheduler): $0. All comfortably inside their free tiers.

All in, Jarvis runs for around $40 a month, and the single biggest line item is a consumer Claude subscription I'd probably be paying for anyway. The part that should feel expensive, the always-on intelligence, is the part that's basically flat-rate, precisely because it runs on Claude Code instead of billing me by the token.

What Makes It Actually Useful

The gap between "AI assistant" and "useful AI assistant" is almost entirely context. Generic assistants are impressive in demos and mediocre in practice because they have no idea who you are.

What made Jarvis cross that gap:

Deep integrations: not API wrappers, but MCP tools with real access and real schemas
Persistent memory: facts you tell it and patterns it finds on its own
Proactive outputs: it shows up, it doesn't just respond
A persona with opinions: less tool, more collaborator

It's not perfect. MCP servers disconnect. Prompts drift. Occasionally it contradicts something from last week. But it's useful in a way that no off-the-shelf assistant has been, and at this point, I'd notice if it disappeared.