DEV Community: Lucas Geovani Castro Brogni

I'm Halfway Through Udacity's AI-Powered Software Engineer Course — Here's What's Already Shifted

Lucas Geovani Castro Brogni — Fri, 20 Feb 2026 10:25:38 +0000

I've been a software engineer for over 10 years. I've done TDD, I know design patterns, and I've shipped production code in many setups. So when I enrolled in Udacity's AI-Powered Software Engineer Nanodegree, it wasn't because I felt like a beginner.

I enrolled because I felt like something was changing faster than I could keep up with, and I wanted a structured way to think about it.

I'm still in the middle of it. But two modules in, one thing has already stuck with me hard enough that I had to write it down.

What I Thought I Knew About TDD

I've been practicing Test-Driven Development and I thought I understood it. In fact, I did — in a world where I was the one writing the code. But then I added AI to the Loop. Here's what changes when you pair TDD with AI code generation: the speed of code production becomes almost violent.

You describe what you want. Claude writes a working implementation in seconds. It feels like productivity on steroids.

And that's exactly where the danger is.

When AI can generate code faster than you can review it, you lose something critical: the design conversation. Without tests in place first, you end up reviewing implementation details instead of guiding outcomes. You become a code reviewer of decisions you didn't make. The AI is driving. You're in the passenger seat, approving turns.

I believe TDD fixes this.

TDD with AI Isn't About Correctness Anymore. It's About Control.

The traditional argument for TDD is that tests catch bugs and force you to think about the API before you write implementation. That's still true. But with AI, there's a more fundamental reason to write tests first: Tests are the specification you hand to the AI. They define what you actually want.

When you write the test before asking the AI to implement anything, you're not just checking future behavior. You're designing it.

You're forcing yourself to answer: what should this do, in concrete, runnable terms? The AI then works within that contract. It can generate as fast as it wants, but it's generating toward your intention, not its own interpretation of your vague prompt.

Without that contract, you get code that works, but may not be the code you needed. And at AI speed, you can accumulate a lot of that before you notice the design has gone sideways.

What This Looks Like in Practice

Before the course reframed this for me, my AI workflow looked like:

Describe the feature to Claude
Review and tweak the generated code
Write tests afterward to lock in the behavior

It felt efficient. It was actually backwards.

Now it looks like:

Write the test that describes the behavior I want
Let the AI implement against that test
Refactor together — me on the design, AI on the implementation

The difference isn't just the process. It's about who's driving. In the first flow, AI is making design decisions, and I'm approving them. In the second, I'm making design decisions, and AI is executing them. That distinction matters enormously at scale.

For me, TDD isn't a safety net for bad code anymore. It's a steering wheel.

Where I'm At

I'm still working through the course. It will still have a module called "Vibe Engineering" that gives instructions on how to do better prompting and engineering oversight of AI output.

When I finish, I'll write a proper retrospective. But I didn't want to wait until the end to share this shift, because it's already impacting my day-to-day work.

If you're an engineer who's been "vibe coding" with AI and wondering why things feel slightly out of control, this might be why.

Testing in Serverless: TDD and Serverless at Scale

Lucas Geovani Castro Brogni — Sat, 14 Feb 2026 09:35:30 +0000

If you're building with serverless, you've probably already found yourself asking, "How am I supposed to properly test this thing?"

You're not alone.

Testing in serverless architectures is consistently one of the biggest pain points developers report, and for good reason. The event-driven nature of it all means your code doesn't run in a single, predictable place. Finding the right test infrastructure for that isn't just complex — it can feel like chasing a moving target.

But here's the thing: the problem usually isn't serverless itself. It's that most teams approach testing in serverless the same way they approached it in monoliths or traditional microservices — and then wonder why it doesn't quite fit.

Test-Driven Development changes that equation. Not because it's a silver bullet, but because it forces you to think about how your code behaves before you think about where it runs. And in serverless, that mindset shift makes all the difference.

In this article, we'll walk through why testing serverless is genuinely hard, what a serverless-native testing strategy looks like, and how TDD can give you back the confidence to ship fast — even at scale.

The Serverless Testing Paradox

Think about why you chose serverless in the first place. No servers to manage, automatic scaling, pay-per-use pricing — and most importantly, the promise that you can stop worrying about infrastructure and focus entirely on your business logic. It's supposed to make things simpler.

So it feels almost cruel that testing ends up being one of the hardest parts.

Here is the paradox: What makes serverless powerful is exactly what makes it tricky to test. In serverless, your application is stateless and ephemeral - it spins up, does its job, and disappears. That's great for scaling. But when you think about what you want in your test infrastructure, you need the exact opposite. It needs to be persistent, reproducible, and fast.

Sometimes, you will implement Lambdas that will communicate with many other AWS services. Perhaps your Lambda reads from S3, writes to DynamoDB, and triggers an SQS message. Replicating that chain locally means either mocking each dependency or spinning up cloud emulators with their own quirks and maintenance overhead.

Then there's the integration testing trap. When an event triggers your function, reproducing that trigger in a test isn't straightforward. In these cases, it's tempting to just deploy and test in the real environment, and this is the trap many serverless teams fall into: they end up with slow, expensive, flaky tests that erode trust in the test suite—and, gradually, developers stop running them.

Luckily, there's a way out. And it starts with rethinking where you test, not just how.

TDD: Your Serverless Development Foundation

If the problem is that serverless testing feels like it's fighting against you, TDD is the practice that puts you back in control.
Test-Driven Development isn't a new idea — but in the serverless world, it carries a different weight.

When your infrastructure is ephemeral, and your functions are small, focused units of logic, writing the test first isn't just good practice. It's the most natural way to design your code.

The core loop is simple: write a failing test, write the minimum code to make it pass, then clean it up. Red, green, refactor. You've probably heard it before.

By following TDD, you're essentially describing what your function should do before you worry about how AWS will run it.

Focusing on testing your business logic, you gain a superpower: your tests run locally in milliseconds, feedback is instant, cloud costs stay at zero, and flakiness from network calls simply disappears.

Let's make that concrete. Say you're building a Lambda that processes an order. The temptation is to think about the full solution right away. What DB are you connecting to? What's the trigger of the lambda? TDD asks you to ignore all of that for now. Start with the only thing that actually matters: what should this function do? Have the answer? Great, so let's just write a quick test for it

test('should calculate total for a valid order', async () => {
  const order = { id: '123', items: [{ price: 20 }, { price: 30 }] };
  const result = await processOrder(order);
  expect(result.success).toBe(true);
  expect(result.total).toBe(50);
});

After confirming your test is failing, write the minimum code to make that pass:

async function processOrder(order) {
  const total = order.items.reduce((sum, item) => sum + item.price, 0);
  return { success: true, total };
}

Notice what just happened. Without ever thinking about AWS, we've built and validated the core of our order processing logic. And better yet, we are sure it works because we just tested it in milliseconds. Everything else that is not part of our core can come later, as a separate concern. And when they do, you'll have a solid, well-tested foundation to build on top of.

But now you're probably thinking — "ok, that's great for the business logic. But what about the rest? What if the bug is in how I'm parsing the event? What if the item isn't actually being saved to DynamoDB? How do I test that without spinning up real AWS infrastructure?"

That's exactly the right question. And it's one that trips up a lot of serverless developers — because they treat testing as a single problem, when it's actually a few, all stacked on top of each other. Each layer of your Serverless architecture has different testing needs, tools, and a different cost-to-confidence trade-off.

That's what the Testing Pyramid is for.

The Testing Pyramid for Serverless

The Testing Pyramid isn't a new concept, but in serverless, it takes on a very specific meaning. The idea is simple: different layers of your application need different kinds of tests, and the higher you go — the closer to real AWS infrastructure — the slower, more expensive, and more brittle your tests become. So you want most of your tests at the bottom, and only a few at the top.

Unit Tests — the foundation

This is where we already are with processOrder. Pure business logic, no AWS, runs in milliseconds. These tests should make up the vast majority of your suite — they're cheap to write, cheap to run, and give you immediate feedback. Every business rule, every edge case, every validation — if it's logic, it belongs here. The goal is to cover as much of your application's behavior as possible before you ever touch a cloud service.

Integration Tests — the middle layer

This is where the handler comes in — and where most serverless developers feel lost. You need to verify that your Lambda correctly parses the event, calls your business logic, and interacts with AWS services in the right way. But you don't want to do that against real AWS infrastructure on every test run.

The answer is fakes. Not mocks — fakes. A mock just verifies that a method was called. A fake is a lightweight, working implementation that behaves like the real thing. Instead of hitting a real DynamoDB table, you inject a fake repository that stores orders in memory and responds exactly like DynamoDB would.

Your handler doesn't know the difference, and neither does your test. You get real confidence in the wiring without real infrastructure costs.

This is also where contract testing becomes valuable. In serverless, your functions rarely live in isolation — one Lambda triggers another, events flow between services, and schemas need to stay in sync.

Contract testing lets you verify that the event your order Lambda produces is exactly what the downstream fulfillment Lambda expects, without deploying either of them. If the contract breaks, you know before it reaches production.

End-to-End Tests — the tip

These are your full-stack smoke tests — real AWS, real events, real database. They're slow, they cost money, and they can fail for reasons completely outside your code. That's why you want very few of them, covering only your most critical user journeys. Think of them not as a safety net, but as a final sanity check before you ship. For our order processing example, this might be a single test that fires a real API Gateway request and verifies the order lands in DynamoDB.

