DEV Community: Agastya Khati

Warp: An Evidence Graph for Procurement Incidents

Agastya Khati — Mon, 05 Oct 2026 06:39:22 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

I built Warp, an AI-assisted procurement incident-response workspace for teams that need to choose a replacement supplier under time pressure.

A supplier failure creates a difficult problem. Procurement needs an alternative quickly. Operations needs to protect production. Quality needs to check certificates and specifications. Legal needs a defensible record before a new agreement is prepared. In many companies, these facts live in separate PDFs, supplier websites, inboxes, spreadsheets, and browser tabs.

Warp brings that investigation into one workflow. It takes an incident, researches alternative suppliers, extracts facts from documents, compares claims against evidence, ranks the options, and prepares a recommendation. It then stops. A person must approve, reject, or request more evidence before the workflow can continue.

The product rule is simple:

AI prepares. Humans authorize.

The demo scenario

The demo starts with an incident involving Pacific Components Ltd. The company supplies the PX-17 Power Controller. Only eight days of inventory remain. The estimated business exposure is $2.4 million.

Warp evaluates three alternative suppliers:

Apex Electronics has a credible certification record, but a longer lead time.
Nexus Manufacturing has a clean business-registration record, direct PX-17 compatibility, and expedited shipping evidence.
Shenzhen Rapid Parts offers the lowest price, but two critical claims fail verification.

Shenzhen claims it was established in 2018. Its business-registration evidence shows a formation date in 2021. It also provides an ISO 9001 certificate, but the certificate registry does not return a matching record.

Warp does not hide these failures inside a black-box risk score. It keeps the supplier claim, the contradicting registration field, the certificate result, the document source, and the final verdict connected and visible.

Why Sanity is central to Warp

Sanity is Warp’s durable supplier evidence graph.

A normal database model could store a supplier score and a short explanation. That would not be enough for this problem. Procurement teams need to inspect the path from a recommendation back to its evidence.

Warp uses Sanity to model the investigation as connected documents:

evidenceIncident stores the disruption context.
evidenceSupplier stores each candidate supplier.
evidenceClaim stores material supplier statements, such as “ISO 9001 Certified” or “Established 2018.”
evidenceDocument stores the document that supports or challenges a claim.
evidenceSource stores external evidence, including registries and web research.
evidenceDecision stores the recommendation, risk rationale, and human decision.

The relationship is deliberate:

incident → supplier → claim → document or source → extracted field → verification result → decision → human approval

This means a conflict is not an error that gets overwritten. It is a first-class part of the graph.

For example, the claim “Established 2018” and the business-registration field “FORMED 2021-06-08” can both exist in Sanity. Warp links them to the same supplier and shows the result as a conflict. The human reviewer can see what was claimed, what was found, and why the recommendation changed.

The Evidence screen reads this graph through GROQ. It presents verified claims, conflicts, unverified claims, documents, external sources, and the recommended supplier in a custom Next.js interface.

Demo

Live app: aegisflow-ai.vercel.app

The video walkthrough shows the complete decision path:

The procurement incident and business impact.
The supplier investigation and recommendation.
The Sanity evidence graph.
Claim-level provenance and conflicting evidence.
Document extraction and source records.
The human approval state.
The integration activity ledger.
The append-only audit trail.

Code

Public repository: github.com/kris70lesgo/Warp

The repository includes the Next.js application, the Sanity Studio, Sanity schemas, the evidence-graph queries, integration clients, and scripts for seeding the baseline graph.

My Build Process

I used Codex as my AI-native development environment. I built Warp with Next.js for the application and Sanity for the structured evidence layer.

The project started from a product question:

What should an AI procurement tool do when evidence is incomplete or contradictory?

My answer became the main product constraint: the AI can research, extract, compare, score, and draft. It cannot silently turn an uncertain conclusion into an approved business action.

The prompt that changed the architecture was:

“Make Sanity the supplier evidence graph. The app investigates suppliers from multiple sources. Sanity must hold the complete evidence state for every supplier, including claims, documents, sources, conflicts, and final decisions.”

At first, the model treated Sanity as a place to save a supplier summary. That produced the wrong application. A summary tells a user what the system concluded, but it loses the path that produced the conclusion.

I corrected the model in three ways.

First, I required separate records for each supplier claim and each piece of supporting or contradicting evidence. A supplier record could no longer hold only a final score.

Second, I required provenance. Every material fact needs to link back to a document field, external source, or explicit fallback. The UI must show whether an input is LIVE, LOCAL, or DEMO SEEDED.

Third, I separated an AI recommendation from a human decision. The recommendation can be stored and explained, but it cannot advance the workflow by itself.

These constraints led to the evidence graph. They also made the app more useful. Instead of asking users to trust a score, Warp lets them inspect the score’s inputs.

Prompts that worked

The strongest prompts described a rule, an actor, and a proof requirement. For example:

“Do not overwrite contradictory claims. Preserve the supplier statement and the evidence that challenges it. Make the conflict queryable and visible in the UI.”

“Show the provenance for every material claim. A human reviewer must be able to trace a recommendation back to a document field or source.”

“Treat a zero-result web search as evidence of missing corroboration, not as an empty result.”

“AI may prepare a decision. Only a human may approve, reject, or send an agreement to signature.”

These prompts produced better results than broad requests such as “build a procurement dashboard with Sanity.” Broad prompts produced generic cards and charts. The tighter prompts produced a workflow with rules, evidence links, and clear responsibility boundaries.

Where the model got stuck

The hardest part was keeping the system honest when an integration was not available.

A model will often fill a UI with plausible output, even when a live API did not respond. That would be dangerous in a supplier-verification workflow.

I added an Integration Activity Ledger to fix this. Every provider call is recorded with its mode:

LIVE means the provider responded.
LOCAL means Warp used a local implementation or extracted fixture.
DEMO SEEDED means Warp used a known demo record and shows that fact.

This rule applies to the visible product. The app does not label a fallback as a live result.

I also kept Sanity distinct from the operational database. Sanity holds the durable, connected evidence graph. Xano holds operational incident records and the append-only event stream. This separation keeps the explanation layer and the workflow ledger clear.

The workflow

A Warp response follows these stages:

Analyse the incident and business exposure.
Search for supplier and market evidence.
Extract relevant fields from supplier documents.
Check claims against source evidence.
Score alternatives with transparent risk dimensions.
Persist the investigation as connected Sanity evidence records.
Prepare a recommendation.
Require human review.
Prepare documents only after approval.
Record every important action in the audit trail.

The important design choice is step six. The recommendation is not the only output of the investigation. The evidence graph is also an output. It lets the system answer future questions without rebuilding the investigation from scratch.

What I did not use

I did not use Sanity App SDK or Sanity Workflows in this version. I built a custom Next.js interface and a dedicated Sanity Studio for the evidence model. I wanted the challenge entry to focus on one idea executed deeply: structured supplier evidence that stays connected through an investigation.

