DEV Community: Prachi

# I Wanted to Understand AI Beyond the Prompt Box: My Journey Into DSPy

Prachi — Tue, 27 Oct 2026 06:32:42 +0000

An exploration of open-source AI, the curiosity that started it, the errors that interrupted it, and the satisfaction of finally making something work.

There is something slightly inconvenient about being curious about too many things.

One day, I want to understand how language models work. Another day, I find myself exploring cybersecurity, quantitative finance, product management, or some entirely different corner of technology. Every field seems to have something interesting hiding underneath the surface, and I have this persistent feeling that I should at least try to understand it.

The problem is that trying everything and actually learning something are two very different things.

It is easy to watch a tutorial, understand the general idea, build something that works once, and move on to the next exciting thing. It is considerably harder to open someone else's codebase, navigate unfamiliar abstractions, figure out why something is failing, and stay long enough to understand what is happening beneath the interface.

For this exploration, I wanted to do the latter.

I decided to investigate DSPy, an open-source framework for programming language-model applications. I did not want to stop at understanding what the framework claimed to do. I wanted to see how it was structured, how its components interacted, and whether I could use what I learned to build a working demonstration of my own.

I started with questions. I ended up with source-code investigations, test runs, configuration errors, a locally running language model, and a much more concrete understanding of what it means to explore an open-source AI project.

This is that journey.

1. Why DSPy?

When we talk about building with language models, the conversation often revolves around prompts.

We write instructions, adjust the wording, test different variations, and hope the model produces the desired output. When the application becomes more complicated, managing those prompts and their interactions can become a problem of its own.

That made me interested in a different question:

What if I could think about a language-model application as a programmable system rather than a collection of prompts?

That question led me to DSPy.

DSPy provides abstractions for defining tasks, composing model-powered modules, and optimizing how those modules use language models. Instead of manually treating every prompt as an isolated piece of text, developers can describe the task they want to perform and build a structured program around it.

I found this interesting because it sits at the intersection of several things I wanted to understand: AI, software architecture, experimentation, and the process of turning an idea into a working system.

I could have chosen a framework simply because it was popular or built a small application using an API and stopped there. But I wanted to investigate the framework itself.

What happens when a prediction is called? What does a signature actually represent? How does a higher-level module build on a lower-level one? And what does optimization mean in a framework like this?

I did not have all the answers when I started.

That was precisely the point.

2. Before Building Anything, I Wanted to Understand the Architecture

My first step was to explore the repository and identify the main components I wanted to investigate.

Rather than trying to understand the entire codebase at once, I focused on a few concepts that appeared central to DSPy's programming model:

Signatures
The Predict module
ChainOfThought
Module composition
BootstrapFewShot optimization

I treated these as connected pieces rather than independent features.

Signatures: Defining the task

A DSPy signature describes the relationship between the inputs a task receives and the outputs it is expected to produce.

For example, a simple classification task might look like this:

import dspy

class ClassifyIntent(dspy.Signature):
    """Classify a customer message into a support category."""

    query: str = dspy.InputField()
    intent: str = dspy.OutputField()

This defines a task that accepts a customer query and produces an intent.

The interesting part is what the code does not contain: I am not manually writing out the complete prompt that the model must follow. Instead, I am defining the task's interface and letting DSPy handle the prediction workflow.

That distinction became a useful starting point for understanding the rest of the framework.

`Predict`: Turning a specification into a prediction

The next component was dspy.Predict.

classifier = dspy.Predict(ClassifyIntent)

result = classifier(
    query="I was charged twice for my order."
)

print(result.intent)

The signature specifies the task. The predictor executes it using the configured language model.

I wanted to understand how that relationship was implemented internally, not just how to use it in a script. That meant looking beyond the example and into DSPy's source code.

This was where the investigation started becoming more interesting. A framework's public interface tells you how developers are expected to use it. Its implementation begins to explain how that interface actually works.

`ChainOfThought`: Building on existing abstractions

I also investigated dspy.ChainOfThought.

Conceptually, it builds on the prediction machinery by extending a supplied signature with a reasoning field. It then delegates prediction to a standard dspy.Predict instance.

What interested me here was the design pattern.

Rather than creating an entirely separate prediction system, DSPy composes existing functionality into a higher-level module. That makes the framework's abstractions easier to connect conceptually: more sophisticated behavior can be built on top of the underlying prediction mechanism.

Modules and composition