The key insight is that by the time you reach this layer, you should already be confident in your logic and your wiring. E2E tests aren't there to find bugs — they're there to confirm that everything is connected correctly in a real environment. If you're relying on them to catch business logic errors, your pyramid is upside down.

Serverless at Scale: Where TDD Proves Its Worth

Now that we already looked at how to test serverless applications, you might still wonder if this would make sense to apply.
For that, you need to always check if the ROI is worth it. For doing it, I always think that it's worth looking at what some of the big names of our area have to say about it.

Kent Beck, in one of its books have said the following sentence:
"Most defects end up costing more than they would have cost to prevent them. Defects are expensive when they occur, both the direct costs of fixing the defects and the indirect costs because of damaged relationships, lost business, and lost development time." — Kent Beck, Extreme Programming Explained

A study by the IBM System Sciences Institute found that a bug fixed during the design phase is 100 times cheaper to resolve than the same bug found in production.

These numbers aren't abstract. In serverless, they hit harder than anywhere else.

In a traditional application, a bug in production affects the instances running at that moment. In serverless, that same bug gets executed once per invocation. At a hundred requests a day, that's manageable. At a million, it's a catastrophe playing out in parallel across your entire infrastructure before anyone has had a chance to notice.

This is where the compounding effect of TDD becomes undeniable. Every test you write early doesn't just prevent one bug — it prevents that bug from multiplying across every invocation, every downstream event it would have triggered, every user it would have affected.

The ROI of a single well-written test isn't fixed. It grows proportionally with your scale.

And it works the other way around too. As your application grows, so does its complexity. Every new function, means you're having more event sources, more service dependencies. Without a strong test foundation, every new feature becomes harder to add safely, because you never have full confidence that it won't break anything. With TDD, each new piece of logic arrives already understood, verified, and documented by its tests. The codebase stays navigable even as it scales.

I've seen this play out firsthand. At a company I worked with, a serverless service with no strong testing foundation had reached a point where a single project would take an engineer 3 weeks to complete — and then 6 weeks in QA and bug fixing. Double the development time, just to stabilise what had already been built.
As the team gradually increased test coverage and adopted a more disciplined approach, time to market improved, and something less obvious happened too: the codebase became safe to improve. Engineers could refactor, optimise, and think about quality as they finally had the confidence that they weren't going to break something in the process.

That's the real competitive advantage. Not just fewer bugs — but the ability to keep moving fast when most teams at your scale have already started slowing down.

The Competitive Advantage

Serverless gives you the power to scale without thinking about infrastructure. TDD gives you the confidence to scale without thinking about what might break. Together, they're not just a technical choice — they're a competitive one.

Teams that invest in testing early ship faster in the long run. They spend less time in QA, less time firefighting production incidents, and more time doing the work that actually moves the business forward.

You don't need to overhaul your entire codebase to get there. You don't need a company-wide initiative or a three-month refactoring project. You just need one function. Pick the Lambda that has caused the most pain recently. Write a test for it. Make it pass. Then write another. Once you start feeling the difference, it's very hard to go back.

The serverless ecosystem is only going to grow. The teams that will thrive in it aren't necessarily the ones with the most engineers or the biggest budgets. They're the ones that have built the discipline to move fast without breaking things — and TDD is how you build that discipline, one function at a time.

Sources & Further Reading

Beck, K., & Andres, C. (2004). Extreme Programming Explained: Embrace Change (2nd ed.). Addison-Wesley Professional. ISBN: 978-0-321-27865-4

IBM Systems Sciences Institute. Relative Cost of Fixing Defects by Phase. Referenced via ResearchGate: https://www.researchgate.net/figure/BM-System-Science-Institute-
Relative-Cost-of-Fixing-Defects_fig1_255965523

Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley Professional. — Kent Beck's dedicated book on TDD, a natural next read after this article.

Fowler, M. Test Pyramid — martinfowler.com/bliki/TestPyramid.html — The canonical reference for the testing pyramid concept applied to modern software architecture.

💬 Enjoyed the article? Let's keep the conversation going — find me on X at @brognilogs

Building an MCP Server on AWS Lambda: Complete Serverless Architecture Guide

Lucas Geovani Castro Brogni — Mon, 02 Feb 2026 16:53:36 +0000

Introduction

Over the past few months, I've been working on something that fundamentally changed how I think about building APIs: implementing the Model Context Protocol (MCP) on AWS Lambda. This isn't just another serverless project—it's about rethinking how we expose services to AI assistants.

In this post, I'll share the complete architecture, the challenges I faced, and the lessons learned while building a production-ready MCP server that enables AI assistants like Claude to interact with APIs in a better way—allowing humans to interact with the assistant without having to worry about what's behind it. Whether you're considering building your own MCP server or just curious about serverless architectures for AI-native interfaces, this guide is for you.

Why Build an MCP Server?

The Problem with Traditional APIs

Traditional REST APIs are designed for human developers. They have:

Complex authentication flows
Verbose request/response structures
Documentation that humans read and interpret
SDKs that wrap HTTP calls

But AI assistants don't need SDKs. They don't read documentation the same way we do. They need structured, predictable interfaces with clear schemas and consistent error handling.

Enter the Model Context Protocol

MCP is an open protocol created by Anthropic that standardizes how AI assistants communicate with external tools. Think of it as a universal adapter between AI models and your services.

Instead of teaching an AI to make HTTP calls and parse responses, you define tools with clear input schemas and let the AI invoke them directly:

// Traditional API approach
"Make a POST to /tasks with this JSON body,
 set the Authorization header, handle pagination..."

// MCP approach
"Call the create_task tool with title: "'Review PR #123'\""

The Motivation

We had a product with a REST API, and users were increasingly working through AI assistants. The question wasn't if we should support MCP, but how.

The business case wrote itself:

Meet users where they are: AI assistants are becoming the default interface for many workflows
Reduce integration friction: Instead of users learning our API, let the AI handle it
Enable new use cases: Natural language interactions open doors that traditional APIs can't

The technical benefits followed:

Standardize the interface: One protocol, multiple AI clients
Improve AI comprehension: Structured tools instead of raw HTTP
Enable natural language workflows: "Do X with Y" just works—the AI handles the complexity
Future-proof the integration: As MCP evolves, so does the server
Hide implementation details: Users don't need to know about endpoints, authentication, or payloads

A Concrete Example: Task Management API

To make this guide practical, I'll use a task management API as our running example throughout this post. Think of it as a simplified Trello or Asana API with endpoints for:

Creating, updating, and deleting tasks
Organizing tasks into projects
Assigning tasks to team members
Tracking task status and due dates

This is just one example. The same architecture and patterns apply equally well to:

E-commerce APIs (products, orders, inventory)
Content management systems (articles, media, categories)
Customer relationship management (contacts, deals, activities)
Analytics platforms (reports, dashboards, metrics)
Any REST API you want to expose to AI assistants

The beauty of MCP is that once you understand the pattern, you can apply it to any domain. The AI assistant doesn't care whether it's managing tasks, processing orders, or analyzing data—it just needs well-defined tools with clear schemas.

Why Serverless?

When designing the architecture, I had several options:

Traditional server (EC2, ECS)
Containerized service (Fargate, Kubernetes)
Serverless functions (Lambda)

I chose AWS Lambda for several compelling reasons:

1. Per-Request Billing Matches Usage Patterns

AI assistants don't make constant requests. Usage is bursty—sometimes hundreds of tool calls in a session, then nothing for hours. With Lambda:

Pay only for actual invocations
No idle compute costs
Automatic scaling from 0 to thousands of concurrent requests

2. Reduced Operational Complexity

Running an MCP server isn't my core business. I don't want to:

Manage server patches
Configure auto-scaling groups
Handle load balancer health checks
Monitor container orchestration

Lambda handles all of this automatically.

3. Natural Fit for Request-Response Workloads

MCP is fundamentally request-response:

AI sends a JSON-RPC request
Server processes it
Server returns a JSON-RPC response

This maps perfectly to Lambda's execution model. No websockets, no long-running connections—just clean, stateless request handling.

4. Built-in Integration with API Gateway

API Gateway provides:

Custom domain management
Request validation
Rate limiting
Authentication via Lambda authorizers
CloudWatch logging

This entire infrastructure is defined in a single serverless.yml file.

The Architecture

Here's the high-level architecture I implemented:

                                    ┌──────────────────┐
                                    │   AI Assistant   │
                                    │  (Claude, etc.)  │
                                    └────────┬─────────┘
                                             │
                                    HTTP POST /v1/mcp
                                             │
                                             ▼
┌────────────────────────────────────────────────────────────────────┐
│                         API Gateway                                 │
│  ┌─────────────────┐    ┌─────────────────┐    ┌────────────────┐ │
│  │ Custom Domain   │    │  Rate Limiting  │    │ Request Routing│ │
│  │ mcp.example.com │    │                 │    │                │ │
│  └─────────────────┘    └─────────────────┘    └────────────────┘ │
└────────────────────────────────┬───────────────────────────────────┘
                                 │
                        ┌────────▼────────┐
                        │ Lambda Authorizer│
                        │  (API Key Auth)  │
                        └────────┬─────────┘
                                 │
                                 ▼
