This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

AI has become incredibly good at giving us answers.

Ask it how a wind vane works and it will explain the whole thing. Ask it how bridges carry weight and you will get a neat explanation of tension and compression. Ask it how shadows can tell time and, within seconds, you have the answer.

That is useful, but I kept thinking about one problem.

Knowing the answer is not the same as discovering it.

So for this hackathon, I wanted to build the opposite of a tutorial.

Instead of an AI that explains everything, I built one that sometimes refuses to explain.

Instead of giving you instructions, it gives you a problem.

Instead of keeping you on the screen, it eventually tells you to put the phone down.

That became NO-KIT.

Don't buy a kit. Don't watch a tutorial. Build it.

What I Built

NO-KIT is an open-source AI maker experience that turns ordinary things around you into small science and engineering challenges.

The interaction starts with a very simple question:

What do you already have?

You might have some cardboard, tape, paper, a straw, a pencil, string, a bottle or a few random objects that were probably going to end up in a drawer or recycling bin.

You show those materials to NO-KIT using your camera.

From there, the system identifies the useful materials and figures out what kind of physical challenge can realistically be built with them.

For example, if you have cardboard, a straw, tape and a pencil, NO-KIT might give you this mission:

WIND HACKER

Build something that can tell which direction the wind is coming from.

Notice what it does not say.

It does not tell you to build a wind vane.

It does not show you five steps.

It does not give you a diagram of the finished object.

The answer stays hidden.

You have to try.

If you get stuck, you can ask for a hint, but even the hints are deliberately limited.

Instead of saying:

"Cut the cardboard into an arrow and attach it..."

NO-KIT might ask:

"What part of your build needs to rotate?"

If you are still stuck, the next hint might be:

"Think about whether both ends should catch the same amount of wind."

The goal is not to withhold help for the sake of being difficult. The goal is to give you just enough help to make the next discovery yourself.

Then comes the most important part of the experience.

NO-KIT sends you outside.

You make a prediction, take the thing you built into the real world and test it.

Maybe it spins endlessly.

Maybe it hardly moves.

Maybe it works immediately.

Maybe it falls apart.

All of those results are useful because now the learner has something real to reason about.

You come back, record what happened, get another small hint if needed, modify the design and try again.

Only after the experiment succeeds does NO-KIT reveal what you actually built and explain the science behind it.

The complete learning loop looks like this:

LOOK
  ↓
CHALLENGE
  ↓
PREDICT
  ↓
BUILD
  ↓
GO OUTSIDE
  ↓
TEST
  ↓
OBSERVE
  ↓
GET ONE HINT
  ↓
ITERATE
  ↓
DISCOVER
  ↓
UNDERSTAND

The idea behind NO-KIT is simple:

the screen should be the shortest part of the experience.

NO-KIT currently includes challenges around wind, sunlight, rainfall, geometry, structures, sound, filtration and flight.

Some examples include:

• Wind Hacker, where you discover how a wind vane works
• Shadow Clock, where sunlight becomes your clock
• Rain Measurer, where everyday materials become a simple rain gauge
• Tree Height, where you estimate the height of a tree using geometry
• Bridge Breaker, where you experiment with paper and structural strength
• Sound Phone, where you explore vibration using cups and string
• Paper Glider, where you test lift, drag and iteration

There is one principle behind all of them:

Learning should not begin with "buy this kit." It should begin with "what do you already have?"

A delivery box can become material.

A bottle heading for recycling can become material.

A straw can become material.

A stick outside can become material.

The world is already full of science kits. Most of them just do not come in boxes labelled "science kit."

I also added a My Shelf section where discoveries can become collectible build cards, plus a small journal for predictions and observations.

And because the theme is literally Touch Grass, there is also a hidden Touch Grass Mode in the UI.

It opens an interactive field of grass that reacts to your pointer.

Was it necessary?

Probably not.

Was I going to submit a Touch Grass project without a button that literally lets you touch grass?

Absolutely not.

Demo

You can try NO-KIT here:

https://no-kit-client.onrender.com/

I recommend opening it on a phone because the experience is designed around camera input and moving between the screen and the real world.

For the quickest demo, try the Wind Hacker flow:

1. Press PLAY
2. Show NO-KIT your materials
3. Choose the Wind Hacker challenge
4. Try building something before requesting hints
5. Record what you think will happen
6. Take your build outside
7. Test it
8. Record what actually happened
9. Modify it if necessary
10. Unlock the discovery

There is also a reliable Demo Mode so the core journey can still be explored without needing to prepare specific materials first.

Code

The project is completely open source:

Repository:

https://github.com/khushi-infinity/NO-KIT

The repository includes the frontend, FastAPI backend, challenge system, material reasoning, Render deployment configuration, architecture notes and project progress log.

How I Built It

The most important architectural decision was that AI should support the experience, not become the experience.

The interesting part of NO-KIT is not sitting inside a chat window.

It is the physical loop outside of it.

The AI handles the parts where reasoning is genuinely useful:

photo of materials
        ↓
material understanding
        ↓
physical properties
        ↓
safe challenge candidates
        ↓
feasibility + learning ranking
        ↓
physical mission
        ↓
build and test
        ↓
observation
        ↓
small AI hint
        ↓
discovery

The frontend is built with React, TypeScript and Vite.

The backend uses FastAPI with Pydantic validation.

I deliberately avoided making the UI look like a typical AI product. There is no large chatbot box, no corporate dashboard and no glowing AI orb.

