3
3
India
1 year of experience
I am a BCA student and aspiring software developer with a strong interest in artificial intelligence, web and app development, automation, game development, and 3D design. I enjoy building practical, innovative projects and transforming ideas into functional solutions using technologies such as Python, JavaScript, React, Firebase, n8n, AI APIs, Roblox Studio, and Blender. I am continuously expanding my technical skills through hands-on development, hackathons, and personal projects, with the goal of creating impactful technology and building a strong career in software and AI.

FactoryForge is a multi-agent software factory designed to automate the software-building process through coordinated AI agents. Instead of asking one agent to handle an entire project, FactoryForge divides the work into explicit, independent work packages with clear ownership, dependencies, deliverables, acceptance criteria, and non-goals. A Planner analyzes the specification and decomposes it into executable packages. Implementers work only within their assigned scope, while Test Authors independently create verification checks. Reviewers inspect the resulting changes and evidence before work is considered complete. The factory is built around explicit agent-to-agent handoffs rather than relying on implicit context. Shared contracts and disjoint file ownership reduce conflicts between parallel agents, while acceptance commands provide concrete evidence that a package actually works. Our Dark Factory demonstration uses BAND Desktop to coordinate the agent team through rooms, tasks, artifacts, and structured communication. The agents collaboratively build and verify a software service while respecting the constraints defined by the specification. The goal of FactoryForge is to demonstrate a reusable software-production system where planning, implementation, testing, review, and verification become coordinated stages of an autonomous development workflow rather than a single AI coding session.
6 Oct 2026

KitchenGuard is a hands-free, voice-native food-safety inspection system designed for commercial kitchens. Instead of forcing workers to stop, type, and complete long inspection forms, KitchenGuard lets them walk through the kitchen and speak naturally. AssemblyAI powers the real-time voice interaction, while KitchenGuard converts spoken observations into structured inspection data. The system uses a deterministic inspection engine to evaluate configurable rules, detect missing information, identify issues, and prevent an inspection from being finalized before required checks are completed. KitchenGuard also includes persistent kitchen memory. For example, if a worker says, “There is a blue cleaning bucket under the refrigerator,” that spatial relationship is stored as structured memory. Later, the worker can ask where the bucket is, update its location, or retrieve its previous location. Corrections are tracked rather than silently overwritten, creating an audit history of observations, changes, issues, and resolutions. The result is a voice-first inspection workflow that combines real-time speech, structured actions, deterministic verification, persistent memory, and report generation.
30 Sep 2026

Modern software projects depend on many interconnected files, APIs, database models, functions, and tests. A change that looks small, such as renaming a field or modifying a shared function, can unexpectedly break other parts of an application. Developers often discover these problems only after changing the actual codebase and running tests, which can make debugging slower and changes riskier. BuildTwin addresses this problem by creating an isolated, disposable twin of a GitHub repository before applying a risky change. The developer provides a repository and describes the proposed change. BuildTwin profiles the repository, detects its technology stack, package manager, and available test workflow, then creates a sandbox where the experiment can happen safely. BuildTwin first runs the existing tests to establish a baseline. It then applies the proposed mutation only inside the sandbox and runs the tests again. When real failures appear, BuildTwin analyzes the affected files, call sites, errors, and execution results to show what the change actually broke. The next step is IBM Bob. Bob receives the real regression context, analyzes the affected code, and prepares a focused remediation patch. BuildTwin applies that patch only inside the isolated sandbox and runs the tests again. BuildTwin does not assume that a fix is correct just because an AI generated it. The fix must pass real verification. Only when the verification succeeds does BuildTwin report SAFE TO DEPLOY. The original repository remains untouched throughout the simulation. The target users are software developers, engineering teams, and teams working with large or interconnected codebases who want to understand the impact of risky changes before merging them. What makes BuildTwin different is the combination of repository isolation, real change simulation, evidence-based regression detection, IBM Bob remediation, and post-fix verification in one workflow. Instead of asking AI whether a change looks safe, BuildTwin actually tests the change in a controlled twin of the application.
27 Sep 2026