┌────────────────────────────────────────────────────────────────────┐
│                      MCP Handler Lambda                             │
│  ┌──────────────┐   ┌──────────────┐   ┌────────────────────────┐ │
│  │ JSON-RPC     │   │ MCP Server   │   │ Tools (example)        │ │
│  │ Parser       │──▶│ Router       │──▶│ ├── create_task        │ │
│  │              │   │              │   │ ├── list_tasks         │ │
│  └──────────────┘   └──────────────┘   │ ├── update_task        │ │
│                                        │ ├── assign_task        │ │
│                                        │ └── get_project_stats  │ │
│                                        └────────────┬───────────┘ │
└─────────────────────────────────────────────────────┼──────────────┘
                                                      │
                                                      ▼
                                          ┌───────────────────┐
                                          │  Your Existing    │
                                          │    REST API       │
                                          └───────────────────┘

Key Components

1. Multiple Lambda Handlers

Instead of one monolithic handler, I split responsibilities:

Handler	Path	Purpose	Auth
MCP Handler	`POST /v1/mcp`	Main protocol handler	Required
Health Check	`GET /v1/health`	Monitoring/uptime	None
MCP Config	`GET /.well-known/mcp-config`	Schema discovery	None
Server Card	`GET /.well-known/mcp/server-card.json`	Server metadata	None

This separation allows independent scaling and simpler debugging.

2. External Lambda Authorizer

Instead of validating API keys in every request, I use a shared Lambda authorizer:

functions:
  mcp:
    handler: dist/index.handler
    events:
      - http:
          path: /v1/mcp
          method: post
          authorizer:
            type: request
            arn: ${env:AUTHORIZER_LAMBDA_ARN}
            resultTtlInSeconds: 0
            identitySource: method.request.header.apikey

This authorizer:

Validates API keys against my authentication service
Returns IAM policies for API Gateway
Can be shared across multiple services
Caches results (I disabled caching for immediate key revocation)

3. Tool Architecture

Each MCP tool follows a consistent pattern. Here's an example using our task management domain (remember, this same pattern works for any API):

// 1. Define the input schema with Zod
const CreateTaskInputSchema = z.object({
  title: z.string().min(1),
  description: z.string().optional(),
  project_id: z.string().optional(),
  assignee_id: z.string().optional(),
  due_date: z.string().datetime().optional(),
  priority: z.enum(['low', 'medium', 'high']).optional(),
});

// 2. Define the tool metadata
const createTaskToolDefinition: McpTool = {
  name: 'create_task',
  description: 'Create a new task in the task management system',
  inputSchema: zodToJsonSchema(CreateTaskInputSchema),
};

// 3. Create the handler factory (dependency injection)
function createTaskHandler(deps: Dependencies): ToolHandler {
  return async (input: unknown): Promise<ToolResult> => {
    const parsed = CreateTaskInputSchema.safeParse(input);
    if (!parsed.success) {
      return formatToolError('VALIDATION_ERROR', parsed.error.message);
    }

    const result = await deps.apiClient.tasks.create(parsed.data);

    if (!result.success) {
      return formatToolError(result.error.type, result.error.message);
    }

    return formatToolResponse(`Task created: ${result.data.title} (ID: ${result.data.id})`);
  };
}

This pattern provides:

Runtime validation via Zod
Type safety throughout
Testability via dependency injection
Consistent error handling

The Challenges

Building this wasn't without its difficulties. Here are the main challenges I faced:

1. Cold Start Latency

Lambda cold starts are the elephant in the room. For AI interactions, latency matters—users expect quick responses.

The Problem:

Node.js Lambda cold starts: 300-500ms typically
With dependencies (Zod, axios, etc.): 500-800ms
In a VPC: add another 200-500ms

My Solution:

Warmup Plugin: Pre-warms Lambdas every 5 minutes in production
Minimal Dependencies: Carefully audited imports
VPC Optimization: Used VPC endpoints where possible
Lazy Loading: Tools only load schemas when called

# serverless.yml
warmup:
  default:
    enabled:
      - prod
    events:
      - schedule: rate(5 minutes)
    concurrency: 1
    prewarm: true

2. Error Handling Across Layers

With MCP, errors can occur at multiple levels:

JSON-RPC parsing errors
Authentication failures
Tool validation errors
External API errors
Rate limiting

The Challenge: Each level has different error formats and expectations.

My Solution: A two-tier error handling strategy:

// Protocol-level errors → JSON-RPC error format
{
  "jsonrpc": "2.0",
  "error": {
    "code": -32600,
    "message": "Invalid Request"
  },
  "id": null
}

// Tool execution errors → Tool response format (better for AI)
{
  "jsonrpc": "2.0",
  "result": {
    "content": [{
      "type": "text",
      "text": "Error: Rate limit exceeded. Try again in 60 seconds."
    }]
  },
  "id": 1
}

The key insight: Tool errors should be returned as tool responses, not protocol errors. This way, the AI can understand and act on them appropriately.

3. Authentication Context Propagation

The Lambda authorizer validates API keys, but the MCP handler needs that key to make downstream API calls.

The Challenge: API Gateway doesn't automatically pass the API key to the Lambda function.

My Solution: Configure the authorizer to return the API key in the authorization context:

// Authorizer returns
{
  principalId: userId,
  context: {
    apiKey: validatedApiKey,
    accountId: accountId
  }
}

// Handler extracts
const apiKey = event.requestContext.authorizer?.apiKey
  ?? extractApiKeyFromHeaders(event.headers);

4. Testing Without Mocks

I follow a strict "no mocks" policy—no jest.fn() or jest.mock(). This forced me to build proper fakes:

// tests/__fakes__/api-client.fake.ts
// Example using task management domain - adapt to your domain
export function createFakeApiClient(): ApiClient {
  const tasks = new Map<string, Task>();

  return {
    tasks: {
      async create(input) {
        const task = { id: generateId(), status: 'pending', ...input };
        tasks.set(task.id, task);
        return { success: true, data: task };
      },
      async get(id) {
        const task = tasks.get(id);
        return task
          ? { success: true, data: task }
          : { success: false, error: { type: 'NOT_FOUND' } };
      }
    }
  };
}

This approach:

Tests real behavior, not implementation details
Catches bugs that mocks would hide
Makes tests more readable
Forces better interface design

5. Choosing an Infrastructure as Code Tool

For deploying Lambda functions, you have several IaC options:

Tool	Pros	Cons
Serverless Framework	Simple YAML config, great plugins ecosystem, fast to get started	Less control over fine-grained AWS resources
AWS SAM	Native AWS support, good for pure Lambda workloads	Smaller plugin ecosystem
AWS CDK	Full programming language, type safety, maximum flexibility	Steeper learning curve, more verbose
Terraform	Cloud-agnostic, mature ecosystem	More complex for Lambda-specific patterns

We went with Serverless Framework for its simplicity and plugin ecosystem. Tools like serverless-offline for local development and serverless-domain-manager for custom domains made the developer experience smooth. The entire infrastructure fits in a single serverless.yml file that's easy to read and modify.

That said, if you're already invested in CDK or Terraform, there's no strong reason to switch—the architecture patterns in this post apply regardless of your IaC choice.

The Benefits

After running this in production, here are the tangible benefits:

1. True Pay-Per-Use Economics

Lambda pricing is based on two factors:

Requests: Number of invocations
Compute time: GB-seconds (memory allocated × execution duration)

The key insight: keep your functions fast and right-sized. A 5ms function costs 100x less than a 500ms function doing the same work. MCP tools that just proxy to an existing API are naturally fast.

The free tier (1M requests + 400K GB-seconds monthly) covers most development and low-traffic production scenarios. Compare that to a traditional server sitting idle at $50+/month waiting for traffic.

Use the AWS Lambda Pricing Calculator to estimate costs for your specific configuration.

2. Operational Simplicity

Things I don't manage:

Server provisioning
OS patching
Load balancer configuration
Auto-scaling policies
Health check infrastructure

Things I do manage:

Business logic
Tool definitions
Error handling

3. Deployment Velocity

Deploying a new tool:

Write the tool handler
Register it in the tool index
npm run deploy:dev
Test
npm run deploy:prod

Total time: ~5 minutes for the deployment itself.

4. Observability for Free (Almost)

Lambda provides built-in:

CloudWatch Logs (automatic)
CloudWatch Metrics (invocations, errors, duration)
X-Ray tracing (optional)
API Gateway access logs

I added OpenTelemetry on top for distributed tracing, but the baseline is already useful.

5. Natural Disaster Recovery

Lambda functions are:

Deployed across multiple availability zones
Automatically retried on infrastructure failures
Stateless (easy to reason about)

No manual DR planning needed.

