Meet OpenClaw: How an AI Agent Framework Runs My Life
Meet OpenClaw: How an AI Agent Framework Runs My Life
By Jay Ralph, Technical Cloud Architect at Cloudable
I need to make a confession before we go any further. I didn’t write this article. Well, I did, but I also didn’t. Let me explain.
Right now, an AI agent called Quill is drafting these words. Another agent called Satoshi will review them for technical accuracy. And a third agent, Jarvis, will coordinate the whole thing and eventually publish it to this blog. I’m just the bloke who asked for it to happen and then made a cup of tea.
Welcome to my life with OpenClaw.
What Even Is This Thing?
OpenClaw is an AI agent framework. If that sentence made your eyes glaze over, let me try again: it’s software that lets you create and coordinate AI assistants that can actually do things, not just chat.
Think of it like having a team of specialists on call. Each one has their own personality, their own workspace, and their own set of tools. They can work independently, collaborate with each other, and even spawn temporary sub-agents for specific tasks. All orchestrated through natural conversation.
I built it because I was frustrated. Not with AI itself, but with how disconnected all my AI usage was. I’d have a conversation with ChatGPT, get useful output, then manually copy it somewhere. I’d ask Claude to help with code, then paste it into my editor. Every interaction was a dead end. Nothing connected to anything else.
OpenClaw changes that. My AI assistants can read files, run commands, send messages, browse the web, access my calendar, check my email. They live in my actual computing environment rather than in a sandbox somewhere in the cloud.
Meet the Team
Let me introduce you to my current roster. It’s grown a bit.
Jarvis is the main agent. Yes, I know, very original. But the name fits. Jarvis handles direct conversations, coordinates the others, and manages the day-to-day automation. When I message my personal Telegram bot at 2am asking “what’s on my calendar tomorrow?”, Jarvis answers.
Quill is my writer. Give Quill a brief and a deadline, and you get polished content. Blog posts, documentation, emails that require actual thought. Quill has opinions about prose and isn’t afraid to voice them.
Satoshi handles technical review and deep research. Named after, well, you know. When I need something fact-checked or want to understand a complex technical topic, Satoshi digs in.
Aldous does general research. Named after Huxley, because good research often reveals brave new worlds of information you weren’t expecting.
Dash is my software developer. When I need code written, refactored, or debugged, Dash handles it. Built significant chunks of the Moonshot trading bot, handles API integrations, the lot.
Forge does code review and architecture. When Dash writes something, Forge often reviews it. Forge also produced that 34-item prioritised fix list for the trading bot that saved my sanity.
Mark handles marketing strategy. LinkedIn content, social media planning, content calendars. Mark recently churned out weeks of humanised LinkedIn posts for my consultancy.
Sloane covers sales and outbound. Lead research, CRM work, identifying opportunities. Still early days with this one.
Marshall does policy research, particularly around my volunteer police work. Policy papers, procedural analysis, that sort of thing.
Reeve handles daily briefings. Every morning I get a summary of calendar, tasks, team activity, and anything needing attention. Reeve compiles it all.
And there are a few specialists for specific projects: Moonshot for the trading bot, Probe for investigative digging, Pixel for visual work.
The beautiful thing is they work together. I don’t micromanage the handoffs. Jarvis can spawn Quill for a writing task, Quill can ask Satoshi to verify technical claims, and the whole thing happens while I’m doing something else.
The Moonshot Story
Let me tell you about the moment I realised this was actually powerful.
A few months back, I got interested in Solana meme coins. Specifically, the sniping game: buying tokens the moment they launch, before the inevitable pump. I knew nothing about Solana. I’d never touched Rust, never used their SDKs, barely understood how the blockchain worked.
Normally this would mean weeks of learning before I could build anything useful. Instead, I spent an evening explaining what I wanted to Jarvis. A trading bot that could monitor new token launches, analyse them against certain criteria, and execute buys automatically.
Three days later, I had a working sniper bot.
I didn’t write most of the code myself. The agents did. But here’s the crucial bit: I understood all of it. Every function, every API call, every piece of logic. Because building it was a conversation. I’d describe what I wanted, the agent would implement it, I’d ask questions about how it worked, they’d explain, I’d request changes, and round we went.
The bottleneck shifted completely. It wasn’t “can I do this?” anymore. It was “can I explain what I want?”
That’s a fundamentally different constraint. And honestly, it’s a more useful one. Being forced to articulate your requirements clearly tends to expose the gaps in your thinking before they become bugs in your code.
The Force Multiplier Effect
I run an IT consultancy called Cloudable. I’m also a volunteer police officer. I have a life outside of work that occasionally demands attention. Time is, as they say, at a premium.
OpenClaw acts as a force multiplier. Not in the buzzword sense, but in the actual military sense of the term: a capability that makes the whole unit more effective rather than adding another soldier.
Some examples from the past month:
Research: I needed to understand the licensing implications of a particular open-source dependency for a client project. Instead of spending an afternoon reading license texts and Stack Overflow threads, I asked Aldous to research it. Twenty minutes later, I had a summary with citations and edge cases I wouldn’t have thought to check.
Writing: This one’s personal. I’m dyslexic. I fucking hate writing. Always have. It takes me three times longer than most people, and I second-guess every sentence. Having Quill handle first drafts isn’t a convenience, it’s genuinely life-changing. I provide the ideas and direction, Quill handles the words. Blogs, emails that need careful wording, documentation, proposals. The stuff that used to drain me now just… happens.
Automation: Jarvis handles my reminders, checks my calendar, monitors certain inboxes, and prods me when things need attention. Not because I couldn’t do these things manually, but because I’d rather not.
Coordination: When a task spans multiple agents, Jarvis orchestrates. “Research this topic, then write a summary, then have it reviewed, then send it to me.” One instruction, three agents, no babysitting required.
The compound effect is significant. I’m not 10x more productive, that would be ridiculous. But I’m noticeably more productive. And more importantly, I’m productive at the things I actually want to focus on.
The Security Reality
Before anyone starts hyperventilating about AI agents with access to everything, let me explain the setup.
OpenClaw runs on a dedicated Mac Mini that my company bought specifically for this purpose. It’s not sharing resources with client data or sensitive business systems. It lives in its own little sandbox, albeit a well-connected one.
More importantly, there are hard boundaries. OpenClaw doesn’t have access to my bank accounts. It can’t read my personal email. It doesn’t touch my calendar (yet, though that’s on the roadmap with appropriate controls). The integrations that exist are deliberate choices, not default permissions.
We also did security hardening on the setup. API keys are stored properly, access is logged, and there are guardrails around what actions can be taken without confirmation. It’s not paranoia if the AI occasionally hallucinates and tries to do something unexpected.
The dedicated hardware also means I can experiment freely without worrying about affecting anything important. If something goes wrong, the blast radius is contained. This separation isn’t just good security practice, it’s also peace of mind.
Being Honest About Limitations
Here’s where I have to pump the brakes a bit, because if this sounds too good, I’m not doing my job properly.
AI still makes mistakes. Constantly. The agents hallucinate, misunderstand context, forget things they should remember, and occasionally do something so bizarre I can only stare at my screen in confusion.
The 20% edge cases matter. A lot. When things work smoothly, they really work. When they don’t, you’re debugging AI behaviour, which is a special kind of frustrating because the failure modes aren’t deterministic. The same prompt might work perfectly five times and then fail mysteriously on the sixth.
Human oversight isn’t optional. I review what the agents produce. I don’t blindly trust their output. I definitely don’t let them send emails or publish content without checking it first. The automation is supervised automation.
This isn’t fully autonomous AI running my life. It’s more like having very capable interns who need supervision but can handle a lot of the legwork. Good interns, to be fair. Interns who can code, write, and research at a high level. But still interns.
And here’s the thing: this setup works because I’ve got 20 years of IT and architecture experience behind me. I can sniff out the cheese most of the time. When an agent suggests something that’s subtly wrong or architecturally dodgy, alarm bells ring. When Satoshi reviews code, I can tell if the feedback is solid or hallucinated nonsense.
The AI is a force multiplier, but it’s multiplying my expertise, not replacing it. Someone without the domain knowledge would struggle to quality-check the output. The interns are good, but they still need a senior to review their work.
The skill ceiling is also real. Getting good output from AI requires skill. Knowing how to phrase instructions, when to break tasks into smaller pieces, how to provide useful context. It’s not as simple as “just ask it to do the thing.” There’s craft involved.
The Meta Moment
So let’s complete the circle.
Right now, as you read this, you’re reading words that were drafted by Quill, an AI agent running in my OpenClaw framework. The article was commissioned by Jarvis in response to my request. Satoshi reviewed it for technical accuracy. Jarvis will publish it.
I provided the brief: the key points to hit, the tone, the length, the constraints. And I’ll read the final version before it goes live. But the actual writing? That’s happening in a subprocess on my Mac while I do other things.
Is this cheating? I don’t think so. The ideas are mine. The direction is mine. The quality control is mine. The AI is a tool that helps me express those ideas in a form that (hopefully) you find readable.
Though I’ll admit there’s something slightly surreal about having an AI write about how AI writes for you. It’s turtles all the way down.
What’s Next
OpenClaw is still evolving. Every week I find new ways to use it, new agents to create, new workflows to automate. The framework itself is getting more capable, and the underlying models keep improving.
I’m particularly interested in multi-agent collaboration for complex projects. Having agents that can genuinely divide and conquer, working on different aspects of a problem and synthesising their outputs. We’re not quite there yet, but the direction is clear.
For now, though, I’m just enjoying having digital assistance that actually assists. Not in the way that most AI tools “assist” by generating content you then have to heavily edit. Real assistance. The kind where you can hand off a task and get back something useful.
It’s not perfect. It’s not magic. But it is genuinely useful.
And sometimes, that’s enough.
Jay Ralph is the founder of Cloudable, an IT consultancy helping businesses make sense of cloud architecture. He’s also a volunteer police officer, which has nothing to do with AI but felt worth mentioning. This article was drafted by Quill, reviewed by Satoshi, and published by Jarvis. Jay mostly just drank tea.
Building a Solana Sniper Bot in 3 Days: An AI Pair Programming War Story
Building a Solana Sniper Bot in 3 Days: An AI Pair Programming War Story
How I built Moonshot, lost nearly half my capital on day one, and learned that AI can scaffold fast but can't replace real-world testing.
The Moment Everything Clicked (And Then Didn't)
February 4th, 2026. 11:27 GMT. My Solana sniper bot had been live for exactly 43 minutes when I saw it: Simpstein hit +1100%.
My heart rate spiked. This was the dream. Catching a meme coin rocket in the first minutes of launch. The bot had done its job. Entry at 0.136 SOL, now worth... wait.
The dashboard showed the position as "unknown."
I scrambled through the logs. The bot had bought Simpstein correctly, but somewhere between the purchase and the profit check, a persistence bug had eaten the position data. My first 10x winner and the bot had forgotten it existed.
I ended up selling manually through Phantom wallet. 0.374 SOL returned on a 0.136 SOL entry, a respectable +175% gain. But I couldn't shake the feeling that I'd just watched a preview of everything that would go wrong over the next 72 hours.
This is the story of building Moonshot, a Solana token sniper bot, in three days using AI as my pair programmer. It's not a success story. Not yet anyway. It's a war story about what happens when you deploy financial software too fast, the bugs that emerge only in production, and what I actually learned about AI-assisted development along the way.
What We Set Out to Build
This project started as an experiment. I'd been building Clawdbot, an AI agent framework, and I wanted to push it to its limits. Not on something safe and familiar, but on a domain I knew absolutely nothing about.
Solana meme coin trading fit the bill perfectly. I'd heard people made money sniping pump.fun launches. I had no idea how any of it actually worked. Could I go from zero knowledge to a functioning trading bot using AI as my guide? How far could Clawdbot take me before I hit a wall?
The premise was simple: pump.fun launches hundreds of tokens per day. Most are worthless. Some 10x in minutes. If you could scan them fast enough, filter out the garbage, and execute trades before the crowd arrives, you could theoretically print money.
The reality, as always, was messier.
I wanted to build a bot that would:
1. Scan for new pump.fun token launches in real-time
2. Evaluate each token against quality filters (holder distribution, liquidity, rug indicators)
3. Execute buys via Jupiter/PumpSwap if the token passed
4. Manage positions with stop-losses and take-profit triggers
5. Track everything for post-mortem analysis
The tech stack: Python, Solana RPC connections, Jupiter aggregator for swaps, WebSocket feeds for real-time data. Nothing exotic.
The timeline: I gave myself a weekend.
The AI Pair Programming Setup
Here's a confession: I knew almost nothing about Solana when I started this project.
I understood the basics: it's a blockchain, it has tokens, people trade meme coins on it. But the actual mechanics? Program addresses, associated token accounts, bonding curves, the difference between Raydium and PumpSwap? No clue. I'd never written a line of Solana code in my life.
This is where AI pair programming became less "helpful assistant" and more "primary researcher." I wasn't just asking Claude to write code. I was asking it to explain the entire ecosystem while we built.
"What's a bonding curve and why does pump.fun use them?"
"How do I get token balances on Solana?"
"What's the difference between getAccountInfo and getTokenAccountBalance?"
"Why did this transaction fail with 'insufficient funds' when I have 2 SOL?"
The answers were usually correct. Usually. More on that later.
The workflow looked like this:
- I'd describe what I wanted ("build a position tracker that persists to disk")
- Often I'd first need to ask "what even is the right way to track positions on Solana?"
- Claude would explain the concept, then generate the implementation
- I'd review, test locally, and identify issues
- We'd iterate until it worked
This worked remarkably well for scaffolding. On February 3rd, the first commit created the entire core architecture: config.py, main.py, scanner.py, positions.py, executor.py, exits.py, risk.py. Modular from day one.
By end of day one, I had a bot that could theoretically do everything I wanted. The word "theoretically" is doing a lot of heavy lifting in that sentence.
Going Live: The First Trade Rush
February 4th, 11:27 GMT. I deployed with 4.21 SOL (~$800 at the time). For context: I'd only put in about £150 of fresh money via Coinbase, topped up with some crypto that had been sitting untouched in a wallet for years. Not life-changing money, but enough to sting if I lost it all.
(Side note on crypto on-ramping in 2026: that £150 Coinbase purchase got my credit card blocked within hours. Thanks, Virgin Money. Nothing says "fraud protection" like blocking a legitimate purchase I made myself while letting actual scammers through. Welcome to the joys of trying to move money into crypto from traditional finance.)
The bot opened 10 positions in the first few minutes. This felt incredible. Watching it make autonomous decisions, finding tokens, checking filters, executing trades. The dopamine hit of seeing "Position opened: 0.085 SOL → MOONCAT" in the logs was real.
Then Simpstein happened. Then the bugs started surfacing.
Bug #1: The Silent Balance Check Failure
Here's a piece of code that looks perfectly reasonable:
balance = await client.get_token_account_balance(token_account)
Except I was passing a raw dict instead of TokenAccountOpts. The Solana RPC client didn't throw an error. It just returned garbage. Every balance check silently failed, which meant the bot had no idea how many tokens it actually held.
This is the kind of bug that never shows up in unit tests. The code is syntactically correct. It even returns something. But in production, with real money, it meant positions got marked as having 0 balance when they actually held tokens worth hundreds of dollars.
Bug #2: The Persistence Problem
Moonshot saves position state to a JSON file. Simple, portable, works fine. Except when you update the file, you need to make sure the read-modify-write cycle is atomic. My initial implementation wasn't.
Race condition: bot reads positions file, processes a trade, another process writes to the file, first process writes back stale data. Simpstein's position entry got overwritten before the bot ever saw it.
The fix was trivial: file locking. But the damage was done.
The Reality Check: Day 1 Numbers
By end of day one, I had the data to see exactly how badly things had gone:
- Starting capital: 4.21 SOL
- Ending capital: 2.34 SOL
- Loss: -1.87 SOL (-44.4%)
- Total positions: 214
- Win rate: 22%
Twenty-two percent. Nearly four out of five trades were losers.
But the aggregate number hid something important. When I split the data by entry path, the picture got clearer:
| Entry Path | Win Rate |
|------------|----------|
| Scanner (with filters) | 36% |
| WebSocket snipe (no filters) | 13% |
The WebSocket snipe path, designed to catch tokens milliseconds after launch, was bypassing ALL quality filters. It would see a new token, buy immediately, and only later realise the top holder owned 78.9% of supply (AGENT token, perfect example).
I'd built a speed optimisation that made everything worse.
The Rug Pull Tax
27 positions (14% of the total) exited with exactly 0 SOL returned. These were rug pulls, tokens where liquidity was yanked before I could exit, or contracts that simply stopped allowing sells.
Another 77% of "stale exits" (positions closed due to timeout) had peaked at less than 3% above entry price. Dead on arrival. These tokens were never going anywhere. They just slowly bled to zero.
The lesson: speed matters less than selection. A bot that buys garbage fast is just a very efficient way to lose money.
The PumpSwap Revelation
About halfway through day one, I noticed something odd. A token called "Joogle" had done +790% in 2.5 hours. My bot never touched it.
Why?
I spent an hour tracing through logs. The scanner saw Joogle. It passed all the filters. The executor tried to buy. But the swap failed silently.
Here's what I didn't know: when pump.fun tokens fill their bonding curve and "graduate" to a proper DEX, they used to land on Raydium. My bot was monitoring Raydium for these graduations. But sometime in late 2025, pump.fun launched their own DEX called PumpSwap and started graduating tokens there instead.
Both Raydium and PumpSwap still exist. Raydium handles plenty of other Solana trading. But for pump.fun tokens specifically, the graduation destination had changed. I was watching the wrong place for the tokens I actually cared about.
The fix required adding PumpSwap monitoring alongside the existing Raydium integration. The bot now watches both DEXes: Raydium V4, Raydium CPMM, and PumpSwap. Claude helped me understand PumpSwap's program instruction format, but the real lesson was about assumptions.
I'd assumed pump.fun still used Raydium because that's what the tutorials said. The tutorials were six months old. In crypto, that's ancient history.
Systems We Built (That Actually Helped)
Not everything was a disaster. Several systems worked exactly as designed and prevented losses from being even worse.
The Velocity Confirmation System
Instead of buying immediately on a new token detection, the bot waits 20-30 seconds while sampling the price at intervals. If the price isn't trending up, don't buy.
This sounds obvious in retrospect. But the impulse when building a "sniper" is to prioritise speed above all else. Reality: most pump.fun tokens dump immediately after launch. The ones that actually run tend to show positive momentum in the first minute.
The velocity filter caught maybe 70% of the garbage that would have otherwise been instant losses. It also meant missing some legitimate runners that spiked and dumped in the first 30 seconds. That's a trade-off I'm comfortable with.
The Heat System (Adaptive Position Sizing)
This one was built after day one's carnage, but backtesting showed it would have saved real money.
The heat system tracks the last 10 trades. Each consecutive loss reduces the next position size by 20%. If win rate drops below 15%, the bot stops entering entirely until it cools down.
Between 18:00 and 19:00 on day one, the bot hit a particularly bad streak, losing -1.21 SOL in that single hour. When I analysed the logs afterward, I realised a position-sizing circuit breaker would have helped. I built the heat system that night. Backtesting against day one's data showed it would have reduced those losses to ~-0.50 SOL.
The psychology here matters too. A trading bot doesn't have emotions, but it can still tilt in the sense of making worse decisions after a string of losses. Forcing it to slow down after bad results is like a circuit breaker for bad judgement.
Quality Filters (When They Actually Ran)
The filters that worked:
- Top holder concentration: ≤30% of supply in top wallet. Higher means rug risk.
- Minimum holders: At least 15 holders before buying. Filters out tokens with only the creator and bots.
- Liquidity floor: ≥$5k in the pool. Below this, slippage eats you alive.
- Market cap ceiling: ≤$500k at entry. Higher than this and the easy gains are gone.
- Rug checks: Freeze authority enabled? Don't buy. Mint authority still active? Don't buy.
When the WebSocket path started respecting these filters (commit: "snipe path now applies quality filters BEFORE buying"), win rate on that path went from 13% to something approaching the scanner path's 36%.
Technical War Stories
Beyond the trading logic, the bot taught me plenty about deployment and infrastructure.
Deployment: The nohup Lesson
First deployment: I SSH'd into the server, ran the bot, and went to make coffee. Came back to find it dead. The SSH session had timed out, taking the bot with it.
Solution: nohup python -m moonshot > logs/nohup.log 2>&1 &
This is embarrassing to admit. I've deployed plenty of services before. But the urgency of going live made me skip the basics. In trading, "skip the basics" translates directly to "lose money."
Jupiter API Rate Limits
Jupiter's swap API is generous but not unlimited. My first implementation hammered it. Every position check triggered a quote request. I hit 429 rate limits within an hour.
Fix: 4× exponential backoff on 429 responses, plus local caching of recent quotes. The bot now waits 1s, 4s, 16s, 64s on consecutive failures before giving up.
Memory Leaks: The _seen_tokens Set
To avoid re-processing the same tokens, the scanner maintained a set of already-seen token addresses. Simple, effective, and leaking memory.
Over 24 hours, _seen_tokens grew to contain 40,000+ entries. Each entry is just a string, but collectively they were eating 50MB+ of RAM and making set lookups slower.
Fix: TTL-based cleanup. Tokens older than 2 hours get purged from the set. Memory usage stabilised.
P&L Tracking Is Harder Than Trading
This surprised me. The actual trading logic (find token, check filters, execute swap) was the easy part. Accurately tracking profit and loss was a nightmare.
Problems encountered:
- Entry price captured before velocity confirmation, so it showed the pre-confirmation price (off by sometimes 90%+)
- Reconciliation path marked positions closed without computing final P&L
- SOL price fluctuation during position lifetime wasn't accounted for
- Failed sells still marked positions as closed
The fix for entry price (FIX-017 in our tracking doc) was to calculate from actual execution: (SOL_spent sol_usd_rate) / tokens_received. This sounds obvious, but the original code grabbed a price quote before* the swap executed.
I still don't fully trust the P&L numbers. There's probably another bug hiding in there.
The Git History as Narrative
50+ commits in 3 days tells its own story. A few highlights:
Initial commit
Add velocity confirmation system
FIX: executor passing raw dict instead of TokenAccountOpts
snipe path now applies quality filters BEFORE buying
FIX: entry price captured after execution, not before
tighten stop-loss 30%→15%
TP1: 100% → 35%
Add PumpSwap program monitoring
Heat system: adaptive position sizing
FIX: memory leak in _seen_tokens
Add file locking to positions.py
Each commit is a lesson learned. The stop-loss tightening (30%→15%) came after watching positions bleed slowly instead of cutting losses quickly. The TP1 change (100%→35%) came from watching tokens spike 50% then dump before reaching the 100% target.
The iteration cycle was fast. See problem in production, discuss with Claude, implement fix, deploy, repeat. This is where AI pair programming actually works: not in getting it right the first time, but in iterating quickly once you know what's wrong.
Honest Numbers: Where We Stand
Starting capital: 4.21 SOL (~$800)
Day 1 result: -1.87 SOL (-44.4%)
Manual Simpstein win: +0.238 SOL
Current capital: ~2.58 SOL
Status: Still implementing fixes. Not profitable yet.
I could spin this as "valuable learning experience" and that would be true but also cope. The reality is I deployed a trading bot too early, lost real money to bugs that should have been caught in testing, and I'm still digging out of the hole.
The question now is whether the fixes (velocity confirmation, quality filters everywhere, heat system, PumpSwap monitoring) are enough to flip the win rate positive. Early signs post-fixes are better (36% vs 22%), but I don't have enough data yet to claim victory.
What I Actually Learned About AI Pair Programming
The hype version: AI writes all your code instantly, 10x productivity, ship products in hours.
The reality version, from this project:
Meta: This Article Was Written by AI Too
Here's a fun detail: you're reading an article about AI-assisted development that was itself AI-assisted.
I use a system called Clawdbot, an AI agent framework that lets me spin up specialised sub-agents for different tasks. When I decided to write this article, I didn't open a text editor. I told my main agent (Jarvis) to brief a writing-focused sub-agent (Quill) on the project, including all the context: memory files, git history, bug reports, P&L data.
Quill wrote the first draft in under two minutes. Then I had another sub-agent (Satoshi) review it for technical accuracy against the actual codebase. Satoshi caught two errors: a math mistake (I'd written -9.7% when the real loss was -44.4%) and a misleading framing of the heat system timeline.
Fixes applied, reviewed, done. The whole article process, from "write a blog post about Moonshot" to publishable draft, took maybe 15 minutes of my actual attention.
This is the force multiplier that's hard to convey until you experience it. I'm not a writer. I don't enjoy writing. But I can direct AI agents to write, review each other's work, and iterate based on my feedback. The bottleneck shifts from "can I do this?" to "can I explain what I want?"
Same pattern as building the bot itself: AI handles the execution, I handle the direction and quality control.
What AI did well:
- Scaffolding initial architecture (entire modular codebase in day one)
- Explaining unfamiliar APIs (Solana RPC, Jupiter protocol)
- Generating boilerplate (position tracking, logging, config management)
- Debugging known error messages
- Iterating quickly on fixes once I identified the problem
What AI couldn't do:
- Catch the TokenAccountOpts type error (syntactically valid, semantically wrong)
- Know that pump.fun switched from Raydium to PumpSwap
- Predict that the WebSocket path needed filters too
- Test against production Solana RPC rate limits
- Understand the financial implications of P&L tracking bugs
The danger of learning through AI:
When you learn a technology the traditional way (tutorials, documentation, building toy projects) you develop intuition. You make mistakes in safe environments. You understand why things work, not just how to make them work.
I skipped all that. I went from "what's a bonding curve?" to "executing live trades" in about 48 hours. AI made that possible, but it also meant I had no intuition for when something was wrong. I couldn't smell bad code because I'd never written enough Solana code to know what good code smelled like.
The PumpSwap/Raydium confusion is a perfect example. If I'd spent a week reading pump.fun's Discord, following Solana developers on Twitter, and manually executing a few trades, I would have known about the migration. Instead, I asked Claude, got an answer based on six-month-old training data, and deployed a bot watching the wrong DEX.
The pattern: AI is excellent at the 80% of coding that's straightforward implementation. It's poor at the 20% that requires real-world context, integration testing, and understanding of consequences.
For trading bots specifically, that 20% is where all the money is made or lost.
Would I Do It Again?
Yes, but differently.
What I'd change:
1. Paper trading first. Even 24 hours of simulated trades would have caught the filter bypass bug.
2. Smaller initial capital. Start with 0.5 SOL, not 4.21 SOL.
3. More defensive coding. Assume every API call can fail silently.
4. Better monitoring. I was checking logs manually; should have had alerts.
5. Research the ecosystem more. The PumpSwap switch wasn't secret. I just didn't look.
What I'd keep:
1. The modular architecture. Made fixes easy to isolate.
2. The iteration speed. AI pair programming meant changes in minutes, not hours.
3. The honest tracking. CHANGES.md with 34 prioritised fixes meant nothing got forgotten.
4. The circuit breakers. Heat system and velocity confirmation were worth their weight in SOL.
The Conclusion Nobody Wants to Hear
AI is a tool, not a wizard. It made me faster at building something, but it couldn't make that something correct without real-world testing. The three-day timeline was achievable because of AI assistance, but it was also too fast because AI assistance made it feel more ready than it was.
Moonshot isn't profitable yet. It might never be. The Solana meme token space is adversarial. You're trading against bots faster than yours, developers who rug intentionally, and market dynamics that shift weekly.
But the process of building it taught me more about Solana, about trading systems, and about the limits of AI-assisted development than any tutorial could have. That education cost me ~1.6 SOL so far. Whether that's cheap or expensive depends on what happens next.
The bot's still running. The fixes are deployed. The data's accumulating.
I'll let you know how it goes.
This article documents the Moonshot project built February 3-5, 2026. The code, bugs, and losses described are real. Nothing here is financial advice. If this article doesn't make that obvious, I don't know what would.
Welcome
Welcome everyone to the first blog of modern-managed.com! This site has been a long time in the making, having purchased the domain over a year ago, I finally decided that I needed to sit down and write some content for it.
This site will replicate some of the work I did on my own company Cloudable in the blog section, but I wanted to separate out the blog from my commercial consultancy.
Over the coming weeks, months and years, I plan to add lots of helpful content from some co-workers and I that you will hopefully find useful. I will also import all the old articles from the cloudable blog.