The interface is designed more like a playful science game, with chunky controls, challenge cards, bright colors, tactile interactions, discoveries and a physical-first flow.

Understanding materials

NO-KIT does not only treat an object as a name.

It also reasons about what that material can physically do.

For example:

cardboard
→ flat
→ lightweight
→ foldable
→ semi-rigid

string
→ flexible
→ connective
→ useful under tension

bottle
→ waterproof
→ container
→ transparent

straw
→ hollow
→ lightweight
→ relatively rigid

This lets the system reason about possible builds instead of relying only on fixed recipes.

The challenge pipeline is roughly:

detect materials
      ↓
normalize names
      ↓
infer physical properties
      ↓
find possible challenges
      ↓
check feasibility
      ↓
apply safety rules
      ↓
score learning value
      ↓
score experimentation value
      ↓
score outdoor relevance
      ↓
return the best options

That matters because the system should not suggest a project simply because one material happens to match.

The build has to make sense.

The open-weight AI layer

The backend is designed around an AIProvider interface:

class AIProvider:
    detectMaterials(image)
    generateChallenges(materials)
    evaluateAttempt(image, challenge)
    generateHint(context)
    explainDiscovery(context)

This gives NO-KIT two important modes.

The first is a deterministic DemoProvider, which keeps the judging experience reliable even if external inference is temporarily unavailable.

The second is an OpenWeightProvider, designed to work with an OpenAI-compatible open-weight inference endpoint.

The current provider configuration is built around:

• Qwen2.5-VL-7B-Instruct for visual understanding
• Qwen2.5-7B-Instruct for text reasoning and tutoring

The model configuration is controlled through backend environment variables rather than being hard-coded into the frontend.

That means the model can be changed without rewriting the product.

Teaching the AI to say less

This turned out to be one of the most interesting parts of the build.

A normal AI assistant is usually optimized to give the most complete answer it can.

NO-KIT often needs to do the opposite.

If the learner is supposed to discover a wind vane, the worst possible response would be a perfect tutorial explaining exactly how to make one.

So NO-KIT follows a different rule:

Give the smallest hint that helps the learner make the next discovery.

Hints are progressive.

Hint 1
small question

Hint 2
conceptual nudge

Hint 3
stronger clue

Discovery
solution revealed

The hidden solution also stays out of the public challenge response until the learner reaches the discovery stage.

That small technical detail protects the core idea of the entire product.

Safety matters

A generative DIY system can become unsafe very quickly if everything is allowed.

NO-KIT therefore filters out projects involving things such as fire, weapons, dangerous chemistry, mains electricity, unsafe ingestion and dangerous heights.

For the filtration experiment, the interface explicitly says:

DO NOT DRINK.

For this project, I would much rather have a smaller library of experiments that I trust than hundreds of automatically generated experiments that should never be attempted.

Render

I built NO-KIT with Render as the deployment platform.

The project includes a render.yaml Blueprint that defines the application architecture as:

Render Static Site
        │
        │ React + Vite
        ▼
   NO-KIT Client
        │
        │ API requests
        ▼
Render Web Service
        │
        │ FastAPI
        ▼
material reasoning
challenge ranking
AI provider
safety + validation

The frontend is currently live at:

https://no-kit-client.onrender.com/

The FastAPI service architecture also includes a /health endpoint for deployment checks, while AI credentials and other secrets remain server-side through environment variables.

Demo Mode is also intentionally treated as a first-class part of the application so a temporary inference failure does not destroy the physical learning flow halfway through a challenge.

Why Does Open Innovation Matter?

I could have connected NO-KIT directly to one closed multimodal API and built the entire product around it.

That would have been easier.

But it would also lock a very experimental learning experience to one model and one provider.

NO-KIT needs something more flexible.

A maker tutor might eventually need a smaller model that runs on a laptop.

A school might want student photos to stay inside infrastructure it controls.

Someone could create a gardening version of NO-KIT.

Someone else could adapt it for electronics, physics, woodworking or environmental science.

A contributor might want to change how hints work, replace the vision model, experiment with a smaller text model or fine-tune the tutor for a particular kind of learner.

With an open-weight architecture, those things are possible.

The architecture is intentionally:

NO-KIT
   ↓
AIProvider
   ↓
compatible open-weight model

instead of:

NO-KIT
   ↓
one proprietary model
   ↓
forever

That flexibility matters especially for education.

A ten-year-old with cardboard and tape does not need exactly the same AI behavior as someone inside a university maker lab.

A classroom with unreliable internet should not require exactly the same infrastructure as a cloud-hosted demo.

Open innovation makes it possible to adapt the intelligence itself to the environment where it is being used.

And that fits the idea behind NO-KIT surprisingly well.

The whole philosophy is:

Use what you have.

That should apply to the AI too.

There is something slightly funny about using capable AI models to eventually generate the instruction:

Put your phone down and go try it yourself.

But that is exactly why I built this.

AI does not always have to replace the difficult part.

Sometimes the difficult part is where the learning happens.

Prize Categories

Best Use of Render

I am submitting NO-KIT for Best Use of Render.

Render powers the deployed web experience and provides the architecture for the backend service that connects material understanding, challenge reasoning, safety checks and AI-powered tutoring.

The project uses a Render Static Site for the React frontend and a Render Web Service architecture for the FastAPI backend, configured through the repository's render.yaml.

So I ended up using cloud infrastructure to build an AI application whose most important instruction is:

Stop looking at the screen. Go build something.

And that feels pretty appropriate for Touch Grass.