DEV Community: Malawige Inusha Thathsara Gunasekara

Built an AI Study Tool That Refuses to Give You the Answers for UoM

Malawige Inusha Thathsara Gunasekara — Sun, 01 Mar 2026 17:10:22 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I am an IT undergraduate at the University of Moratuwa(UoM), Sri Lanka. In our community, the night before a brutal technical exam is chaotic. When faced with a massive, complicated past-paper question that we don't understand, students often hit a wall of panic and just give up (we call it going "Bora").

The problem with existing AI study tools is that they just give you the final answer or the raw code. That doesn't help you learn; it just helps you cheat. I wanted to build a tool for my batchmates that acts like a senior student holding a late-night study session(a "Kuppi") guiding you to the answer without actually giving it to you.

What I Built

I built Triage AI, a cross-platform (Next.js Web + Flutter Android) tool designed specifically for technical exam preparation. You simply snap a photo of a difficult past paper question, and the app uses AI to break it down.

Instead of solving the problem, it returns three specific things:

Core Concepts: The exact fundamental topics you need to Google to understand the question.

The Trap: It identifies the subtle pitfall or trick hidden in the question designed to make students fail.

Attack Plan: A step-by-step strategic breakdown of how to approach the solution.

If you are still stuck, Triage AI features a "Practice" mode that generates a similar question, and a "Hint" system that provides progressive, helpful nudges (never the answer) to get you unblocked.

Demo

Live: Vercel
This weekend sprint proved to me that AI doesn't have to be a shortcut that ruins learning. When built with the right constraints, it can be the ultimate teaching assistant.

Code

Source Code: Github

How I Built It

Balancing this weekend challenge with my strict university workload was tough. As an IT undergraduate, I couldn't afford to ignore my own university assignments to build an app. Because I was juggling coursework and only had the weekend to code, I needed to keep the technical setup extremely lean and fast.

The Brain: I used the Google Gemini 2.5 Flash API because it can process uploaded images incredibly fast.

The Logic: I built a Next.js application to handle the requests. I wrote strict prompts and set up Gemini to return structured data, which made it easy to display the results in clean UI cards.

The App: The Next.js backend powers both a smooth React web app and a native Flutter Android app(kinda buggy though) at the same time.

Aside from time management, the hardest technical challenge was the Hint System. To ensure the AI didn't repeat itself or accidentally reveal the answer, the app keeps track of the clues you've already seen. It sends this history back to Gemini so that the next hint is a progressively more specific nudge in the right direction.

Good luck with exams, batchmates!

How I Built a 15,000+ Line Flutter App with Gemini to "Hack" My University Attendance

Malawige Inusha Thathsara Gunasekara — Wed, 25 Feb 2026 18:55:37 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

As an IT undergraduate balancing startup ambitions and a heavy coursework load, missing too many classes can lead to disastrous exam bans. To solve this, I built Attendance Tracker (code-named "The 80%"). It's a cross-platform Flutter application designed to mathematically optimize university attendance using offline-first storage and AI.

The app features a "Danger Zone Planner" that calculates the exact margin for absences across specific sessions (Lectures, Labs, Tutorials). This allows students to simulate granular scenarios and understand their attendance buffer, ensuring they never accidentally drop below their mandatory academic thresholds.

Google Gemini played a massive, two-fold role in this project:

The Architecture (Agentic AI): This project scaled to over 15,000 lines of code. I used the Gemini 3 Pro (High) model inside the Antigravity IDE as an autonomous coding agent to help architect the offline-first database (Hive), manage state (Provider), and handle complex UI animations.
The Core Feature (API Integration): The biggest friction point in attendance apps is manual data entry. I integrated the Gemini 2.5 Flash API to handle multimodal timetable extraction. Users simply upload their official university schedule as a PDF or image, and Gemini intelligently parses the unstructured data into a clean matrix of subjects, times, and session types.

Demo

You can experience the live web app directly in your browser:

Live Web App: Attendance Tracker Web

Source Code: GitHub Repository (Only the Demo source code is available with the latest apk releases)

Screenshot:

What I Learned

Building a 15,000+ line production app taught me several critical lessons:

Background Asynchronous Processing: Because parsing detail-heavy timetable PDFs via the Gemini API can take time, I had to learn how to run these complex tasks in the background. This ensures the UI doesn't freeze, allowing users to navigate the app while waiting for an in-app "Timetable Ready" notification.
Defensive Engineering: AI isn't perfect. I learned to build a robust "Draft Review" step so users can verify and edit the AI's extracted timetable before committing it to the Firebase database.
System Design: Implementing an offline-first architecture with Hive local caching and syncing it seamlessly with Firebase Firestore taught me how to handle complex data states across varying network conditions.

Google Gemini Feedback

The Good:
The multimodal capabilities of gemini-2.5-flash are incredible. It flawlessly handled messy, poorly formatted university PDFs and images, turning unstructured visual data into a clean, usable dataset. Using Gemini 3 Pro (High) as an agentic coding partner felt like having a senior engineer on call, saving me weeks of boilerplate coding and UI tweaking.