I explored DSPy's module structure to understand how these components fit into larger applications.

This mattered because real applications rarely consist of a single prediction. They combine multiple steps, pass outputs between components, and organize model calls into a workflow.

Thinking in terms of modules shifted my attention from individual prompts to the structure of the application around them.

`BootstrapFewShot`: Exploring optimization

The final major component I focused on was BootstrapFewShot.

DSPy's teleprompting and optimization machinery can use training examples, model-generated demonstrations, and an evaluation metric to construct a predictor with demonstrations selected through an optimization process.

This raised another question for me: how do you demonstrate optimization without confusing the existence of an optimizer with proof that it improves performance?

I would return to that question when I began testing the framework.

3. Moving From Reading Code to Running It

Understanding an architecture on paper is useful. Running the code gives you a different kind of understanding.

I created a small investigation demo covering the concepts I had been exploring. The goal was not to build an elaborate product. It was to make the framework's behavior observable through a few focused examples.

The demo covered: https://youtu.be/klimwICb1a4

Inspecting signatures.
Executing dspy.Predict.
Executing dspy.ChainOfThought.
Composing a customer-support pipeline.
Demonstrating the BootstrapFewShot workflow.

For the initial experiments, I used DSPy's DummyLM.

A dummy language model is useful when you want to test a program's structure without depending on a real model response. It allows you to investigate how components are called and how data moves through the workflow.

However, I needed to be precise about what that proved.

A successful mock-based demonstration is evidence that the workflow executes. It is not evidence that a real language model will produce accurate outputs.

I wanted to demonstrate both.

That meant moving beyond the initial tests and connecting DSPy to a real model.

4. The First Setback: My Code Would Not Even Import

Open-source exploration sounds particularly elegant when described after everything has worked.

The actual process is less elegant.

At one point, Python raised a SyntaxError inside:

dspy/predict/chain_of_thought.py

The error pointed to a line of explanatory prose that Python was interpreting as code.

I had managed to get ordinary article text into a Python source file while working between the investigation and its explanation. Naturally, Python was not impressed by my literary ambitions.

The immediate problem was not DSPy's architecture. The file itself was syntactically invalid.

I inspected the affected section, checked the repository's Git status, and verified the source file rather than immediately reinstalling packages or changing unrelated code.

Once the file was back to valid Python, I tested the import again.

dspy_investigation_demo/.venv/bin/python -c "import dspy; print('DSPy version:', dspy.__version__)"

The output was:

DSPy version: 3.4.1

That was a small but important lesson in debugging: identify the layer where the failure occurs before attempting to fix it.

A syntax error in a source file, a missing dependency, and a model connection failure are different problems. Treating them as interchangeable usually creates more problems than it solves.

I had not learned anything profound about language-model optimization from this incident. I had, however, practiced a more useful habit: inspect the evidence before changing the system.

5. Testing the Workflow

With DSPy importing successfully, I ran the investigation's test suite.

dspy_investigation_demo/.venv/bin/pytest dspy_investigation_demo/test_demo.py -v

All five tests passed:

test_signature_declaration_and_fields
test_basic_predict_execution
test_chain_of_thought_execution
test_composed_pipeline_execution
test_optimization_with_bootstrap_fewshot

These tests covered the basic prediction workflow, signature declarations, module composition, and the optimization demonstration.

At this stage, I had evidence that the examples executed successfully under the test conditions.

But I still wanted to see the framework communicate with a real model.

That became the next stage of the investigation.

6. Connecting DSPy to Gemma Through Ollama

I already had Ollama installed and the gemma4:latest model available locally.

My next goal was straightforward: configure DSPy to use Gemma and create a small classification task.

I started with a customer-support example.

The input was:

I was charged twice for my order. Please refund the extra payment.

The expected category was billing.

The classification task itself was simple. The integration was where the debugging began.

The 404 error

My first DSPy execution failed with:

InvalidRequestError: 404 page not found (ollama, HTTP 404)

This was confusing because the model was installed and Ollama was available.

I needed to distinguish between two questions:

Was Ollama actually working?
Was DSPy communicating with it correctly?

I tested Ollama's API directly rather than assuming that the failure meant the model was broken.

Testing Ollama independently

I sent a direct request to the local chat endpoint, asking Gemma to reply with a fixed phrase.

My first attempt failed because the JSON contained an extra comma and a misplaced closing bracket.

The server responded with:

invalid character ']' looking for beginning of value

That was not a model failure or a DSPy failure. It was simply an invalid request body.

After correcting the JSON, the request succeeded:

{
  "model": "gemma4:latest",
  "message": {
    "role": "assistant",
    "content": "CONNECTION WORKS"
  },
  "done": true
}

The exact response structure returned by Ollama included additional metadata, but the important result was clear: Gemma responded successfully to a direct API call.

I now had evidence that Ollama was functioning independently of DSPy.

That narrowed the problem considerably.

Fixing the DSPy integration

The remaining issue was the way DSPy routed the model request.

I adjusted the model configuration to use DSPy's LiteLLM compatibility engine explicitly, keeping the Ollama endpoint and model name consistent with the working direct request.

The relevant configuration became:

lm = dspy.LM(
    "ollama_chat/gemma4:latest",
    api_base="http://localhost:11434",
    api_key="",
    model_type="chat",
    engine="litellm",
    cache=False,
)

dspy.configure(lm=lm)

With that configuration, the demo finally executed successfully.

The important part of this debugging process was not simply discovering which setting worked. It was separating the model server from the framework integration, testing them independently, and using the results to narrow down the failure.

I went from a generic HTTP 404 to a working local inference pipeline by breaking the problem into smaller, testable pieces.

7. The Moment the Demo Actually Worked

With the integration working, I ran the classification script again.

The output was:

--- DSPy + Gemma: Real Model Inference ---

Input: I was charged twice for my order. Please refund the extra payment.

Predicted intent: billing

Inference completed successfully.

It was a small result.

No complicated interface. No elaborate multi-agent system. No dramatic claim about changing the future of AI.

Just a customer message going into a program, a real local language model processing the request, and a category coming out.

But this result represented a different kind of progress from the earlier mock-based demonstration.

I had now verified that DSPy could execute the task using Gemma through Ollama on my machine.

I then extended the experiment into an interactive customer-support demo. Instead of supplying a single hard-coded input, I could enter different messages and have the program return a category and a suggested response.

For example, the inputs could describe:

A duplicate charge.
A delayed delivery.
An application that crashes when uploading a file.

The program used the same signature and prediction module for each request.

That made the demonstration more useful because I could observe how the same task definition behaved with different inputs.

It also introduced an important limitation: the categories and responses were model-generated, not guaranteed answers. A working inference pipeline does not automatically establish classification accuracy, response quality, or reliability across a wider dataset.

Those questions would require a separate evaluation.

For this investigation, the goal was narrower: understand the framework's structure and demonstrate a functioning real-model integration.

I had achieved that.

8. What I Learned Beyond the Code

The technical results were useful, but the process taught me a few things that were not specific to DSPy.

First, understanding a framework is different from knowing how to call it

It is easy to learn the syntax for creating a predictor.

It takes more work to understand how signatures define task interfaces, how modules compose, how prediction execution is organized, and where optimization fits into the design.

Reading source code alongside running small experiments helped connect these ideas.

I did not need to understand every file in the repository. I needed to identify the components relevant to my questions and follow their relationships.

That is a much more manageable way to approach a large codebase.

Second, a successful execution is not the same as a successful evaluation

The five passing tests demonstrated that my mock-based workflows executed under the tested conditions.

The Gemma experiment demonstrated that real inference worked.

Neither result, on its own, proved that DSPy produced better outputs than a manually written prompt or that BootstrapFewShot improved task performance.

To establish that, I would need a defined dataset, an appropriate metric, a baseline, and a controlled comparison.

That distinction matters because AI projects can look impressive long before their actual performance has been measured.

I wanted my investigation to distinguish what I had demonstrated from what remained to be tested.

Third, errors can help narrow a problem down

The syntax error, malformed JSON, and HTTP 404 were different failures at different layers.

Fixing them required different approaches.

I learned to check whether the source file was valid, whether the local model server responded, whether the request itself was well formed, and whether DSPy's provider configuration was correct.

Debugging became less about randomly changing settings and more about asking which assumption had failed.

Finally, curiosity needs a direction

I started this exploration because I wanted to understand something unfamiliar.

But curiosity alone can easily become endless browsing: another repository, another framework, another concept that seems interesting enough to investigate.

The useful part was choosing a specific set of questions and following them far enough to produce evidence.

I examined the architecture, built a small demo, tested the workflow, connected a real model, and recorded the result.