Sanity Project Details

Sanity project ID: af8ykvwc
Dataset: production
Frontend query language: GROQ
Sanity Studio: included in the repository under /sanity

Sanity is the durable record of a Warp investigation.

One investigation can persist the incident context, candidate suppliers, supplier claims, documents, extracted fields, web and registry sources, verification results, conflicts, recommendation, and human decision.

The schema preserves disagreement. If a supplier statement conflicts with a registration record or certificate check, Warp keeps both records. It marks the claim as VERIFIED, CONFLICT, or UNVERIFIED, but it does not erase the source material.

That is the reason Sanity is central to the product. It changes the system from an AI tool that produces an answer into a decision workspace that preserves the evidence behind the answer.

Agent Session

I am not embedding the raw agent session because it contained development credentials during integration testing. Any public agent session should be reviewed and scrubbed before publishing.

Warp uses Sanity to make supplier decisions structured, queryable, and reviewable.

AI prepares. Humans authorize.

[Boost]

Agastya Khati — Mon, 07 Sep 2026 06:59:45 +0000

DEV Weekend Challenge: Generosity Edition Submission 💜

Agastya Khati

Sep 7

Funded: Making Room for Education Through Generosity

#devchallenge #weekendchallenge

4 min read

Funded: Making Room for Education Through Generosity

Agastya Khati — Mon, 07 Sep 2026 06:59:33 +0000

This is a submission for Weekend Challenge: Generosity Edition)

What I Built

I built Funded, a student-focused crowdfunding platform designed around generosity in education.

Students can create fundraisers for tuition, books, housing, technology, course access, and other learning costs. Donors can discover real student stories, listen to an AI-generated audio introduction, and preview donation options.

My goal was to make asking for educational support feel more human, transparent, and accessible. Funded helps students turn a few honest notes into a respectful campaign story, while giving donors clearer ways to understand who they are helping and why.

Demo

The demo shows the complete Funded experience:

Discovering live student fundraisers
Creating a campaign with the Gemini Story Coach
Publishing the fundraiser instantly to the live feed
Listening to an ElevenLabs-generated campaign narration
Previewing a Dodo Payments checkout flow without making a real payment
Donating through Phantom using Solana Devnet, with an on-chain transaction receipt

Code

https://github.com/kris70lesgo/funded

How I Built It

Funded is a React and TypeScript web application with a custom frontend focused on a calm, editorial crowdfunding experience. The interface uses a clean layout, warm student imagery, clear campaign cards, and simple donation flows so the product feels trustworthy rather than overwhelming.

Campaign creation and publishing

The fundraiser creation flow collects the information a donor actually needs to understand a request:

Fundraiser title
Education category
Funding goal
Student name
Cover image
Personal story
Fundraiser updates

Once a campaign is submitted, it is stored in Supabase and receives a unique slug-based URL. The application then redirects the student to their live fundraiser page. The campaign is also available in the Discover feed so other users can find it immediately.

Campaign owners can delete their own fundraiser through an in-app confirmation interface. This was important because students should remain in control of the campaigns and stories they publish.

Supabase

Supabase is used for authentication and campaign data storage.

The application supports normal email and password sign-up and sign-in. After a user signs in, the interface updates to show their account state instead of showing the Sign in action.

Fundraiser records are stored in Supabase, including the title, category, story, funding goal, creator details, campaign progress, image, and publication date. The Discover page retrieves these campaigns so the public feed reflects newly published fundraisers instead of only showing static content.

I also added sample fundraiser data to Supabase so the demo has realistic student campaigns available immediately. This helps demonstrate the complete donor experience from the first visit.

Google Gemini: Story Coach

One of the biggest barriers for students is knowing how to write a fundraiser story. Students may have a real need and a strong goal, but still struggle to explain it in a way that is clear, respectful, and comfortable to share.

The Gemini Story Coach solves this by taking a few student-provided notes, such as:

What they are studying
What they need funding for
Their achievements or current situation
Their future goals
Why this support matters now

Gemini then helps create a well-structured campaign story. The output is designed to be supportive and concise, not exaggerated or manipulative. The student can always edit the story before publishing, keeping their own voice and control over the final fundraiser.

ElevenLabs: Audio campaign stories

Every fundraiser has the option to include an AI-generated audio narration powered by ElevenLabs.

The narration turns the campaign story into a spoken introduction that donors can play directly on the fundraiser page. This adds an emotional and accessible layer to the platform. Instead of only reading a block of text, a donor can listen to the student’s goals and reason for fundraising.

This feature is useful for accessibility, mobile users, and donors who connect more strongly with a spoken story. It also makes each fundraiser page feel more personal without requiring students to record their own audio.

Solana and Phantom

Funded supports a Solana donation flow through Phantom.

For the hackathon demo, the integration uses Solana Devnet. When a donor chooses to contribute with SOL, the application prepares the transaction and asks the donor to approve it in their Phantom wallet. Funded never receives or stores wallet private keys.

After approval, the transaction can be referenced as an on-chain receipt. This creates a transparent record of the contribution and demonstrates how blockchain can support trust in crowdfunding.

Using Solana also helps show a future direction for Funded: transparent, low-friction support that can be verified publicly while still keeping the donor in control of their wallet.

Dodo Payments

Funded also includes a Dodo Payments checkout flow for donors who prefer a familiar checkout experience.

For this hackathon demo, the Dodo checkout is shown as a preview only. No real payment is intentionally completed. This lets the project demonstrate how a traditional payment flow would fit into the platform while keeping the demo safe and focused on the user journey.

Why these technologies matter together

Funded combines these technologies to address different parts of the generosity experience:

Supabase makes fundraisers persistent, live, and manageable.
Google Gemini helps students communicate their needs with confidence.
ElevenLabs gives fundraiser stories a more personal and accessible voice.
Solana provides transparent, wallet-controlled contributions with on-chain proof.
Dodo Payments provides a familiar checkout path for future real-world contributions.

Together, these tools help turn generosity into something that is easier to ask for, easier to understand, and easier to trust.

Prize Categories

Best Use of Solana — Funded integrates Phantom wallet donations on Solana Devnet. Donors approve transactions in their own wallet, and the resulting transaction can act as transparent, public proof of support.
Best Use of ElevenLabs — Funded generates playable audio narrations for fundraiser stories using ElevenLabs. This makes campaigns more personal and accessible for donors.
Best Use of Google AI — Funded uses Gemini as a Story Coach that helps students transform a few honest notes into a clear, respectful, and shareable fundraiser story while keeping the student in control of the final content.

Fruit Dash: A Solstice Platformer with Binary Code Gates

Agastya Khati — Sat, 20 Jun 2026 11:06:26 +0000

This is a submission for the June Solstice Game Jam

What I Built

I built Fruit Dash, a lightweight 2D browser platformer inspired by the bright, playful energy of June and the June Solstice.

