DEV Community: abdullah haroon

Building DreamCanvas: An AI Agent That Imagines a New World Every Day | 10 Days of Building AI Agents on AWS | Day 10

abdullah haroon — Tue, 01 Sep 2026 03:24:00 +0000

Building DreamCanvas: An AI Agent That Imagines a New World Every Day

10 Days of Building AI Agents on AWS | Day 10

Tag: #agents

DreamCanvas is an always-on AI creative agent that imagines a new fictional world every day before you even open the app.

Vision: Creativity That Does Not Wait

Most creative applications wait for a user to open them, enter a prompt, and request something new.

I wanted to explore a different idea:

What if a creative application could continue creating even when nobody was actively using it?

That idea became DreamCanvas.

DreamCanvas is an autonomous AI creative agent that generates a brand-new fictional world every day.

Instead of opening an application and asking an AI to imagine something, the user can return later and discover that a completely new world has already been created.

The experience is simple:

You leave → DreamCanvas keeps working → You return → A new world is waiting

The goal was to create an experience where inspiration is already waiting.

What Does DreamCanvas Create?

Each generated world has its own identity and creative details.

A world can include:

Unique world name
Genre
Atmosphere
Tagline
World overview
Environment
Inhabitants
A special rule of the universe
Main conflict
A surprising discovery
A story seed that could become the beginning of a larger story

This means DreamCanvas does not simply generate a short idea or random paragraph.

It creates the foundation of an entirely new fictional universe.

Every day, the agent has the opportunity to create something completely different.

One day, it might imagine a civilization living beneath an endless ocean.

The next day, it could create a city where memories are traded as currency.

Another day, it might imagine a forgotten kingdom floating between planets.

The user does not need to ask for these worlds.

They are already waiting.

The Always-On Agent Workflow

DreamCanvas works differently:

User leaves
        ↓
EventBridge wakes the agent automatically
        ↓
Agent checks recent worlds
        ↓
Agent remembers previous creative directions
        ↓
Agent chooses a different direction
        ↓
Groq generates a new fictional world
        ↓
Lambda validates the response
        ↓
World is stored in DynamoDB
        ↓
User returns later
        ↓
A new world is already waiting

The application does useful creative work without waiting for a user to request it.

That is the main idea I wanted to explore.

Lightweight Agent Memory

One of the important features of DreamCanvas is memory.

Before generating a new world, the agent retrieves recent creations from Amazon DynamoDB.

The recent worlds provide context such as:

Previous world names
Genres
Atmospheres
Settings
Main concepts
Inhabitants
Conflicts
Summaries

This information is provided to the AI during the next generation.

The agent is instructed to avoid repeating similar creative directions.

For example, if recent worlds have focused on:

Futuristic cities
Fantasy kingdoms
Dark mysterious worlds

The next generation can be encouraged to explore something meaningfully different.

Perhaps:

A peaceful alien ecosystem
A world inside a living machine
A civilization existing in people's dreams
An ancient world where time moves differently

This gives DreamCanvas a lightweight form of memory.

I deliberately did not use a vector database or a complicated AI framework.

For this use case, recent DynamoDB records provide enough context to influence future generations while keeping the architecture simple.

This was an important design decision.

Not every AI agent needs a complex memory system. Sometimes remembering the most recent actions is enough.

How I Built It

I intentionally kept the project architecture simple and focused.

Frontend

The frontend uses:

HTML
CSS
Vanilla JavaScript

I did not use a large frontend framework because the main purpose of the project was to demonstrate the always-on AI agent architecture.

The website allows users to:

View today's generated world
Explore complete world details
Browse previously imagined worlds

When the user opens the application, the frontend requests the latest generated world from the backend.

Because the autonomous workflow has already run, the new world is ready to display.

The Autonomous Backend

The most important part of DreamCanvas runs on AWS.

An Amazon EventBridge schedule automatically wakes the agent every day.

The scheduled event invokes an AWS Lambda function.

The workflow begins with an important check.

Step 1: Check for Today's World

Lambda first checks whether a world has already been generated for the current day.

This makes the workflow idempotent.

Has today's world already been created?

YES → Stop

NO → Continue generation

This prevents accidental duplicate generations and unnecessary AI API usage.

Step 2: Retrieve Recent Memory

If no world exists for the current day, Lambda retrieves several recent worlds from Amazon DynamoDB.

These records act as the agent's memory.

Step 3: Choose a New Creative Direction

The recent worlds are used as context.

The AI is instructed to create something meaningfully different from recent generations.

The goal is not simply randomness.

The goal is informed variety.

The agent knows what it recently created and uses that information when creating something new.

Step 4: Generate the World

Lambda sends the creative context to the AI through the Groq API.

Groq acts as the creative generation engine.

Step 5: Validate the AI Response

The backend does not blindly store the AI response.

The Lambda validates the generated data before saving it.

This is important because the application expects structured information.

The validation checks that the required data exists and that the response can be safely processed.

If the AI response is malformed, the application handles the problem safely and can retry generation rather than storing invalid data.

Step 6: Save the New World

Once validation succeeds, the new world is stored in Amazon DynamoDB.

The generated world then becomes available through the application's API.

When the user returns later, the frontend can immediately display it.

Separating AI Generation from Infrastructure

One of the key architectural decisions was separating the AI generation service from the always-on application infrastructure.

Groq handles creative AI generation.

AWS handles:

Scheduling
Serverless execution
Storage
API access
Security
Logging
Monitoring
Deployment

The separation looks like this:

AWS EventBridge
        ↓
AWS Lambda
        ↓
DynamoDB Memory
        ↓
Groq API
        ↓
AWS Lambda Validation
        ↓
DynamoDB Storage

This allows the application to combine an external AI model with AWS serverless infrastructure.

AWS Services Used

DreamCanvas uses a lightweight serverless architecture built with the following AWS services.

AWS Lambda

AWS Lambda runs the DreamCanvas agent and backend API logic.

It handles:

Daily world generation
Checking for duplicates
Retrieving recent worlds
Preparing AI prompts
Calling the Groq API
Validating responses
Storing new worlds
Serving API requests

Amazon EventBridge

Amazon EventBridge automatically triggers the DreamCanvas agent every day.

This is what transforms the project from a normal AI application into an always-on system.

The user does not need to press a button.

The scheduled event wakes the agent automatically.

Amazon DynamoDB

Amazon DynamoDB stores the generated fictional worlds.

It also acts as lightweight agent memory.

Before creating a new world, the agent retrieves recent records and uses them as context to avoid repetitive output.

Amazon API Gateway

Amazon API Gateway provides API endpoints for the frontend.

The frontend can use these endpoints to:

Retrieve today's world
Browse previous worlds
View individual world details

Amazon S3

Amazon S3 hosts the static frontend.

The frontend consists of:

HTML
CSS
JavaScript

AWS Secrets Manager

AWS Secrets Manager securely stores the Groq API key.

The key is never exposed in browser code or committed to the repository.

The Lambda backend retrieves the secret using AWS permissions.

The security flow looks like this:

Frontend
    ↓
API Gateway
    ↓
Lambda
    ↓
Secrets Manager
    ↓
Retrieve Groq API Key
    ↓
Groq API

Amazon CloudWatch

Amazon CloudWatch provides logs and monitoring.

It helps monitor:

Scheduled generation events
Lambda execution
Validation failures
API errors
Application debugging

AWS SAM

I used AWS SAM to define and deploy the serverless infrastructure.

SAM uses AWS CloudFormation underneath and makes it easier to define serverless resources as infrastructure as code.

This means the AWS environment can be deployed consistently from the project instead of manually creating resources one by one.

DreamCanvas is an always-on AI creative agent that remembers recently imagined worlds, automatically creates a new one every day using Groq, and uses AWS serverless services to make sure the next world is waiting before the user even opens the application.

App and Source Code