The Cons (Let's Be Honest)

No architecture is perfect. Here's what I'd do differently or what remains challenging:

1. Cold Starts Are Real

Despite warmup plugins, cold starts happen. When traffic spikes after idle periods, the first few requests are slow. For AI interactions where users expect sub-second responses, this can be jarring.

Mitigation: Provisioned Concurrency (but adds cost and complexity).

2. Debugging is Harder

When something fails in Lambda:

You can't SSH in
Logs are the only visibility
Reproducing issues requires understanding the exact event

Mitigation: Extensive structured logging and local testing with serverless-offline.

3. Vendor Lock-In

This architecture is deeply tied to AWS:

Lambda function handlers
API Gateway events
CloudWatch logging
IAM for authorization

Moving to GCP or Azure would require significant rewrites.

Mitigation: Keep business logic in pure functions, isolate AWS-specific code.

4. Costs Can Spike from Unexpected Places

Lambda is often the cheapest part of your bill. Watch out for:

API Gateway: Charges per request, can exceed Lambda costs at scale
CloudWatch Logs: Verbose logging adds up fast—log wisely
Retry loops: A bug causing infinite retries can burn budget in hours
Long-running functions: Cost scales linearly with duration—optimize slow tools

Mitigation: Set billing alerts from day one, implement rate limiting, and keep functions fast. Review your AWS Cost Explorer monthly to catch surprises early.

5. Complex Local Development

Testing locally with serverless-offline isn't the same as production:

Authorizers don't actually invoke
Cold starts don't happen
VPC networking differs

Mitigation: Deploy to a dev stage frequently, automate integration tests.

Tips for Building Your Own MCP Server on Lambda

Based on my experience, here are actionable tips. I'll continue using the task management example, but remember: replace "task" with your domain concept (product, order, article, contact, etc.) and the patterns remain exactly the same.

1. Start with the Tool Schema

Before writing any code, define your tool schemas:

// Define WHAT the tool does before HOW
// Example: task management (adapt to your domain)
const toolDefinition = {
  name: 'create_task',
  description: `Create a new task in the project.
    Returns the task ID and creation timestamp.
    Requires a title. Optionally accepts project_id, assignee, and due_date.`,
  inputSchema: {
    type: 'object',
    properties: {
      title: {
        type: 'string',
        description: 'The title of the task',
      },
      project_id: {
        type: 'string',
        description: 'The project to add this task to',
      },
      // ...
    },
    required: ['title'],
  },
};

The description matters—it's what the AI uses to understand when to call your tool.

2. Use Zod for Runtime Validation

TypeScript types vanish at runtime. Use Zod for actual validation:

// Example: validating task input (adapt schema to your domain)
const CreateTaskSchema = z.object({
  title: z.string().min(1, 'Title is required'),
  due_date: z.string().datetime().optional(),
  priority: z.enum(['low', 'medium', 'high']).default('medium'),
});

// In handler
const result = CreateTaskSchema.safeParse(input);
if (!result.success) {
  return formatToolError('VALIDATION_ERROR', result.error.message);
}

This catches bad input before it causes problems downstream.

3. Return AI-Friendly Error Messages

Don't return technical errors to the AI:

// Bad
return { error: 'ECONNREFUSED 127.0.0.1:5432' };

// Good
return formatToolError(
  'SERVICE_UNAVAILABLE',
  'Unable to create task. The service is temporarily unavailable. Please try again.'
);

The AI will relay this to the user—make it understandable.

4. Use Factory Functions for Dependency Injection

Avoid global state. Use factories:

// Don't do this
const apiClient = new ApiClient(process.env.API_KEY);

export function handleCreateTask(input) {
  return apiClient.tasks.create(input); // Hard to test!
}

// Do this
export function createTaskHandler(deps: { apiClient: ApiClient }) {
  return async function handleCreateTask(input) {
    return deps.apiClient.tasks.create(input); // Testable!
  };
}

5. Implement Graceful Degradation

When external services fail, handle it gracefully:

async function handleToolCall(tool: string, input: unknown) {
  try {
    const handler = tools.get(tool);
    if (!handler) {
      return formatToolError('UNKNOWN_TOOL', `Tool "${tool}" not found`);
    }

    const result = await handler(input);
    return result;
  } catch (error) {
    // Log the real error
    logger.error('Tool execution failed', { tool, error });

    // Return a user-friendly message
    return formatToolError(
      'INTERNAL_ERROR',
      'Something went wrong. Please try again.'
    );
  }
}

6. Add Structured Logging from Day One

You'll need it for debugging:

const logger = createLogger({
  service: 'mcp-server',
  level: process.env.LOG_LEVEL || 'info',
});

// In handler
logger.info('Tool invoked', {
  tool: toolName,
  input: sanitizeInput(input),
  requestId: context.awsRequestId,
});

7. Separate Protocol Handling from Business Logic

Keep the MCP protocol handling separate:

src/
├── index.ts          # Lambda handler (thin)
├── mcp/
│   ├── protocol.ts   # JSON-RPC parsing
│   └── server.ts     # MCP routing
└── tools/
    ├── tasks/                      # Example: task management
    │   ├── create-task.tool.ts
    │   ├── list-tasks.tool.ts
    │   └── update-task.tool.ts
    └── projects/                   # Group tools by domain concept
        └── get-project-stats.tool.ts

This makes testing easier and keeps concerns separated.

8. Test with Real AI Assistants Early

Don't wait until the end to test with actual AI:

Deploy to dev
Configure your AI assistant to use it
Try natural language requests
Iterate on tool descriptions

You'll discover that tool descriptions matter more than you think.

9. Implement Rate Limiting at Multiple Levels

Protect yourself:

API Gateway: Request throttling
Authorizer: Per-key rate limits
Tools: Per-operation limits

# serverless.yml
provider:
  apiGateway:
    throttle:
      burstLimit: 200
      rateLimit: 100

10. Monitor Cold Starts

Track them explicitly:

let isColdStart = true;

export async function handler(event, context) {
  if (isColdStart) {
    logger.info('Cold start', { requestId: context.awsRequestId });
    isColdStart = false;
  }
  // ...
}

Use this data to tune warmup settings.

Key Metrics After Running in Production

Here's what I'm seeing after some time:

Metric	Value
Average latency (warm)	~100ms
Average latency (cold)	~600ms
Cold start rate	<5% (with warmup)
Error rate	<0.1%

Conclusion

Building an MCP server on AWS Lambda has been a rewarding journey. The combination of:

MCP's standardized protocol for AI interactions
Lambda's serverless model for operational simplicity
Functional programming principles for maintainability

...creates an architecture that's both powerful and practical.

Is it perfect? No. Cold starts are annoying, debugging requires discipline, and you're locked into AWS. But for the use case of exposing your existing APIs to AI assistants—letting users interact naturally without worrying about the technical details—the benefits far outweigh the drawbacks.

The real magic happens when you see someone ask an AI assistant to "do something" and watch it seamlessly translate that into the right API calls. No documentation lookup, no curl commands, no debugging JSON payloads. Just natural conversation that gets things done.

If you're considering building your own MCP server, I hope this guide helps you avoid some of my early mistakes and gives you a solid foundation to build on.

Resources

Have questions or want to share your own MCP journey? Find me on X @brognilogs or drop a comment below.

Claude Code Will Be As Good As You Are

Lucas Geovani Castro Brogni — Fri, 21 Nov 2025 15:04:46 +0000

Over the past few months, I've been living in Claude Code. I'm talking about serious, production-level work—building new services, refactoring legacy systems, rebuilding our integration test infrastructure from scratch. If I'm being honest, over 80% of the code I've shipped in that time was generated by AI.

But here's what nobody tells you: AI-generated code isn't replacing my engineering skills. It's amplifying them. And more importantly, it's exposing every gap in my own thinking.

The code Claude produces will only be as good as the design you drive it toward. After months of experimentation—vibe coding, setting draconian rules, trying every configuration imaginable—I've learned that great AI-assisted development isn't about prompting harder. It's about thinking better.

The Journey: From Chaos to Clarity

When I first started with Claude Code, I did what most developers do: I described what I wanted and hoped for magic. Sometimes it worked. Often it didn't.

Then I went in the opposite direction. Every instruction was spelled out. The results were getting better, but my performance wasn't. I was spending sometimes more time rewriting prompts than it would take me to write the code.

At some point then, I realized that I was using Claude Code wrong and that the problem of the code not getting the results I expected soon was because Claude Code is actually just a tool that reflects what your design and architecture are.

In summary, I realized that if your design is bad, the code it will generate will be bad. If your principles are clear, the code will be clear.

Design First, Generate Second

Here's what changed everything for me: I stopped thinking about "getting AI to write good code" and started thinking about describing my design in the most clear way possible so anyone can understand - AI or Human.

In my CLAUDE.md, I now keep a section like this:
markdown

## Code Quality Principles

**Function Design:**
- Pure functions with no side effects whenever possible
- Max 20 lines per function (guideline, not law)
- Max 3-4 parameters - use objects for more complex inputs
- Names should read like sentences: `calculateUserSubscriptionStatus()` not `checkUser()`

**Testing Philosophy:**
- Test-Driven Development - write the test first, always
- Each test should validate one behavior
- Use descriptive test names that explain the "why": `should_return_null_when_user_has_expired_trial`


**CRITICAL: Never use mocks (jest.fn(), jest.mock(), etc.) in tests.**

Instead:
- **Unit tests**: Create **fakes** (in-memory implementations) in `tests/__fakes__/`
- **Integration tests**: Use **Testcontainers** for real dependencies

**Fake example:**

// tests/__fakes__/database.fake.ts
export function createFakeDatabase(): Database {
  const links = new Map<LinkId, Link>();

  return {
    async getLink(id: LinkId) {
      const link = links.get(id);
      return link
        ? { success: true, data: link }
        : { success: false, error: { type: 'NOT_FOUND', linkId: id } };
    },
    async saveLink(link: Link) {
      links.set(link.id, link);
      return { success: true, data: link };
    },
  };
}

But here's the crucial part: these aren't arbitrary rules.
They're my answer to 'what does good look like in practice.

When I say "pure functions with no side effects," I'm communicating that I value testability and predictability over clever stateful solutions.

When I enforce 20-line functions, I'm saying I value readability and single responsibility.

Claude Code doesn't just follow these rules—it internalizes the philosophy behind them.

The TDD Cycle with AI: Green, Reflect, Refactor

The most powerful pattern I've found combines Test-Driven Development with AI iteration.

It goes like this:

Write the test first (or have Claude write it based on your specification)

describe('MCP Server Authentication', () => {
  it('should reject requests without valid API keys', async () => {
    const request = createMockRequest({ apiKey: 'invalid' });
    const response = await handleMCPRequest(request);

    expect(response.status).toBe(401);
    expect(response.error).toContain('Invalid API key');
  });
});

Let Claude implement
Sometimes it nails it. Sometimes it doesn't. And here's the counterintuitive part: that's okay. If the test passes but the implementation feels wrong, you've learned something valuable.
Reflect before refactoring
When the output isn't what you expected, pause. Don't immediately ask for a rewrite. Ask yourself:

Was my architectural vision clear in the prompt? Did I provide enough context about existing patterns in the codebase? Are my guidelines actually contradictory? Did I specify what to build but forget why this feature exists?

Refactor with intention Now go back to Claude with clarity:

"The authentication logic works, but it's mixing concerns. Let's separate API key validation into its own pure function that returns a Result type. The handler should only orchestrate, not implement business logic."

The second iteration is almost always better—not because Claude "learned," but because you clarified your thinking.

Real Example: Test Infrastructure Rewrite

Let me give you a concrete example from my current work. I'm rewriting our integration tests—tests that have been running against actual production-like environments for years. These tests are slow (some take 5+ minutes), flaky (they fail randomly), and frankly, embarrassing. They're pure .js files with some functions and assertions thrown in. No real structure or patterns.

The complexity is real: we need authentication strategies that work in test environments, we need to mock AWS services (S3, SQS, DynamoDB), we need database state management, and we need all of this to be fast and reliable.

First attempt (vibe coding):

"Rewrite these integration tests to use Testcontainers and proper test architecture."

Claude generated... tests. They used Testcontainers. They had a setup and teardown. But they didn't even pass.
Some have failed because they couldn't authenticate.
Others failed because they didn't change the configuration and were trying to go on AWS instead of LocalStack, others were having cross dependencies with other tests and would be flaky - exactly the opposite of what we wanted to achieve.

Second attempt (after reflection):

I realized I was asking Claude to solve a design problem I hadn't solved myself. So I stepped back and documented the actual testing architecture:

## Integration Testing Principles

**Test Isolation:**
- Each test runs in its own Testcontainer instance
- Database state resets between tests using transactions
- No shared state between test cases
- Tests can run in parallel without conflicts

**Authentication Strategy:**
- Mock Authentication Service - We are focusing on the behaviour, not the authorization

**AWS Service Mocking:**
- LocalStack for S3, SQS, DynamoDB in containers
- One LocalStack instance per test file (isolated but fast)
- Test fixtures populate services in beforeAll
- Cleanup in afterAll, not in individual tests

**Test Structure:**
- Arrange: Set up test data using factory functions
- Act: Make actual HTTP requests to the service
- Assert: Verify both response and side effects (DB state, queue messages)
- Each test validates ONE behavior path

Then I prompted:

"Rewrite the links generation for tests following our integration testing principles. Use Testcontainers for MySQL, LocalStack for AWS Service. Show me the test structure for one complete test case."

The result? Fast, reliable, and actually maintainable.

Not because I prompted better, but because I designed better.

The better part? When I asked Claude to rewrite the next test file, it already understood the patterns. It knew the setup to follow.

The QA Multiplication Effect
Here's where this gets really interesting for teams. I'm on a 12-developer team with only 2 QAs company-wide. That's a bottleneck. My mission has been pushing toward 99% automated QA coverage.
Claude Code isn't just writing my application code—it's writing my test infrastructure. But only because I've been crystal clear about what quality means:

What This Means for Your Engineering Career

If you're worried that AI will make you obsolete, you're looking at it wrong. Claude Code isn't replacing engineers—it's raising the bar for what engineering means.

The skills that matter now:

System design thinking - Can you articulate how components should interact?
Architectural decision-making - Can you explain why this approach over that one?
Code review expertise - Can you spot the subtle bugs, the performance issues, the maintainability problems?
Quality standards definition - Can you define what "good" looks like for your domain?

These are senior-level skills. If you've been coasting on syntax knowledge and Stack Overflow copy-paste, yeah, you're in trouble. But if you're actually engineering—thinking about trade-offs, designing systems, setting quality standards—you've just gained a superpower.

The Uncomfortable Truth

Here's what I wish someone had told me when I started: Claude Code will ruthlessly expose the gaps in your own thinking.
If you can't explain your design clearly enough for an AI to implement it, you probably can't explain it to a human teammate either.

If your code quality standards are vague, Claude will produce vague code. If you don't actually understand the architectural patterns you're trying to use, the generated code will be architecturally confused.

This is uncomfortable. It's much easier to blame the tool. But it's also an incredible learning opportunity.

Every time Claude produces code that's "not quite right," you have a choice: get frustrated, or get curious. Why didn't it work? What was unclear? What assumption did I make that I didn't communicate?

Practical Advice: Start Small, Think Big

If you're just getting started with Claude Code:

Document your non-negotiables first
Before you generate a single line of code, write down your quality standards. What does "good code" mean in your context? Start with 5-10 core principles.
Use TDD as your safety net
Write tests first. Let Claude implement. If tests pass but code feels wrong, you've learned something about your specification.
Iterate in public
Share your CLAUDE.md files with your team. Debate them. Refine them. The best engineering standards are the ones the whole team understands and buys into.
Measure what matters
Track: test coverage, bug escape rate, time-to-production. Not: lines of code generated, prompts per day. Optimize for outcomes, not activity.
Embrace the reflection cycle
When output isn't what you wanted, resist the urge to immediately re-prompt. Take five minutes to understand why. Write it down. Update your guidelines. Then re-prompt.

The Future Is Already Here

We're in a weird transitional moment. Some developers are treating Claude Code like autocomplete++. Others are treating it like a junior developer to micromanage. Both are missing the point.

The developers who will thrive are the ones who realize this:
Claude Code isn't a replacement for engineering skills. It's a mirror that reflects the quality of your engineering thinking.

If your design is bad, your code will be bad. If your architecture is elegant, your code will be elegant. If your quality standards are high, your output will be high-quality.
Claude Code will be as good as you are.

Serverless Meets Zero Trust: Designing Secure Cloud-Native Apps from Day One

Lucas Geovani Castro Brogni — Mon, 02 Jun 2025 11:01:44 +0000

Serverless has grown exponentially in the last few years, and yet it is not done. In 2023, Datadog found that 70% of its customers who used AWS were adopting some serverless services.

While serverless is on the rise, it was identified by CrowdStrike in 2024 that the biggest security threat in modern applications is Cloud misconfiguration.

That is explained by the fact that as systems grow more complex and distributed, the risk of accidentally exposing resources or granting excessive permissions increases. In such a scenario, a more robust and proactive approach to security becomes critical.

In this article, to help address this challenge, I'd like to present the concept of "Zero Trust" and how to apply its principles to serverless applications from day one.

For the practical examples of this article, I am building a REST API for uploading and retrieving sensitive files. For achieving this, we are using the following tech stack:

AWS as cloud provider
Serverless Framework for orchestration
Resend for sending emails
Core components: Lambda, API Gateway, S3, IAM, CloudWatch
Serverless CI/CD

You can check the code on https://github.com/brognilucas/zero-trust-serverless-sample

What is Zero Trust?

Zero Trust is a security strategy based on the principle of "never trust, always verify."
This security framework assumes that threats can exist everywhere,
And thus nothing should be trusted by default, even if it is inside your own perimeter, in this case, inside the VPC of your cloud.

Before looking into it specifically for the serverless context, and cloud configuration problems is important to have a better understanding of the key tenets of zero trust.

Least privilege access:

One should never have more access than it needs to.

Continuous verification:

Ensure identity is checked before granting any type of access.

Assume breach:

Assume that no system is perfect and that sooner or later a breach will happen, and therefore always try to do your best to minimize the impact.

Strong identity:

Leverage multi-factor authentication (MFA) and context-aware policies whenever possible.

Applying Zero Trust to Serverless Applications

Applying ZERO trust architecture on the project requires as previously written, applying the following items:

Identity & Access Management

Always require authentication for actions to be performed. On the example of this project, for uploading a file, checking files that the user has, or for downloading a file, the authentication is required.

For login:
Our implementation had the structure of authorization via user & password + 6 digit code sent via email.

For protected routes: usage of JWT token

You can achieve such protection on serverless by applying the following structure on the configuration:

provider: 
  httpApi:
    authorizers:
      authorizer:
        type: request
        identitySource: "$request.header.Authorization"
        functionName: authorizer
        enableSimpleResponses: true


functions:
  authorizer:
    handler: auth/jwt-authorizer.handler

And the Lambda for authorization:

import jwt from 'jsonwebtoken';

export const handler = async (event) => {
  try {
    const token = event.headers.authorization.split(' ')[1];
    if (!token) {
      return {
        isAuthorized: false,
      };
    }
    const decoded = jwt.verify(token, process.env.JWT_SECRET);    
    return {
      isAuthorized: true,
      context: {
        email: decoded.email
      }
    };
  } catch (error) { 
    return {
      isAuthorized: false,
    };
  }
};

For this example, we didn't have any type of roles, as every user could make upload of their files, and only manage it's own files, but it would be possible for a second iteration to implement a ROLE based system, where some users could only see files, others would be able to put files, etc.

Implementing Least Privilege with IAM Roles

For this project, we used S3 Buckets and DynamoDB, and each Lambda would need access to some specific resources, but with different levels of privileges. An example is that the Lambda that can list the files should not have access to get or put files in the bucket.

Another example is that the Lambda that will authorize the user should not be able to insert or update the user table, but it obviously needs to get the user and create a new MFA code onto another table.

Such controls when building the IAM ROLE are created in the following spec:

functions: 
 signin:
    handler: auth/signin.handler
    events:
      - httpApi:
          path: /signin
          method: post
    role: SigninLambdaRole

resources:
  Resources:SigninLambdaRole:
      Type: AWS::IAM::Role
      Properties:
        RoleName: zero-trust-confidential-files-api-signin-lambda-role-${self:provider.stage}
        AssumeRolePolicyDocument:
          Version: "2012-10-17"
          Statement:
            - Effect: Allow
              Principal:
                Service:
                  - lambda.amazonaws.com
              Action:
                - sts:AssumeRole
        Policies:
          - PolicyName: SigninLambdaPolicy
            PolicyDocument:
              Version: "2012-10-17"
              Statement:
                - Effect: Allow
                  Action:
                    - dynamodb:GetItem
                  Resource:
                    - arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/Users-${self:provider.stage}
                - Effect: Allow
                  Action:
                    - dynamodb:PutItem
                  Resource:
                    - arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/MfaCodes-${self:provider.stage}

As it can be seen, no permissions that are not necessary are granted any of the resources.

Microsegmentation & Isolation

Microsegmentation is fundamental to Zero trust, where the idea is to divide the environment in small and isolated blocks, allowing that each block has its own scope of security. By following such approach, in case of a breach, the impact is limited.

In practical terms, for doing so in our project, we have achieved it by splitting the Lambdas by its own IAM role as shown in the previous example.

Other than that, such approach also helped us to achieve a few good software engineering practices, such as SRP (Single Responsibility Principle), while also facilitating logs auditing, faster and secure deployments, higher scalability, etc.

Observability & Auditing

Observability is another essential component of a Zero trust architecture, even further when thinking about serverless environments.
For our project, we are using CloudWatch to collect logs, and the serverless dashboard for understanding what is happening at all times. With it, we can always have ideas about the status of our application, understand patterns, and check for possible errors or security breaches.

Securing the CI/CD Pipeline

As you can imagine though, zero trust go beyond the security of the production application, but rather it also requires Zero trust for the deployments, and the code itself.

Therefore, the usage of proper configuration on your CI/CD, the usage of parameters, environment variables and limited access of such components are a MUST when implementing a zero trust architecture.

For this project, the parameters have been put on the serverless configuration, and injected onto the yml file by them.

provider:
  name: aws
  runtime: nodejs20.x
  stage: ${opt:stage, 'dev'}
  environment:
    RESEND_API_KEY: ${param:resendApiKey}
    JWT_SECRET: ${param:jwtSecret}
    EMAIL_FROM: ${param:emailFrom}
    S3_UPLOAD_BUCKET_NAME: ${param:s3UploadBucketName}-${self:provider.stage}

Best Practices and Common Pitfalls

When implementing Zero Trust architecture in serverless environments, it's fundamental to follow some best practices and be prepared to avoid some anti-patterns. Following such practices will help you to achieve a more secure, scalable, and maintainable system.

Following, I have listed some of the patterns that are recommended to build a secure serverless application:

Validate inputs and payloads
Use secret rotation
Use environment variables and parameters stored in a safe environment
Frequently monitor your application
Avoid the usage of wildcard permissions (*)
Avoid long-running functions or critical external dependencies without fallback mechanisms

Conclusion

The Zero Trust architecture has become essential for modern applications. In a situation where cloud and serverless are highly used, adopting Zero Trust means assuming that no component, user, or service is automatically trusted, and can represent a significant reduction in the risks of accidental exposures, unauthorized access, and even insider attacks.

Given that misconfiguration can and is the main reason for security breaches, following best practices, checking on your configuration, and using the right tools is the best way to help you unlock the benefits that serverless can provide.

Also, it's always important to remember that security does not end at the moment of deployment: it is an ongoing process that involves constant monitoring, detailed auditing, and frequent adjustments to respond to new threats and vulnerabilities.

For those who want to delve deeper into the subject, some recommended readings are the OWASP Serverless Top 10, which highlights the main risks specific to this model, and the official Serverless Framework documentation focused on security, in addition to other best practices recognized in the market.

Sources and inspired content:

https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf

https://www.datadoghq.com/state-of-serverless/

https://www.crowdstrike.com/en-us/cybersecurity-101/cloud-security/cloud-vulnerabilities/

https://www.youtube.com/watch?v=NBL-v984sc4

https://www.youtube.com/watch?v=WTJAjGKmAds

[Boost]

Lucas Geovani Castro Brogni — Sat, 17 May 2025 08:10:03 +0000

Lucas Geovani Castro Brogni

Jul 26 '24

My learnings as a temporary manager

#management #leadership

Comments

3 min read

What I've learned by building a fully serverless application

Lucas Geovani Castro Brogni — Fri, 16 May 2025 07:24:03 +0000

A few years back, while doing my masters in Software Architecture, I challenged myself to create a fully serverless application to be my graduation project.

The idea of that project was to check how a fully serverless application would look, and where it would stand when choosing an architecture for other projects.

For this project, I decided to go with a fairly simple but powerful set of tools: Serverless Framework, NodeJS, MongoDB running on Atlas, API Gateway for the endpoints, and AWS SNS for events. While the app itself centered around evaluating NFL draft prospects, the real learning came from designing and evolving the architecture.

The Good

1 - Faster time to market

With no need to manage infrastructure, you can build, iterate, and ship features faster. In a matter of days, I had a fairly functional MVP.

2 - Cost Efficiency

As this was an academic project, it was so good to see that in the end of the day, I was not spending any money on my infrastructure. But obviously, this is a huge advantage for companies as well, especially early-stage companies that are just building their product without having to worry about how much the bill will come at the end of the day.

3 - High availability

Serverless platforms are designed with fault tolerance and high availability out of the box. Your functions run across multiple availability zones, minimizing the risk of downtime.

4 - Built-in scalability

I didn’t have to think about scaling up or down at any point during the project. Whether there was one request or a thousand, AWS Lambda just handled it. That made the architecture feel robust and production-ready, even for an academic exercise. That's a massive advantage when you're building something with unpredictable or spiky workloads.

The Trade-offs

1 - Cold starts are real

In development, it’s easy to overlook cold starts, but in production, even for a small project, I could notice delays on initial invocations, especially for functions with more dependencies. It taught me to pay more attention to package sizes, lazy loading, and even runtime choices.

*2 - Testing and local development aren't straightforward *

Running everything locally with a full simulation of the cloud stack was difficult. I used tools like serverless-offline, but they only go so far. For testing, I had to think carefully about how I would approach it. At the end of the day, I was only able to have unit tests, as for integration tests, I would have to actually deploy the application, which would have slowed me down and decreased the feedback loop.

3 - Vendor lock-in

Using AWS services so heavily meant I was tightly coupled to that ecosystem. You are always able to move it to another cloud provider if that's something you want to do, but that would obviously require a good amount of rework.

Results

Overall, building this project was one of the most educational experiences I’ve had in terms of hands-on architecture.
It helped me move beyond theory and directly experience the practical pros and cons of serverless in a real-world system.

I could learn that Serverless is incredibly powerful, especially when you need to move fast, stay lean, and scale effortlessly. But as with everything else in software engineering, it has trade-offs.
In many cases, the best results come from combining serverless with other architectural patterns, as in that case, you can get the best of both worlds.

Doing TDD improved my DevExp

Lucas Geovani Castro Brogni — Fri, 02 May 2025 09:49:10 +0000

A long time ago, I had worked on a project that had no tests whatsoever. In fact, I was working in a team dedicated to fixing bugs, which was called the Support LVL 3 team. It was awful, could you imagine spending your whole days just getting bugs to fix and never creating anything new, and eventually getting a bug that you had fixed before again? Well, that was my reality.

After a few months there, I was already feeling, something was not right, and I had no idea how we could actually avoid such problems, and that was the moment I learned about automated testing.

Well, unfortunately, it wasn't in that project that I started applying it, at that moment, for many people that I worked with, there was a belief that tests would slow us down.

Shortly after leaving that company, I went to a place where I was incentivized to test my own code. It wasn't TDD yet, but it was some advance. I could finally stop seeing regressions, and would not have a team dedicated only to fixing bugs, which was awesome. I was still not producing my best code, though, and sometimes, I would write tests that were so broad that in case of a bug, I would still spend a few hours debugging to figure out where the error was.

A few years down the road, at a conference, I came across this talk about TDD, and then I got hooked.

The speaker wasn’t just talking about tests—he was talking about design, focus, and developer flow. He explained how writing tests first could lead to more modular, predictable, and clean code. It sounded almost too good to be true. But the examples were so simple, so intentional, that I left the room thinking: “Why haven’t I been doing this all along?”.

Well, when I first started applying, it looked somewhat less obvious.

I started playing with it on side projects, but I wasn't somehow getting the benefits. I would write this test, add the code, change the test, then be like, am I doing this wrong?

I saw some people use TDD and handle it with an elegance and speed that I could only assume was from some years of experience, while I felt like I was constantly tripping over myself. Wasn't this meant to speed up my work?

I even began to question everything, even as if maybe my first team was right - Tests maybe slow you down. What if this was all just theory that did not really work in the real-world development?

I decided to keep researching, though, and keep trying it out. During this research, I came across another incredible talk, "TDD, Where Did It All Go Wrong" by Ian Cooper.

That talk changed everything.

I finally understood what I was doing wrong. I was testing the code, not the behaviour I wanted to achieve. I was creating a highly tight coupled test of my implementation details. That’s why it felt painful. That’s why it wasn’t working.

Armed with that new perspective, I gave it another go. And this time, it was different.

I stopped trying to test everything. I focused on testing what mattered. I stopped coupling my tests to how the code was written and focused on what it should do. My tests became simpler. My code became more expressive.

And that is the reason I can say that applying TDD rightly improved my DevExp. After learning how to do it properly, I finally got the benefits everyone talked about. I started having fewer regressions, faster feedback, and having more time to do what I really like to do: build great software products.

If you are still figuring out what TDD is and if you should use it, that's ok, just keep practicing, because one day it will click, and when it does, it will be like pulling back a curtain to reveal a scene you didn't know was there.

MVVM on React: Why it might be the best solution for you?

Lucas Geovani Castro Brogni — Wed, 08 Jan 2025 12:13:34 +0000

In one of my recent experiences, you often would find components such as the example below:

import React, { useState, useEffect } from "react";
import { TodoApiImpl } from "../../TodoApi/TodoApi";
import './TodoOldStyle.css'
const api = new TodoApiImpl();
const TodoOldStyle = () => {
  const [todos, setTodos] = useState<any[]>([]);
  const [newTodoText, setNewTodoText] = useState("");

  useEffect(() => {
    const fetchTodos = async () => {
      const fetchedTodos = await api.getTodos();
      setTodos(fetchedTodos);
    };
    fetchTodos();
  }, []);

  const addTodo = async () => {
    if (!newTodoText.trim()) return;
    const newTodo = await api.addTodo(newTodoText);
    setTodos([...todos, newTodo]);
    setNewTodoText("");
  };

  const toggleTodo = async (id: number) => {
    const toggledTodo = await api.toggleTodo(id);
    setTodos(todos.map(todo => (todo.id === id ? toggledTodo : todo)));
  };

  const deleteTodo = async (id: number) => {
    await api.deleteTodo(id);
    setTodos(todos.filter(todo => todo.id !== id));
  };

  return (
    <div className="todo-container">
      <h1>Todo List</h1>
      <div className="todo-input">
        <input
          type="text"
          placeholder="Add a new todo"
          value={newTodoText}
          onChange={(e) => setNewTodoText(e.target.value)}
        />
        <button onClick={addTodo}>Add</button>
      </div>
      <ul className="todo-list">
        {todos.map((todo) => (
          <li key={todo.id} className={`todo-item ${todo.completed ? "completed" : ""}`}>
            <label>
              <input
                type="checkbox"
                checked={todo.completed}
                onChange={() => toggleTodo(todo.id)}
              />
              <span>{todo.text}</span>
            </label>
            <button className="delete-button" onClick={() => deleteTodo(todo.id)}>
              Delete
            </button>
          </li>
        ))}
      </ul>
    </div>
  );
};

export default TodoOldStyle;

That was making me really frustrated, as our code was not easy to test, the dev experience was not great, and the maintenance was starting to become a nightmare.

At that point, I started to look for alternatives, of how could we have a better code, improving the cohesion, coupling, and testability of our application, while also improving the Developer Experience.

The solution that I found? To start using MVVM.

What is MVVM?

If you're not familiar with MVVM (Model-View-ViewModel), it is an architectural pattern for frontend and mobile development that was created initially by John Gossman at Microsoft.
Its main objective is to provide a better separation of concerns, which then provides an increase in the cohesion, coupling, and testability of the applications.

This pattern breaks down the application into three key components:

Model: The data layer, that represents the application's core data and business logic. It is responsible for fetching, storing, and manipulating data.

View: The user interface, is responsible for presenting data to the user. It listens for user input and forwards events to the ViewModel.

ViewModel: The intermediary between the View and Model. It retrieves data from the Model, processes it, and exposes it to the View. The ViewModel also handles user interactions by updating the Model and instructing the View on updating the UI.

For a better understanding, using the same Todo Example, the application would then have, a model, a ViewModel, a View, and an Entrypoint for the application.

So how does that look like on the code:

Step 1: Define the Model

This Model, will eventually be injected over the view model, and would be injected over the view model and serve as the business logic + data manager.

// Todo/model/TodoModel.tsx. 

import { TodoApi } from "../../../TodoApi/TodoApi";

export interface ITodoModel {
  getTodos(): Promise<Todo[]>;
  addTodo(text: string): Promise<Todo>;
  toggleTodo(id: number): Promise<Todo>;
  deleteTodo(id: number): Promise<void>;
}

export default class TodoModel implements ITodoModel {
  constructor(private todoApi: TodoApi) {}

  async getTodos() {
    return await this.todoApi.getTodos();
  }

  async addTodo(text: string) {
    return await this.todoApi.addTodo(text);
  }

  async toggleTodo(id: number) {
    return await this.todoApi.toggleTodo(id);
  }

  async deleteTodo(id: number) {
    return await this.todoApi.deleteTodo(id);
  }
}

Step 2: Create the ViewModel

The ViewModel acts as the moderator between the View and the Model. For better testability, use DI pattern, allowing the Model to be injected over the ViewModel, and keep the state management here, so the View would only be responsible for rendering the UI.

// Todo/view-model/TodoViewModel.tsx. 

import { useEffect, useState } from "react";
import { Todo } from "../../../TodoApi/TodoApi";
import TodoModel from "../model/TodoModel";

export const useTodoViewModel = (model: ITodoModel) => {
  const [todos, setTodos] = useState<Todo[]>([]);
  const [newTodoText, setNewTodoText] = useState("");

  const fetchTodos = async () => {
    const fetchedTodos = await model.getTodos();
    setTodos(fetchedTodos);
  };

  const addTodo = async () => {
    if (!newTodoText.trim()) return;
    const newTodo = await model.addTodo(newTodoText);
    setTodos([...todos, newTodo]);
    setNewTodoText("");
  };

  const toggleTodo = async (id: number) => {
    const toggledTodo = await model.toggleTodo(id);
    setTodos(todos.map((todo) => (todo.id === id ? toggledTodo : todo)));
  };

  const deleteTodo = async (id: number) => {
    await model.deleteTodo(id);
    setTodos(todos.filter((todo) => todo.id !== id));
  };

  const onNewTodoTextChange = (text: string) => setNewTodoText(text);

  useEffect(() => {
    fetchTodos();
  }, [])


  return {
    todos,
    newTodoText,
    addTodo,
    toggleTodo,
    deleteTodo,
    fetchTodos,
    onNewTodoTextChange
  };
};

Step 3: Create the View

For the sake of simplicity, add todo, and list of todos are in the same component, but in an actual application, please divide it.

As stated before, the View should only receive the props and render it accordingly keeping the logic, and state management away of it.

// Todo/view/TodoView.tsx. 

import React from "react";
import "./TodoView.css";
import { Todo } from "../../../TodoApi/TodoApi";


interface TodoViewProps {
  todos: Todo[];
  toggleTodo: (id: number) => void;
  deleteTodo: (id: number) => void;
  addTodo: () => void;
  newTodoText: string;
  onNewTodoTextChange: (text: string) => void;
}

export const TodoView: React.FC<TodoViewProps> = ({
  todos,
  toggleTodo,
  deleteTodo,
  addTodo,
  onNewTodoTextChange,
  newTodoText,
}) => {
  return (
    <div className="todo-ctainer">
      <h1>Todo List</h1>
      <div className="todo-input">
        <input
          type="text"
          placeholder="Add a new todo"
          value={newTodoText}
          onChange={(e) => onNewTodoTextChange(e.target.value)}
        />
        <button onClick={addTodo}>Add</button>
      </div>
      <ul className="todo-list">
        {todos.map((todo) => (
          <li key={todo.id} className={`todo-item ${todo.completed ? "completed" : ""}`}>
            <label>
              <input
                type="checkbox"
                checked={todo.completed}
                onChange={() => toggleTodo(todo.id)}
              />
              <span>{todo.text}</span>
            </label>
            <button className="delete-button" data-testid={`delete-button-${todo.id}`} onClick={() => deleteTodo(todo.id)}>
              Delete
            </button>
          </li>
        ))}
      </ul>
    </div>
  );
};

Step 4: Orchestrate it all

Here that would be the component rendered via router, or imported over others.
This component, orchestrates the injection of the Model over the ViewModel, the API over the Model, and connects the model with the View.

// Todo/App.tsx. 

import { TodoApiImpl } from "../../TodoApi/TodoApi";
import TodoModel from "./model/TodoModel";
import { useTodoViewModel } from "./view-model/TodoViewModel";
import { TodoView } from "./view/TodoView";

const api = new TodoApiImpl();
const model = new TodoModel(api);

export const Todo = () => {
  const result = useTodoViewModel(model);

  return <TodoView {...result} />;
};

Conclusion

While the MVVM pattern adds complexity upfront, due to setting up the additional layers, the long-term benefits have a huge payback over the initial investment, as with this architecture, you achieve low coupling with high cohesion, separation of concerns, better testability, and maintainability.

It helps you to build scalable, testable, and maintainable applications that can evolve with ease.

Whether you're working on a small app or a large enterprise project, adopting patterns like MVVM will help you maintain a clean architecture and improve the overall development experience.

Removing code smells: Using dependency injection through Props in React

Lucas Geovani Castro Brogni — Tue, 26 Nov 2024 09:38:51 +0000

Have you ever got to jumped into a React application and looked at some components and thought it was so hard to test?

How could you do it, if it had the API client imported to the file, and the dependency was not managed by you?

Well, one can say you can use mocks, and that would solve the problem. Yes, at some level this is true, but on the other hand, your test becomes much more complex, and as the application grows it gets harder and harder to test.

Well, here comes a much better solution for it: Use dependency injection through the component properties.

If you don't know what dependency injection is then a quick definition:

Dependency Injection is a technique used to achieve Inversion of Control by passing (injecting) an object’s dependencies rather than having the object create them itself. The goal of DI is to decouple the creation of objects from their usage, making the system more modular, easier to test, and easier to maintain. DI can be done in various ways, such as constructor injection, setter injection, or interface injection, each providing different levels of flexibility and control.
-Robert C. Martin - Clean Code: A Handbook of Agile Software Craftsmanship

In react there are a few ways for achieving it, but the easiest and probably the cleaner is using the props to pass it.

~~You might want to use the context to avoid props drilling, but that's the subject of another article.~~

Ok, how to implement it then? Well, here comes the code.

Let's say you have a Todo application and want to fetch a list of Todos.

For that, you will implement an interface of the API so we not only use Dependency Injection, but also follow the Dependency Inversion principle.

// src/api/ITodoAPI.ts
export interface ITodoAPI {
  getTodos(): Promise<Todo[]>;
}

As we are using typescript, we are going to also declare, our Todo type.

// src/types.tsx
export type Todo = {
  id: number;
  title: string;
  completed: boolean;
}

With both interface and types defined, we can then implement our API Class. This is the place where your dependencies will land. If you want to use Axios, feel free to import it here, if you have another dependency, it does not have a problem to import, as this will be your Adapter for the outside world. Please note, that this class has no connection with the TodoList component whatsoever.

// src/api/TodoAPI.ts
import { ITodoAPI } from './ITodoAPI';
import { Todo } from '../types.tsx'; 
import * as axios from 'axios'; 

export class TodoAPI implements ITodoAPI {
  private URL = 'https://should-be-in-the-env.com';

  async getTodos(): Promise<Todo[]> {
    const result = await axios.get(`${this.URL}/todos`);
    return result.data;
  }
}

When you go the development of the component itself, the most important thing will be defining that your component will receive via Prop a todoAPI property with type of ITodoAPI so, it makes your component wait to receive the API and allows it to be used later.

// src/components/TodoList.tsx
import React from 'react';
import { ITodoAPI } from '../api/ITodoAPI';

interface TodoListProps {
  todo API: ITodoAPI;
}

const TodoList: React.FC<TodoListProps> = ({ todoAPI }) => {

  return (
    <></>
  );
})