Fruit Dash is a colorful pixel-art platformer where the player chooses a character, enters a 50-level world, collects fruit, avoids traps, fights enemies, activates checkpoints, and clears each stage by reaching the end flag.

The game includes:

50 generated platforming levels
Character selection
Level selector
Fruit collection
Jumping and double jumping
Fireball/powerball attacks
Enemies that scale by level
Checkpoints and end flags
Saws, spikes, fire traps, arrows, fans, trampolines, moving platforms, boxes, and surfaces
Background music with mute/unmute control
Mobile and tablet touch controls
Turing Gate binary puzzles on milestone levels

For the June Solstice theme, I wanted the game to feel like a bright seasonal arcade adventure: colorful, energetic, full of motion, and centered around progression. The solstice is a turning point in the year, and Fruit Dash mirrors that through the way each level moves the player forward into new hazards, enemies, and mechanics.

I also added a specific Alan Turing-inspired mechanic: Turing Gates. On milestone levels, the exit is locked behind a small binary code puzzle. The player must shoot three binary switches until the bits match the target code. This connects the platforming gameplay to computation, binary logic, code-breaking, and Turing’s legacy in computer science.

Video Demo

Code

GitHub repository:

kris70lesgo / fruitdash

Fruit Dash

Fruit Dash is a lightweight 2D browser platformer built for the June Solstice Game Jam. It is a colorful fruit-collecting platformer about movement, progression, and small moments of code-breaking.

The game runs directly in the browser with plain HTML, CSS, and JavaScript. No heavy game engine is required.

Play

Live demo:

https://game-jade-one-25.vercel.app

Local run:

python3 -m http.server 4173

Then open:

http://127.0.0.1:4173/game-src/index.html

Features

50 generated platforming levels
Home screen, level selector, and character selection
Fruit collection with multiple fruit types
Jumping, double jumping, checkpoints, and end flags
Tiered enemies: mushrooms, Vomfy, slimes, and mixed late-game waves
Fireball/powerball attack with character-specific colors
Traps and movement tools: saws, spikes, fire, arrows, fans, trampolines, moving platforms, boxes, and surfaces
Turing Gates on milestone levels with binary switch puzzles
Looping background music with mute/unmute control
Touch controls for mobile and tablet, including a fire button
Vercel-friendly root entry page

Controls

Move: A/D or…

View on GitHub

Live demo:

https://game-jade-one-25.vercel.app

How I Built It

Fruit Dash is built with plain HTML, CSS, and JavaScript. I intentionally avoided a heavy game engine so the game would stay lightweight, easy to deploy, and fully controllable in the browser.

The game runs on an HTML canvas. The player, enemies, fruits, traps, projectiles, platforms, checkpoints, Turing Gates, and HUD are all drawn and updated manually in JavaScript.

The visual style comes from pixel-art PNG assets and sprite sheets. The game uses sprites for characters, fruits, terrain, traps, enemies, fireballs, checkpoints, and UI elements.

The level system is generated in code. Each level creates a different combination of:

Ground platforms
Floating platforms
Fruits
Boxes
Checkpoints
End flags
Moving platforms
Hazards
Trampolines
Fans
Enemies
Turing Gates on milestone levels

Difficulty increases as the level number rises. Early levels focus on movement and collection. Later levels introduce more enemies, hazards, and tighter platforming situations.

Enemies are introduced by level tier:

Early levels use mushroom enemies
After level 10, Vomfy enemies appear
After level 30, slimes appear
After level 40, enemy types are mixed together

The player can shoot fireballs using Enter, mouse click, tap, or the mobile fire button. Fireballs use sprite-sheet animation and have character-specific colors. They disappear when they hit enemies, platforms, traps, switches, or other solid objects.

For the Turing-inspired mechanic, levels 10, 20, 30, 40, and 50 include Turing Gates. Each gate displays a 3-bit binary target. The player shoots three bit switches to toggle them between 0 and 1. When the current bit pattern matches the target, the exit unlocks.

I also added background music. The original audio file was an OGG file around 11 MB, which felt too large for a small browser game. I used FFmpeg to convert it into a smaller MP3 file, reducing it to around 4.1 MB and improving browser compatibility. The music loops after the first player interaction because browsers usually block autoplay audio until the user clicks, taps, or presses a key.

For mobile support, I added touch controls that appear automatically on touch screens. Mobile and tablet players can move, jump, and fire without a keyboard.

The game is deployed as a static site on Vercel. I also added a root index.html so the deployed URL opens correctly instead of returning a 404.

Challenges I Faced

One of the biggest challenges was making sure the collision system matched the visuals. At one point, some platforms had collision but were not visibly drawn because the wrong part of the terrain sprite sheet was being used. This made the character look like they were standing on invisible platforms. I fixed this by correcting the terrain tile coordinates and adding safer fallback drawing for platform types.

Generated level quality was another major challenge. Since levels are built in code, some objects were originally placed in awkward spots. Fruits could appear in cramped areas that were hard or impossible to reach. Fans could appear under platforms, pushing the player directly into a ceiling. I added a cleanup pass to the level generator that checks fruit placement, reduces overlapping fruit clusters, and only places fans where the upward air path is actually useful.

The arrow trap also needed redesign. Initially, touching an arrow restarted the player, which felt unfair and not very meaningful. I changed arrows into directional boosters so they become a movement mechanic instead of just another punishment.

Enemy sprite alignment was tricky too. Some enemy sprite sheets had transparent padding, so enemies looked like they were floating even when their collision boxes were touching the ground. I adjusted enemy drawing offsets so their feet visually line up with the platform.

Adding Turing Gates required balancing the puzzle with the platforming. I did not want to turn the whole game into a slow puzzle game, so I placed the binary gates only on milestone levels. That way the Alan Turing tribute appears clearly, but the main game still feels like an arcade platformer.

Audio also had browser-specific challenges. Modern browsers block autoplay audio, so the music starts after the first player interaction. I also added a mute/unmute button so the player has control.

Deployment had one final issue: Vercel initially showed a 404 because the actual game was inside game-src/index.html, not the project root. I fixed this by adding a root index.html that forwards to the game.

Prize Category

I am submitting for two prize categories:

Best Ode to Alan Turing

Fruit Dash includes a Turing-inspired mechanic called Turing Gates.

On milestone levels, the exit is locked behind a binary code puzzle. The game displays a 3-bit target code, and the player must shoot three binary switches until the switch values match the target.

This is an arcade-style tribute to Alan Turing’s legacy in computation, logic, code-breaking, and the foundations of modern computer science. I wanted the tribute to exist inside the gameplay itself, not only in the submission description.

The player solves a small binary logic problem, unlocks the gate, and continues the level.

Best Google AI Usage

Google AI helped throughout the development process. I used Antigravity IDE for development ,also while building and iterating on the game. It helped with code generation, debugging, gameplay iteration, layout fixes, and improving the structure of the app.

AI assistance was especially useful for:

Debugging invisible platform issues
Fixing sprite alignment problems
Improving generated level placement
Adding enemies and attacks
Adding mobile controls
Adding audio controls
Optimizing the background music file
Preparing the project for Vercel deployment
Shaping the Turing Gate binary puzzle mechanic

I also used Gemini models / Gemini API workflows during the creative process for asset and image-related experimentation. The final game is still a browser-based JavaScript game using local assets, but Google AI helped speed up the design, development, debugging, and iteration process.

Finishing HELIX: Building an AI-Powered Space Operations Intelligence Platform with GitHub Copilot

Agastya Khati — Fri, 05 Jun 2026 14:29:52 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

This is my submission for the GitHub Finish-Up-A-Thon Challenge.

The idea behind this challenge really hit home for me: finally finish what you started.
HELIX started as a satellite tracking and conjunction detection project. It already had a working backend, orbital propagation, a 3D globe, and basic AI summaries. But it still felt like a technical prototype.
For this challenge, I brought it much closer to a finished product.
I turned HELIX into an AI-powered space operations intelligence platform that can investigate orbital risk, correlate multiple space data sources, and generate explainable operational assessments.
GitHub Copilot helped me push the project from “cool prototype” to something that feels like a real mission operations console.

Demo

Github Repository :

kris70lesgo / helix

HELIX

Coral-Powered Space Operations Intelligence Platform

HELIX is an AI-powered Space Operations Intelligence Platform that transforms fragmented orbital, launch, and space weather data into actionable mission intelligence.

Built on top of Coral's federated SQL runtime, HELIX enables operators, researchers, and analysts to investigate conjunction risks, correlate launch activity, monitor orbital congestion, and generate explainable operational assessments through multi-step AI investigations.

Unlike traditional satellite trackers, HELIX focuses on answering:

What is happening in orbit?

Why is it happening?

What should operators pay attention to next?

Why HELIX?

Earth's orbit is becoming increasingly congested.

Thousands of active satellites, frequent launches, and growing debris populations create a complex operational environment where understanding risk requires data from multiple disconnected systems.

Most tools can visualize orbital activity.

HELIX investigates it.

Using Coral as a unified intelligence layer, HELIX correlates:

Satellite conjunction events
Launch schedules and mission activity
Space weather conditions
Satellite metadata
Historical orbital trends

…

View on GitHub

What HELIX Does

HELIX is a local-first space situational awareness and mission intelligence platform.

It helps answer questions like:

Why are conjunction risks elevated today?
Which satellites repeatedly appear in high-risk events?
Are upcoming launches contributing to orbital congestion?
Is space weather affecting operational risk?
What should an operator monitor next?

Instead of only showing satellite positions, HELIX performs structured investigations over operational data.

Core Features

3D Satellite Monitoring

HELIX includes a real-time globe interface for viewing satellites and conjunction events.

The frontend uses:

Next.js
React
TypeScript
Three.js
react-globe.gl

The backend uses:

FastAPI
SQLite
SGP4 orbital propagation
KD-tree optimized conjunction detection

System Architecture:

Multi-Source Operational Intelligence

HELIX connects multiple operational data sources:

Local satellite and conjunction database
NOAA space weather data
Launch Library launch data
Space-Track metadata

These sources are exposed through Coral as SQL-queryable tables.

That means HELIX can run cross-source intelligence queries like:

conjunction risk + NOAA space weather
launch activity + current solar conditions
closest conjunctions + Space-Track object metadata
Starlink launch activity + local conjunction pressure

Multi-Step AI Investigation Agent

The biggest finish-up improvement was moving from:
prompt → query → summary
to:
prompt → investigation plan → query chain → findings → assessment → recommendations

The investigation engine is deterministic and safe.
It does not generate arbitrary SQL.
Instead, it chooses from approved Coral SQL templates and runs a bounded sequence of investigation steps.

Example investigation:
`User: Why are conjunction risks elevated today?

[1] Querying conjunction risk distribution
[2] Analyzing closest high-risk events
[3] Detecting repeated satellite involvement
[4] Comparing risk density by day
[5] Checking upcoming launch activity
[6] Checking NOAA space weather
[7] Correlating findings
[8] Generating operational recommendations`

Before and After

When I started, HELIX was primarily a space visualization prototype.

The first version could display satellites on a 3D globe and visualize orbital tracks, but the overall product was still incomplete. The core visualization layer worked, but most of the operational intelligence layer was missing. The Intel experience and the Conjunctions workflow existed mostly as ideas and partially implemented components rather than finished features.

The early version included the basic foundation:

Satellite globe visualization
Object counts and statistics
Basic live status information
Planned Intel and Conjunctions navigation
Early conjunction detection data

While the foundation was solid, it did not yet feel like a complete operations platform. Users could observe activity in orbit, but they could not effectively investigate, analyze, or act on that information.

The Final Version

The final version of HELIX is much closer to a real mission-control-style interface.

It now includes:

A polished interactive satellite globe
Live satellite detail drawer
High-risk conjunction overlays
Conjunction count indicators and alert banners
Fully functional Intel console
Working Conjunctions panel
Operational investigation workflow
Coral-backed cross-source intelligence analysis
AI-generated operational recommendations

The current interface transforms the globe from a visualization component into an operational workspace.

Instead of simply displaying satellites, HELIX now surfaces:

Active high-risk conjunction events
Detailed satellite metadata
Live position and velocity information
Investigation context
Operational intelligence insights

The globe is no longer just showing data it is helping explain and investigate it.

How GitHub Copilot Helped

GitHub Copilot played a major role in turning unfinished concepts into working product features.

The most significant contributions were helping build the areas that previously existed only as plans:

The Intel console
The Conjunctions workflow
Backend intelligence endpoints
The multi-step investigation engine
Coral SQL query chaining
Frontend operational panels and UI states

More importantly, Copilot helped support the entire engineering workflow rather than simply generating isolated code snippets.

The process looked like this:

Inspect the existing codebase
Understand the backend and frontend architecture
Identify where missing features should integrate
Implement backend APIs
Connect frontend interfaces
Test the application
Resolve integration and debugging issues
Polish the final experience

Copilot was especially valuable for bridging the gap between planned functionality and working functionality.

Many parts of the interface already existed visually, but they were not fully connected to operational workflows. Copilot helped move the project from:

Button exists
→ Feature planned
→ Logic incomplete

to:

Button exists
→ Backend implemented
→ Frontend connected
→ Investigation workflow operational
→ Feature fully functional

Outcome

As a result, HELIX evolved from a satellite visualization prototype into a complete AI-powered space operations intelligence platform.

It now supports:

Operational investigations
Conjunction monitoring
Cross-source intelligence analysis
AI-assisted assessments
Coral-backed data correlation
Actionable operational recommendations

The project did not require a complete rebuild.

It required finishing the missing pieces, connecting existing systems together, and transforming concepts into working features.

GitHub Copilot helped make that transition possible.

The Comeback Story of HELIX

Before the Finish-Up-A-Thon, HELIX was a project with a lot of potential but it was stuck in the place where many ambitious side projects end up.