Live App:
[http://dreamcanvas-frontend-305218268847-us-east-1.s3-website-us-east-1.amazonaws.com/]

Building FridgeChef AI: Turning Available Ingredients into Recipes | 10 Days of Building AI Agents on AWS | Day 9

abdullah haroon — Mon, 31 Aug 2026 02:28:00 +0000

10 Days of Building AI Agents on AWS | Day 8

Opening the fridge and still not knowing what to cook is a frustrating daily problem.

You may already have chicken, eggs, vegetables, rice, spices, and other ingredients at home, but still spend more time searching for recipes than actually preparing a meal.

That was the problem behind FridgeChef AI.

FridgeChef AI is an AI-powered recipe assistant that transforms the ingredients already available in your kitchen into personalized meal ideas using generative AI and AWS serverless technologies.

The idea is simple:

Available Ingredients → Preferences → AI → Personalized Recipe

Instead of searching through multiple recipe websites, users can enter what they already have and let AI suggest what they can cook.

Vision and What FridgeChef AI Does

One of the most common everyday frustrations is standing in front of the refrigerator wondering:

What can I actually cook with this?

Even when we have several ingredients available, it can be difficult to combine them into a complete meal idea.

This often leads to:

Wasted time searching for recipes
Unnecessary grocery purchases
Ingredients being forgotten
Food eventually expiring unused

I wanted to build a focused application that solves this one problem.

With FridgeChef AI, users simply enter the ingredients available in their kitchen and select optional preferences such as:

Preferred cuisine
Dietary restrictions
Cooking time

The AI then generates personalized recipe suggestions in seconds.

Each response can include:

Recipe suggestions
Required ingredients
Cooking instructions
Estimated cooking time
Additional cooking tips

The goal was not to build a complete recipe platform with thousands of manually created recipes.

Instead, the focus was on one useful experience:

Tell FridgeChef what you have, and let AI help you decide what to cook.

By encouraging users to cook with ingredients they already have, the application can also help reduce unnecessary food waste.

How I Built It

I wanted the project to use a modern serverless architecture while keeping the deployment process automated and reproducible.

Frontend

The frontend was built using:

React
Vite

The interface uses a warm, kitchen-inspired design focused on making the experience simple and intuitive.

Users can:

Add available ingredients
Select cuisine preferences
Choose dietary options
Specify their preferred cooking time
Generate personalized recipes

The frontend communicates with the backend through an API.

Backend

The backend was developed using Node.js and deployed as an AWS Lambda function.

Instead of maintaining a traditional server, the backend runs only when a request is received.

The request flow is:

User enters ingredients
        ↓
Frontend sends request
        ↓
Amazon API Gateway
        ↓
AWS Lambda
        ↓
Groq API
        ↓
Recipe generation
        ↓
Structured JSON response
        ↓
Frontend displays recipes

This architecture keeps the backend lightweight and serverless.

The AI Recipe Generation

For AI-powered recipe generation, I integrated the Groq API.

The backend receives the user's ingredients and preferences and creates a structured prompt.

For example, the input may contain:

`
Ingredients:
Chicken, rice, onions, tomatoes, garlic

Cuisine:
Pakistani

Dietary Preference:
None

Cooking Time:
30 minutes
`plaintext

The backend sends this information to the AI model and requests a structured recipe response.

The AI can generate information such as:

Recipe name
Description
Ingredients
Cooking instructions
Estimated preparation time
Cooking tips

The response is then formatted into structured JSON before being returned to the frontend.

Using structured responses makes it easier for the application to reliably display the generated recipes.

Why I Chose a Serverless Architecture

This project did not need a traditional server running continuously.

Recipe generation happens only when a user submits ingredients.

That makes a serverless architecture a good fit.

The backend can remain inactive until a request arrives:

No request → No backend processing

When a user generates a recipe:

Request arrives → Lambda runs → AI generates recipe → Response returns

This allowed me to focus on the application rather than managing servers.

AWS Services and Architecture

The application uses several AWS services.

AWS Amplify Hosting

AWS Amplify hosts the React frontend and makes the application publicly accessible.

It provides the hosting layer for the user interface.

Amazon API Gateway

Amazon API Gateway receives requests from the frontend and routes them to the serverless backend.

The frontend does not communicate directly with the AI provider.

Instead:

Frontend ↓ API Gateway ↓ AWS Lambda ↓ Groq APIplaintext

This keeps the AI integration inside the backend.

AWS Lambda

AWS Lambda runs the Node.js backend.

It is responsible for:

Receiving recipe requests
Processing ingredients and preferences
Creating the AI prompt
Calling the Groq API
Processing the AI response
Returning structured recipe data

Lambda runs when the application receives a request, so there is no continuously running backend server.

AWS SAM

I used AWS SAM (Serverless Application Model) to simplify the development and deployment of the serverless backend.

SAM makes it easier to define and deploy resources such as:

Lambda functions
API Gateway endpoints
IAM permissions
Environment configuration

AWS CloudFormation

The infrastructure is provisioned using AWS CloudFormation.

Rather than manually creating resources through the AWS Console, the infrastructure is defined as code.

This means the deployment can be repeated consistently.

The infrastructure definition includes:

AWS Lambda configuration
API Gateway configuration
IAM roles and permissions
Environment variables
Required service connections

The workflow becomes:

Infrastructure Code → AWS SAM → CloudFormation → AWS Resources

Amazon CloudWatch

Amazon CloudWatch is used for monitoring and debugging.

During development, CloudWatch logs helped identify deployment and runtime issues.

Architecture Overview

The complete architecture looks like this:

USER │ ▼ AWS Amplify React + Vite App │ ▼ Amazon API Gateway │ ▼ AWS Lambda Node.js │ ▼ Groq API AI Recipe Generation │ ▼ AWS Lambda Process AI Response │ ▼ Amazon API Gateway │ ▼ React Frontend │ ▼ Personalized Recipes

The application starts when a user submits a list of ingredients through the frontend.

API Gateway receives the request and invokes the Lambda function.

Lambda prepares the AI prompt and sends it to the Groq API.

Once the AI generates recipe suggestions, the backend formats the result into structured JSON and returns it through API Gateway.

The frontend then displays the recipes to the user.

Infrastructure as Code

One of my main goals was to avoid manually configuring cloud resources.

I used AWS SAM and AWS CloudFormation to automate the infrastructure deployment.

Instead of creating resources one by one through the AWS Console, the backend infrastructure can be deployed using the AWS CLI.

This approach makes deployments:

Repeatable
Easier to manage
Easier to update
Less dependent on manual configuration

During development, I encountered challenges related to CloudFormation parameter handling and environment variables.

After debugging the deployment scripts and configuration, I was able to automate the deployment workflow and deploy the backend consistently.

This was an important learning experience because it showed me that building an application is not only about writing the frontend and backend code.

Deployment and infrastructure configuration are also important parts of the development process.

Challenges I Faced

Like other serverless projects, the main challenges were related to deployment and configuration.

Some of the issues involved:

CloudFormation parameters
Environment variable configuration
Deployment scripts
AWS resource configuration

Debugging these issues helped me better understand how the different parts of a serverless application connect together.

Using Infrastructure as Code also made it easier to identify configuration problems because the infrastructure was defined explicitly instead of being hidden inside manual AWS Console settings.

What I Learned

Building FridgeChef AI gave me valuable hands-on experience with serverless application development on AWS.

Infrastructure as Code

I strengthened my understanding of Infrastructure as Code by deploying the backend through AWS SAM and CloudFormation.

This helped me understand how cloud resources can be defined and managed as part of the application codebase.

API Gateway and Lambda

I learned more about integrating Amazon API Gateway with AWS Lambda.

The project required designing the flow between:

The React frontend
API Gateway
Lambda
The external AI provider

This gave me more experience with serverless APIs and event-driven backend architecture.

AI Integration

Another important learning was integrating an external AI provider into an AWS application.

Groq handles the AI inference, while AWS provides the infrastructure required to deliver the application.

The combination looks like this:

AWS manages the application infrastructure → Groq provides AI generation

This separation allows the application to use managed cloud services while integrating specialized AI capabilities.

Debugging Deployments

Working through CloudFormation and deployment issues also improved my troubleshooting skills.

I learned more about:

Managing deployment parameters
Working with environment variables
Reading deployment errors
Debugging CloudFormation configuration
Structuring applications for repeatable deployment

FridgeChef AI is an experiment in combining generative AI with AWS serverless technologies to solve a simple everyday problem.

The application takes ingredients that users already have and transforms them into personalized meal ideas.

The complete workflow is simple:

Open the App → Enter Ingredients → Choose Preferences → Generate Recipes

Building the project gave me more experience with:

React and Vite
AWS Amplify
Amazon API Gateway
AWS Lambda
AWS SAM
AWS CloudFormation
Amazon CloudWatch
Serverless architecture
Infrastructure as Code
Groq AI integration

More importantly, it demonstrated how quickly a useful AI-powered application can be built by combining managed AWS services with a focused product idea.

Sometimes the best project is not the one with the most features.

It is the one that solves a small, annoying problem well.

Try FridgeChef AI

Live Application:

https://staging.d2rlx4nfgtm79o.amplifyapp.com/

Building VibePlaylist AI: Turning Everyday Moods into AI-Curated Playlists | 10 Days of Building AI Agents on AWS | Day 8

abdullah haroon — Sat, 29 Aug 2026 02:18:00 +0000

10 Days of Building AI Agents on AWS | Day 8

Tag: #agents

Have you ever had a very specific mood but could not find the right music for it?

Maybe it is a late-night drive after a long day, a quiet evening when you are feeling nostalgic, a study session that needs focus, or simply a moment that feels difficult to describe with a normal playlist.

That is the idea behind VibePlaylist AI.

VibePlaylist AI is a generative AI application that turns a user's situation, feeling, memory, place, or activity into a personalized themed playlist.

Instead of manually searching through hundreds of songs, users can describe what they are experiencing, choose a vibe, and let AI curate a musical concept around that idea.

The Idea Behind VibePlaylist AI

A user can enter something like:

Late-night drive through Islamabad after a long and exhausting day.

They can then select a vibe such as:

Chill
Romantic
Sad
Energetic
Dreamy
Nostalgic
Focus

After clicking Create Playlist, VibePlaylist AI generates:

A playlist name
A short description
The selected vibe
Eight song recommendations

For example, the result could become Midnight Miles, with a description inspired by quiet roads, city lights, and reflective thoughts, followed by eight songs that fit the atmosphere.

The core experience is simple:

Your Moment → Choose a Vibe → AI Curates → Discover Your Playlist

The application is not intended to replace music streaming platforms. There is no music playback or Spotify integration.

The creative part is the curation itself.

A simple sentence from the user becomes a complete musical concept that they can explore on their preferred streaming platform.

Building the Experience

For this project, I deliberately kept the scope focused.

The application has one primary purpose: turn a feeling or situation into a themed playlist.

Almost every part of the interface supports that single interaction.

Frontend

The frontend was built using:

HTML5
CSS3
Vanilla JavaScript

I chose a lightweight frontend because the application did not require complex state management or a large component system.

The visual design uses a cinematic black-and-gold theme with clean typography and simple interactive elements.

The main interface contains:

A text input for describing the moment
Vibe selection buttons
A single Create Playlist action

Once the AI response arrives, the playlist is displayed in a dedicated result section containing the playlist name, description, vibe, and track list.

The AI Behind the Playlist

The AI layer is powered by the Groq API.

The backend sends two important pieces of information to the model:

What the user is experiencing
The vibe they selected

I designed the prompt so the model behaves more like a music curator rather than simply returning random song names.

The AI is instructed to:

Create a suitable playlist title
Match the requested mood
Generate exactly eight tracks
Avoid duplicate songs
Create a relevant playlist description
Return a predictable JSON response

The request flow is:

User describes a moment
          ↓
User selects a vibe
          ↓
Frontend sends request
          ↓
AWS Lambda processes it
          ↓
Groq analyzes the mood
          ↓
AI creates playlist JSON
          ↓
Frontend displays the playlist

Why Structured AI Output Matters

One of the practical challenges was making sure the AI response could be reliably consumed by the frontend.

AI-generated text can be unpredictable.

Rather than asking the browser to interpret a large block of generated text, the backend requests structured JSON containing information such as:

json { "playlistName": "Midnight Miles", "description": "A soundtrack for quiet roads and reflective thoughts.", "vibe": "Nostalgic", "tracks": [ { "title": "Song Name", "artist": "Artist Name" } ] }json

This makes the response much easier to:

Validate
Process
Display
Handle when errors occur

It also keeps the frontend logic simple.

This project reinforced an important lesson for me:

A good AI application is not only about the prompt. The format and reliability of the response matter just as much.

Keeping the API Key Secure

Another important consideration was API security.

The Groq API key is never placed inside the frontend code.

The browser does not communicate directly with Groq.

Instead:

Browser ↓ AWS API Gateway ↓ AWS Lambda ↓ Groq APIplaintext

This keeps the AI API key away from client-side JavaScript.

The serverless backend handles communication with the external AI service.

AWS Architecture

VibePlaylist AI uses a serverless AWS architecture.

There is no traditional server that needs to remain running continuously.

The main AWS services used are:

Amazon S3 for storing the static frontend
Amazon CloudFront for global delivery and HTTPS
Amazon API Gateway for exposing the POST /generate endpoint
AWS Lambda for running the Node.js backend
AWS IAM for permissions and access control
AWS CloudFormation for defining and provisioning infrastructure

The complete architecture looks like this:

USER │ ▼ CloudFront │ ▼ Amazon S3 HTML / CSS / JavaScript │ │ Create Playlist Request ▼ Amazon API Gateway │ ▼ AWS Lambda Node.js │ ▼ Groq API │ ▼ Playlist JSON │ ▼ User Interface

Infrastructure as Code

One of my goals was to avoid manually building the AWS environment through the console.

The infrastructure is described in an AWS CloudFormation YAML template.

This includes:

AWS resources
Permissions
Service connections
API configuration
Stack outputs

This makes the infrastructure part of the project itself.

Instead of manually recreating the environment, it can be provisioned from the template.

Managing Multiple AWS Accounts

For deployment, I used a dedicated AWS CLI profile named account2.

Because multiple AWS accounts were configured on my development machine, I added identity verification to the deployment process.

Before creating or updating resources, the workflow checks the AWS identity being used.

This helped prevent deploying infrastructure to the wrong AWS account.

The deployment process follows this idea:

Verify Account → Deploy Infrastructure → Confirm Outputs

It is a small safeguard, but useful when working across multiple AWS accounts.

What I Learned

Building VibePlaylist AI gave me practical experience with the complete lifecycle of a small AI application.

Designing Frontend and Backend APIs

I learned more about designing communication between a frontend and a serverless backend, including:

Sending JSON requests
Handling asynchronous responses
Validating generated data
Managing API errors
Displaying results cleanly

Working with API Gateway and Lambda

The project helped me better understand the serverless model.

Instead of running a Node.js server continuously, the Lambda function is invoked when the application receives a request.

The flow is event-driven:

Request arrives → Lambda runs → AI is called → Response is returned

Infrastructure as Code with CloudFormation

CloudFormation was another important learning experience.

Defining the AWS environment as YAML changed how I think about deployment.

Instead of treating the AWS Console as the place where the application is built, the infrastructure becomes part of the project.

That means it can be:

Versioned
Reproduced
Updated
Deployed consistently

AI Responses Need More Than a Good Prompt

One of the biggest lessons from this project was that the prompt is only one part of an AI application.

A complete application also needs to consider:

Response structure
Data validation
Error handling
API security
Frontend integration
User experience

Generating good output is important.

Making that output reliable and useful inside a real application is equally important.

Keeping the Product Focused

Most importantly, VibePlaylist AI reinforced the idea that a creative AI application does not need dozens of features.

A simple idea, a focused interface, and one useful AI interaction can create an enjoyable experience.

The entire application revolves around one question:

What does this moment sound like?

The user provides the moment.

AI creates the musical direction.

Final Thoughts

VibePlaylist AI is a small experiment in turning everyday moments into musical ideas using generative AI.

A late-night drive, a difficult day, a nostalgic memory, a study session, or any other feeling can become the starting point for a curated playlist.

By combining Groq with AWS serverless services, I built a simple workflow:

Describe Your Moment → Select a Vibe → Generate a Playlist

This project demonstrates how AI can take a simple piece of human input and transform it into a creative experience.

It also gave me more hands-on experience with serverless architecture, API design, structured AI responses, CloudFormation, and secure backend integration.

Sometimes, a creative AI application does not need to do everything.

It only needs to do one thing well.

Try VibePlaylist AI

Live App:
https://d1u2qhbqs932dd.cloudfront.net/

ReplyPilot AI: Generating Email Replies with AI | 10 Days of Building AI Agents on AWS | Day 7

abdullah haroon — Fri, 28 Aug 2026 02:08:00 +0000

10 Days of Building AI Agents on AWS | Day 7

One of the most repetitive tasks in my daily workflow is replying to emails.

Whether it is acknowledging a meeting request, responding to a client, replying to a colleague, or sending a professional follow-up, I often spend more time thinking about how to phrase the message than actually writing it.

To solve this problem, I built ReplyPilot AI, an AI-powered email reply assistant that generates professional email responses within seconds.

Instead of manually drafting every response, users simply:

Paste the email they received
Choose the desired tone
Generate a polished AI reply

The application also keeps a history of generated replies, allowing users to revisit previous responses without generating the same reply again.

The Problem

Writing an email is usually not technically difficult.

The difficult part is deciding how to write it.

Questions such as these can slow down even a simple reply:

How formal should I be?
Should I sound friendly or strictly professional?
How do I politely decline?
How should I follow up?
How can I acknowledge a request professionally?
What is the best way to phrase my response?

These small decisions happen repeatedly throughout the day.

ReplyPilot AI was built to reduce that friction.

The goal is simple:

Received Email → Select Tone → AI Generates Reply

Instead of starting from a blank page, the user receives a polished draft within seconds.

What ReplyPilot AI Does

ReplyPilot AI is a web application that uses generative AI to create professional email replies.

Users provide the received email and select a desired writing style or tone.

The AI analyzes the content and generates an appropriate response.

The application allows users to:

Paste a received email
Choose a writing tone
Generate a professional reply
Copy the generated response
Browse previously generated replies
Revisit reply history
View simple usage statistics

Every generated reply is stored in Amazon DynamoDB.

This provides a searchable history and prevents users from losing previous AI-generated drafts.

The application also tracks statistics such as:

Total replies generated
Processed emails
Application usage

How I Built It

I wanted the application to be:

Lightweight
Serverless
Responsive
Scalable
Inexpensive to operate

Frontend

The frontend was developed using:

React
Vite

The interface allows users to generate replies, browse previous replies, and view application statistics.

Backend

The backend is built using:

Node.js
Express
serverless-http
AWS Lambda

Express runs inside AWS Lambda using serverless-http, allowing the API to operate in a serverless environment.

The frontend communicates with the backend through Amazon API Gateway.

AI Generation

For AI inference, I integrated the Groq API.

The Lambda backend sends the received email and selected tone to the AI.

Groq generates a professional response based on that context.

The workflow is:

Received Email
       ↓
Choose Tone
       ↓
React Frontend
       ↓
Amazon API Gateway
       ↓
AWS Lambda
Express.js Backend
       ↓
Groq API
       ↓
Generated Reply
       ↓
Amazon DynamoDB
       ↓
Reply History

AWS Architecture

ReplyPilot AI uses a fully serverless AWS architecture.

The main AWS services used are:

AWS Amplify
AWS Lambda
Amazon API Gateway
Amazon DynamoDB
AWS CloudFormation
AWS SAM
Amazon CloudWatch

The overall architecture is:

User
        │
        ▼
AWS Amplify
React Frontend
        │
        ▼
Amazon API Gateway
        │
        ▼
AWS Lambda
Express API
        │
   ┌────┴────┐
   ▼         ▼
Groq API   Amazon DynamoDB
   │         │
   └────┬────┘
        ▼
Generated Reply and History

How the Workflow Works

The complete workflow follows these steps:

The user opens ReplyPilot AI on AWS Amplify.
The user pastes the email they received.
The user selects the desired tone.
The React frontend sends the request to Amazon API Gateway.
API Gateway invokes AWS Lambda.
Lambda processes the request through the Express backend.
Lambda sends the prompt to the Groq API.
Groq generates a professional email reply.
The generated reply is returned to the frontend.
The reply is also stored in Amazon DynamoDB.
The user can later access the reply from the history section.

This creates a simple but useful workflow:

Email → AI → Professional Reply → Stored History

Infrastructure as Code

The backend infrastructure is managed using:

AWS SAM
AWS CloudFormation

Instead of manually creating resources through the AWS Console, the infrastructure is defined as code.

This makes the deployment:

Repeatable
Easier to reproduce
Easier to update
More consistent

The complete serverless backend can be recreated through the deployment workflow.

Challenges I Faced

Building ReplyPilot AI involved several deployment and infrastructure challenges.

CloudFormation Parameter Validation

One of the early issues involved CloudFormation parameter validation.

Infrastructure templates must match expected configurations precisely, and incorrect parameter definitions can prevent deployments before the application even starts.

This helped me better understand the importance of validating infrastructure configuration.

Lambda Configuration Problems

I also encountered Lambda configuration issues during deployment.

These required reviewing the function settings and ensuring the deployed environment matched what the application expected.

API Gateway Routing Issues

Another challenge involved API Gateway routing.

The frontend and backend both worked individually, but requests needed to be correctly routed from API Gateway to the Express application running inside Lambda.

Debugging this helped me understand how API Gateway and Lambda integrate in a serverless API.

Out of Memory Error

After deployment, I encountered an out-of-memory error.

The application required adjustments to its Lambda memory configuration during testing.

Using logs and deployment tools, I identified the issue, updated the configuration, and redeployed successfully.

This was an important reminder that serverless applications still require resource planning.

Even though there are no servers to manage, memory and runtime configuration still directly affect application performance.

Debugging with CloudWatch

One of the most valuable tools during development was Amazon CloudWatch.

CloudWatch logs helped me diagnose Lambda runtime issues and understand what was happening after deployment.

When something worked locally but failed in the cloud, logs provided the information needed to investigate the actual serverless execution environment.

The development workflow involved:

Deploy → Test → Check CloudWatch Logs → Identify Issue → Update Configuration → Redeploy

This gave me practical experience debugging production-style serverless applications.

What I Learned

Building ReplyPilot AI gave me hands-on experience with several AWS services and modern application development concepts.

AWS Serverless Development

I gained practical experience using:

AWS Lambda
Amazon API Gateway
Amazon DynamoDB
AWS Amplify

These services work together to create a complete application without managing traditional servers.

Infrastructure as Code

Using AWS SAM and CloudFormation helped me understand the value of defining infrastructure as code.

Resources can be deployed consistently instead of manually recreating them through the AWS Console.

Connecting Frontend and Serverless Backend

I learned more about connecting a modern React application with a serverless backend.

The flow between Amplify, API Gateway, Lambda, and DynamoDB became a complete end-to-end application architecture.

Debugging Serverless Applications

CloudWatch logs, AWS SAM, and repeated testing helped me understand how to troubleshoot problems in deployed serverless environments.

Building Around Everyday Problems

Most importantly, this project reinforced a simple lesson:

A small everyday annoyance can become a genuinely useful application.

Writing professional email replies is something many people do every day.

Reducing the time spent drafting them can make a small but meaningful difference.

The application demonstrates how:

AI can automate repetitive communication tasks
Serverless architecture can keep infrastructure simple
DynamoDB can provide persistent reply history
AWS SAM and CloudFormation can make deployments repeatable
CloudWatch can help debug real deployment issues

The core workflow remains simple:

Received Email → Choose Tone → AI Generates Reply → Save to History

Sometimes the most useful AI applications are not the most complicated ones.

They simply remove friction from tasks we already do every day.

Try ReplyPilot AI

Live Demo:
Open ReplyPilot AI

Building DevDigest AI: An Always-On Agent That Prepares Your Daily Developer Briefing | Day 6

abdullah haroon — Wed, 26 Aug 2026 01:57:00 +0000

10 Days of Building AI Agents on AWS | Day 6

Developers live in a world of constant information.

Every day brings new AI models, AWS announcements, cloud updates, open-source releases, developer tools, frameworks, GitHub projects, and learning opportunities.

Access to information has never been easier.

Keeping up with everything, however, has become increasingly difficult.

That is the problem I wanted to solve with DevDigest AI.

DevDigest AI is an always-on AI agent that prepares a daily developer briefing before you even open the app.

Instead of manually visiting multiple websites, checking feeds, and deciding which updates actually matter, the agent works in the background and prepares a concise digest automatically.

The vision behind the project is simple:

The best tool is one that does useful work before you ask it to.

The Vision: Your Developer World, Summarized Every Day

DevDigest AI collects fresh information from reliable developer-focused sources and transforms it into a short, readable daily briefing.

The digest can include important updates from areas such as:

AI
AWS and cloud computing
Open source
Developer tools
Frameworks and technologies
Relevant opportunities

It also includes a Learn Today section that highlights one useful technical concept or topic.

The goal is not to collect as much information as possible.

The goal is to identify what matters and make it easier for developers to stay informed without manually searching through dozens of sources.

Most importantly, the user does not need to press a button to start the process.

Every day, the autonomous workflow runs in the background:

EventBridge wakes the agent
        ↓
The agent collects fresh information
        ↓
Duplicate and low-value items are filtered
        ↓
Recent digests are checked
        ↓
Groq analyzes and summarizes the information
        ↓
The AI response is validated
        ↓
The completed digest is stored
        ↓
The user returns later
        ↓
Today's briefing is already waiting

This is what makes DevDigest AI an always-on AI agent.

It independently gathers information, remembers what it has previously reported, creates a new briefing, and prepares the result before the user returns.

How I Built DevDigest AI

I intentionally kept the architecture simple and serverless.

For the frontend, I chose plain HTML, CSS, and JavaScript instead of introducing a large frontend framework.

The goal was to focus on the autonomous agent rather than add unnecessary complexity.

The frontend retrieves the latest digest from an API and presents it in a clean, developer-focused interface.

For the backend, I used Node.js and AWS Lambda.

The core daily agent is triggered automatically on a schedule.

It performs several tasks:

Collects information from reliable sources
Removes duplicate items
Filters low-value information
Checks previous digests
Selects relevant fresh updates
Sends the selected information to Groq
Validates the AI-generated response
Stores the completed digest

Keeping the AI Grounded in Real Sources

One of my key decisions was to avoid giving the AI unrestricted freedom to invent information.

DevDigest AI provides Groq with collected source material and instructs it to summarize only that information.

The generated response is then validated before it is stored.

This includes checking that generated source URLs correspond to actual collected sources.

The goal is to reduce the risk of the AI:

Inventing news
Creating fake announcements
Adding events that did not happen
Generating incorrect source links

The AI acts as an analysis and summarization layer rather than an unrestricted source of information.

The workflow looks like this:

Collected Sources → Filtered Information → AI Analysis → Validation → Daily Digest

Lightweight Agent Memory with DynamoDB

DevDigest AI also has a lightweight form of memory.

Before generating a new briefing, the system checks recent digests stored in Amazon DynamoDB.

This gives the agent context about what it has already reported.

For example, if an important AI announcement was already included in yesterday's digest, the agent can avoid repeatedly presenting the same update unless there is meaningful new information.

This helps:

Reduce repetition
Provide more variety
Prioritize genuinely new information
Give the agent context about previous outputs

I deliberately did not use a vector database or a complex agent framework.

For this project's requirements, recent digest history in DynamoDB provides a simpler and more appropriate memory mechanism.

Not every AI agent needs complex memory. Sometimes recent structured history is enough.

AWS Services and Architecture

I used AWS SAM (Serverless Application Model) to define and deploy the infrastructure as code.

The main services used are:

AWS SAM for serverless infrastructure and deployment
Amazon EventBridge to automatically wake the agent every day
AWS Lambda to run the daily agent and backend API logic
Amazon DynamoDB to store daily digests and provide lightweight memory
AWS Secrets Manager to securely store the Groq API key
Amazon API Gateway to expose backend endpoints to the frontend
Amazon S3 to host the static HTML, CSS, and JavaScript frontend
Amazon CloudWatch for logs and monitoring

The architecture follows this flow:

EventBridge Schedule
        ↓
DevDigest Daily Agent
AWS Lambda
        ↓
Reliable RSS Feeds and APIs
        ↓
Filter and Deduplicate Information
        ↓
Check Recent Digests
Amazon DynamoDB
        ↓
Retrieve Groq API Key
AWS Secrets Manager
        ↓
Groq AI Analysis and Summarization
        ↓
Validate AI Output
        ↓
Store Daily Digest
Amazon DynamoDB
        ↓
API Gateway + Lambda
        ↓
HTML, CSS and JavaScript Frontend
Amazon S3

Infrastructure as Code with AWS SAM

I used AWS SAM because I wanted the infrastructure to be reproducible.

Instead of manually creating resources through the AWS Console, the infrastructure is defined and deployed as code.

The project includes:

Serverless infrastructure definitions
Automated deployment scripts
Resource configuration
IAM permissions
API configuration
Account verification before deployment

The deployment workflow verifies the currently authenticated AWS account before making infrastructure changes.

This helps ensure that the project is deployed only to the intended AWS account.

Challenges and Key Decisions

Automation vs Information Quality

One of the biggest challenges was balancing automation with information quality.

An autonomous agent should not simply collect everything it finds.

That would recreate the same information overload the project is designed to solve.

To address this, the workflow focuses on:

Collecting a limited number of reliable items
Removing duplicates
Preferring newer information
Filtering low-value items
Using recent digests as memory

The goal is not more information.

The goal is better information.

Preventing AI Hallucinations

Another important challenge was preventing the AI from inventing information.

The agent must not create fake news, events, announcements, or source links.

For this reason:

Information is collected first.
The AI receives the collected source material.
The AI is instructed to summarize only that material.
The generated response is validated.
Source URLs are checked against the collected source data.
Only validated output is stored.

This makes the system more reliable than simply asking an AI model to tell the user what happened today.

Keeping the Architecture Affordable

I also wanted to keep the architecture simple and affordable.

Serverless services allow the application to run without maintaining an always-running server.

The daily workload is event-driven.

The infrastructure performs work when the agent is scheduled to run rather than continuously consuming resources.

This makes serverless architecture a good fit for an autonomous agent that performs a scheduled daily task.

What I Learned

Building DevDigest AI taught me several important lessons about AWS and autonomous systems.

Event-Driven Serverless Architecture

I gained hands-on experience with an architecture where Amazon EventBridge triggers work automatically without user interaction.

A scheduled event can completely change how an AI application works.

Instead of:

User opens app → User asks → AI responds

The workflow becomes:

Schedule → Agent wakes up → Information is collected → AI analyzes → Result is stored → User discovers it later

Infrastructure as Code

I learned more about using AWS SAM and infrastructure as code to define and deploy cloud resources consistently.

Instead of treating infrastructure as a collection of manually created services, I could define the system as code and reproduce the deployment.

Simple Agent Memory

Another important lesson was that an agent does not always need a complicated framework or vector database.

For DevDigest AI, DynamoDB provides memory by allowing the system to review recent outputs before creating something new.

The memory is simple, but it directly supports the agent's purpose.

Validating AI Output

AI is powerful for summarization and analysis, but external information should be handled carefully.

Restricting the AI to collected source material and validating its final response makes the system more reliable.

This was one of the most important design decisions in the project.

Thinking Beyond Reactive AI

Finally, this project helped me think differently about AI applications.

Many AI applications are reactive.

The user opens an app and asks the AI to do something.

But an always-on agent can work proactively.

It can:

Wake up automatically
Collect information
Review its previous outputs
Analyze new data
Create something useful
Prepare the result before the user asks

That changes the relationship between the user and the application.

Final Thoughts

DevDigest AI is my experiment in building an autonomous developer intelligence agent.

Every day, it wakes up automatically, remembers what it has already reported, collects fresh information, filters duplicates, analyzes relevant updates, validates its output, and prepares a new briefing.

The user simply returns to the application.

Today's digest is already waiting.

The core idea behind the project is simple:

AI applications do not always need to wait for the user to start the conversation.

Sometimes, the most useful agent is one that does the work while you are away.

DevDigest AI in One Sentence

DevDigest AI is an always-on AI agent that wakes up every day, remembers recent developer updates, collects and analyzes fresh information, and prepares a new developer briefing before you even open the application.

Try DevDigest AI

Live App:
Open DevDigest AI

Building Meeting2Tasks: Turning Meeting Conversations into Actionable Tasks with AI and AWS | 10 Days of Building AI Agents on AWS | Day 5

abdullah haroon — Mon, 24 Aug 2026 01:40:00 +0000

10 Days of Building AI Agents on AWS | Day 5

Meetings are essential for collaboration, but they often create another problem: someone has to spend time reviewing notes, writing summaries, extracting action items, and documenting key decisions.

Whether it is a team stand-up, client discussion, or project planning session, this repetitive work can sometimes take almost as long as the meeting itself.

To solve this problem, I built Meeting2Tasks, an AI-powered web application that automatically transforms meeting transcripts into structured summaries, actionable tasks, key decisions, risks, and unanswered questions.

Instead of manually organizing notes after every meeting, users simply paste their meeting transcript, and the application does the rest in seconds.

The Problem

One of the most repetitive tasks in project management is documenting meetings.

After almost every meeting, someone needs to:

Read through lengthy meeting notes or transcripts
Summarize the discussion
Identify action items
Record important decisions
Highlight project risks
Capture unanswered questions
Save everything so it can be reviewed later

This process is repetitive, time-consuming, and can result in inconsistent documentation.

I wanted to build a tool that could eliminate much of this manual work while producing structured and consistent results.

What Meeting2Tasks Does

Meeting2Tasks is a web application designed to automate meeting documentation.

Users simply:

Paste a meeting transcript
Click Analyze
Let AI process the conversation
Receive structured insights

The application generates:

A concise meeting summary
Actionable tasks
Important decisions
Identified risks
Open questions

Once the analysis is complete, the application stores the meeting and its generated insights in Amazon DynamoDB.

Users can revisit previous meetings whenever needed, while the dashboard provides statistics and access to meeting history.

The result is a faster and more organized workflow for teams that regularly conduct meetings.

How It Works

The workflow is straightforward:

Meeting Transcript → AI Analysis → Structured Insights → Stored Meeting History

When a user submits a transcript, the application sends it through the backend for AI analysis.

The Groq API processes the meeting content and returns structured results.

These results are then stored in DynamoDB for future access.

User submits transcript
        │
        ▼
React + Vite Frontend
        │
        ▼
Amazon API Gateway
        │
        ▼
AWS Lambda
        │
   ┌────┴─────┐
   ▼          ▼
Groq API   DynamoDB
   │          │
   └────┬─────┘
        ▼
Structured Meeting Insights

How I Built It

The application consists of a React frontend and a serverless backend running on AWS.

Frontend

The frontend was developed using:

React
Vite

This provides a fast and responsive interface for submitting transcripts, viewing results, and accessing previous meetings.

The frontend communicates with a REST API exposed through Amazon API Gateway.

Backend

The backend uses:

Express.js
Node.js
AWS Lambda

The Express.js application runs inside AWS Lambda, allowing the backend to scale automatically without managing traditional servers.

When a user submits a transcript, the backend processes the request and sends the transcript to the Groq API.

The AI then generates structured insights including summaries, tasks, decisions, risks, and open questions.

The processed results are stored in Amazon DynamoDB.

Deployment

The frontend is deployed using AWS Amplify.

The backend infrastructure is built and deployed using AWS SAM, which helps define and manage the serverless application.

Using this architecture allowed me to focus more on building the application instead of managing servers and infrastructure manually.

AWS Services Used

AWS Amplify

Used to host and deploy the React frontend.

This makes the application publicly accessible and simplifies frontend deployment.

Amazon API Gateway

Provides REST API endpoints connecting the frontend with the backend.

AWS Lambda

Runs the Express.js backend in a serverless environment.

The backend executes when requests arrive without requiring an always-running server.

Amazon DynamoDB

Stores:

Meeting records
AI-generated summaries
Action items
Decisions
Risks
Open questions

This allows users to revisit and manage previous meeting results.

AWS SAM

AWS Serverless Application Model was used to:

Define the backend infrastructure
Build the serverless application
Test deployments
Deploy Lambda and API resources

Groq API

Groq handles the AI analysis.

It transforms raw meeting transcripts into structured and actionable insights.

Architecture Overview

The complete architecture looks like this:

                         User
                           │
                           ▼
                 React + Vite Frontend
                           │
                           ▼
                     AWS Amplify
                           │
                           ▼
                  Amazon API Gateway
                           │
                           ▼
               AWS Lambda (Express.js)
                           │
                 ┌─────────┴─────────┐
                 ▼                   ▼
              Groq API         Amazon DynamoDB
                 │                   │
                 └─────────┬─────────┘
                           ▼
            AI Analysis and Stored Meetings

The workflow starts whenever a user submits a meeting transcript through the web application.

The backend handles the AI request, processes the response, stores the relevant data, and returns structured results to the user.

Challenges I Faced

Like most real-world projects, building Meeting2Tasks involved several technical challenges.

Running Express.js with AWS Lambda

One of the biggest challenges was integrating an Express.js application with AWS Lambda while ensuring API Gateway correctly routed requests.

This required understanding how a traditional web framework could work inside a serverless execution environment.

DynamoDB Reserved Attribute Names

I also encountered issues with DynamoDB because some attribute names conflicted with reserved words.

This required modifying database queries and expressions to avoid those conflicts.

It was a useful reminder that database design and query syntax need careful attention, even in serverless applications.

Deployment to the Wrong AWS SAM Stack

Another significant challenge involved deployment.

During debugging, I discovered that updates were being deployed to the wrong AWS SAM stack.

This caused new API routes not to appear in production, even though everything worked correctly locally.

After identifying the stack configuration issue and deploying to the correct stack, all endpoints functioned as expected.

This experience helped me better understand:

Serverless deployments
Stack configuration
Production debugging
The difference between local and deployed environments

What I Learned

Building Meeting2Tasks gave me valuable hands-on experience with modern serverless application development.

Some of the key things I learned include:

Building Serverless APIs

How to build REST APIs using AWS Lambda and API Gateway without managing traditional servers.

AWS SAM Deployments

How AWS SAM can simplify building, testing, and deploying serverless applications.

Hosting React Applications

How AWS Amplify can be used to deploy and host a modern React frontend.

Serverless Architecture Design

How services such as API Gateway, Lambda, and DynamoDB can work together as a complete backend architecture.

Integrating External AI

How to connect an external AI service such as Groq with an AWS-based application.

Debugging Deployments

How configuration mistakes, stack selection, and deployment environments can cause production issues even when an application works locally.

Persistent Data with DynamoDB

How DynamoDB can store application data and make AI-generated results available for future use.

Why This Matters

The main idea behind Meeting2Tasks is simple.

Teams should spend more time making decisions and completing important work, not repeatedly documenting conversations.

AI can help automate the repetitive part.

Instead of manually reviewing a long transcript, users can receive structured information within seconds.

Transcript → Summary → Tasks → Decisions → Risks → Questions

This does not replace the meeting itself. It reduces the administrative work that follows it.

Final Thoughts

Meeting2Tasks started with one simple problem: manually documenting meetings is repetitive and time-consuming.

By combining AI with serverless AWS technologies, I built an application that transforms lengthy meeting transcripts into structured, actionable insights within seconds.

The project demonstrates how AI can help eliminate repetitive work while allowing teams to focus more on making decisions instead of documenting them.

It also showed me how services such as AWS Lambda, API Gateway, DynamoDB, Amplify, and SAM can work together with an external AI provider to build a scalable application.

Source Code and Live Application

GitHub Repository:
Meeting2Tasks on GitHub

Live Application:
Open Meeting2Tasks

Building VerseCraft AI: Turning Ideas and Emotions Into Original Poems | 10 Days of Building AI Agents on AWS | Day 4

abdullah haroon — Fri, 21 Aug 2026 19:00:00 +0000

Building VerseCraft AI: Turning Ideas and Emotions Into Original Poems

10 Days of Building AI Agents on AWS | Day 4

Tag: #creative-expression

VerseCraft AI transforms simple ideas, emotions, memories, and thoughts into original poems using generative AI.

The project combines Groq with a serverless AWS architecture to explore how a focused creative experience can bring together AI, web development, and cloud services.

Vision and What the App Does

What if you could turn a simple thought, feeling, memory, or idea into a poem in seconds?

That was the idea behind VerseCraft AI, a simple AI-powered creative writing application.

Instead of asking users to write a complete poem themselves, VerseCraft lets them provide a simple idea and choose a mood. The application then transforms that input into an original poem.

For example, a user can enter:

"A lonely person watching the rain from a rooftop at midnight."

They can then select a mood such as:

Emotional
Romantic
Sad
Inspirational
Dark
Peaceful
Funny

After clicking Generate Poem, VerseCraft creates a title and an original poem inspired by the user's idea and selected mood.

The goal was not to build a complicated AI platform.

I wanted to create one focused creative experience that is simple to understand, enjoyable to use, and produces something people can share.

The generated poem is displayed in a clean, artistic interface with options to copy the poem and generate another one.

The application is designed to make creative writing feel accessible, even when someone does not know where to start.

How I Built It

I decided early that I wanted to keep the application focused and avoid unnecessary complexity.

There are no:

User accounts
Databases
Payment systems
Complicated dashboards

The entire application revolves around one simple interaction:

Idea → Mood → AI → Poem

The frontend was built using HTML, CSS, and JavaScript.

I wanted the interface to feel more like a small digital writing studio than a traditional AI dashboard, so I focused on a minimal design with a black, white, and yellow or gold visual theme.

AI Generation with Groq

For AI generation, I used the Groq API.

The backend receives the user's idea and selected mood and sends them to the AI with a carefully designed prompt.

The prompt instructs the model to generate:

A suitable title
An original poem
A structured response that the frontend can display cleanly

The generation flow is:

User Idea → Selected Mood → Backend → Groq AI → Generated Poem

One important decision was to keep the Groq API key completely away from the frontend.

The browser communicates with the backend API instead of communicating directly with Groq.

This prevents the API key from being exposed in client-side JavaScript.

Serverless Backend

The backend uses Node.js running on AWS Lambda.

When a user requests a poem:

The user enters an idea and selects a mood.
The frontend sends the request to API Gateway.
API Gateway invokes AWS Lambda.
Lambda processes the input.
Lambda securely calls the Groq API.
Groq generates the poem.
Lambda returns the structured result.
The frontend displays the poem.

User
  │
  ▼
Frontend
  │
  ▼
API Gateway
  │
  ▼
AWS Lambda
  │
  ▼
Groq API
  │
  ▼
Poem JSON
  │
  ▼
Frontend displays poem

AWS Services Used and Architecture

VerseCraft AI uses several AWS services:

Amazon S3 for storing and hosting the static frontend files, including HTML, CSS, and JavaScript.
Amazon CloudFront for delivering the frontend globally through a CDN and providing HTTPS.
Amazon API Gateway for providing the public API endpoint used by the frontend.
AWS Lambda for running the serverless Node.js backend that communicates with Groq.
AWS IAM for providing permissions and execution roles required by AWS services.
AWS CloudFormation for defining and provisioning infrastructure using YAML.

The overall architecture is:

                         USER
                           │
                           ▼
                    ┌──────────────┐
                    │  CloudFront  │
                    │ HTTPS / CDN  │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │      S3      │
                    │ HTML/CSS/JS  │
                    └──────────────┘

       User clicks "Generate Poem"
                           │
                           ▼
                    ┌──────────────┐
                    │ API Gateway  │
                    │POST /generate│
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │    Lambda    │
                    │   Node.js    │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │   Groq API   │
                    │ Generative AI│
                    └──────┬───────┘
                           │
                           ▼
                       POEM JSON

CloudFormation ties the AWS infrastructure together and makes deployment reproducible.

Instead of manually creating every AWS resource, the infrastructure can be provisioned from a YAML template.

This serverless architecture also means there is no always-running application server to maintain.

The backend runs when requests arrive, making the architecture a good fit for a focused creative application.

Why I Kept It Simple

A key decision behind VerseCraft AI was to focus on one experience and do it well.

It would have been easy to add:

User profiles
Saved poem collections
Social features
Multiple dashboards
Complex AI settings
Payment systems

But none of those were necessary for the core idea.

The most important workflow is simply:

A person has an idea. AI helps turn that idea into something creative.

Keeping the application focused allowed me to concentrate on the experience and the underlying serverless architecture.

What I Learned

Building VerseCraft AI gave me the opportunity to combine several areas I had been learning separately into one complete application.

Connecting AI to a Frontend

It is easy to call an AI API from a simple script.

Building the complete flow is different.

I had to think about:

Browser requests
API design
Request formats
Error handling
Structured AI responses
Backend security

The complete flow became:

Browser → API Gateway → Lambda → Groq → Lambda → Browser

Serverless Backend Development

I learned more about how AWS Lambda and API Gateway can create a backend without maintaining a traditional server.

The application only runs backend code when a request arrives.

Infrastructure as Code

Using CloudFormation made me think about AWS infrastructure as a complete system rather than a collection of resources manually created through the AWS Console.

Defining resources, permissions, dependencies, and outputs in YAML makes deployments easier to reproduce.

Simple AI Experiences Can Still Be Useful

One of my biggest takeaways was that a creative AI application does not need to be complicated to be useful.

The most important part of VerseCraft AI is the experience:

Give someone a blank box, let them express an idea, and turn that idea into something creative.

Final Thoughts

VerseCraft AI is a small experiment in combining creative expression, generative AI, and serverless AWS infrastructure.

The core idea is simple:

Idea → Mood → AI → Poem

Sometimes, a focused application can create a better experience than a feature-heavy platform.

VerseCraft AI gives users a simple starting point. They bring an idea, feeling, memory, or even just one sentence, and the AI helps transform it into something creative.

Try VerseCraft AI

Live App:
Open VerseCraft AI

If you have an idea, a feeling, a memory, or simply a sentence in your head, give it to VerseCraft AI and see where it takes you.

Building StoryForge: An Always-On AI Agent That Creates a New Story | 10 Days of Building AI Agents on AWS | Day 3

abdullah haroon — Fri, 21 Aug 2026 01:26:05 +0000

Building StoryForge: An Always-On AI Agent That Creates a New Story Every Day

10 Days of Building AI Agents on AWS | Day 3

Tag: #agents

What if your creative app didn't wait for you to open it?

That was the idea behind StoryForge, an always-on AI storytelling agent that creates a brand-new story every day before you even visit the application.

Traditional AI writing tools are reactive. You open a website, enter a prompt, choose some options, and ask the AI to generate something.

StoryForge takes a different approach.

It works in the background as an autonomous creative agent.

Every day, it:

Wakes up automatically
Remembers what it has created recently
Chooses a new creative direction
Generates a fresh story
Validates the result
Saves it for the user

So when the user comes back, a brand-new story is already waiting.

The user leaves → the agent wakes up automatically → it remembers recent stories → it creates something new → the user returns to discover it.

The Vision

I wanted to build something simple while demonstrating an important idea:

The best creative tool does not always need to wait for instructions.

StoryForge is built around the concept of passive creativity.

Instead of opening an application and asking:

What should I write today?

The user can simply return and discover what the AI agent has already created.

The goal wasn't to build a complicated multi-agent system or a massive AI platform.

I wanted to demonstrate one clear always-on agent workflow.

The agent should:

Act without waiting for the user
Run automatically
Remember recent context
Use that context to influence its next action
Create something new
Have its work ready before the user returns

Lightweight Agent Memory

One challenge with generating stories automatically is repetition.

If the AI receives the same instructions every day, it may repeatedly generate similar genres, themes, settings, or story structures.

To reduce this, StoryForge has a lightweight form of memory.

Before generating a new story, the agent retrieves recent stories from its database, including information such as:

Title
Genre
Theme
Setting
Summary

This recent creative history is provided to the AI as context.

The generation instructions tell the agent to avoid repeating:

Similar premises
Recent genres
Themes
Settings
Story structures

This means StoryForge isn't simply running the exact same prompt every day.

It uses its recent creative history to influence what it creates next.

How StoryForge Works

The entire workflow begins automatically.

Step 1: EventBridge Scheduler wakes up the agent

Every day, Amazon EventBridge Scheduler triggers the story-generation workflow.

The user doesn't need to click a button.

The agent wakes up automatically.

EventBridge Scheduler
        ↓
AWS Lambda
        ↓
Check today's story
        ↓
Retrieve recent memory
        ↓
Generate a new story with Groq
        ↓
Validate response
        ↓
Save to DynamoDB
        ↓
Story is ready for the user

Step 2: Check for duplicate generations

The Lambda function first checks whether a story has already been generated for the current day.

This makes the workflow idempotent and prevents:

Duplicate stories
Unnecessary AI API calls
Extra costs
Multiple executions creating conflicting data

Step 3: Retrieve recent stories from DynamoDB

The agent retrieves recently generated stories from Amazon DynamoDB.

These stories act as the agent's lightweight memory.

For StoryForge, I didn't need a vector database or complex memory architecture.

The last few stories provide enough information for the AI to understand what it has recently created and move in a different creative direction.

Step 4: Generate a fresh story with Groq

The Lambda function sends the generation request to the Groq API.

Groq acts as the creative AI engine, while AWS handles the infrastructure, automation, storage, and security surrounding the agent.

The AI returns a structured story containing:

Title
Genre
Theme
Setting
Summary
Full story
Moral

The Lambda validates the response before saving it.

If the AI returns malformed or incomplete data, the system handles the failure safely instead of storing corrupted information.

AWS Architecture

The architecture is intentionally simple and serverless:

EventBridge Scheduler
        ↓
AWS Lambda
        ↓
Amazon DynamoDB
        ↓
Groq API
        ↓
Amazon DynamoDB
        ↓
API Gateway
        ↓
Static HTML, CSS and JavaScript
        ↓
Amazon S3

AWS Services Used

AWS Lambda: Autonomous story-generation agent and backend API logic
Amazon DynamoDB: Story storage and lightweight memory
Amazon EventBridge Scheduler: Automatically wakes the agent every day
Amazon API Gateway HTTP API: Connects the frontend with the backend
AWS Secrets Manager: Securely stores the Groq API key
Amazon S3: Hosts the static frontend
Amazon CloudFormation: Infrastructure as Code and automated deployment
Amazon CloudWatch Logs: Monitoring and debugging

Security

The Groq API key is never exposed in the frontend or committed to source code.

It is securely stored in AWS Secrets Manager, and Lambda retrieves it using IAM permissions following the principle of least privilege.

Frontend
    No API Key
        ↓
API Gateway
        ↓
Lambda
        ↓
AWS Secrets Manager
        ↓
Groq API

Why HTML, CSS, and Vanilla JavaScript?

I deliberately kept the frontend simple.

The goal wasn't to demonstrate a complex frontend framework. The focus was on the autonomous AI agent architecture.

The frontend only needs to:

Display today's story
Browse previous stories
View individual stories
Communicate with the backend API

HTML, CSS, and vanilla JavaScript were enough.

This allowed me to focus on:

Automation, Memory, AI, and Serverless Architecture

Challenges and Key Decisions

The biggest challenge was balancing the idea of an AI agent with the need to keep the project simple.

It would have been easy to add:

Vector databases
Complex agent frameworks
Multiple AI models
Several interacting agents

But those additions weren't necessary for this use case.

Instead, I focused on the essential characteristics of an always-on agent:

It acts without waiting for the user.
It runs on a schedule.
It remembers recent context.
It uses that context to influence its next action.
It creates something new.
Its output is ready when the user returns.

Why DynamoDB Was Enough for Memory

A major lesson from this project was that not every AI agent needs a complex memory system.

For StoryForge, the agent only needs to know what it created recently.

Retrieving recent:

Titles
Genres
Themes
Settings
Summaries

provides enough context to encourage creative variety.

Sometimes the simplest memory architecture is the one that best fits the problem.

What I Learned

Building StoryForge helped me better understand:

Serverless Architecture

How Lambda, API Gateway, DynamoDB, and S3 can work together to create a complete application without managing servers.

Event-Driven Automation

How EventBridge Scheduler can transform a traditional reactive AI application into an always-on system.

Instead of:

User → Request → AI → Result

The workflow becomes:

Schedule → Agent → Memory → AI → Storage → User discovers the result

The user is no longer responsible for initiating every action.

Lightweight Agent Memory

Not every agent needs a vector database or complicated retrieval system.

For StoryForge, DynamoDB provides enough recent context to influence future generations.

Infrastructure as Code

CloudFormation makes infrastructure deployment more repeatable and consistent while reducing manual configuration.

Secure AI Integration

AWS Secrets Manager keeps the Groq API key away from the frontend and source code, while IAM controls access.

What's Next?

StoryForge currently focuses on one simple promise:

A new story every day.

In the future, I would like to explore allowing the agent to develop a stronger creative identity over time.

It could:

Analyze patterns in previous stories
Experiment with different narrative styles
Track genres it has used most
Explore underused creative directions
Adapt to genres users enjoy

But for now, I intentionally kept the project focused.

Final Thoughts

StoryForge proves that an always-on AI agent doesn't need to be complicated.

Sometimes, all it takes is:

A scheduled event, a little memory, an AI model, storage, and the ability to act while the user is away.

That combination can transform a traditional reactive AI application into something proactive.

The key idea behind StoryForge is simple:

The user doesn't have to ask for creativity every day. The system can create while they're away.

StoryForge in One Sentence

StoryForge is an always-on AI storytelling agent that automatically remembers its recent stories, creates a new one every day using Groq, and saves it with AWS before the user even opens the app.

Try StoryForge

Live App:
Open StoryForge

Building ByteMentor AI: An Always-On Learning Agent with AWS Serverless | 10 Days of Building AI Agents on AWS | Day 2

abdullah haroon — Fri, 24 Jul 2026 05:00:00 +0000

Self-learning has never been easier, yet staying consistent remains one of the biggest challenges. We have access to countless tutorials, courses, documentation, and videos, but deciding what to learn next often becomes a task of its own. Even after choosing a topic, preparing study material, finding practice exercises, and creating revision questions can consume valuable time before any actual learning begins.

I wanted to solve this problem by building ByteMentor AI, an autonomous learning companion that prepares personalized daily learning content before the learner even opens the application.

Instead of functioning as another AI chatbot that waits for user input, ByteMentor proactively generates structured learning sessions on a schedule. Every day, it analyzes the learner's roadmap, determines the next topic, generates a complete lesson with practical examples, coding exercises, quizzes, and revision material, then stores everything so it is immediately available when the learner returns.

The objective was straightforward:

Allow learners to focus on learning instead of planning what to learn.

The Idea

Learning roadmaps have become increasingly popular, but they usually stop after listing topics in order. The learner is still responsible for researching each concept, finding quality resources, and deciding what to study every day.

I wanted to extend the roadmap into something more intelligent.

Instead of simply displaying a list of topics, ByteMentor continuously transforms that roadmap into daily learning sessions. Once a roadmap has been created, the application knows exactly what should come next and prepares everything automatically.

Each generated lesson includes:

Detailed explanation of the topic
Practical coding examples
Hands-on programming exercises
Multiple-choice quiz questions
Learning summary
Productivity tips

When the learner opens the application, today's lesson is already waiting.

System Architecture

                GitHub
                   │
                   ▼
             AWS Amplify
                   │
                   ▼
          React + TypeScript
                   │
                   ▼
            Amazon API Gateway
                   │
                   ▼
              AWS Lambda
        (ByteMentor AI Agent)
           │             │
           ▼             ▼
        Groq API     DynamoDB
           ▲             │
           └──────┬──────┘
                  ▲
                  │
      Amazon EventBridge Scheduler

Each AWS service is responsible for a single part of the workflow, resulting in a scalable and event-driven architecture.

Frontend

The frontend is built using:

React
TypeScript
Vite
Tailwind CSS

The interface allows learners to:

Generate personalized learning roadmaps
View today's lesson
Browse previous lessons
Track learning history

The application is deployed using AWS Amplify, which automatically builds and deploys the frontend directly from GitHub.

Backend

The backend is built using Node.js and AWS Lambda.

Amazon API Gateway exposes REST endpoints that communicate with Lambda functions responsible for handling business logic.

The backend is responsible for:

Reading learning roadmaps
Determining the next lesson
Generating AI content
Saving generated lessons
Retrieving previous learning sessions

Because everything runs inside Lambda, there are no servers to manage, making the application lightweight and cost-effective.

AI Content Generation

ByteMentor integrates with a large language model to generate structured educational content.

Rather than requesting plain text responses, the application prompts the model to return structured JSON, making it easy to render lessons consistently across the interface.

Each lesson contains:

Topic overview
Step-by-step explanation
Code snippets
Practical exercise
Quiz questions
Key takeaways

This approach creates a much richer learning experience than simply displaying AI-generated paragraphs.

Persistent Storage

Amazon DynamoDB stores all generated learning content.

This includes:

Learning roadmaps
Daily lessons
Learning history
Generated quizzes
Coding exercises

Since lessons are stored after generation, learners can revisit previous sessions without requiring the AI model to generate them again.

Making the Agent Autonomous

The defining feature of ByteMentor is that it operates proactively rather than reactively.

Instead of waiting for a user to request a lesson, Amazon EventBridge Scheduler automatically invokes the Lambda function every morning.

The scheduled workflow looks like this:

EventBridge Scheduler
        │
        ▼
AWS Lambda
        │
        ▼
Read learning roadmap
        │
        ▼
Determine today's topic
        │
        ▼
Generate lesson
        │
        ▼
Create coding challenge
        │
        ▼
Generate quiz
        │
        ▼
Store in DynamoDB
        │
        ▼
Lesson ready before user logs in

This means the learner is welcomed with fresh learning content every day without initiating any manual action.

AWS Services Used

The project combines several AWS services into a single serverless workflow.

AWS Amplify
Amazon API Gateway
AWS Lambda
Amazon EventBridge Scheduler
Amazon DynamoDB
Amazon CloudWatch
AWS IAM
AWS SAM

Each service contributes a focused responsibility, making the system easy to maintain and extend.

Development Process

The project began with designing a clean learning workflow rather than focusing solely on AI generation.

The roadmap became the central source of truth for determining future lessons. Once that workflow was established, the backend was designed around AWS Lambda functions capable of generating and storing lessons independently.

The frontend was then built to consume those generated lessons, allowing users to view content without worrying about how or when it was created.

Finally, EventBridge Scheduler transformed the application from an on-demand AI tool into an autonomous learning agent by moving lesson generation to a scheduled background process.

What I Learned

Building ByteMentor provided valuable experience across several AWS services and architectural patterns.

Some of the key takeaways include:

Designing event-driven serverless applications
Building production deployments using AWS SAM
Using Amazon EventBridge Scheduler for background automation
Connecting API Gateway with AWS Lambda
Designing DynamoDB data models
Building structured AI prompts that consistently return machine-readable responses
Separating frontend and backend responsibilities for easier maintenance

More importantly, the project reinforced the idea that AI becomes significantly more useful when it performs work proactively instead of waiting for user requests.

Future Improvements

There are several features I plan to add in future iterations:

Amazon Cognito authentication
Progress tracking and learning analytics
Achievement badges and learning streaks
PDF lesson exports
Voice narration
AI-generated diagrams
Spaced repetition for long-term retention
Multi-user support

These additions will further enhance the personalized learning experience while maintaining the autonomous nature of the platform.

Conclusion

ByteMentor AI demonstrates how serverless AWS services can be combined to create an autonomous learning system that works continuously in the background.

By leveraging AWS Lambda, EventBridge Scheduler, DynamoDB, API Gateway, and Amplify, the application generates personalized learning sessions without requiring user intervention. Instead of deciding what to study every day, learners can simply open the application and begin learning immediately.

Building this project was an excellent opportunity to explore event-driven architectures, serverless development, and AI-powered automation while creating a practical solution to a real productivity problem.

Live Demo

https://main.d2qeklo0lut2is.amplifyapp.com/

GitHub Repository

https://github.com/ABDULLAH408/ByteMentor_AI

Building FocusAI: Simplifying Daily Task Planning: 10 Days of Building AI Agents on AWS | Day 1

abdullah haroon — Thu, 16 Jul 2026 22:05:58 +0000

Every morning begins the same way. I sit down, make a list of everything I need to accomplish, and then spend several minutes deciding where to start.

The challenge is rarely creating the list. The real challenge is prioritizing it.

Some tasks are urgent. Others are important but not time-sensitive. Some can wait until later in the day. Deciding what deserves immediate attention often becomes a task of its own, creating unnecessary friction before any real work has even started.

That everyday problem inspired me to build FocusAI, an AI-powered productivity assistant that helps transform a simple list of tasks into a structured action plan.

Rather than replacing project management platforms or adding another complex productivity system, FocusAI focuses on solving one specific problem:

What should I work on first today?

The objective was straightforward. Build a practical application that removes the mental overhead of planning the day so users can spend more time doing meaningful work.

The Idea Behind FocusAI

There is no shortage of productivity applications available today. Most of them are packed with features such as project management, kanban boards, recurring tasks, collaboration tools, reminders, calendars, and detailed reporting.

While these tools are incredibly powerful, they can also introduce additional complexity for someone who simply wants to organize today's workload.

FocusAI takes a different approach.

Instead of asking users to create projects, assign priorities, organize boards, or maintain workflows, it asks for only one thing:

Your list of tasks.

Once the tasks are submitted, FocusAI analyzes them using generative AI and produces an organized action plan within seconds.

The experience is intentionally lightweight, allowing users to focus on execution rather than planning.

What FocusAI Does

The workflow is designed to be as simple as possible.

Enter or paste your list of daily tasks.
Click Prioritize My Day.
Receive an AI-generated plan almost instantly.

For every task, FocusAI generates:

Priority level
Estimated completion time
Recommended first step
Reasoning behind the recommendation

In addition to task-level insights, the application also provides:

A summary of the day's workload
A productivity tip based on the submitted tasks

The interface intentionally avoids unnecessary features and distractions. Every design decision was made with one goal in mind: helping users start working as quickly as possible.

Architecture

From the beginning, I wanted the application to be fully serverless.

A serverless architecture removes the need to manage infrastructure while providing scalability, reliability, and a streamlined deployment process.

The overall architecture looks like this:

React + Vite
      │
      ▼
AWS Amplify
      │
      ▼
Amazon API Gateway
      │
      ▼
AWS Lambda
      │
      ▼
Amazon Bedrock
(Amazon Nova Lite)
      │
      ▼
AI Generated Productivity Plan

Technology Stack

The frontend was built using React and Vite, providing a fast development experience and a responsive user interface.

The application is hosted on AWS Amplify, which automatically builds and deploys new versions whenever changes are pushed to GitHub.

The backend consists of an AWS Lambda function exposed through Amazon API Gateway.

When a user submits their tasks, the Lambda function constructs a structured prompt and sends it to Amazon Bedrock, where Amazon Nova Lite analyzes the task list and generates recommendations.

The response is then returned to the frontend and presented as a clean, structured productivity plan.

AWS Services Used

FocusAI is built using the following AWS services:

AWS Amplify
Amazon API Gateway
AWS Lambda
Amazon Bedrock
Amazon Nova Lite
Amazon CloudWatch
AWS Identity and Access Management (IAM)

GitHub is used for source control and continuous deployment.

Designing for Reliability

One aspect I wanted to address early in development was reliability.

AI-powered applications should continue to provide value even when AI services are temporarily unavailable because of quota limits, service interruptions, or network issues.

To handle these scenarios, I implemented a fallback planner.

Whenever Amazon Bedrock cannot process a request, the application automatically generates a structured productivity plan using predefined prioritization logic instead of returning an error.

Although the fallback is not as sophisticated as the AI-generated response, it ensures the application remains functional and useful under all circumstances.

This small addition significantly improved both the user experience and the resilience of the application.

Challenges Along the Way

Like most cloud-native applications, the majority of the work involved connecting services together rather than building the interface itself.

Some of the biggest challenges included:

Configuring Amazon API Gateway correctly
Resolving CORS issues between the frontend and backend
Setting up IAM permissions for Amazon Bedrock
Debugging Lambda function execution
Successfully invoking Amazon Nova Lite through Bedrock
Monitoring requests using Amazon CloudWatch Logs
Managing deployment through AWS Amplify

Working through these challenges provided valuable hands-on experience with AWS services that is difficult to gain from documentation alone.

Key Takeaways

Building FocusAI strengthened my understanding of modern serverless application development.

Some of the most valuable lessons included:

Building scalable applications with AWS Lambda
Deploying frontend applications using AWS Amplify
Creating REST APIs with Amazon API Gateway
Integrating foundation models through Amazon Bedrock
Managing permissions securely with IAM
Using CloudWatch for monitoring and debugging
Designing graceful fallback mechanisms for AI-powered systems

Perhaps the most important lesson was that AI should enhance an application rather than become a dependency that prevents it from functioning.

Building software that continues to deliver value even when intelligent services are unavailable is an important aspect of creating reliable user experiences.

Future Improvements

There are several features I would like to explore in future iterations of FocusAI.

Some of the planned improvements include:

User authentication with Amazon Cognito
Productivity history and analytics
Weekly productivity reports
Calendar integration
Meeting summarization
AI-generated daily schedules
Smart reminders and notifications

These additions would allow FocusAI to evolve from a daily planning assistant into a more complete productivity companion while maintaining its simplicity.

Live Demo

Try FocusAI

https://main.d10s0skyfp0lmj.amplifyapp.com/

Source Code

GitHub Repository

https://github.com/ABDULLAH408/FocusAI

Closing Thoughts

Building FocusAI was an opportunity to explore how modern serverless technologies and generative AI can work together to solve an everyday problem.

The project reinforced an idea that I find increasingly important in software development. Great applications do not always need dozens of features. Sometimes the best solution is the one that removes a small but recurring source of friction from a user's day.

FocusAI was built with that philosophy in mind.

It takes a simple list of tasks and turns it into a clear plan, allowing users to spend less time deciding what to do next and more time making meaningful progress.

I hope you find it useful, and I would love to hear your feedback or suggestions for future improvements.

Thank you for reading.

Day 6: Why Vibe Coding Fails in Production (And How Kiro Helps to Fix It)

abdullah haroon — Mon, 18 May 2026 09:17:00 +0000

After building a project using Kiro’s spec-driven development workflow and comparing it with tools like Cursor and GitHub Copilot, one thing became very clear: AI coding itself is not the issue. The real problem is how we approach it.

Most developers today are unintentionally practicing what is now called “vibe coding”, a workflow where you rely heavily on AI prompts, quick iterations, and instant code generation without properly designing the system beforehand. It feels fast, flexible, and even powerful in the beginning. But when you try to take that same approach into production-level systems, the cracks start to show.

What Vibe Coding Actually Looks Like

Vibe coding usually starts with a simple prompt. You ask the AI to build something like a game, a dashboard, or a backend system, and it immediately generates working code. From there, you keep improving it step by step using follow-up prompts such as “fix this bug,” “add this feature,” or “make it cleaner.”

At first, this feels like rapid development. You are building fast, seeing instant results, and constantly moving forward. But the issue is that there is no real system design behind the code. Everything is being added reactively instead of being designed intentionally.

Why Vibe Coding Breaks in Production

The biggest problem with vibe coding is that it works only in the early stage. As the project grows, structure starts to break.

First, architecture becomes unclear because features are added through separate prompts, leading to inconsistent code organization. Second, context starts to degrade, and AI may lose track of earlier decisions. Third, complexity increases uncontrollably because everything is patched together instead of being designed properly. This is the point where projects start becoming hard to maintain.

My project Experience

I noticed this clearly while building Flappy Bird in Node.js. At the start, everything was smooth and fast. But as more features were added, the logic started overlapping, debugging became harder, and small changes affected other parts of the game. It felt productive at first, but over time, the lack of structure started creating problems.

How Kiro Changes the Workflow

Kiro solves this by introducing spec-driven development. Instead of jumping straight into prompts like “build Flappy Bird,” you first define a structured specification describing how the system should work.

In my case, I defined gameplay rules like gravity, pipes, scoring, and collision before any code was generated. Kiro then built the implementation based on that structure. This shifts development from reactive coding to intentional system design.

From Reactive to Structured Development

In vibe coding, you fix problems after they appear. In Kiro, you define the system first, and most issues never appear in the first place. This makes development more controlled, predictable, and structured.

Why Structure Matters More Than Speed

Most AI tools focus on speed, but speed without structure does not scale. Vibe coding works well for prototypes and experiments, but breaks down in larger systems because complexity grows too quickly. Kiro solves this by introducing structure before code exists

Final Thoughts:
AI development is evolving from fast code generation to structured system design.Copilot helps you write faster, Cursor helps you work with code, but Kiro helps you define systems before they are built. And that’s the key difference.

Vibe coding fails in production not because AI is weak, but because structure is missing from the process.

Day 5: Kiro vs Cursor vs GitHub Copilot (Real Developer Comparison)

abdullah haroon — Sun, 17 May 2026 08:00:00 +0000

After building a project in Node.js using Kiro’s spec-driven workflow, We started to clearly understand where Kiro stands in the AI development ecosystem. Up until now, I had used multiple AI coding tools in real projects: Cursor, GitHub Copilot, and now Kiro, but this was the first time I compared them from a workflow perspective, not just feature lists. And honestly, the difference is not just in “code quality.” It’s in how each tool shapes the way you think while building software.

Understanding the Three Tools First

Before comparing them, it’s important to understand what each tool is actually optimizing for.

GitHub Copilot is mainly focused on speed. It helps you write code faster inside your editor by suggesting completions as you type. It’s great for small improvements and boilerplate reduction, but it still depends heavily on your own structure.

Cursor takes things a step further. It’s more like an AI-native IDE where you can chat with your codebase. It understands context better than Copilot and allows more interactive development, especially for debugging and refactoring.

Kiro on the other hand, feels different. It is not just trying to help you write code faster, it is trying to enforce a development structure through spec-driven development.

That distinction is where everything starts to change.

Workflow Comparison (The Real Difference)

When I built a project in Node.js using Kiro, the workflow started with a spec. That single change affects everything downstream.

With Kiro, I first defined behavior, system design, and features before writing any code. The AI then generated implementation based on that structure.

In Cursor and Copilot, the workflow is more direct. You start coding or prompting immediately, and structure evolves naturally through iteration.

This difference might seem small, but it completely changes how your project grows over time.

Kiro forces intent-first development.
Cursor and Copilot encourage code-first development.

Code Structure and Architecture Handling

This is where the gap becomes very visible. With GitHub Copilot, code structure depends entirely on the developer. It is excellent at completing functions and reducing repetitive work, but it does not guide architecture decisions. Cursor improves this by understanding more of the project context. It can refactor files, explain logic, and assist in debugging across multiple files.

But Kiro goes one level higher, it tries to shape the architecture before the code even exists. Because everything starts from a spec, the structure is more intentional from the beginning. In my Node.js project, this was very noticeable. Kiro naturally separated game logic into clear modules instead of dumping everything into one file.

AI Interaction Style

The interaction style of each tool is also very different.

Copilot feels passive. It waits for you to write code and then predicts what comes next.

Cursor feels conversational. You actively discuss your codebase with the AI and iterate through changes.

Kiro feels directive in a different way. You are not just chatting or coding, you are defining system behavior through structured specifications, and the AI executes based on that. This makes Kiro feel less like an assistant and more like a system builder.

Debugging and Iteration

Debugging is where Cursor really shines. When something breaks, Cursor can analyze your project, suggest fixes, and even refactor multiple files at once. It feels very practical for real-world development.

Copilot is weaker here because it does not fully understand project-wide context.

Kiro approaches debugging differently. Instead of directly patching code, you often go back and refine the spec. The system then regenerates or adjusts implementation based on updated requirements.

Speed vs Structure vs Control

Each tool optimizes for something different.

Copilot optimizes for speed of writing code.
Cursor optimizes for interactive development and debugging.
Kiro optimizes for structured system design through specs.

When we used them in real projects, this difference became very clear.

If you want quick code snippets, Copilot is enough.
If you want full project-level AI assistance, Cursor is very strong.
If you want structured AI-native development, Kiro feels more forward-thinking.

Final Outcome

After using all three tools in real development scenarios, we realized they are not direct replacements for each other. They represent different stages in the evolution of AI-assisted development.

Copilot represents the first phase: autocomplete intelligence.
Cursor represents the second phase: conversational coding.
Kiro represents a third phase: structured AI-native development.

And that third phase is what makes Kiro interesting.

It is not trying to replace developers.It is trying to change how developers think before they even write code.