A few weeks ago, I participated in the IBM Bob 2.0 Hackathon. It was a 48-hour event with 15,000+ participants. My project didn’t win.
And honestly? I’m grateful for that.
Not because I think failure is fun, but because it forced me to confront a pattern I’ve seen before: when the build gets exciting, I can start optimizing the technology before I’ve fully validated the problem, the constraints, and the judging criteria.
That’s not just a hackathon problem. It’s a product problem.
The project I built was "Nerve".
The idea behind nerve is simple but important: most coding agents treat every prompt like a fresh start. They forget context, re-plan everything from scratch, and lose work when a user changes direction mid-task. I wanted to build something that treated work as a persistent graph rather than a one-off prompt.
In other words, nerve is a coordination layer for agentic software development.
Instead of “new prompt = new plan,” nerve keeps a live task graph across prompts and sessions. It understands dependencies, tracks what is running, what is pending, and what can be safely replanned without interrupting in-flight work. It’s designed to allow AI coding agents to behave more like a collaborative engineering teammate and less like a forgetful assistant.
This is the kind of problem I care deeply about because it sits at the intersection of:
- AI systems
- software architecture
- developer experience
- workflow design
The core problem A lot of people talk about AI coding tools as if the main challenge is just “make the model smarter.”
But the real challenge is often workflow and continuity.
If your agent doesn’t understand the work graph, it can’t reason about:
- what is already in progress
- what is blocking other tasks
- what should be replanned after a new instruction
- what should remain untouched while the user changes direction
That was the gap I was trying to solve with nerve. The product idea was solid: persistent state, dependency-aware execution, incremental replanning, and a better model for long-running software work.
The technical stack The project was built across multiple layers:
Backend
- Python 3.13
- Uvicorn + Socket.IO
- LangChain + LangGraph
- Model integrations including IBM watsonx.ai, OpenRouter, Groq, Anthropic, DeepSeek, and more
- OCI Object Storage for file handling
- Async Python for task and execution coordination
Frontend / CLI
- Node.js 22
- React
- Ink (for terminal UI)
- Vite + TypeScript for the web workspace
The stack wasn’t arbitrary. I wanted the project to reflect a real developer workflow:
- model orchestration in the backend
- terminal-first interaction for power users
- browser-based workspace for accessibility and demos
- file and execution context that felt like a real coding environment, not a toy prompt UI
What I got wrong The honest answer is this: my idea was good, but my competition strategy was weak.
I got too focused on building. I spent too much energy perfecting the system and not enough energy validating whether I was solving the problem in the way the hackathon expected.
I didn’t pay enough attention to:
- the competition requirements
- the judging rubric
- the narrative needed to present the product clearly
- the constraints of a judged environment
In other words, I built something interesting without making sure it fit the framework in which it would be evaluated.
That was the real mistake.
The lesson This was the biggest lesson for me:
At a hackathon, the rules are part of the product.
You can build a compelling technical solution, but if it doesn’t fit the criteria, the story, and the expected format of the judging process, it won’t get recognized. A good idea is not enough; it has to be framed and delivered in a way that the judges can understand and evaluate.
This taught me something about product thinking:
- innovation without alignment is wasted effort
- the problem isn’t just what you build, it’s how it is positioned
- constraints are not obstacles; they are design inputs
- being technically strong is not the same as being strategically effective
It also taught me something about myself: I’m willing to be critical when it matters. I’m not interested in pretending the result was better than it was. I want to learn from the failure and improve my process.
That is the kind of honesty I think matters in engineering.
What I’m taking forward I’m not walking away from this empty-handed.
I’m walking away with:
And most importantly, I’m more convinced that the idea behind nerve is worth exploring further.
Because the challenge is not just building an AI assistant. It’s building a system that respects continuity, dependencies, and long-running intent.
That’s the future I want to work on.
If you’re interested in the project itself, you can check it out here: The presentation
And if you’re in the middle of your own build, I’d encourage you to do this before writing the next line of code: Read the rubric. Understand the criteria. Then build.
Because sometimes the biggest technical mistake isn’t the architecture. It’s forgetting that the rules are part of the product.
If you are interesting in working or hiring me, you can contact +60109068966 via Whatsapp.
Top comments (0)