The foundation was already there.

It had a FastAPI backend, satellite data ingestion, orbital propagation, conjunction detection, a SQLite database, and a 3D globe interface. It could track satellites, visualize orbital activity, and identify close approaches between objects in space.

Technically, it worked.

But it didn't feel finished.

HELIX could tell users what was happening, but it struggled to explain why it was happening. The AI layer was limited to basic summaries, many features felt disconnected, and the overall experience resembled a collection of powerful components rather than a unified intelligence platform.

In short, HELIX felt more like a satellite-tracking prototype than a true mission operations system.

That was the state of the project when I began the finish-up process.

Enter GitHub Copilot

Instead of starting over, I focused on understanding what already existed.

Using GitHub Copilot and advanced GPT-5.5 style assistance, I began by inspecting the codebase, mapping the architecture, and identifying the areas that would create the biggest impact if improved.

The process became highly iterative:

Understand the existing system
Identify weak points
Plan improvements
Implement safely
Test thoroughly
Repeat

Rather than rewriting everything, I concentrated on strengthening what was already there.

Bringing HELIX Back to Life

The first step was cleaning up and stabilizing the architecture while preserving the satellite tracking and conjunction detection capabilities that already worked.

From there, I introduced Coral as the data orchestration layer and connected multiple operational datasets into a unified queryable system.

Suddenly, HELIX was no longer looking at isolated pieces of information.

It could correlate data across:

Conjunction events
Satellite metadata
Launch activity
NOAA space weather
Space-Track datasets

The project started evolving from a visualization tool into an intelligence platform.

The Biggest Transformation

The most significant change was the intelligence workflow itself.

Before, the AI interaction looked something like this:

Ask a question
→ Run a query
→ Summarize the results

It worked, but it was shallow.

The system answered questions without actually investigating them.

I wanted HELIX to think more like an analyst.

So I built a deterministic investigation engine that transformed the workflow into:

Ask a question
→ Build an investigation plan
→ Execute approved Coral queries
→ Correlate findings
→ Generate an assessment
→ Recommend next actions

With the help of Copilot, I implemented:

Multi-step investigation workflows
Query tracing and transparency
Passive monitoring alerts
Operational recommendations
Investigation timelines in the UI
Backend intelligence endpoints
Frontend investigation experiences

The system stopped behaving like a chatbot and started behaving like an operations analyst.

A Different Kind of Answer

Consider a question like:

Why are conjunction risks elevated today?

Previously, HELIX would have returned a simple summary of conjunction data.

Now it performs a full investigation.

It can:

Analyze conjunction density
Identify repeatedly involved satellites
Check recent launch activity
Review NOAA space weather conditions
Compare current activity with historical patterns
Correlate findings across multiple datasets

Only then does it generate an assessment and suggest possible operational actions.

That fundamentally changed how the platform feels.

From Prototype to Platform

The transformation wasn't about adding flashy features.

It was about connecting everything together.

GitHub Copilot helped accelerate the parts that often cause projects to stall:

Understanding a large codebase
Architecture planning
Safe refactoring
Backend development
Frontend improvements
SQL generation
API debugging
Documentation
Final validation

Feature by feature, HELIX became more cohesive, more intelligent, and more useful.

Where HELIX Stands Today

Before the Finish-Up-A-Thon, HELIX was a promising demonstration of satellite tracking technology.

Today, it feels like a genuine AI-powered space operations console.

It can investigate, correlate, explain, and recommend not just visualize.

The project didn't need a complete rewrite.

It needed someone to finish what had already been started.

GitHub Copilot helped make that possible.

And in many ways, HELIX's biggest achievement wasn't the technology itself—it was finally crossing the line from almost finished to fully realized.

My Experience with GitHub Copilot

How GitHub Copilot Helped

I used GitHub Copilot heavily throughout the finish-up process, specifically with advanced ChatGPT/GPT-5.5 style coding assistance.

Copilot helped with:

reading and understanding the existing codebase
planning the architecture
refactoring the project safely
adding the investigation engine
creating backend endpoints
improving the frontend UI
generating SQL query templates
debugging API issues
writing documentation
validating the final build

The most valuable part was not just code generation. It was the ability to work iteratively:

inspect the existing project
identify weak points
plan the next phase
implement safely
test
repeat

That workflow made it possible to finish a project that otherwise could have stayed half-done.

one of the best blogs about hermes agent

Agastya Khati — Sun, 31 May 2026 05:33:20 +0000

Hermes Agent Challenge Submission: Write About Hermes Agent

Paimon

May 31

Nous Research Hermes Agent: Setup and Tutorial Guide

#hermesagentchallenge #devchallenge #agents

10 min read

Credexia: AI-Powered Loan Compliance Built with Google Gemini

Agastya Khati — Wed, 04 Mar 2026 04:05:01 +0000

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

Building Credexia: How Gemini Became My 48-Hour Co-Founder

The Event

I built Credexia at the LMA Edge Hackathon, where the theme was loan market innovation. The challenge was to modernize how banks handle loan servicing after the trade is signed. While trading platforms have gone digital, post-closing operations are still stuck in Excel hell. I had 48 hours to change that.

The LMA ecosystem has tools for drafting loans and platforms for price discovery, but there is a massive white space in between. Banks can agree on trades and sign loans digitally, yet post-closing servicing and settlement remain fragmented. Excel sheets, endless email chains, manual data re-entry, broken reconciliation. Liquidity is not blocked by lack of capital. It is blocked by operational friction.

My goal was to build the Operating System for Loans. A unified platform connecting covenant monitoring, trade settlement, and cash distribution in real time.

What I Built

Credexia is a unified desktop platform covering three critical loan lifecycle stages in one dashboard. It is built on Next.js 16 with React 19, TypeScript 5.8, and styled with Tailwind CSS 4, MUI 7, and Framer Motion for animations.

Demo Video

See Credexia in action:

https://youtu.be/3GrR22gW9SU?si=aFDLldcB2vOJYxK8

Live Website

Try the platform:

https://credexia.vercel.app/

GitHub Repository

View the code:

kris70lesgo / Credexia

Credexia

A Next.js + Supabase + Ethers-powered platform for blockchain-verified loan covenant monitoring, OCR-driven data extraction, and portfolio analytics.

Features

AI-assisted chat for covenant guidance (Gemini)
OCR-backed document intake with fallback parsing
Covenant calculations (Debt/EBITDA, ICR, current ratio)
Polygon Amoy sealing for compliance events
Dashboard for loans, uploads, reports, and trade utilities

Stack

Next.js 16, TypeScript, Tailwind
Supabase (auth, DB, storage)
Ethers.js for Polygon interactions
Google Gemini for AI responses and parsing

Prerequisites

Node 18+ and npm
Supabase project with SUPABASE_URL and service key
Polygon Amoy RPC endpoint and funded deployer key
Gemini API key for AI features

Setup

