LLMs like Claude, Cursor, and GitHub Copilot are getting better at solving coding problems. But anyone who has ever written a business feature knows that the real challenge is not just writing the code. The code should follow your existing coding patterns, respect organization specific linting rules, use the right libraries, and fit into your architecture. So no matter how tempting it is for a developer to just copy paste the title and maybe description from the ticket in your favourite ticket management system its highly likely not going to produce code which is closer to the final version.

AWS has recently introduced the MCP server for AWS Serverless. You can read the official announcement here. I’ve been testing it using the latest MCP server with continue.dev plugin and Claude Sonnet 4 as the LLM backend. While the MCP server bundles a variety of tools, I want to focus on the three that stood out the most in my usage. 🔍 1. get_lambda_guidance-This tool helps determine if a given use case is suitable for AWS Lambda.

The Rise of the Agentic Web: From GenAI Applications to Inter-Agent Protocols The advent of Generative AI (GenAI) marked a significant shift in application development. Initially, we focused on building applications powered by large language models, enabling tasks like content generation, summarization, and code assistance. These applications were primarily monolithic, relying on single models to perform complex tasks. As the field matured, we recognized the limitations of this approach. Complex tasks often require a combination of skills and knowledge domains, which a single model might not efficiently handle.

AWS Lambda is an indispensable component of modern cloud architectures. Its serverless nature, low infrastructure requirements, and pay-as-you-go pricing have made it a cornerstone of production workloads. However, while the benefits of AWS Lambda are undeniable, it is crucial to be aware of certain considerations to ensure its successful implementation. Monolithic or Individual Lambda First choice we often faced with how much code should be there in one lambda. AWS best practice is against having a monolith lambda See here but if we separate out each functionality to separate lambda wouldn’t we end up in an explosion of lambdas?

Introduction AWS Lambda supports various runtimes like Java, Go, Python , Nodejs, but what if we like to use a language for which lambda doesn’t have a support? What if even for a supported language we want to use a version which is yet not supported by AWS Lambda? Lambda has support for custom runtime. Custom runtime provides an opportunity to define support for runtime which is yet to be supported out of the box.

Often a service needs to call Http endpoints , Feign comes from the OpenFeign project makes it easier to call http endpoints in a declarative fashion. Spring has openfeign integraton through its Spring Cloud OpenFeign integration. How To include feign clients The actual project for feign is OpenFeign https://github.com/OpenFeign/feign . Spring comes with it’s own starter . Add below dependency to the project <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> For an example let’s create a service named feign-serviceA which will call feign-serviceB .