With the right workflow and a small team of specialized agents, this was not an issue. We had a fully working PoC running end-to-end in under 48 hours. A scope that would normally require multiple engineers and a couple of weeks of work.
Yes, you read that right. And no, this is not another bullshit story about LLMs replacing engineers.
Shipping under pressure. A brand new thing in the space. Real constraints, unclear docs, and a ticking clock.
We had a fully working PoC running end-to-end in under 48 hours. A scope that would normally require multiple engineers and a couple of weeks of work.
Same problems. Same constraints. Different workflow.
The Web3 hype cycle and the race to ship
In crypto, the “thing” that captures everyone’s attention changes fast. We have lived through the NFT wave, then the meme coin era, and right now, prediction markets are the hot topic.
Prediction markets are basically places where people stop arguing on Twitter and start putting money behind their opinions. Instead of “trust me bro,” it becomes “bet me bro.” They turn collective vibes into prices and opinions into measurable signals about the future. For example, you can trade on whether a candidate will win an election or whether a specific token will hit a certain price by the end of the month.
When the ecosystem moves this quickly, staying relevant is not about having perfect architecture on day one. It is about shipping fast enough to learn in the real world.
That urgency is why speed became our main constraint.
We did not need a production-ready system. We needed proof that the idea could work end-to-end before the window closed. In less than 48 hours, we had a working PoC with custom on-chain Anchor programs, a backend layer that coordinated with them, and a live integration with Kalshi’s Web2 API. We wired everything together, validated behavior through scripts and tests, and ran the full flow on a local validator.
The point was not just that it worked, but how quickly it came together. Doing this from scratch with a single experienced backend and smart contract developer would realistically have taken a couple of weeks. Instead, we compressed that timeline into two days, proving both the technical feasibility of the model and our ability to move at the pace the market demands.
Where Web2 assumptions met self-custody reality
Okay, let me rewind and tell this properly from the beginning.
We got the requirement that we wanted to integrate Kalshi and bring prediction markets into the Solflare app. At first glance, this sounded straightforward. Just another API integration, nothing special. As an experienced backend engineer, I honestly did not expect anything dramatic here. I assumed it would be another clean Web2 service, a few endpoints, some auth, some mapping, and we would be done.
So I opened the Kalshi app, started playing with it, and then dove into their integration documentation. I wanted to understand how their markets worked, how positions were represented, how settlement happened, and how a third party like us was supposed to plug in.
At the beginning, everything still felt normal. The docs were structured, the concepts made sense, and I could already picture how a basic integration would look in our backend. I was mentally sketching out services, flows, and data models while reading.
But the deeper I went, the more things started to feel off.
Kalshi’s entire model was clearly built around users having their own accounts, their own credentials, and their own API keys. That might be fine for a centralized trading app, but it clashed directly with how Solflare is built. We are a self-custody wallet. Our users do not “log in” to external platforms. They own their keys, their assets, and their interactions happen on chain.
In our world, the user should not need a separate Kalshi account just to participate in a prediction market inside their wallet. That completely breaks the Web3 promise of ownership, composability, and seamless on-chain interaction.
I kept reading, thinking maybe there was some kind of partner mode, a shared account model, or a more Web3-friendly integration path. But page after page, the same assumption kept coming back. Everything revolved around per-user accounts and centralized identity.
The day “just follow the docs” died
I realized that the “just follow the docs” path was simply not going to work for Solflare. The very foundation of their model was incompatible with how we operate.
In that moment, the initial confidence faded into disappointment. And very quickly, disappointment turned into full PANIK MODE.
That moment forced a rethink.
If we could not make Kalshi fit into Solflare on their terms, we had to flip the problem around and make Kalshi fit our terms. Instead of every user having their own Kalshi account, we started designing a single Solflare vault that would mirror one Kalshi account on the Web2 side. From the user’s perspective, everything would remain self-custodial and on chain. From Kalshi’s perspective, they would still see a single trading entity. What we did not fully appreciate at the time was that pooling user funds through a single account effectively makes you a broker. And being a broker comes with its own licensing and compliance regime that does not fit neatly into how Kalshi contemplates third-party integrations.
What did the design look like?
For each prediction market, we moved away from individual bets and toward a pooled position model. When users took a Yes or No position, they were not placing an order on Kalshi directly. Instead, they received tokenized shares representing their slice of a shared pool for that market. The pool held the collateral, tracked exposure, and later handled settlement collectively.
This meant we needed real on-chain logic, not just a thin API wrapper. We built a custom Anchor program that acted as a broker layer between Solflare users and the external market. It managed collateral custody, tracked user positions per market, and provided deterministic settlement logic once an outcome was known. At the same time, we built a coordinating backend service that talked to Kalshi, executed trades off-chain, and then reconciled those fills back to the program through an oracle flow.
The backend was not just a simple proxy. It handled market discovery, orderbooks, caching, rate limits, and all the messy details of Kalshi’s API. It also acted as the bridge that translated Web2 events into on chain state changes in our broker program.
In practice, this gave us a workable model for the PoC. Users interacted purely through Solflare and on chain accounts. Kalshi saw a clean, centralized counterparty. And we controlled the entire lifecycle of positions, from deposit and trading to final settlement.
That architectural pivot was the key insight. Instead of forcing Solflare into Kalshi’s model, we built our own model and mapped it to Kalshi behind the scenes.
That was the key value of the PoC. It proved that the model could work end-to-end inside a self-custody wallet, and gave us a much clearer picture of what the right production path would need to look like.
That’s also where the PoC exposed its own limit. The idea worked end to end, but the compliance reality we had already sensed was now impossible to ignore. We couldn’t take this exact path to production. And almost at that exact moment, DFlow reached out. They had built the same bridging concept we were chasing, bringing Kalshi’s prediction markets on chain in a compliant way, with the right infrastructure, the right legal structure, and an actual partnership with Kalshi already in place. It was exactly what we needed, right when we needed it. So instead of reinventing what they had already solved, we integrated with them.
Treating AI like a team, not a tool 👨🏻💻
The breakthrough came from a structured multi-agent setup, not raw AI coding.
Before diving into the details, here is a quick visualization of how my small agent team is organized:
I run a small team of specialized agents instead of a single all-purpose assistant. The core idea is simple: planning first, coding second. We validate the concept and lock a high-level technical specification before diving into implementation.
To make this work in practice, I separated the process into two clear phases: planning and execution.
In the planning phase, everything revolved around a Planner Agent. Its job was to think before we built. Under it, I used three subagents that worked together.
- The Spec Agent focused on flows, assumptions, and the threat model. It forced us to be explicit about custody, who controls funds, and what happens when things go wrong.
- The Architecture Agent shaped the core idea of the Solflare vault, defined boundaries between on-chain and off-chain logic, and mapped how data would move between systems.
- The Risk Agent listed edge cases, failure modes, and clear non-goals so we did not overengineer a PoC.
When the design felt solid, we moved into execution.
In the execution phase, the Engineer Agent took over. This agent owned implementation and coordination. Instead of trying to do everything itself, it delegated work to specialized builders.
- The Solana Contract Agent implemented the Anchor program, defined PDAs, accounts, and settlement logic.
- The Backend Agent handled Kalshi integration, signing, orchestration, and reconciliation between Web2 and the on-chain state.
- The Testing Agent built local validator tests, scripts, and edge case scenarios so we could validate the flow quickly.
- The Code Polishing Agent cleaned up the structure, removed duplication, and made the output look like real production code rather than raw AI drafts.
Once all pieces came together, a separate Reviewer Agent performed an independent sanity check. It did not write code. Instead, it questioned assumptions, flagged inconsistencies, and forced clarity where things were fuzzy.
Finally, the Engineer Agent applied that feedback, aligned all agents again, and produced the working PoC.
In practice, this split kept us fast without losing discipline. Planner agents kept us honest about what we were building. Engineer agents kept us moving. The reviewer made sure we did not fool ourselves.
Getting to this setup took some trial and error. I bounced between different models and configurations, testing them across planning, reasoning, and implementation tasks. I tried heavier “thinking” models, smaller, faster ones, and mixed setups for different agents.
In the end, I kept coming back to Claude, with some specialized agents on OpenAI models. In my current setup, most agents run on Opus and Sonnet, not because they are perfect, but because they are reliable at holding context, respecting architectural constraints, and staying aligned across longer workflows.
The exact model matters less than how it is used. What made the real difference was narrowing each agent to a very specific role, backed by a strict system prompt that defines its responsibilities, boundaries, and expectations.
AI as leverage, not a replacement
In the end, this experiment was less about prediction markets and more about how we build under pressure. The PoC proved that we could bridge Web2 and Web3 in a way that respected Solflare’s self-custody principles, while still working with a traditional provider like Kalshi.
The real win was the process. A clear split between planning and execution, plus a structured multi-agent setup, let us move fast without losing control of the architecture. AI did not replace engineering judgment. It amplified it, reduced friction, and helped us validate a complex idea before investing months of work.
We did not ship this exact architecture to production, but the process gave us the conviction and context to recognize the right path once it appeared. Confidence in the vault model, clarity on the technical risks, and a solid foundation for the next step. And something we did not expect: it led us straight to DFlow, the partner who had already built what we were trying to solve.
I’m curious where LLMs help you the most today: architecture, implementation, testing, or review? And where do they still fail you?