With all the setup ready, then it's time for the actual implementation of the component.

// src/components/TodoList.tsx
import React, { useEffect, useState } from 'react';
import { ITodoAPI } from '../api/ITodoAPI';
import { Todo } from '../types'


interface TodoListProps {
  todoAPI: ITodoAPI;
}

const TodoList: React.FC<TodoListProps> = ({ todoAPI }) => {
  const [todos, setTodos] = useState<Todo[]>([]);

  useEffect(() => {
    const fetchTodos = async () => {
      const todos = await todoAPI.getTodos();
      setTodos(todos);
    };

    fetchTodos();
  }, [todoAPI]);

  return (
    <div>
      <h1>Todo List</h1>
      <ul>
        {todos.map((todo) => (
          <li key={todo.id}>
            <span>
              {todo.title}
            </span>
         </li>
        ))}
      </ul>
    </div>
  );
};

export default TodoList;

With this, we can now test our component in isolation of the application, without any dependency on jest.mocks or an actual API running. For that we can use a Fake implementation of the API.

describe('TodoList', () => {
  // Fake implementation of the ITodoAPI
  const fakeTodoAPI: ITodoAPI = {
    getTodos: async (): Promise<Todo[]> => [
      { id: 1, title: 'Test Todo 1', completed: false },
      { id: 2, title: 'Test Todo 2', completed: true },
    ]
  };

  it('should render a list of todos', async () => {
    render(<TodoList todoAPI={fakeTodoAPI} />);

    // Wait for todos to be fetched and displayed
    await waitFor(() => screen.getByText('Test Todo 1'));

    expect(screen.getByText('Test Todo 1')).toBeInTheDocument();
    expect(screen.getByText('Test Todo 2')).toBeInTheDocument();
  });
});