I did not master DSPy in a day. That was never a realistic goal.

I developed a more concrete understanding of a framework by working through a small, defined investigation.

That is a better outcome than simply collecting another technology name to put on a profile.

9. What I Would Explore Next

This investigation gave me a working foundation, but it also raised questions I have not yet answered.

The most interesting next step would be to evaluate optimization rather than merely demonstrate that an optimizer runs.

I would want to:

Build a small, labeled customer-support dataset.
Define a metric for classification quality.
Measure a baseline predictor before optimization.
Run BootstrapFewShot with suitable training examples.
Evaluate the optimized predictor on held-out examples.
Compare the results under the same conditions.

That would help answer a more substantive question: under what conditions does DSPy's optimization process improve the task, and how much improvement can be measured?

I would also want to investigate failure cases, including ambiguous messages, overlapping categories, and inputs that do not fit the predefined labels.

Those experiments would move the project from an architectural investigation and working demonstration toward a more rigorous evaluation.

For now, I have deliberately kept the scope small. A clear experiment with honest limitations is more useful than a complicated demo whose results I cannot explain.

Conclusion: The Point Was Never to Know Everything Immediately

I started this investigation with a familiar kind of curiosity: I wanted to understand another part of AI, and I did not want to settle for a superficial explanation.

I chose DSPy because its approach to programming language-model applications gave me a concrete architectural question to explore. I investigated its signatures, prediction modules, composition, and optimization workflow. I created a demonstration, ran five tests using a dummy language model, and then connected DSPy to Gemma through Ollama for real inference.

Along the way, I encountered errors that forced me to distinguish between source-code problems, malformed requests, and integration issues. I fixed them, verified the working configuration, and extended the experiment into an interactive demo.

The final output was modest. The learning process was more valuable.

I am still interested in too many things to pretend that I have settled on one narrow path. I want to explore AI, cybersecurity, quantitative systems, software engineering, and the ways technology becomes useful to people.

But I am beginning to understand that exploring everything does not mean trying to master everything simultaneously.

Sometimes it means choosing one question, following it beyond the documentation, making something work, understanding why it works, and being honest about what you have not yet proved.

I don't need to know everything today.

I do want to become the kind of person who can approach something unfamiliar, investigate it seriously, and build a working understanding of it.

For this project, that meant going from What exactly is DSPy doing? to a working local inference pipeline.

For the next one, the question will probably be different.

The process, I hope, will be better.

Project Evidence

This investigation included:

Source-code exploration of DSPy's signatures, prediction modules, and optimization machinery.
A demonstration covering signatures, Predict, ChainOfThought, module composition, and BootstrapFewShot.
Five passing tests using a dummy language model.
A real-model inference script using DSPy 3.4.1, Ollama 0.40.10, and the locally installed gemma4:latest model.
An interactive customer-support classification demonstration.

Scope note: The mock-based tests verified the example workflows. The Gemma integration verified that local inference worked for the demonstrated task. A controlled benchmark comparing prediction quality before and after optimization was outside the scope of this investigation.

SponsorLoop: More Support. Bigger Impact.

Prachi — Sun, 25 Oct 2026 19:16:10 +0000

SponsorLoop: An AI Agent for Sponsorship Outreach

A submission for Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Organizing a college hackathon is hard enough. Finding sponsors, researching companies, writing personalized pitches, managing follow-ups, and tracking commitments can feel like running an entirely separate operation.

SponsorLoop is an AI-powered sponsorship workflow agent designed for student hackathons, college festivals, and conferences.

It helps organizers:

Discover potential sponsors: Identify relevant prospects and review their fit for an event.
Prepare personalized pitches: Generate outreach drafts using event details and sponsorship packages.
Keep humans in control: Review and approve outreach drafts before they can be sent.
Manage the sponsorship pipeline: Track prospects from discovery and research through outreach, negotiation, and confirmation.
Track commitments: Keep sponsor deliverables and organizer obligations organized in one place.
Prepare social outreach: Create LinkedIn and Instagram message drafts that organizers can review and use themselves.

The goal is to reduce the repetitive coordination work involved in sponsorship outreach, giving organizers more time to focus on the event itself.

Demo

**Live demo:https://github.com/Prachivats-21/sponsorloop
**Video demo:https://youtu.be/-wnLMzHzC8k

The demo walks through finding sponsor prospects, generating a tailored pitch, reviewing and approving the draft, and tracking the sponsorship pipeline.