The Bad and The Ugly:
When you let an AI agent loose on a 15,000-line codebase, you push context windows to their absolute limits. Occasionally, the IDE agent would lose the thread of the architecture, hallucinating variable names or forgetting how distant files interconnected.

On the API side, relying heavily on Gemini 2.5 Flash for file parsing introduced the reality of rate limits. To prevent the app from breaking for users during high-traffic periods, I had to engineer a Multi-API Key Support system, allowing the app to rotate through different user-provided Gemini keys to ensure uninterrupted parsing. Additionally, highly non-standard timetable layouts occasionally confused the model, making the manual draft review step an absolute necessity. Overall, it's a powerhouse, but it requires strict guardrails in a production environment.

The Shores of Denial – The World that Shouldn't Exist

Malawige Inusha Thathsara Gunasekara — Fri, 23 Jan 2026 13:23:07 +0000

My Voluntary Descent

When I first stepped onto the Fort Oasis pier as Tyler, the atmosphere was immediately suffocating. My first instinct wasn't to explore, it was to leave. I was given the functioning boat , then took the exit, and triggered the ending within minutes. But as the credits rolled, I realized I hadn’t actually played the game; I had simply committed a "coward’s move." I chose the "Safe Lie" because the reality of the island was too unsettling. I believe everyone have tried that in their first playthrough.

On my second run, I refused the boat. I stayed because I wanted the content. By staying, I felt like I was actively validating Tyler’s internal chaos. The game stopped being a survival horror and started feeling like a psychological autopsy I was performing on myself.

Navigating a Broken Mind

As I explored Fort Oasis, I realized it isn't just a game with a map; there are some metaphors. Since the game doesn't tell us the direct story, I explored the internet and found that the story explains about the terminal disease and the depression on the character I'm playing. I began to see the environment as a manifestation of Tyler’s isolation:

The Mining Colony: This is the skeletal remains of a life once filled with productivity and purpose, now hollowed out.
The Rot: The black, organic corruption "overwrite" the walls was visceral. It’s the visual language of a terminal illness that doesn't just inhabit the world but replaces it.
The Permafrost: The cold represents an emotional numbness I think Tyler uses to shield himself from the memory of Leda’s love (Leda is Tyler's wife). It is the "Distant Embrace" of a death that has already begun.

The Realization of the Mission

In the beginning, I followed the story believing I was on a rescue mission. However, the deeper I went, the more I felt manipulated. I wasn't there to save a colony; I was there to witness the final shutdown of me(actually the Tyler).

The most haunting part of my experience was the silence. Before the monsters ever appeared, the weight of being all alone in a dying world was more terrifying than any jump-scare. That silence is the bridge between Tyler’s past and the "Total Chaos" of his current mental state and the void left behind when love is replaced by a diagnosis.

I Built a Cyberpunk Terminal Portfolio with Next.js, Antigravity and Gemini AI

Malawige Inusha Thathsara Gunasekara — Fri, 16 Jan 2026 19:16:04 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

I’m Inusha Gunasekara, an IT undergraduate at the University of Moratuwa, Sri Lanka, and the co-founder of Tekkeys, where we're building agentic AI tools.

For this challenge, I didn’t want to build just another "landing page." I wanted to build a Digital Twin. I conceptualized "System 1"—a sentient, terminal-based operating system that represents my skills, projects, and personality as code. The goal was to create an interface that feels alive, combining the raw utility of a CLI with the polished aesthetics of a cyberpunk interface.

I initially engineered the system as a fully autonomous clone powered by the Gemini 2.5 Flash-Lite API. However, to guarantee 100% uptime and zero latency for public access, I pivoted the architecture to a deterministic "Simulation Mode." This hybrid approach preserves the sentient "vibe" of the AI while ensuring the reliability required for a production-grade portfolio.

Portfolio

https://inusha-portfolio-326006174526.us-central1.run.app

(Type "help" to see available commands, or try "projects" to see what I'm working on.)

How I Built It

My portfolio is a Stateless Terminal built for extreme performance, security, and zero-cost scaling.

The Tech Stack:

Framework: Next.js 16 (App Router) for the core React architecture.
Styling: Tailwind CSS v4 for the utility-first, cyberpunk aesthetic.
Infrastructure: Google Cloud Run (Serverless) for scalable, containerized deployment.
Containerization: Docker (Multi-stage build) using the standalone output mode.

The "Digital Twin" Architecture:
The core of this project is "System 1"—a digital representation of my persona.

Initial Prototype: I originally built a fully autonomous agent using the Gemini 2.5 Flash-Lite API. While powerful, I identified that relying on a metered API for a high-traffic public landing page introduced potential latency and quota risks ("The Reddit Hug of Death").
Production Optimization: To ensure a production-grade user experience, I engineered a Deterministic Simulation Engine. This engine mimics the streaming "typing effect" of an LLM but pulls from an optimized, local knowledge graph. This decision reduced API latency from ~400ms to <5ms and eliminated all running costs, while preserving the "sentient" feel of the terminal.

Deploying to Google Cloud Run:
I chose Cloud Run for its "Scale to Zero" capability. By using a multi-stage Dockerfile, I reduced the final container size by approximately 80%. This ensures the portfolio spins up instantly when a user visits but costs $0 when idle.

What I'm Most Proud Of

1. The "Halt Sequence" (`sudo delete`)

I wanted the terminal to feel like a real, vulnerable operating system, not just a read-only website. I implemented a hidden "kill switch" where users can type sudo delete followed by confirm. This triggers a dramatic, system-wide crash simulation—turning the screen black and forcing a "reboot" sequence. It adds a layer of gamification that encourages users to explore the boundaries of the interface.

2. Engineering the "Simulation Engine"

While it was tempting to keep the live Gemini API connection, I am most proud of the decision to build a Deterministic Simulation Engine. I realized that for a portfolio, reliability is a feature. By architecting a local "mock stream" that replicates the exact typing patterns and latency of an LLM, I achieved the "sentient AI" feel without the risk of API quotas or network latency. It taught me that sometimes the best engineering solution is removing a dependency, not adding one.

3. Secure Live Data (Gas Tracker)

I built a real-time Ethereum Gas Tracker that fetches live data from Etherscan. Instead of exposing my API keys on the client side, I built a secure Next.js Server-Side Proxy. This route acts as a gateway, injecting the secrets on the server before forwarding the request to Etherscan.

4. The "Cyberpunk" Polish

I spent significant effort fine-tuning the visual details. Balancing these high-fidelity "glitch" effects with the performance requirements of a web app (using Tailwind CSS v4) was a rewarding challenge in frontend optimization.

Check The portfolio live in action: https://inusha-portfolio-326006174526.us-central1.run.app

The Features I Killed to Ship "The 80%" App in 4 Weeks

Malawige Inusha Thathsara Gunasekara — Mon, 12 Jan 2026 15:02:41 +0000

I almost fell into a trap believing that "more features" equals a "better product." When I started building The 80%, an assistant tool which helps students to keep track of their attendance, medicals and GPA. I had a strict four-week deadline to ship a production-ready attendance tracker. I quickly realized that if I tried to build everything I wanted, I would never ship what the user needed. Then I remembered what Elon Musk said, "The Best Part is No Part." I didn't just cut features to save time; I cut them to save the architecture from unnecessary complexity.

Here are the five worth-mentioning features I killed in The 80%.

1. The Backup Server Trap

I wasted the first few days being obsessed with 100% uptime. I wanted to build a secondary failover server just in case Firebase went down. I realized I was solving an imaginary problem. Firebase has 99.99% uptime, while the probability of my users having poor campus Wi-Fi is high. The real risk wasn't Google servers failing. It was the connection dropping between the classroom and the cloud. I abandoned the backup server entirely and embraced an Offline-First Architecture using Hive. By treating the user's device as the primary data source, the app works perfectly regardless of server status, I learned that I shouldn't build complex distributed systems when a local database solves the actual problem.

2. The Medical Cloud Storage Nightmare

I planned to add a feature allowing students to upload photos of their medical certificates to the cloud so they would never lose them. But as I designed it, two major problems appeared: the extreme cost of storing images for thousands of users on the Firebase Free Tier, and the liability of holding Personally Identifiable Information (PII). If I held medical records, I was responsible for protecting them from data breaches. As a student developer, I didn't want the risk of a data breach hanging over my head. To solve this, I built the "The Local Wallet." within the app itself. Instead of uploading files, the app simply saves the images in the device's local sandbox and stores a link to the file path. The data stays 100% on the user's phone, resulting in zero cloud costs and zero privacy liability. I learned that the most secure data is the data you never collect.

3. The "Automated Email" Fantasy

I wanted to build a productivity hack where the app would automatically send official emails from the student's university account using SMTP or OAuth. It sounded like a great productivity hack until I looked at the technical reality. University firewalls and Multi-Factor Authentication (MFA) makes this feature hard to implement. Making it work I had two bad choices.

Requesting Credentials from the User: Asking users for their university passwords which leads to a a massive security violation that looks exactly like phishing. or
Enterprise Verification: I would have to navigate the university's bureaucracy to get official OAuth approval. I avoided this method in order to reduce the complexity of the app. I killed this automation entirely and stuck with the traditional email flow. The app automatically opens the default email app, then the user can send the drafted email with the medical report. I learned two major lessons here. First one is "Trust is harder to build than a feature." And as developers we shouldn't compromise security for a "cool" automation.

4. All University Supported Grading System

I had a plan to create a database containing the grading scales for all major universities all around the world to automate the GPA calculation process. But I quickly realized that this needs constant maintainability, which I don't have time to do as a undergraduate. It would require weeks of manual data entry and maintenance, and if a university changed their grading policy, my app would be instantly outdated. It simply wasn't worth the effort for my app. Instead, I built a feature that allows the user to configure their own grading scale. This taught me that when shipping, flexibility is often better than hard-coded perfection.

5. Sync Custom Profile Picture Across Devices

I wanted users to be able to pick a photo from their gallery and have that custom profile picture sync across all their devices via Firebase. This led me to the "Cost" problem again. I would need a paid Firebase plan to store these custom images, or I would have to bloat the database by storing base64 strings, which requires unnecessary processing power and time. I compromised by removing the ability to upload custom photos and instead provided a set of high-quality, pre-defined 3D avatars. I only sync the Avatar ID (a simple integer) across devices, keeping the data transfer minimal. This was a valuable lesson in distinguishing between what is needed (identifying users) versus what is wanted (full customizability).

Conclusion

It is easy to add features. It is hard to remove them. By killing these features, I didn't just save time; I built a product that is faster, cheaper to run, and more secure. I learned that my job isn't to build the most complex version of an idea, but to ship the version that actually works. The 80% proved to me that sometimes, the best code is the code you delete.

🔗 Explore the Project

📂 GitHub Repository: View the demo code and releases
📝 Project Documentation: Read the Notion Docs

Building AI Agents: Concepts & Architecture

Malawige Inusha Thathsara Gunasekara — Wed, 07 Jan 2026 15:11:40 +0000

If you look past the hype cycle, AI Agents represent a fundamental shift in how we write software. We are moving from defining how a task is done (traditional automation) to defining what the goal is and letting the system figure out the rest.

This article breaks down the conceptual architecture of AI agents, how they differ from standard automation, and the memory systems required to make them actually useful.

The Core Definition: What is an Agent?

An AI Agent is a computational entity that acts independently on a user's behalf. Unlike a standard script that executes a rigid sequence of commands, an agent creates its own plan.

To be considered "Agentic," a system generally needs these characteristics:

Reflective: It learns from previous steps (loops back to correct errors).
Autonomous: It executes without manual hand-holding after the initial prompt.
Reactive: It responds to environmental changes (e.g. an API failure or new data).
Proactive: It can schedule actions based on recognized patterns.

The Paradigm Shift: Automation vs. Agentic Systems

As developers, we are used to Deterministic Execution.

Traditional Automation: Input ---> Process A ---> Process B ---> Output. If the input is unstructured or ambiguous, the pipeline breaks. It relies on fixed decision trees.
Agentic Systems: Non-Deterministic Execution. The agent receives an ambiguous goal (e.g. "Plan a trip to Tokyo based on my emails"). It uses an LLM to reason about the request, decomposes it into sub-tasks, and decides which tools to call.

The Reality Check: The critical difference is the ability to handle "fuzzy" inputs. Agents thrive where drop-down menus fail.

The Agent Architecture

A functional agent consists of four core components. Think of this as the anatomy of the system:

Perception: How the agent "sees" (Text, Audio, Images).
Planning (The Brain): The LLM. This handles reasoning, reflection, and task decomposition.
Tools (The Hands): Python functions, APIs, or Microservices. The agent doesn't "know" how to search the web; it "knows" it has a tool called search_web() and decides when to invoke it.
Memory: The context and state storage.

Deep Dive: Memory Systems

Most developers stop at "Context Window" (Short-term memory), but robust agents require a memory architecture inspired by human cognition.

Memory Type	Human Parallel	AI Implementation
Short-term	Remembering a phone number for 12s.	Context Window: Limited by token counts (OpenAI/Anthropic). Enhanced via caching.
Long-term	Knowledge retained for years (e.g. specialized skills).	RAG (Retrieval-Augmented Generation): Vector databases (like MongoDB) storing domain-specific docs.
Working	Processing new info during a conversation.	Hybrid RAG: Combining real-time internet search (e.g. Tavily) with stored knowledge.
Episodic	Remembering specific past events.	Interaction Logs: Storing user specific past sessions to recall context later.
Semantic	Memories triggered by meaning (rose = love).	Semantic Cache: Retrieving similar past queries to save API costs and speed up responses.

The Tech Stack for Memory:

Modern stacks often use a unified database (like MongoDB) to handle both operational metadata (JSON) and vector embeddings. This avoids the "synchronization hell" of trying to keep a SQL database in sync with a separate Vector DB like Pinecone.

The RAG Pipeline (Retrieval Architecture)

If the Agent is the brain, RAG is the library it references. A standard pipeline involves:

Data Prep: Cleaning, anomaly detection, and "chunking" data (breaking text into embedding-suitable segments).
Ingestion: Passing chunks through an embedding model to get vectors, stored in your DB.
Retrieval: The agent converts a user query into a vector, performs a Vector Search (semantic similarity) or Hybrid Search (keyword + semantic), and feeds the relevant chunks to the LLM.

A Framework for Building

Don't open your IDE yet. The biggest mistake developers make is jumping into code without mapping the reasoning flow.

Level 0: The Paper Phase

Map the manual process step-by-step.
Identify which steps are computational (calculating a sum) vs. reasoning (deciding if a tone is rude).
Determine where you need a human-in-the-loop for reliability.

Level 1: The Prototype

Single Agent, Single Tool.
Use a notebook. Do not overengineer a multi-agent swarm for a simple task.

Level 2: The MVP

Connect 3 functions/tools to 1 agent.
Focus on the problem, not the technology. Ask: "Does this actually save time, or is it just cool?"

Conclusion

Building agents is less about prompt engineering and more about systems engineering. It requires managing state, designing robust tools, and structuring memory effectively.

How I Built a Flutter + Gemini AI App to "Hack" My University Attendance (Open Source)

Malawige Inusha Thathsara Gunasekara — Sat, 03 Jan 2026 17:59:33 +0000

The Problem: The "80% Anxiety"

If you are an engineering student (like me at the University of Moratuwa), you know the terror of the 80% Rule.

It’s simple math: Attend 80% of classes or get banned from the exam.

But in reality, it’s a nightmare.

"If I skip today's lecture, does my percentage drop to 79.9%?"
"Did the lecturer count that medical leave?"
"Can I afford to sleep in tomorrow?"

I found myself doing complex algebra at 2 AM just to decide if I could skip a morning lecture. I needed a tool that didn't just "track" habits, but actually strategized for me.

So, I built The 80 Percent.

Here is how I engineered the fullstack software using Flutter, Google Gemini AI, and a heavily optimized Firebase backend, all while staying on the Free Tier.

1. The Strategy Engine: "Safe to Skip" Logic

Most habit trackers just say "You are at 75%." That’s useless information. I needed actionable advice.

I wrote a custom algorithm that looks at the future remaining sessions of the semester to calculate a "Safety Margin."

The "Buffer" Formula

If you are above your target, how many classes can you miss before you hit the danger zone?

I implemented this formula in Dart:

Dart

// The Magic Formula
int calculateSafeSkips(int present, int total, double target) {
  // Formula: Floor( (Present / Target) - Total )
  int skips = ((present / target) - total).floor();
  return skips < 0 ? 0 : skips;
}

Scenario: You attended 18/20 classes. Target is 80%.
Result: You can safely skip 2 more classes.
Why it matters: It stops students from panic-attending classes they don't need to, preventing burnout.

The "Recovery" Formula

If you are failing, how many classes must you attend in a row to survive?

Dart

// The Recovery Formula
int calculateRecovery(int present, int total, double target) {
   // Formula: Ceil( (Target * Total - Present) / (1 - Target) )
   return ((target * total - present) / (1 - target)).ceil();
}

This was critical because a student at 70% needs to know exactly when they will be safe again.

2. The AI Challenge: Parsing Timetables with Gemini 2.5

The biggest friction in any student app is Setup. Nobody wants to manually type in 15 modules and timeslots.

I wanted a feature where a user could upload their official PDF/image timetable, and the app would set itself up instantly.

Why Gemini 2.5 Flash?

I chose Google's Gemini 2.5 Flash because:

Speed & Cost: It is the current standard for high-speed, low-cost inference, perfect for a free student app.
Multimodal Intelligence: It accepts PDF/Image inputs directly.
Zero-Shot Capability: Unlike older models that needed endless examples, 2.5 Flash is smart enough to extract complex grid data with just a single, well-structured system instruction.

The Implementation

Instead of wasting tokens on "few-shot" examples, I used a System Instruction approach. I defined the exact JSON schema in the prompt and let the model do the heavy lifting.

Dart

// Actual Code from the App
final model = GenerativeModel(
  model: 'gemini-2.5-flash', 
  apiKey: apiKey
);

final prompt = """
You are an intelligent assistant that extracts university timetable data.
**GOAL**: Extract timetable metadata, modules, and classes into structured JSON.
**SCHEMA**:
{
  "modules": [{"code":String, "name":String...}],
  "classes": [{"day":String, "time":String, "location":String...}]
}
""";

final response = await model.generateContent([
  Content.text(prompt),
  Content.data('image/png', timetableImageBytes)
]);

The app parses the JSON response and batch-writes the classes to the local database. This "Zero-Shot" approach keeps the request payload small and fast.

3. The Architecture: Surviving the Firebase Free Tier

As a student, I have $0 budget.

Firebase is great, but the Firestore limits (50,000 reads/day) are a trap. If I have 500 users and they open the app 10 times a day, fetching 10 records each... that’s 50,000 reads. Quota exceeded on Day 1.

My "Offline-First" Solution

I designed the app to be Offline-First using a Repository Pattern.

Local Caching: When a user opens the app, it loads data from the local cache instantly.
Lazy Syncing: It only writes to Firestore when the user explicitly changes something (Marking Attendance).
No Images in DB: I initially wanted to sync profile pictures, but storing images requires the "Blaze" (Paid) plan or Base64 hacks that bloat document size. I cut this feature to ensure the app stays 100% free and fast.

This architecture means I can scale to thousands of users without paying a cent.

4. The Result: A Production-Ready Beta

"The 80%" isn't just a calculator; it's a full-stack academic tool.

Tech Stack: Flutter, Firebase Auth/Firestore, Provider, Gemini API.
Status: Open Source & Beta Live.

Building this taught me that Engineering is about tradeoffs. I had to trade fancy features (cloud images) for stability (free tier limits), and I had to trade simple logic for complex math to make the app actually useful.

Try it out

I’m looking for feedback from fellow developers and students.

Check out the ecosystem:
👉 Notion Documentation
👉 Demo code and APK file

(Star the repo if you think the project is cool! ⭐)

The AI Filmmaking Pipeline: Directing Without a Camera

Malawige Inusha Thathsara Gunasekara — Sat, 03 Jan 2026 16:48:45 +0000

As IT students, we are used to pipelines: CI/CD, data processing, rendering. Surprisingly, modern filmmaking is evolving into just another computational pipeline. Here is the no-nonsense guide to the tools and logic you need to replace a film crew with a GPU.

1. Pre-Production: The Logic Layer

Before generating pixels, you need to generate structure. This phase is about planning and visualization essentially the "architecture design" of your film.

Brainstorming & Scripting: Don't stare at a blank page. Use Claude for brainstorming concepts and ChatGPT to structure the actual script and treatment.
The Framework: The session introduced a structured approach to story generation that feels very similar to debugging:
- Objective (Why?): What is the core message?
- Idea (What?): The plot points.
- Story (How?): The narrative structure. ## 2. Production: The Generative Engine

This is where the heavy lifting happens. We are swapping cameras for diffusion models.

The Stack

Midjourney: For generating high-fidelity static shots and storyboards.
Google VEO 3: The heavy hitter for realistic video generation.
Kling AI & Krea AI: For converting static images into motion (Image-to-Video). ### The "Master Prompt" Algorithm

For developers, this is the most valuable takeaway. You don't just type "cool scene." You use a parameterized function.

The Formula: [Emotional tone] + [Visual reference] + [Subject] + [Composition] + [Lighting] + [Camera settings]

Example Code: [Royal, epic, ancient] meets [Lord of the Rings, 300] of [Krishna speaking with Pandavas] inside [Hastinapur palace] shot on [IMAX film camera]

3. Post-Production: The Audio-Visual Merge

Raw video is silent. To sell the illusion, you need the "audio stack."

Music: Suno generates original soundtracks based on mood prompts.
Voice: ElevenLabs handles realistic voiceovers and cloning, removing the need for actors.
Assembly: Bring it all together in CapCut or DaVinci Resolve. ## Summary: The New Workflow

The workflow has shifted from capture to synthesis:

Ideate with LLMs (Claude/Gemini).
Generate assets with Diffusion models (Midjourney/VEO).
Animate with Motion models (Kling).
Synthesize audio (Suno/ElevenLabs).

Bitcoin 101: From Barter to Blockchain

Malawige Inusha Thathsara Gunasekara — Thu, 01 Jan 2026 13:44:48 +0000

Money has evolved significantly over human history. We started with the barter system, trading goods directly, which was inefficient. We moved to commodity money like gold and salt, then to fiat money (USD, EUR) backed by governments, and eventually to digital banking.

But in 2009, Bitcoin emerged as the first decentralized, borderless, and scarce digital currency, removing the need for central authorities.

In this article, we’ll break down the technical fundamentals of Bitcoin, from the whitepaper to the architecture of a block.

The Vision: The 2008 Whitepaper

Satoshi Nakamoto’s whitepaper introduced a peer-to-peer digital currency that solved the double-spending problem using Proof-of-Work (PoW).

Core Principles

Fixed Supply: There will never be more than 21 million BTC.
Decentralization: No single authority controls the network.
Immutability: Once a transaction is on the blockchain ledger, it cannot be altered.
Censorship Resistance: Anyone can transact; no one can be blocked.

Under the Hood: Block Architecture

A blockchain is essentially a timestamped chain of blocks. Think of a block like a "page" in a ledger.

Structure of a Block

Every block contains three main components:

Block Header: Metadata about the block.
Transaction Counter: The number of transactions included.
Transactions: The actual list of payments.

The Block Header

The header is critical for mining and validation. It includes:

Version: The rules the block follows.
Previous Block Hash: The link to the previous block (creating the "chain").
Merkle Root: A summary of all transactions.
Timestamp: When the block was mined.
Difficulty Target (nBits): Defines how hard it is to mine the block.
Nonce: The variable number miners change to solve the cryptographic puzzle.

Data Structures: Merkle Trees & Roots

Bitcoin uses Merkle Trees (a type of binary tree) to verify data efficiently.

The Merkle Tree: Hashes every transaction, pairs them up, and hashes them again until only one hash remains.
The Merkle Root: This single "root" hash acts as a fingerprint for the entire block.

Why is this useful? It allows for Simplified Payment Verification (SPV). A user can verify a specific transaction existed without downloading the entire blockchain history. If even one bit of a transaction changes, the Merkle Root changes completely.

Consensus: Proof-of-Work (PoW)

How does the network agree on the truth? Through mining.

Miners collect transactions.
They compete to solve a cryptographic puzzle by adjusting the Nonce.
The winner gets the block reward (new BTC + transaction fees).

While secure and decentralized, PoW is energy-intensive and has limited scalability.

Scaling & Evolution

The Rise of Altcoins

Following Bitcoin, "1st Gen" altcoins emerged. Most were forks of Bitcoin with minor tweaks:

Litecoin: Faster block times.
Namecoin: Decentralized DNS.
Ethereum: Eventually introduced smart contracts, moving beyond simple currency.

The Lightning Network (Layer 2)

Bitcoin processes only ~7 transactions per second. To solve this, the Lightning Network was built as a Layer 2 solution.

How it works: Users open payment channels and transact off-chain instantly and cheaply.
Settlement: Only the final balances are recorded on the main blockchain.

This enables fast micropayments, though it comes with challenges like routing complexity and liquidity constraints.

Conclusion

Bitcoin revolutionized money by combining cryptography, game theory, and distributed systems. Understanding these fundamentals—Merkle trees, block headers, and consensus mechanisms—is the first step to mastering the wider Web3 landscape.

A Guide to Web3 Infrastructure & Concepts

Malawige Inusha Thathsara Gunasekara — Thu, 01 Jan 2026 13:18:54 +0000

As we transition from the centralized platforms of Web2 to the decentralized protocols of Web3, the developer stack is evolving. However, building decentralized applications (DApps) doesn't mean abandoning all traditional infrastructure. Instead, it involves a powerful fusion of cloud services, specialized SDKs, and blockchain nodes.

In this article, we’ll explore the evolution of the web, how Google Cloud Platform (GCP) powers Web3, and the essential tools like MetaMask SDK, Infura, and Redis that make modern DApps possible.

The Evolution of the Web

To understand where we are going, we must understand where we came from.

Web1 (The Static Web: 1990s – Early 2000s)

Read-only: This era consisted of static HTML pages where users only consumed information.

Control: Content was strictly owned by the site creators.

Web2 (The Interactive Web: 2005+ )

Read + Write: The rise of social media and mobile apps allowed users to create content.

Centralization: While interactive, the business model relied on centralized platforms (like Facebook or Google) owning user data and monetizing via ads.

Web3 (The Decentralized Web: Emerging)

Read + Write + Own: Built on blockchain technology, Web3 allows users to own their data, identities, and digital assets via wallets.

Control: The network is distributed, meaning no single company owns everything.

Google Cloud Platform (GCP) in Web3

Even in a decentralized world, robust cloud infrastructure is vital. GCP provides scalable solutions for Web3 projects.

1. Blockchain Node Hosting
Running validator or full nodes is resource-intensive. GCP allows projects to spin up nodes quickly with high uptime, as seen in their partnership with Solana for fast node deployment.

2. Data & Indexing
Blockchains are massive data stores, but querying them is hard. GCP tools like BigQuery host Ethereum and Bitcoin datasets, allowing developers to analyze transactions using standard SQL.

3. Security & AI Fusion
Security: GCP offers enterprise-level encryption and compliance, which is critical for apps dealing with financial assets.

AI: Google is combining AI services (like Vertex AI) with Web3 for use cases such as fraud detection and personalized metaverse experiences.

Other Notable GCP Products for Web3: Cloud Run, API Gateway/Apigee, Cloud Armor, and Identity Platform.

Connecting the User: MetaMask SDK
The MetaMask SDK is a crucial tool for frontend integration, ensuring users can interact with the blockchain seamlessly.

Key Features

Cross-Platform Support: It works in browsers, mobile apps, desktop apps, and even game engines like Unity and Unreal.

Web3 Login: It simplifies authentication by allowing users to log in with their wallet ("Sign-in with Ethereum") rather than a username and password.

Transaction Handling: The SDK provides functions to request, sign, and broadcast transactions without the developer needing to manage low-level network handling.

Why It Matters

Without the SDK, developers would have to manually integrate Ethereum JSON-RPC and wallet APIs, which is error-prone. The SDK makes integration "plug-and-play".

Accessing the Chain: Infura
If MetaMask handles the user, Infura handles the infrastructure. It is a service by ConsenSys that provides API access to blockchains like Ethereum, Polygon, and Arbitrum.

Instead of running your own node, you use Infura’s API to read data, send transactions, or listen to events.

Listening to Events
Smart contracts emit "events" when actions occur (e.g., a Transfer event when tokens move). Infura allows apps to subscribe to these events via WebSocket & JSON-RPC.

Real-time updates: Apps can be notified of new trades or transfers instantly.

Filtering: Developers can query specific block ranges or contract addresses to get exact data.

Core Concepts: Data & Messaging
When building the backend for these applications, you will encounter specific architectural concepts.

On-chain vs. Off-chain
On-chain: Actions happen directly on the blockchain; they are secure, transparent, and immutable, but can be slow and expensive.

Off-chain: Actions happen outside the blockchain (for speed or cost) and may be synced later.

Redis
Redis is an open-source, in-memory data store often used in Web3 architectures.

Speed: It stores data in RAM, making it incredibly fast.

Use Cases: It is used for caching database queries, storing user sessions, or managing leaderboards.

Pub/Sub: Redis supports the Publish/Subscribe messaging pattern, which is essential for handling real-time event notifications.

Summary
Building in Web3 requires a mix of new paradigms (Blockchains, Wallets, Smart Contracts) and proven technologies (GCP, Redis). By leveraging tools like Infura for node access and MetaMask SDK for user experience, developers can focus on creating value rather than managing infrastructure.

Architecting Web3: Integrating Blockchain Events with Google Cloud (GKE)

Malawige Inusha Thathsara Gunasekara — Thu, 01 Jan 2026 11:35:05 +0000

Building for Web3 isn't just about writing Smart Contracts; it’s about how you handle data off-chain at scale. As an IT student at the University of Moratuwa, I’ve been exploring how to bridge the gap between decentralized truth and centralized performance.

1. The Core Infrastructure: Web3 Meets GCP
To build a resilient dApp, you cannot rely on a single node. You need a scalable backend. Using Google Kubernetes Engine (GKE), a professional architecture should be split into three distinct layers:
Event Listener Deployment: Dedicated pods that listen to blockchain events via tools like Infura.
Worker Deployment: Asynchronous processes that handle the heavy lifting and logic.
API Layer: The gateway serving processed data to the end-users.

2. Choosing the Right Data Store
A common mistake is trying to store everything on-chain. It's too slow and expensive. Instead, use the right tool for the job:
Firestore: For real-time NoSQL document storage.
Cloud SQL: For managed relational data (Postgres/MySQL).
BigQuery: For large-scale data warehousing and historical analysis.
Redis: Essential for caching and managing message queues in async systems.

3. Security & Privacy: Zero-Knowledge Proofs
Scaling isn't just about throughput; it's about privacy. Zero-Knowledge Proofs (ZKP) allow us to prove knowledge of a secret without revealing the secret itself.

The Three Pillars: Completeness, Soundness, and Zero-Knowledge.

Tooling: Building ZK circuits often requires specialized languages like Circom.

4. Understanding the Blockchain Foundation
While the "Web3" hype focuses on UI, the engineering value lies in the data structures:
Merkle Trees: These binary tree structures are what allow for efficient transaction verification within a block header.
Consensus Algorithms: Solving the Byzantine General’s Problem to ensure trustless coordination among independent nodes.
Token Standards: Implementing the right standard is key—ERC-20 for fungibility, ERC-721 for unique assets, and ERC-1155 for hybrid applications.

Summary
The future of the web isn't purely decentralized; it’s a hybrid approach. By combining the trustless nature of Blockchain with the scalability of Cloud providers like GCP, we can build systems that are both secure and performant.

What is your preferred stack for handling off-chain data? Let's discuss in the comments.

DEV Community: Malawige Inusha Thathsara Gunasekara

Built an AI Study Tool That Refuses to Give You the Answers for UoM

The Community

What I Built

Demo

Code

How I Built It

How I Built a 15,000+ Line Flutter App with Gemini to "Hack" My University Attendance

What I Built with Google Gemini

Demo

What I Learned

Google Gemini Feedback

The Shores of Denial – The World that Shouldn't Exist

My Voluntary Descent

Navigating a Broken Mind

The Realization of the Mission

I Built a Cyberpunk Terminal Portfolio with Next.js, Antigravity and Gemini AI

Portfolio

How I Built It

What I'm Most Proud Of

1. The "Halt Sequence" (sudo delete)

2. Engineering the "Simulation Engine"

3. Secure Live Data (Gas Tracker)

4. The "Cyberpunk" Polish

The Features I Killed to Ship "The 80%" App in 4 Weeks

1. The Backup Server Trap

2. The Medical Cloud Storage Nightmare

3. The "Automated Email" Fantasy

4. All University Supported Grading System

5. Sync Custom Profile Picture Across Devices

Conclusion

🔗 Explore the Project

Building AI Agents: Concepts & Architecture

The Core Definition: What is an Agent?

The Paradigm Shift: Automation vs. Agentic Systems

The Agent Architecture

Deep Dive: Memory Systems

The RAG Pipeline (Retrieval Architecture)

A Framework for Building

Conclusion

How I Built a Flutter + Gemini AI App to "Hack" My University Attendance (Open Source)

The Problem: The "80% Anxiety"

1. The Strategy Engine: "Safe to Skip" Logic

The "Buffer" Formula

The "Recovery" Formula

2. The AI Challenge: Parsing Timetables with Gemini 2.5

Why Gemini 2.5 Flash?

The Implementation

3. The Architecture: Surviving the Firebase Free Tier

My "Offline-First" Solution

4. The Result: A Production-Ready Beta

Try it out

The AI Filmmaking Pipeline: Directing Without a Camera

1. Pre-Production: The Logic Layer

The Stack

3. Post-Production: The Audio-Visual Merge

Bitcoin 101: From Barter to Blockchain

The Vision: The 2008 Whitepaper

Core Principles

Under the Hood: Block Architecture

Structure of a Block

The Block Header

Data Structures: Merkle Trees & Roots

Consensus: Proof-of-Work (PoW)

Scaling & Evolution

The Rise of Altcoins

The Lightning Network (Layer 2)

Conclusion

A Guide to Web3 Infrastructure & Concepts

The Evolution of the Web

Web1 (The Static Web: 1990s – Early 2000s)

Web2 (The Interactive Web: 2005+ )

Web3 (The Decentralized Web: Emerging)

Google Cloud Platform (GCP) in Web3

Key Features

Why It Matters

Architecting Web3: Integrating Blockchain Events with Google Cloud (GKE)

1. The "Halt Sequence" (`sudo delete`)