For using it on our application we can then on the root of the application pass the actual class for our component and it will work equally.

// src/App.tsx
import React from 'react';
import TodoList from './components/TodoList';
import { TodoAPI } from './api/TodoAPI';

const todoAPI = new TodoAPI();

function App() {
  return (
    <div className="App">
      <TodoList todoAPI={todoAPI} />
    </div>
  );
}

export default App;

Conclusion

By using dependency injection, we can easily swap between fake and real implementations of the API in our React components. This makes the component modular, testable, and easier to maintain. Whether you are testing your component with a fake API in isolation or using the real API in production, the code structure remains the same, making it adaptable and scalable for larger applications.

Hopefully, it has helped! Happy coding.

You are an amazing engineer. You may just haven't noticed yet.

Lucas Geovani Castro Brogni — Wed, 23 Oct 2024 15:20:30 +0000

Recently, I've been going through impostor syndrome. Obviously, that has put my mood down and decreased my productivity, as I was feeling incapable of doing good work or delivering high-quality value.

If you feel like this, here is an exercise that will help you get through it, just as it helped me.

Think for a couple of minutes about all the technologies, design patterns, databases, processes, and everything else you need to know to be an engineer. How could an impostor know all of this?

I'm pretty sure, your journey has been full of learning, adapting, and solving problems. No one stumbles upon this kind of skill set by accident. Each challenge you’ve faced has contributed to your growth. A true impostor wouldn’t be able to do as much as you did, nor keep the determination to continue learning more and more.