Code

GitHub repository: [Add your SponsorLoop repository URL]

SponsorLoop includes a FastAPI backend, a React frontend, SQLite-backed event and sponsorship records, a typed tool registry, and a workflow orchestrator.

The project is designed around a modular architecture so that the AI provider and individual tools can evolve without requiring the entire application to be rebuilt.

How I Built It

I built SponsorLoop as a workflow-oriented agent rather than a chatbot that simply returns text.

The application combines:

FastAPI for the backend API.
React and Vite for the frontend.
SQLite for persistent event, prospect, and outreach records.
Pydantic v2 for typed data validation.
A tool registry and custom orchestrator for coordinating the application's workflow.
An AI-provider layer designed to support different inference backends.

I'm using Hermes as part of my agent approach, with the aim of making the workflow tool-driven and extensible. The application itself manages the event data, sponsorship pipeline, and human-approval rules.

The project also contains an integration for running Gemma 2 through Ollama, alongside a deterministic fallback engine. The fallback keeps the core workflow usable when an external AI provider or local model service is unavailable.

One design principle matters particularly here: generated outreach is not automatically authorized outreach. Drafts require human approval before they can proceed to the sending workflow.

This separation makes it possible to automate repetitive preparation without giving the agent unrestricted control over external communication.

Why Does Open Innovation Matter?

Sponsorship workflows are not identical across communities.

A small college hackathon, a university technical festival, and a developer conference can have very different sponsor categories, outreach styles, packages, and approval processes.

Open innovation makes SponsorLoop easier for other organizers and developers to inspect, adapt, and extend. Someone could customize the sponsor categories, add a new outreach channel, improve the matching logic, or connect another AI provider without rebuilding the entire product.

It also makes the project's limitations easier to examine. Developers can see how the workflow operates, where human approval is enforced, and how the application behaves when an AI provider is unavailable.

For a project intended to help student communities, that flexibility matters. The goal is not to lock organizers into one provider or one rigid workflow. It's to give them a foundation they can improve together.

The Lazy Payoff

The repetitive work involved in sponsorship outreach includes searching for prospects, tailoring pitches, and keeping the pipeline up to date.

SponsorLoop brings those tasks into one workflow, reducing the amount of manual switching between documents, messages, and tracking sheets.

I haven't included a measured time-saving figure because I don't want to present an estimate as a benchmark. A useful next step is to compare the time required to research and draft outreach for the same set of sponsors manually versus using SponsorLoop.

The intended payoff is straightforward: less administrative repetition, more time for the work that actually makes an event successful.

Thank You!!!!!!!

Opportunity Radar: Never Miss an Opportunity Again 🎯

Prachi — Sun, 18 Oct 2026 18:23:32 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

As a college student, I've spent way too much time searching for hackathons, internships, and other opportunities across platforms like Unstop, LinkedIn, and various event websites.

The frustrating part wasn't finding opportunities. It was keeping track of them.

One opportunity would be on one platform, another somewhere else, and by the time I remembered to check again, registration might already be closed. I wanted to participate in more hackathons, explore internships, and discover opportunities relevant to my interests, but keeping track of everything became a task of its own.

So, I started building Opportunity Radar.

Opportunity Radar is an AI-assisted platform designed to bring opportunities into one place and help students discover which ones are relevant to them.

Here's what the current version can do:

Discover opportunities: Browse a structured collection of opportunities, including hackathons and other student-focused listings.
Match opportunities to your profile: Get relevance scores based on your interests and eligibility information.
Extract information using AI: Turn unstructured opportunity information into structured data, with a fallback path when local AI inference isn't available.
Add opportunities: Save additional listings through the interface.
Work with real application links: Keep the source and application information connected to each listing.

The project currently has a working React frontend and FastAPI backend, with opportunity listing, matching, extraction, and API health checks implemented.

The bigger vision is to make opportunity discovery less fragmented, so students can spend less time hunting for registrations and more time actually applying, building, and participating.

Who would pay for it?

Students would be the primary users, but the potential paying customers are institutions and communities that want to help students find relevant opportunities.

College placement cells, student clubs, hackathon communities, and career development teams could use a platform like this to curate opportunities, distribute relevant listings, and help students discover options they might otherwise miss.

I'm still exploring the business model. For now, the priority is building something useful, validating the core experience, and expanding its coverage responsibly.

Demo