Install deps: npm install
Copy .env.local.example to .env.local (if present) and set:

SUPABASE_URL=
SUPABASE_SERVICE_ROLE_KEY=
SUPABASE_ANON_KEY=
GEMINI_API_KEY=
POLYGON_RPC_URL=
BLOCKCHAIN_PRIVATE_KEY=
API_KEY=                  # optional API auth
ALLOWED_ORIGINS=*         # comma-separated list in prod

Run dev server: npm run dev
Optional: compile contracts: npx hardhat compile

Scripts

npm run dev – start Next.js dev server
npm…

View on GitHub

Monitoring

Tracks financial covenants like Debt/EBITDA and ESG covenants like Carbon Emissions. Users upload a PDF financial report. AI extracts values and calculates compliance. A traffic light system shows status: Green for Safe, Amber for Warning, Red for Breach. If an ESG covenant is breached, the interest rate automatically adjusts according to loan terms.

TradeClear

Digitizes the transfer of loan ownership. Users upload a Notice of Assignment PDF. AI extracts Seller, Buyer, and Trade Amount. After approval, the Ownership Register updates instantly. This removes manual ledger updates entirely.

AgentFlow

Automates the Payment Waterfall. It distributes borrower payments across lender banks, enforces zero rounding error, assigns any remainder to the Agent Bank, and generates SWIFT-ready CSV in seconds.

Global State

All three modules share a Global State. If ownership changes in TradeClear, AgentFlow instantly reflects the new owner without a page reload. This is managed through an in-memory global singleton with hot-reload safety, though this would need Redis or a database for true production multi-instance deployment.

How Gemini Powered Everything

I used Gemini at every layer of the stack. Not as a helper. As a co-builder. The AI layer centers on Google Gemini 2.5 Flash with a 4-tier fallback system: Gemini 2.5 Flash, Gemini 2.5 Pro, Gemini 1.5 Flash, and Gemini 1.5 Pro. OCR.space serves as a raw text backup when needed. A confidence gate at 60% ensures that if AI confidence drops below this threshold, the user must confirm before proceeding.

Document Understanding

The core feature is PDF ingestion. A credit analyst uploads Q4 financials. Gemini extracts the numbers, calculates ratios, and flags breaches. The extraction targets totalDebt and ebitda fields with confidence scoring. When confidence is low or parsing fails, an OCR fallback path activates.

The first extraction test I ran returned a Debt/EBITDA ratio of 47x. The real number was 4.7x. Gemini had misread a table cell. That single failure taught me why finance demands confidence gates and deterministic logic. I rebuilt the extraction layer with strict validation and the 60% confidence threshold.

Code Generation

I wrote maybe 40% of the React components myself. The rest came from Gemini prompts. The traffic light dashboard, the upload flow, the audit log interface. I would describe what I needed, iterate twice, and have production-ready code. The marketing landing page with animated hero, the login authentication flow, the portfolio dashboard with analytics cards, the loan tables, the document intake with OCR processing, the compliance reporting, the trade workflow UI, and the AI agent orchestration view all benefited from Gemini-generated code.

Blockchain Integration

I used Gemini to write the Solidity contracts for Polygon Amoy testnet. The CovenantRegistry.sol contract handles SHA-256 covenant sealing. Each compliance event gets a txHash for immutable audit trails. When I hit the "private key fiasco" at 3 AM, where my .env key had an extra character, Ethereum keys must be exactly 64 hex characters, Gemini debugged the error message with me. I also implemented a demo mode using FNV-1a hash simulation when the network fails, ensuring the demo never crashes regardless of API failure.

Trade Clearing Architecture

The trade module has 7 sub-routes forming a complete lifecycle: upload, parse, validate, owners, approve, confirm, and events. This supports partial ownership transfers between banks. The in-memory trade state singleton prevents loss during Next.js hot reload, though production would need a persistent store.

Payment Waterfall Precision

The waterfall distributes cash to syndicate members by ownership share. Floating-point remainder always assigns to Agent Bank to ensure exact totals. This handles fractional splits and guarantees perfect totals, solving the zero-variance requirement that took six hours to perfect. Not because the math is hard. Because financial systems demand perfection.

AI Chat Assistant

I built a covenant guidance chatbot powered by Gemini. It answers questions about loan covenants, risk analysis, debt-to-EBITDA calculations, document uploads, OCR extraction, blockchain verification, and portfolio insights.

The Pitch Deck

Yes, I even used Nano Banana, Gemini's image generation, for the pitch deck visuals. The LMA judges saw AI-generated diagrams explaining AI-powered compliance. Meta, but effective. Gemini helped structure the narrative and create visuals that made institutional infrastructure feel tangible.

Credexia_ Reinventing Trust, Transparency, and Automation in Loan Markets.pptx - Google Slides

docs.google.com

Technical Architecture

The frontend runs on Next.js 16 App Router with 18 API routes covering loans, chat, OCR, parsing, extraction, covenant calculations, blockchain sealing, compliance events, portfolio data, uploads, waterfalls, and the full trade lifecycle.

All business logic is implemented as pure functions with deterministic outputs. The covenant engine in particular has no side effects, calculating Debt/EBITDA ratios, Interest Coverage Ratios, and Current Ratios with strict mathematical precision.

Database and authentication use Supabase with Postgres and Storage. The blockchain layer uses Ethers.js 6 with Hardhat 3 for smart contract development. Smart contracts are written in Solidity and deployed to Polygon Amoy testnet.

What I Learned

AI Needs Guardrails

My first extraction failure taught me that finance cannot tolerate hallucination. The 47x versus 4.7x error led to the confidence gate system and deterministic validation layers. Every AI output gets verified before it touches a financial calculation.

Model Names Are Chaos

I spent two hours debugging 404 errors before realizing "gemini-2.5-flash" and "gemini-2.5-flash-preview" are different endpoints. The 4-tier fallback system was born from necessity, not planning. Incorrect model names caused API failures that required the retry logic I implemented.

Simulation Beats Broken Reality

OCR on messy financial tables failed constantly. Rather than fight it, I built demo-friendly PDFs with clean formatting and a manual override. The demo worked. The architecture was real. Resilient architecture means the app never crashes during demo regardless of API failure.

The Last Mile Is Process, Not Math

Getting the payment waterfall to sum to exactly 100% with no rounding errors took six hours. Not because the math is hard. Because financial systems require perfection. The operational friction in fintech is not about complex calculations. It is about ensuring those calculations are auditable, deterministic, and zero-error.

Schema Drift Happens Fast

Frontend expected fields that did not exist in Supabase. I adapted the frontend to the database rather than migrating the database mid-hackathon. This pragmatic approach preserved velocity when time was critical.

What Worked and What Didn't

What Worked

Speed. I prototyped a full-stack fintech platform in 48 hours because Gemini accelerated every decision. Multi-modal document understanding. The ability to throw a PDF at an API and get structured JSON back feels like magic when it works. The traffic light UI gave instant risk visibility across the portfolio. Honest error handling meant no silent failures. Users see real confidence and validation errors.