Now that you know you're amazing, here are some tips on how to transform this realization into positive work:

Celebrate small wins: Every task you complete, no matter how simple, is an achievement. Recognizing your daily successes helps you build confidence and stay motivated.

Focus on growth, not perfection: There is no such thing as perfection. You will commit mistakes, but those will help you to continue growing.

Set realistic goals: Break down your work into achievable steps. By having it, you can celebrate every time you achieve it, and your motivation will stay high throughout the process.

Seek feedback: Instead of guessing whether your work is good enough, ask for feedback from peers or mentors. Constructive criticism helps you grow and reinforces the fact that you're capable of delivering valuable work.

Reflect on past accomplishments: Take time to look back at projects you’ve completed successfully. Look back on all that you know. That will help you to reinforce to yourself that you're capable and that each new challenge is just another opportunity to learn and grow even more.

By keeping these practices in mind, you will be able to overcome the impostor syndrome and be a better engineer in the long run.

My learnings as a temporary manager

Lucas Geovani Castro Brogni — Fri, 26 Jul 2024 09:10:45 +0000

A few months ago, my manager went on maternity leave and chose me to replace her for 10 months until she'd be back.

I had no management experience or background, so it was surprising for both the other engineers and myself.

But as someone that embraces challenges, and loves to experience new stuff, I couldn't get more excited with the opportunity.