**Live demo:https://youtu.be/Byri8N50mLo

Code

**GitHub repository: https://github.com/Prachivats-21/Opportunity-radar

The project is being developed as an open-source application, with a frontend, backend API, opportunity data, matching logic, AI-assisted extraction, and tests.

How I Built It

I built Opportunity Radar using a combination of web development, backend APIs, deterministic matching logic, and open-weight AI.

Current tech stack:

Frontend: React, TypeScript, and Vite
Backend: Python and FastAPI
AI inference: Ollama with a locally accessible model, including the Gemma model family explored during development
Data validation: Pydantic
Opportunity matching: Profile-based matching logic with relevance scoring
Testing: Automated backend tests and frontend build checks

One of the interesting parts was figuring out where AI actually helps and where it doesn't need to be involved.

Opportunity listings often contain unstructured information, including descriptions, eligibility requirements, and deadlines. AI can help extract that information into a structured format. Once the information is structured, deterministic logic can handle matching and validation more predictably.

This hybrid approach makes the system easier to test and reason about than relying on a model to make every decision.

I'm also working toward a modular source-integration architecture, so additional opportunity providers can be connected without rebuilding the entire application around each one.

The current version is a foundation, not a finished all-in-one aggregator. Broader platform integrations, automated updates, and more comprehensive deadline tracking are part of the direction I'm working toward.

Why Does Open Innovation Matter?

Opportunity Radar is built around a problem that affects students across different colleges, backgrounds, and technical skill levels.

Open innovation matters here because opportunity discovery shouldn't depend on access to an expensive proprietary AI service or a closed ecosystem.

Using open-weight models and local inference gives me greater control over experimentation, model selection, and the way information is processed. It also lets me explore a hybrid architecture where AI handles unstructured information while transparent application logic handles matching.

Open source makes the project easier for other developers to inspect, test, extend, and contribute to. Someone could improve the matching algorithm, add a new authorized data source, improve extraction accuracy, or build a feature for a particular student community.

I'd also like the source integrations to remain responsible. Not every platform provides a public API, and not every website permits automated collection. Building openly means making those limitations visible and designing integrations around permitted access rather than treating every website as data to scrape.

For me, open innovation isn't just about using an open model. It's about making the solution itself something others can understand and build upon.

Prize Categories

Select only the partner categories that match the tools and requirements actually used in the submitted project.

Open-source AI / open-weight model category, if applicable to the challenge's official criteria.
Any other applicable partner category, after checking its specific eligibility requirements.

What's Next?

The next steps for Opportunity Radar are to expand the opportunity database, add authorized source integrations, improve deadline tracking, strengthen profile-based recommendations, and validate the product with actual students.

The long-term goal is simple: students shouldn't have to be professional opportunity hunters just to find opportunities worth pursuing.

This is version one, and there's plenty left to build. But it starts with a problem I've experienced myself, and I'm excited to keep working on it.

Thanks for checking out Opportunity Radar! 🚀

DEV Community: Prachi

# I Wanted to Understand AI Beyond the Prompt Box: My Journey Into DSPy

1. Why DSPy?

2. Before Building Anything, I Wanted to Understand the Architecture

Signatures: Defining the task

Predict: Turning a specification into a prediction

ChainOfThought: Building on existing abstractions

Modules and composition

BootstrapFewShot: Exploring optimization

3. Moving From Reading Code to Running It

4. The First Setback: My Code Would Not Even Import

5. Testing the Workflow

6. Connecting DSPy to Gemma Through Ollama

The 404 error

Testing Ollama independently

Fixing the DSPy integration

7. The Moment the Demo Actually Worked

8. What I Learned Beyond the Code

First, understanding a framework is different from knowing how to call it

Second, a successful execution is not the same as a successful evaluation

Third, errors can help narrow a problem down

Finally, curiosity needs a direction

9. What I Would Explore Next

Conclusion: The Point Was Never to Know Everything Immediately

Project Evidence

SponsorLoop: More Support. Bigger Impact.

SponsorLoop: An AI Agent for Sponsorship Outreach

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

Opportunity Radar: Never Miss an Opportunity Again 🎯

What I Built

Who would pay for it?

Demo

Code

How I Built It

Why Does Open Innovation Matter?

Prize Categories

What's Next?

`Predict`: Turning a specification into a prediction

`ChainOfThought`: Building on existing abstractions

`BootstrapFewShot`: Exploring optimization