The Friction

Inconsistency. Same prompt, different results across model versions. Structured output sometimes ignored my schema. Financial tables in PDFs remain a hard problem. I needed OCR.space as a backup for messy scans. The messy financial tables broke OCR repeatedly, requiring the demo-friendly PDF approach.

What I Needed

Better documentation on model capabilities. Clearer error messages when context windows overflow. Native support for financial table extraction without custom preprocessing. More predictable structured output formatting for financial data.

Who This Is For

Credexia serves Credit Risk Analysts, Loan Agency Teams, Syndicated Loan Traders, Treasury Operations, ESG Compliance Teams, and Audit & Regulatory Teams. Eventually it will serve rating agencies, regulators, and institutional investors. This is not consumer SaaS. This is institutional infrastructure.

Business Model

Monetization can happen through per-loan subscription, per-document processing fees, per-settlement fees, compliance enterprise licenses, ESG pricing modules, and audit trail services.

What's Next

Credexia is not a hackathon toy. It is institutional infrastructure. I am adding real-time ESG covenant monitoring, expanding to trade settlement workflows, and building out the audit trail for regulatory compliance.

Gemini got me from idea to working demo in 48 hours. The next 48 days are about making it production-grade. The architecture is real. The global state works. The blockchain sealing provides immutable audit trails. The payment waterfall guarantees zero variance. The AI extraction learns from every validation.

The foundation is built. Now it is time to scale.

Built with Next.js, Supabase, Polygon, and Google Gemini.

Bridgy: Helping Overwhelmed Communities Choose the Right Tool, Not Another Tool

Agastya Khati — Mon, 02 Mar 2026 04:32:18 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

A few months ago, a friend reached out to him late at night.

“Do you know any tool that can actually help with this? I’ve been searching for an hour and now I’m more overwhelmed than when I started.”

The friend was a college student. Smart, capable, constantly juggling assignments, exams, and expectations.

He also had ADHD.

The problem wasn’t a lack of tools it was the opposite.

Productivity apps. ADHD planners. Focus tools. Study systems. Recommendation threads. Endless “best apps” lists.

Each search added another decision.

Each decision increased the cognitive load.

By the time the search ended, nothing had been chosen and the overwhelm had only grown.

The person reading that message understood immediately.

He is part of the same overlapping communities:

a college student
a developer
someone living with ADHD

In these communities, the hardest part is often not execution it’s starting.

And starting means choosing. Choosing means evaluating options. And evaluating options is exhausting when your brain is already overloaded.

What actually helped wasn’t finding another tool.

What helped was when someone narrowed the field and said:

“Based on what you’re dealing with right now, start here.”

Bridgy is built for that moment.

What I Built

Bridgy is a transparent, rule based resource matching web app designed to reduce decision paralysis not add to it.

Instead of asking users to browse endlessly, Bridgy:

Accepts natural language input or a simple 3 question guided flow
Interprets context (community, problem, urgency)
Matches users to 2–3 curated resources
Explains why each resource was selected
Suggests one concrete next action

There are:

no black-box recommendations
no scraping
no tracking
no stored personal data

Every recommendation is deterministic and explainable.

AI is used only to understand language and rewrite explanations empathetically never to decide what resources are shown.

Demo

Video Demo

Code

GitHub Repository

kris70lesgo / bridgy

Bridgy

Transparent, rule-based resource matching for neurodivergent minds.

Bridgy helps people with ADHD, autism, dyslexia, anxiety, depression, and related conditions find the right tools and support — without black-box algorithms, data collection, or tracking. Every recommendation is deterministic and explainable.

Overview

Bridgy is a static-first, privacy-first web app. Users describe what they need — either by answering a short guided questionnaire or typing freely — and Bridgy matches them to a curated set of 32+ resources using a fully transparent, deterministic scoring engine.

There is no backend database, no user accounts, no analytics, and no data sent to third parties beyond an optional LLM call to parse free-text input. The entire matching logic lives in client-side code that anyone can read.

…

View on GitHub

The full codebase is open and readable.

All matching logic, scoring rules, and data models live in the repository.

How I Built It

Architecture Philosophy

Bridgy is intentionally:

Static-first
Privacy-first
Explainable by design

There is:

no backend database
no user accounts
no analytics
no stored user data

The app works fully even without an API key.

Tech Stack

Layer	Technology
Framework	Next.js 16 (App Router)
Language	TypeScript (strict)
UI	React 19
Styling	Tailwind CSS v4
Icons	Lucide React
LLM Gateway	OpenRouter (GLM-4.5 → Gemini 2.0 Flash fallback)
Deployment	Vercel

How Bridgy Works

User Input
- Guided mode (community → problem → urgency)
- OR free-text natural language
Intent Parsing
- Free text is parsed into structured intent using GLM-4.5
- Falls back to Gemini 2.0 Flash
- If no API key exists, a keyword-based local parser runs instead
Deterministic Scoring
- Community match: +3
- Problem match: +3
- Urgency match: +1
- Human support (when requested): +2

Same input always produces the same ranked output.

Transparent Results
- 2–3 matched resources
- “Why this?” explanations
- One clear next action

Why These Decisions Matter

Bridgy deliberately avoids:

web scraping
live search
user tracking
black-box AI recommendations

For people who are already overwhelmed, trust and clarity matter more than clever automation.

Every design decision was made to reduce cognitive load not increase it.

Closing

Technology has done a great job building tools for communities.

It has done a much worse job helping people navigate between them.

Bridgy is a small attempt to bridge that gap not by adding more options, but by helping someone take one clear step forward when everything feels like too much.

Sometimes, that’s enough to change the direction of a day.

Copilot Sherlock : Governed Incident Investigation CLI

Agastya Khati — Sun, 15 Feb 2026 16:14:19 +0000

This is a submission for the GitHub Copilot CLI Challenge

Copilot Sherlock — Governed Incident Investigation CLI

AI proposes. Humans decide. The system verifies.

What I Built

I built Sherlock, a CLI-based incident investigation system that demonstrates how to use GitHub Copilot CLI inside a real production-style workflow, not just as a code generator or chat assistant.

Sherlock turns raw production evidence (logs, metrics, deployments) into a governed, auditable incident decision with a strict lifecycle:

AI performs bounded reasoning
Humans explicitly decide (ACCEPT / MODIFY / REJECT)
The system enforces authority and lifecycle rules
Outcomes are recorded as append-only organizational memory
All artifacts are cryptographically verifiable

AI never decides. Humans always decide.

This is not an AI demo.
It’s an incident lifecycle system with AI inside it.

The 90-Second Pitch

Most incident tools do one of two things:

Give you AI suggestions with no governance
Give you checklists with no intelligence

Sherlock separates intelligence from authority:

AI proposes multiple competing hypotheses with evidence and confidence
Humans approve or reject the outcome
The system enforces lifecycle gates, memory isolation, and execution rules
Every decision is immutable and externally verifiable