Bellow I list a few of my learnings.

It doesn't matter how good of an engineer you are, it doesn't mean you're going to be a good manager

I've been proud of being a good engineer for a while, and most of the feedback I have received has been positive for a few years in a row. Turns out that being a manager is much different than being an engineer, and that being good as an engineer doesn't mean you're going to be a good manager.

That was my case!

When I first started in her position, I was completely lost.

Previously, I used to know what my weekly challenges would be. However, when I transitioned into management, there was always something new popping up, and it usually revolved around people.

One example was that at a certain moment, there was quite a big conflict between an engineer and the PM. I had no idea how to deal with it.

Build trust ASAP

Nothing will help you more in the journey as a manager, than having the trust of your employees.

When I started, I was probably terrible, as I said before. But having created trust with the people, and making sure that they understood that I was there for them was what helped me the most.

By having their trust, and always being transparent with them, I could give feedback, learn their struggles, and fight for a better situation.

Don't keep hands-on, or at least not very often

I had to learn it in the worst way. When I initially transitioned to the EM position, I thought I would still have time to be hands-on. For a couple of months, I tried to do both, be an engineer, and be a manager. I learned that I was not doing well either.
Nor I did have time to focus on solving technical problems, nor did I pay careful attention to the people problem.
When transitioning to a people manager position, your focus needs to be the people.

You will become a better engineer by working a bit as a manager

Yes, that's right. Even if you will not be coding as much, or dealing as much with technical problems, you can be sure that by working as a manager, you will become a better engineer.

Being an engineer is much more than just focusing on the hard skills, and by becoming a manager, you will start taking deadlines more seriously, you will learn how to communicate better, have more empathy to deal with tough situations, and have more focus on what matters.

Management is not for everyone

If you are trying to be a manager or have read through it, it doesn't feel like the right fit for you, embrace the IC path. Both paths have their own unique challenges and rewards.

Focus on where your strengths and passions lie, and you'll find fulfillment and achievement in your career.