There are no feedback loops, no auto-approval, and no adaptive behavior.

This is what production-grade AI assistance looks like.

Demo

Video Walkthrough (Full End-to-End Run)

GitHub Repository

https://github.com/kris70lesgo/sherlock-demo

One-Command Demo

./run-demo.sh

This executes the entire incident lifecycle:

Evidence normalization and trust validation
Scope reduction (thousands of log lines → a few signals)
AI hypothesis reasoning using GitHub Copilot CLI
Mandatory human governance (ACCEPT / MODIFY / REJECT)
Organizational memory write (append only, read only)
Operational integration (Slack / JIRA simulation)
Cryptographic provenance and trust report generation

Fresh Incident IDs

To avoid append-only memory conflicts, you can run:

./sherlock investigate INC-999

Copilot Auth vs Offline Mode

Sherlock uses GitHub Copilot CLI for Phase 3 reasoning when authenticated.

If Copilot is not authenticated, Sherlock falls back to an offline post-mortem generator so the demo still completes.

To authenticate Copilot:

gh auth login

My Experience with GitHub Copilot CLI

Copilot CLI was used as a reasoning engine, not as an authority.

Specifically:

Copilot generates multi-hypothesis RCAs from scoped evidence
Each hypothesis includes:
- Evidence FOR
- Evidence AGAINST
- Confidence contribution
Confidence is budgeted and uncertainty is explicit
Hypotheses can be ruled out with justification

Crucially:

Copilot cannot finalize anything
It cannot approve itself
It cannot modify governance rules
Its output is preserved even when rejected

The most valuable aspect of Copilot CLI here wasn’t speed it was structured reasoning under constraints.
Once those constraints were clear, Copilot became a reliable component in a larger system instead of a black box.

Why This Matters

Sherlock demonstrates:

How to use Copilot CLI inside a production workflow
How to prevent AI feedback loops
How to enforce human authority mechanically
How to make AI output externally verifiable
How to integrate AI without letting it run the system

Most tools ask you to trust them.

Sherlock gives you a way to verify them.

That’s the difference between a demo and a product.

Final Notes

Language: Bash + Python
Interface: CLI (interactive and non-interactive modes)
Architecture: 7 phase, strictly isolated pipeline
Status: Frozen, validated, demo ready

Thanks for checking it out.

[Boost]

Agastya Khati — Sun, 01 Feb 2026 03:49:52 +0000

3D-First Portfolio Built with Antigravity

Paimon ・ Jan 31

#devchallenge #googleaichallenge #portfolio #gemini

Building a Portfolio with Gemini - New Year, New You Portfolio Challenge

Agastya Khati — Sat, 31 Jan 2026 13:50:57 +0000

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

About Me

This project started with a simple question:

What happens when you stop treating AI as a tool that writes code, and start treating it as a creative and technical collaborator?
I wanted to explore how far modern Google AI tools specifically Gemini 3 and Antigravity could take an idea when used for thinking, designing, iterating, and refining, not just generating snippets.

This portfolio is the result of that exploration.

It’s not meant to be flashy for the sake of it. It’s meant to show how clarity, motion, and structure can emerge naturally when ideas are shaped collaboratively with AI from the very first layout decision to the final animation timing.

Portfolio

Video Walkthrough

To better showcase the motion, flow, and animation details, here’s a short walkthrough of the portfolio.

This video highlights:

The hero intro animation
Scroll-based reveals and transitions
Micro-interactions and motion pacing
Overall visual flow and structure

Note on presentation

While the portfolio is fully deployed on Google Cloud Run, embedding it directly inside a DEV post limits viewport size and affects animation timing.

To preserve the intended experience, a short video walkthrough is included below, along with a direct link to view the portfolio in a full browser window.

Live Portfolio:

https://port-709587781727.us-central1.run.app/

--labels dev-tutorial=devnewyear2026

How I Built It

This portfolio was built through an AI-assisted vibe-coding workflow powered by Gemini 3 and Google Antigravity.

Rather than starting with rigid wireframes or a fixed specification, the process focused on momentum — letting ideas evolve quickly while keeping the system coherent.

Gemini 3 as a Creative and Technical Partner

Gemini 3 was used throughout development as a reasoning and design partner.

Instead of asking it to “write code,” I used Gemini to:

Explore multiple animation approaches before choosing one
Reason about motion pacing and visual hierarchy
Design section flow and narrative structure
Stress-test interaction ideas conceptually
Refine micro-interactions and transitions

Gemini helped answer questions like:

How long should an intro animation last before it feels slow?
How do you guide attention without overwhelming the user?
Where should motion stop so content can breathe?

This kind of feedback loop made it possible to move fast without losing intention.

Hero Intro Animation

One of the clearest examples of Gemini’s impact is the hero intro animation.

Instead of dropping the user into a static page, the portfolio opens with a carefully paced sequence:

The hero content begins subtly scaled down and centered
It fades in and scales up smoothly
The layout then transitions into its natural position
Supporting elements appear in a controlled, staggered flow

This animation was iterated multiple times using Gemini to evaluate:

Timing curves
Ease functions
Entry order
Emotional impact vs. speed

The result is an intro that feels cinematic but restrained designed to set tone, not steal attention.

Antigravity as the Execution Engine

While Gemini helped shape ideas, Antigravity made execution fluid.
Antigravity allowed rapid iteration across:

Component structure
Animation tuning
Layout refinements
Refactors without breaking flow

Instead of working file by file, Antigravity made it possible to think system-wide adjusting animation logic, layout, and styling together while maintaining consistency.

This kept the creative momentum high without sacrificing technical cleanliness.

Tech Stack

Next.js (App Router)
React
TypeScript
Tailwind CSS
GSAP for complex timeline animations
Framer Motion for scroll-based reveals and micro-interactions
Radix UI / shadcn for accessible primitives
Deployed on Google Cloud Run

What I’m Most Proud Of

The Flow

Nothing in this portfolio is abrupt.
Sections don’t “appear.”

They arrive.
Animations guide the eye instead of competing for attention, creating a calm, readable experience that still feels alive.

Animation Discipline

Motion is used sparingly and purposefully:

GSAP handles moments that require precision and choreography
Framer Motion handles moments that should feel natural and responsive
CSS handles everything that doesn’t need JavaScript

This balance keeps performance high and interactions smooth.

AI as an Enabler, Not a Gimmick

There’s no visible chatbot.

No AI button.
Yet AI is present in every decision.
Gemini and Antigravity didn’t replace creativity they amplified it. They made it possible to explore more ideas, discard weaker ones faster, and refine the strongest concepts with confidence.

Closing Thought

This project isn’t about a portfolio.
It’s about possibility.
It’s about what happens when developers stop asking AI to do the work and start asking it to think with them.
Gemini 3 and Antigravity didn’t just help build this site they shaped how it came to life.
And that’s the most exciting part.