There's a narrative spreading through the industry: "AI is making junior developers obsolete."

Let me be direct: this is short-sighted thinking that will backfire.

Here's the math that people are missing: without juniors, there are no seniors. The senior engineers everyone is fighting to hire didn't emerge fully formed. They started as juniors who made mistakes, learned from them, and built the judgment that makes them valuable.

If companies stop hiring juniors because AI can "do the work," they're not solving a problem – they're creating a future talent crisis.

But here's what's actually true: AI can dramatically accelerate the journey from junior to senior – if you use it right.

The key word is if.

The Lesson That Still Applies

Years ago, when I was teaching people how to code, I wouldn't let them touch a keyboard for almost two months. No IDEs. No syntax. Just pen and paper. Flowcharts. Logic. Thinking things through.

And yes, they hated it.

Every cohort went through the same cycle: confusion, frustration, resistance… and then something clicked. The point was never to torture people. The point was to separate thinking from typing.

Today, I'm doing almost the exact same thing. Except now, the thing I'm keeping people away from isn't the keyboard. It's AI.

AI didn't change the fundamental dynamic of learning. It just moved the shortcut.

The developers who resisted the flowchart phase always struggled later. They could write syntax, but they couldn't solve problems. The ones who embraced the delay became the strongest engineers.

The same pattern is emerging with AI.

What AI Actually Changed (And What It Didn't)

AI made output cheap. You can generate a landing page, an onboarding flow, a backend API – even an entire MVP – in minutes.

But the hardest part of building software was never typing. It was deciding what to build, understanding why, and knowing what comes next.

AI doesn't automatically make juniors better. What it does is make bad thinking harder to spot.

You can look productive. You can ship something. You can even get early praise. And still not understand what you built.

The Hidden Cost

When someone generates code without understanding it:

• They can't debug it. When something breaks, they're starting from zero.
• They can't extend it. The next feature becomes another "prompt and pray" session.
• They can't teach it. Knowledge doesn't transfer because there's no knowledge – just output.
• They don't learn and evolve. Each project starts from the same baseline.
• They accumulate debt. Every line they don't understand is a liability someone else will pay for.

The Two Types of Knowledge

Not all engineering knowledge is the same.

Teachable knowledge you can learn from books, tutorials, and AI: syntax, design patterns, API documentation, best practices.

Earned knowledge only comes from experience: what happens when a production database runs out of disk space at 3 AM, how systems actually behave under load, the intuition that something "feels wrong" before you can articulate why.

You cannot shortcut earned knowledge. No amount of AI prompting will give you the gut feeling that comes from debugging a cascading failure at 3 AM while stakeholders are breathing down your neck.

But here's the insight: AI can dramatically compress teachable knowledge acquisition, freeing up more time for earning experiential knowledge.

The path from junior to senior used to take 5-10 years partly because so much time was spent learning syntax and memorizing APIs. AI eliminates most of that friction.

What's left is the stuff that matters: judgment, architecture, debugging under pressure, understanding systems holistically.

Why "Vibe Coding" Will Keep You Junior Forever

There's a term going around that I really don't like: "vibe coding."

Not because AI is bad. But because the term celebrates skipping the hard part.

Vibe coding sounds creative and playful. But what it often means is: "I don't really know what's happening here, but the demo works."

That's not engineering. That's gambling with better UX.

When you vibe code, you don't build a mental model. You build a result. And results without models don't scale.

The One-Shot Illusion

People brag about "one-shotting" an app or MVP. You can one-shot output. But you can't one-shot understanding.

The real test happens a week later – when something breaks, when a user asks for a change, when you need to add the next feature.

If your entire mental model is "ask AI and paste the answer," you don't have a system. You have a screenshot.

The Accelerated Path

Here's what my workflow looks like today, after 35+ years:

I spend very little time writing code.

Instead, I spend my time on planning, architecture, guiding AI, testing, review, and quality control. The actual code generation? AI does that.

But here's what's critical: I can do this because I've already built the mental models. I know what good code looks like. I can spot problems in AI-generated output. I understand the tradeoffs being made.

This is the endgame. This is what senior looks like in the AI era.

But you can't start here. If you try to adopt this workflow without foundational knowledge, you'll produce garbage confidently.

The Progression Model

Instead of asking "Should juniors use AI?" the better question is: "When, and how?"

The answer: staged access. Not banned. Staged.

Stage 1: Foundation (Weeks 1-8)

AI Role: Reviewer only

Write pseudocode and flowcharts first. Implement solutions manually. Use AI to review, critique, or explain – not to write. When AI suggests something, explain why it's suggesting it.

This is the hardest stage because it requires discipline. You'll feel slow. You'll watch others "ship faster." Ignore them. They're building on sand.

Stage 2: Assisted Implementation (Weeks 9-16)

AI Role: Collaborator

Use AI for boilerplate and repetitive code. Review all generated code line-by-line. Modify and improve AI suggestions.

The test: Can you debug it when it breaks? Can you extend it for the next feature? If yes, you're building real capability. If no, slow down.

Stage 3: Full Leverage (Months 4-12)

AI Role: Force multiplier

Strategically delegate well-understood tasks. Use AI for exploration and rapid prototyping. Maintain ownership of architecture and key decisions.

Stage 4: Architect Mode (Year 1+)

AI Role: Implementation engine

Spend 80-90% of your time on planning, architecture, and review. Write code only for the most critical or novel problems. Guide AI with precise specifications and constraints.

The constant across all stages: Human thinking remains at 100%.

The Modern Flowchart

The flowcharts I taught weren't about boxes and arrows. They were about delayed execution in service of clarity.

For visual learners, actual flowcharts and whiteboarding are still incredibly valuable. The medium matters less than the practice.

What you're building is a mental model of the entire application:

Understanding the models/objects: What are the core entities? How do they relate? Where does data live and flow?

Understanding the user flow: What triggers each action? What does the user see at each step? Where can things go wrong?

Understanding sync vs. async: What happens immediately? What happens in the background? What if async operations fail? This is where junior developers consistently struggle – and where bugs hide.

The Pre-AI Checklist

Before opening any AI tool, answer these:

1. What is the specific problem I'm solving? (One sentence, no jargon)
2. What are the inputs and outputs? (Concrete examples)
3. What are the constraints? (Performance, security, compatibility)
4. What are the edge cases? (What could go wrong?)
5. How will I verify the solution works? (Test criteria)
6. What do I expect the solution to look like? (Rough shape)

If you can't answer these questions, you're not ready to use AI effectively. You're ready to be confused by it.

For Engineering Leaders: Why You Should Still Hire Juniors

Some companies are reducing junior hiring because they believe AI can replace entry-level work. This is a mistake.

The Talent Pipeline Problem

Senior engineers don't materialize from thin air. If the industry stops investing in juniors, we're consuming a non-renewable resource.

The companies still hiring and developing juniors will have a massive advantage in 5-10 years when everyone else is fighting over a shrinking pool of seniors.

The AI-Augmented Junior

A junior using AI correctly can be productive much faster than previous generations. Ramp-up shrinks from 12-18 months to 4-6 months.

But this only works if you:

1. Invest in the foundation phase (don't let them skip to "AI does everything")
2. Pair them with seniors who can evaluate AI-assisted output
3. Create psychological safety for them to admit when they don't understand
4. Measure learning, not just output

Why This Matters for Teams

If juniors are rewarded for shipping fast without understanding, seniors end up doing archaeology instead of architecture. That's how good teams burn out.

The Team Anti-Patterns

The "AI Expert" Junior: Ships fast, can't explain anything, needs rescue on every bug.

The Archaeology Sprint: Seniors spend 40% of their time reverse-engineering AI-generated code.

The Invisible Debt: Everything works until it doesn't, then nobody knows why.

The Knowledge Silo: Only the AI "knows" how the system works.

The Team Best Practices

• Code review includes "explain this to me": If you can't explain it, you don't merge it.
• Architecture decisions are human decisions: AI can inform, but humans own the choices.
• Pairing includes AI discussion: Talk through what AI suggested and why you accepted or modified it.
• Documentation captures reasoning: Not just what, but why.

The THINK-BUILD-VERIFY Loop

A practical framework for AI-augmented development:

THINK (Human-Led): Define problem clearly. Identify constraints. Sketch approach. Anticipate edge cases.

BUILD (AI-Assisted): Accelerate with AI. Review every line. Modify for context. Maintain understanding.

VERIFY (Human-Owned): Test against requirements. Check edge cases. Ensure explainability. Document reasoning.

When to Use AI

Good uses: Boilerplate you understand but don't want to type. Exploring unfamiliar APIs. Generating test cases. Code review and suggestions. Explaining existing code.

Dangerous uses: Architecture decisions you don't understand. Security-critical code without review. Performance-sensitive logic without testing. Anything you couldn't debug if it broke. Business logic you can't explain to a colleague.

The Future Is Amplification, Not Replacement

AI is making undisciplined developers obsolete – at every level.

The junior who vibe codes without understanding? Obsolete. The senior who can't adapt their workflow to leverage AI? Also increasingly obsolete.

But the junior who uses AI as a learning accelerator while building real mental models? They'll reach senior-level capability faster than any previous generation.

And the companies smart enough to invest in these juniors? They're building the talent pipeline everyone else will be desperate for in five years.

AI is a power tool. Seniors know where to cut. Juniors learn by measuring twice.

If we get this right, AI won't replace good engineers. It'll finally let them focus on what actually matters: solving hard problems, making sound decisions, and building things that last.

The goal isn't to use AI less. It's to think more.

Key Takeaways

For Junior Developers:

• Resist using AI for code writing in the first 8 weeks
• Use AI as a reviewer, not an author, until you have mental models
• If you can't explain it, you don't understand it
• Teachable knowledge can be compressed; earned knowledge cannot be skipped

For Engineering Leaders:

• Without juniors, there are no seniors – invest now
• AI-augmented juniors ramp faster, but need the foundation phase
• "Explain this to me" is the new code review standard
• The companies hiring juniors today win the talent war tomorrow

For Everyone:

• AI made output cheap, not thinking cheap
• Results without mental models don't scale
• The goal is leverage without dependency

Here's why I'm doing this – and why you might want to join early.

The Problem I Keep Seeing

If you've tried deploying AI agents to production, you know the pattern.

The demo works beautifully. You chain together some prompts, hook up a few tools, show it to stakeholders. Everyone's excited.

Then you try to scale it. And it collapses.

The problem isn't the models. Claude, GPT-5, Gemini – they're incredible.

The problem is nobody's teaching the infrastructure side. The memory management. The orchestration. The observability. The deployment patterns that make the difference between "cool demo" and "system that actually works."

We're all making the same mistakes because that institutional knowledge doesn't exist yet.

So I'm Writing That Book

I've spent 30+ years building production systems that scale – across finance, data infrastructure, and AI deployment. My open-source libraries get 10+ million downloads a month. I've been in the trenches building systems that have to work when money's on the line.

Over the past few years, I've been building agentic AI systems. Hitting the same walls everyone else hits. Figuring out what actually works in production.

"Production-Grade Agentic AI" is everything I wish existed when I started. A comprehensive, ~600-page guide covering:

• What actually makes systems "agentic" (the three pillars most systems are missing)
• Memory systems that scale beyond toy examples
• Orchestration that handles real-world failures
• Observability that shows you what agents are thinking
• Deployment patterns with automatic failover
• Multi-model infrastructure to avoid vendor lock-in
• Real production examples, not just demos

This isn't vendor documentation. These are universal architecture patterns that work regardless of which LLM you're using.

Why I'm Publishing While Writing

Traditional publishing doesn't work for technical content that's evolving this fast. By the time a book goes through the full cycle, half the content is outdated.

More importantly: I want your feedback while I can still incorporate it.

Your questions. Your confusion. Your "this doesn't make sense" moments. Your production war stories. They make the book better – not just for you, but for everyone who reads it after.

So I'm writing in public. Releasing chapters as I finish them. Building this with the community, not in isolation.

Read It Now

The book is available today on LeanPub at founder pricing: $5 minimum (pay what you want).

Current status: 40% complete, over 200 pages already available

Timeline: Complete by November 22, 2024

Pricing: Increases every two weeks as content is added

• Now - Oct 24: $4.99+ (Founder Tier)
• Oct 25 - Nov 7: $9.99+ (Early Access)
• Nov 8 - Nov 21: $14.99+ (Pre-Launch)
• Nov 22 - Dec 5: $49.99 (Launch Week – covers Black Friday)
• Dec 6+: $79.99 (Standard Price)

Early readers also get access to a private GitHub repository with code examples, production templates, and community discussions.

Get early access on LeanPub →

A hardcover edition will be available on Amazon for those who prefer physical books.

Who This Is For

Engineers, architects, and technical leads building AI systems beyond the prototype stage.

If you're tired of agents that work in demos but break in production – if you want to understand the infrastructure that makes agentic systems reliable at scale – this is for you.

The teams that figure this out first will have a massive advantage.

Let's Build This Together

We're figuring out production agentic AI together. Not from ivory tower research, but from the trenches of building systems that have to work.

Your experience matters. Your perspective matters.

Let's build agents that actually work in production.

Join the early access →

Key changes:

1. Opens with the announcement as the lead
2. Explains the "why now" and "why this format"
3. Emphasizes the collaborative aspect
4. Makes the pricing and timeline more prominent
5. Stronger call-to-action throughout
6. Shorter, more scannable

Want me to adjust the tone or emphasis?

Walk into any AI conference, scan through GitHub's trending repositories, or browse the latest YC batch, and you'll see the same pattern everywhere: "AI workflow" tools, "agent orchestration platforms," and "intelligent automation" that reduces artificial intelligence to glorified script execution.

Here's the uncomfortable truth: "Agent workflow" is an oxymoron. And until we acknowledge this fundamental contradiction, we'll keep building brittle systems that break the moment reality doesn't match our templates.

The Great Contradiction

Let me be clear about what I mean:

Workflows are deterministic sequences. They follow predefined steps: Step 1 → Step 2 → Step 3. They're designed by humans who think they can predict every possible scenario. They're rigid, brittle, and fundamentally reactive.

Agents are supposed to be autonomous decision-makers. They should understand context, adapt to situations, and reason through problems. They should handle the unexpected gracefully, not crash when reality doesn't match the template.

You cannot have both. The moment you force an "agent" into a workflow, you've eliminated its intelligence. You've created an expensive, unreliable script that happens to use LLMs for some of its steps.

Why Everyone Got It Wrong

The entire industry fell into this trap because workflows feel like control. CTOs and engineering managers look at AI agents and think: "This is powerful, but unpredictable. I need to control it with workflows."

So we built systems that look like this:

Incident Detected
      ↓
Step 1: Analyze logs
      ↓
Step 2: Check runbooks
      ↓
Step 3: Execute remediation
      ↓
Step 4: Update ticket
      ↓
Step 5: Notify team

And we called it "intelligent incident response."

But what happens when:

• The logs are in an unexpected format?
• The runbook doesn't cover this specific scenario?
• The remediation fails and needs adaptation?
• The notification system is down?

The "intelligent agent" breaks. Because it was never intelligent – it was just a script with AI sprinkles.

The Workflow Death Spiral

Here's what happens to every workflow-based "AI" system:

Initial Workflow
      ↓
Edge Case Appears
      ↓
Patch Added
      ↓
Complexity Increases
      ↓
More Edge Cases
      ↓
More Patches
      ↓
Unmaintainable Mess
      ↓
Complete Failure

I call this the Workflow Death Spiral. Each patch makes the system more brittle, each edge case requires human intervention, and eventually, you have a Rube Goldberg machine that no one understands.

We've all seen it: the "simple" automation that now has 47 conditional branches, 23 exception handlers, and a 200-page runbook that no one reads. That's not intelligence – it's technical debt with an API key.

What Real Intelligence Looks Like

Here's how a truly autonomous system handles the same incident:

Incident Detected → Agent receives context:

"We have an incident. Here's what I know about our systems,
our procedures, and our past responses. Now think."

The agent doesn't follow steps. It reasons:

• "This looks similar to the database timeout issue from last month, but the symptoms are slightly different..."
• "Let me check the logs, but I'll also look at network metrics since that was the root cause before..."
• "The standard runbook suggests restarting the service, but given the current load, let me try scaling first..."
• "I should notify the team, but let me gather more context first so I can give them actionable information..."

Notice the difference? The agent isn't following a sequence – it's thinking through the problem using institutional knowledge as guidance, not gospel.

The SOP Revolution: Knowledge vs. Scripts

This is where Standard Operating Procedures (SOPs) come in – but not the way you think.

Most companies use SOPs as workflows: rigid sequences that must be followed exactly. But intelligent systems need SOPs as institutional knowledge – wisdom to reason over, not steps to execute blindly.

Instead of:

SOP: Incident Response Workflow
1. Check logs
2. Consult runbook
3. Execute fix
4. Update ticket

We need:

SOP: Incident Response Knowledge
- Our systems typically fail in these patterns...
- When we see these symptoms, it usually means...
- Past incidents taught us that...
- Be careful of these edge cases...
- Always consider these factors...

The difference is profound. The first creates robots. The second creates intelligent systems that can adapt, reason, and handle the unexpected.

"But We Need Control!" - The Valid Concern

I hear you. Autonomous systems sound scary. Let me address the elephant in the room: autonomous doesn't mean uncontrolled.

True intelligence operates within guardrails, not workflows:

• Guardrails: "Never delete production data. Always preserve user privacy. Escalate if confidence < 80%."
• Workflows: "If user says X, do Y. If user says Z, do Q."

Guardrails define boundaries. Workflows define every step. One enables intelligence, the other prevents it.

Think of it this way: we don't give human employees step-by-step scripts for every possible situation. We give them principles, training, and boundaries. Why would we do less for AI systems that are supposed to be intelligent?

How to Maintain Control Without Workflows:

1. Observable Reasoning: Every decision includes a reasoning trace
2. Reversible Actions: Built-in rollback capabilities
3. Confidence Thresholds: Automatic escalation when uncertain
4. Human Override: Always available, rarely needed
5. Audit Trails: Complete record of decisions and why they were made

Test Your System: The Intelligence Litmus Test

Is your "AI agent" actually intelligent? Run this diagnostic:

□ Can it handle a scenario you didn't explicitly program?
□ When it fails, does it adapt or just error out?
□ Can it explain WHY it made a decision, not just WHAT it did?
□ Does adding new capabilities require rewriting workflows?
□ Can it learn from past incidents without code changes?
□ Does it get better over time or just accumulate patches?

Score:

• 0-2 checks: You have an expensive script
• 3-4 checks: You're halfway to intelligence
• 5-6 checks: You have a true autonomous agent

Why This Matters Now

We're at a critical inflection point. The AI industry is racing to build "production-ready agent platforms," and almost everyone is building workflow engines with LLM steps.

This approach will fail. Not because the technology isn't ready, but because the architecture is fundamentally flawed.

You cannot achieve autonomous intelligence by chaining deterministic steps. You cannot create adaptive systems by predicting every possible scenario. You cannot build truly intelligent agents by reducing them to glorified automation.

The companies building workflow-based systems are optimizing for the illusion of control while sacrificing the very intelligence that makes AI valuable. They're building faster horses while the automobile is being invented in the garage next door.

Common Objections (And Why They're Wrong)

"But LLMs hallucinate!" Yes, and humans make mistakes. The solution isn't to remove all decision-making capability – it's to ground decisions in knowledge and add appropriate guardrails.

"This sounds expensive!" What's more expensive: an intelligent system that handles edge cases, or an army of engineers constantly patching workflows that break in production?

"We need compliance and auditability!" Reasoning traces are MORE auditable than workflows. You can see exactly why a decision was made, not just that Step 3 was executed after Step 2.

"Our team isn't ready for this!" Your team is already drowning in workflow maintenance. Give them systems that think, not scripts to debug.

The Migration Path: From Workflows to Intelligence

If you're stuck with existing workflows (and who isn't?), here's your path forward:

1. Start with non-critical systems - Test autonomous reasoning where failures won't hurt
2. Convert SOPs gradually - Transform procedures into knowledge bases one at a time
3. Run in parallel - Let both systems operate simultaneously, compare results
4. Measure what matters - Track adaptability, not just execution speed
5. Expand based on confidence - Increase autonomy as trust builds

This isn't a big-bang migration. It's an evolution from brittle to brilliant.

The Path Forward

So what does real autonomous AI infrastructure look like?

1. Agents that reason over knowledge, not execute workflows
2. SOPs as institutional wisdom, not rigid procedures
3. Context and memory that inform decisions, not just store data
4. Orchestration that coordinates intelligence, not manages scripts
5. Infrastructure that supports autonomy, not constrains it

This isn't just a philosophical distinction – it's a practical one. Workflow-based "agents" require constant human intervention, break on edge cases, and scale poorly. Truly autonomous systems adapt, learn, and handle the unexpected gracefully.

The Bottom Line

Every minute we spend building "AI workflow" tools is a minute spent moving backwards. We're taking the most powerful reasoning technology ever created and reducing it to expensive automation.

The companies that figure this out first – that build truly autonomous AI systems with intelligent guardrails instead of rigid workflows – will have an insurmountable advantage.

The Challenge

Here's my challenge to you: Take your most complex workflow-based "AI agent" and throw something 10% outside its design parameters at it. Watch it fail spectacularly. Then ask yourself: Is this the future we're building?

The real question isn't whether to build workflows or intelligence. It's whether you'll be disrupted by someone who chose intelligence while you were still debugging workflows.

Your move.

If this resonates with you, I'm working on a book about building production-grade agentic AI that goes deep into these architectural principles. Sign up here to get access to the first draft when it's ready.

I remember how one day, we were meeting with a major retail chain. Their "big move" into the digital age? Put their product catalog online. That's it. Customers would still have to call in orders or show up at the branch.

We sat in their corporate office surrounded by glossy brochures and award plaques. They even brought in the CEO himself to impress us.

They thought they were nailing it. In reality, they were already doomed. Amazon, eBay, and later Shopify were coming like a tidal wave. The business model was about to collapse. Power was shifting from physical storefronts to digital platforms.

But they couldn't see it. Because in their minds, they'd already "entered the internet". Job done.

That's not progress. That's the illusion of progress.

Nokia's mistake (that wasn't really a mistake)

We love to think Nokia and Blackberry ignored the iPhone. That they were arrogant or asleep at the wheel. The truth? They weren't.

When Steve Jobs unveiled the iPhone, Nokia's CFO said: "This launch will benefit us. The iPhone will expand the market, and people will choose our N95".

They thought they had it covered. But they didn't. They were stuck in the same illusion of progress.

Because the winners weren't just "adding mobile". They were becoming mobile.

Uber wasn't possible without GPS, a touchscreen, and an app store in everyone's pocket. Uber wasn't mobile-enabled. Uber was mobile.

The trap of "faster horses"

You've probably heard the line often attributed to Henry Ford: "If I had asked people what they wanted, they would have said faster horses".

That's the trap. Focusing on incremental improvements – faster, cheaper, shinier versions of what already exists – while missing the bigger shift entirely.

It's the same trap companies fall into when they think they're innovating by tweaking around the edges, instead of reimagining the game itself.

Even Edison missed it

When Edison lit up Pearl Street in Manhattan in 1882, he imagined a few thousand lightbulbs at peak demand. That was the vision.

He couldn't picture the ripple effect: washing machines, televisions, microwaves, computers. He couldn't see how electricity would reshape society itself – women entering the workforce, teenagers glued to PlayStations.

That's the thing with revolutions. We see the first step, not the avalanche that follows.

Fast forward to 2025: "Make me an AI"

Today, history repeats itself. "Make me an internet" has become "Make me an AI".

Companies are rolling out pet projects so the CEO can tell the board: we're doing AI. It's the modern record-company-website move.

And look – there's nothing wrong with experimenting. The danger is mistaking that for progress.

The real questions

When I ask myself if my own company has truly changed because of AI, the honest answer is: not enough.

The real question isn't how do we add AI?

The questions are:

• What do we dismantle so we can rebuild?
• How are our customers changing? (streaming vs. records)
• How is the business model shifting? (taxis vs. Uber)
• Where is the power moving? (customers? platforms?)
• How do we deliver 10x the value? (Google vs. Yellow Pages)
• What's our role in this new landscape?
• And what will never change?

Because if we don't ask those questions, we'll end up exactly like that foreclosed retail chain: sitting in a shiny boardroom, eating raisins, telling ourselves we're "relevant".

AI has changed the way we build software. We're now using the 50-20-30 principle: Devs spend 50% of their time planning, 20% coding, and 30% validating/testing.

And it works!
👇

— Ran Aroussi (@aroussi) August 22, 2025

This guide presents a systematic approach to AI-assisted development that we've been refining at Automaze, where human developers focus on what they do best (thinking, planning, architecting) while AI handles what it does best (rapid implementation of well-defined specifications).

If you've felt overwhelmed trying to integrate AI into your development workflow, or if you've been burned by AI confidently building the wrong thing, this discipline will help you harness AI's power while maintaining control over your project's direction and quality.

The Reality Check

Why AI Changes Everything (And Nothing)

What AI Can Do Today

✅ Write code faster than any human

• Generate boilerplate in seconds
• Implement algorithms from descriptions
• Create tests from examples
• Refactor with perfect syntax

What AI Cannot Do (Yet)

❌ Make architectural decisions

• Choose between microservices vs monolith
• Decide on caching strategies
• Select the right database for your scale
• Balance tradeoffs between performance and maintainability
• Understand your specific business constraints

The Critical Insight

AI is an incredible executor, but a terrible architect

AI will build exactly what you specify, and it will build it fast. But it will build it wrong if your spec is wrong, and it cannot tell you IF you should build it.

Your job as a developer isn't going away – it's evolving. The old model of 80% coding and 20% thinking is becoming 50% planning, 20% coding, and 30% validating. The developers who thrive will be the ones who embrace this shift.

The New Time Allocation

How Developers Should Spend Their Time in the age of AI

50% Planning & Thinking

This is where your value lives

Deep requirements analysis is now the core of your job. Interview stakeholders multiple times, challenge assumptions aggressively, document edge cases obsessively, and define failure modes explicitly. Your architectural decisions – system boundaries, data flow, scale considerations, and integration points – are what AI cannot do for you.

Every hour spent here saves 10 hours of rework.

10-20% Coding with AI

The execution phase is now the shortest phase

You're now a prompt engineer, not a code writer. A quality controller, not a typist. An architectural guardian, not an implementer. You provide context, and AI generates the implementation.

You: "Implement the cache invalidation strategy from section 3.2"
AI: [Generates 200 lines of code]
You: "Add circuit breaker pattern for Redis"
AI: [Updates with fault tolerance]

20-30% Testing & Fine-Tuning

Trust, but verify everything

This isn't just running tests. It's validating against original requirements, stress testing edge cases, performance profiling, security auditing, and user experience validation. The fine-tuning loop becomes: AI generates, you test against spec, find gaps, update prompts, and repeat until perfect.

The Five-Phase Discipline

A Systematic Approach to AI-Assisted Development

Why "No Vibe Coding"

AI amplifies ambiguity. While humans can infer intent, AI cannot. Humans question weird requirements; AI implements them. A vague instruction to AI produces confidently wrong code. "No vibe coding" isn't about rigidity – it's about clarity.

Phase 1: Brainstorm

Think Deeper Than Comfortable

Spend time exploring the problem space thoroughly. Write down multiple approaches and pick the best ones. Ask "what could go wrong" until you've exhausted possibilities. Consider how this fits your long-term vision, not just immediate needs.

Deliverable: Rough notes, sketches, stakeholder feedback, initial constraints

Phase 2: Document

Write Specs That Leave Nothing to Interpretation

Your PRD must include:

• Problem Statement: Why are we building this?
• Success Metrics: How do we measure success?
• User Stories: Who uses this and how?
• Acceptance Criteria: Specific, testable requirements
• Non-Goals: What we explicitly won't do
• Constraints: Technical, business, and resource limits

❌ Bad: "The system should be fast"
✅ Good: "API responses return within 200ms for 95% of requests under 1000 req/sec load"

Phase 3: Plan

Make Technical Decisions Explicitly

Create your implementation blueprint with technology choices and justifications, system architecture, data models, API contracts, and task decomposition. Always explain the WHY:

Decision: Use PostgreSQL for user data
Why:
- ACID compliance required for financial data
- Complex queries needed for reporting
- Team expertise already exists
- Scaling to 1M users is sufficient

Phase 4: Execute

Build Exactly to Spec

For each task: Load context and spec into AI, generate implementation, review against acceptance criteria, adjust prompts if needed, and commit when criteria are met. You're crafting prompts and providing context, not writing boilerplate or implementing standard patterns.

Phase 5: Track

Maintain Transparent Progress

Document what acceptance criteria were met, what decisions were made, what assumptions changed, and what blockers exist. Every decision documented, every change justified, every deviation explained. Your future self (and AI) will thank you.

Example: Building a Rate Limiter

The Old Way (Pre-AI)

1. Quick chat about requirements (30 min)
2. Start coding (2 days)
3. Realize edge cases throughout
4. Add features as discovered (ongoing)
5. Test and fix bugs (1 day)

Total: 3-4 days, multiple revisions

The New Way (AI-Assisted)

Day 1 Morning: Brainstorm (2 hours)

• Interview API team about traffic patterns
• Research rate limiting algorithms
• Consider bypass mechanisms
• Document failure modes

Day 1 Afternoon: Document (3 hours)

## PRD: Rat#e Limiter

#### Problem
API abuse is costing $50K/month in infrastructure

#### Success Metrics
- Reduce suspicious traffic by 80%
- Zero impact on legitimate users
- Response time overhead <5ms

#### Acceptance Criteria
- [ ] Implements token bucket algorithm
- [ ] Supports 100K unique keys
- [ ] Redis-backed with local cache fallback
- [ ] Configurable per endpoint and user
- [ ] Graceful degradation on Redis failure

Day 2: Plan and Execute

• Architecture: API Gateway plugin
• Storage: Redis with local LRU cache
• AI generates implementation per spec
• Reviews and adjustments

Day 3: Test and Fine-tune

• Load test with production patterns
• Validate failure behavior
• Performance profiling

Total: 2.5 days, zero architectural revisions

The Mindset Shift

From Coder to Architect-Conductor

You're not a typist anymore. Your identity shifts from "I write code" to "I design systems and ensure quality."

The Skills That Matter Now

1. Systems thinking - Understanding how pieces connect
2. Clear communication - Writing specs AI can't misinterpret
3. Edge case imagination - Thinking of what could go wrong
4. Quality judgment - Knowing when code is production-ready
5. Prompt engineering - Getting AI to build what you envisioned

What to Focus On

Invest in: System design, technical writing, domain modeling, requirements analysis, test strategy

Worry less about: Syntax memorization, algorithm implementation, boilerplate patterns, code formatting

The uncomfortable truth: AI won't replace developers, but developers using AI will replace developers who don't. More specifically, developers who can architect and specify will replace developers who only code.

Context Optimization with Sub-Agents

Scaling AI Development Without Context Explosion

As projects grow, context overwhelms. Claude's context window is large but not infinite, and full project context slows responses while increasing costs.

The Sub-Agent Pattern

Main Agent (Orchestrator)
    ├── API Agent (owns backend context)
    ├── UI Agent (owns frontend context)
    ├── Data Agent (owns database context)
    └── Test Agent (owns test context)

Each sub-agent gets ONLY relevant context. The API agent knows about endpoints and authentication but not CSS or frontend state. The UI agent knows components and design systems but not database schemas.

Real Impact

Without Sub-Agents:

• Context: 100K tokens
• Response time: 45 seconds
• Cost: $0.50 per interaction
• Accuracy: Often references wrong components

With Sub-Agents:

• Context: 10K tokens per agent
• Response time: 8 seconds
• Cost: $0.08 per interaction
• Accuracy: High, focused domains

Sub-Agent Communication

Sub-agents return structured summaries to the main orchestrator:

{
  "agent": "api",
  "task": "auth-endpoints",
  "status": "complete",
  "decisions": [
    "Used JWT for stateless auth",
    "Implemented refresh token rotation"
  ],
  "interfaces": {
    "endpoints": ["/auth/login", "/auth/refresh"],
    "errors": ["AUTH_001", "AUTH_002"]
  },
  "concerns": [
    "Need Redis for rate limiting"
  ]
}

Use sub-agents when you have clear domain boundaries, large codebases (>100 files), or specialized domains. Avoid them for small scripts or tightly coupled systems.

Introducing CCPM

A Tool That Enforces This Discipline

Good intentions aren't enough. It's easy to skip documentation under pressure, tempting to "just start coding," and difficult to coordinate multiple AI agents.

CCPM (Claude Code Project Management) is a tool that enforces this discipline:

1. Forces the five phases - Can't code without a spec
2. Maintains context - No more re-explaining to AI
3. Enables parallel AI agents - Multiple AIs on one project
4. Creates audit trails - Every decision tracked in GitHub
5. Integrates with existing tools - GitHub Issues as database

Quick Example

# Force#s you to brainstorm and document
/pm:prd-new feature-name

## Forces you to plan
/pm:prd-parse feature-name

## Enables parallel execution
/pm:epic-oneshot feature-name
/pm:issue-start 1234  # AI agent 1
/pm:issue-start 1235  # AI agent 2

CCPM doesn't change the discipline – it enforces it. You could follow this process manually, but it does make it systematic and repeatable, especially powerful for team coordination.

Common Questions

"This seems like a lot of overhead"

The overhead is front-loaded. You'll spend 2x time planning but 0.2x time debugging and reworking. Net win: 50% faster delivery with higher quality.

"What if requirements change?"

They will. But now changes are explicit, documented, and AI can refactor faster than you can type. Changes are less painful when specs exist.

"What about exploratory coding?"

Still valuable! But timebox it, call it what it is (research), and don't ship it. Use exploration to inform your spec, then build properly.

"Is this just waterfall?"

No. You can iterate, but each iteration follows the discipline. Think of it as "structured agility" – flexible in direction, disciplined in execution.

Your Next Steps

Start Small

1. Pick one small feature in your current project
2. Write a complete PRD before coding
3. Time yourself through all five phases
4. Use AI for execution following your spec exactly
5. Compare to your normal process

Build the Habit

• Track your time allocation – aim for 50/20/30
• Build your edge case muscle – list 10 for every feature
• Practice prompt engineering – get faster at directing AI
• Share your specs – get feedback from teammates

The Bottom Line

The future belongs to developers who can:

• Think deeply about problems
• Specify solutions precisely
• Orchestrate AI execution
• Validate quality rigorously

The question isn't whether to adopt this discipline. The question is whether you'll adopt it before your competition does.

Share Your Experience

This guide represents our current understanding of how to effectively blend human expertise with AI capabilities, but we know we're just scratching the surface.

If you're implementing these practices, hitting roadblocks, or discovering better patterns, I'd love to hear from you.

Share your experiences, successes, and failures – the entire developer community benefits when we learn together.

Remember: AI amplifies your decisions. Make them good ones.

Links

• CCPM Tool: github.com/automazeio/ccpm

We built CCPM (Claude Code Project Management) to fix this. It's a lightweight project management system that keeps AI agents on track by treating GitHub Issues as your source of truth and making every line of code traceable back to a spec.

The Problem Nobody Talks About

Here's what actually happens when you try to build with AI agents today:

Monday: "Let's build a caching system!" Tuesday: "Wait, why are we using Redis again?" Wednesday: "Who decided on this architecture?" Thursday: "These two agents just rewrote each other's work" Friday: "I have no idea what's actually done"

Sound familiar? The issue isn't the AI. It's that most AI development happens in isolation: a single developer, working with Claude in their local environment, with progress trapped in chat logs. When you try to scale this up, everything falls apart.

Breaking AI Development Out of Its Silo

CCPM does something different: it makes AI development visible to your entire team. By using GitHub Issues as the backbone, we get:

True team collaboration. Multiple Claude instances can work on the same project simultaneously. Your human teammates see AI progress in real-time through issue comments. No more "what did the AI do?" meetings.

Seamless handoffs. An AI agent can start a task, a human developer can finish it, another AI can write the tests. The context travels with the issue, not trapped in someone's chat history.

Scale that actually works. Add team members without onboarding friction. Run multiple AI agents in parallel on different issues. Your distributed team stays synchronized automatically, using the GitHub workflows they already know.

This isn't just project management. It's a collaboration protocol that lets humans and AI agents work together using infrastructure your team already trusts.

No More Vibe Coding

Here's our core principle: every line of code must trace back to a specification.

We enforce a strict discipline:

1. Brainstorm thoroughly before touching code
2. Document requirements that leave nothing to interpretation
3. Plan with explicit technical decisions
4. Execute exactly to spec
5. Track progress transparently

No shortcuts. No assumptions. No "I think this is what they meant." When an AI agent picks up a task, it knows exactly what to build because the spec says so.

What CCPM Actually Does

CCPM is refreshingly simple: write specs, turn them into GitHub Issues, and let agents work in parallel without conflicts.

Here's the workflow:

1. Write a real PRD (Product Requirements Document)
2. Convert it to an epic with technical decisions baked in
3. Decompose into tasks with clear acceptance criteria
4. Sync to GitHub as properly linked issues
5. Execute in parallel without stepping on each other (using Git worktrees)

The magic is that everything stays connected. Your implementation traces back to your spec, your commits trace back to your issues, and your issues trace back to your PRD.

A Real Example

Let me show you what this looks like in practice. Say you're building a memory system for your app:

# Start with a proper spec
/pm:prd-new memory-system
# Launches a guided session to capture requirements and constraints

# Convert to technical plan
/pm:prd-parse memory-system
# Creates an epic with architecture decisions

# Ship it to GitHub
/pm:epic-oneshot memory-system
# Creates GitHub issues with proper relationships

# Start working (in parallel!)
/pm:issue-start 1235  # API endpoints
/pm:issue-start 1236  # Frontend components
/pm:issue-start 1237  # Test suite

# Keep everyone informed
/pm:issue-sync 1235
# Updates flow to GitHub as comments

Your whole team can see what's happening. Product managers check issue comments. Developers review PRs tied to specific acceptance criteria. Everything has a paper trail.

Why GitHub Issues? (And Not Another Tool)

We tried everything. Notion, Linear, custom databases. They all created the same problem: a silo between planning and code.

GitHub Issues live where your code lives. They give you:

• Comments for the audit trail
• Labels for organization
• Relationships for dependencies
• An API everyone already knows
• Webhooks your tools already use

Plus, when an AI agent updates an issue, your human teammates see it immediately. The single source of truth isn't a concept, it's literally your issue tracker.

The Parallel Execution Secret

Here's something we discovered: most "single" tasks aren't single at all. That "implement auth" ticket? It's actually database changes, API endpoints, frontend components, tests, and documentation.

CCPM recognizes this. Each agent works in its own git worktree:

# These all run simultaneously without conflicts
/pm:issue-start 1235  # Agent 1: API
/pm:issue-start 1236  # Agent 2: Frontend
/pm:issue-start 1237  # Agent 3: Tests

No merge conflicts. No overwritten work. When they're done, you have a clean history with each commit tied to its acceptance criteria.

The Unexpected Benefits

After dogfooding this for a few months, we noticed things we didn't expect:

Onboarding is instant. New team members (human or AI) can read the PRD, check the epic, and understand everything in minutes.

Reviews are actually reviewable. Instead of a massive PR with "implemented stuff," you get targeted commits tied to specific criteria.

The "what were we thinking?" problem disappears. Every weird decision has a paper trail back to its requirement.

Remote teams love it. Async collaboration just works when everything flows through issues.

Some Opinions We Baked In

CCPM makes deliberate choices:

• Specs aren't optional. No spec, no code. This keeps AI aligned and humans informed.
• Local-first, sync when ready. Work happens locally, GitHub gets updates when you choose.
• Issues over Projects. GitHub Projects are fine for visualization, but Issues are the source of truth.
• Boring tech wins. Shell scripts, markdown, git. Nothing fancy, everything debuggable.

Try It Yourself

Getting started takes about two minutes:

# Clone CCPM into your project
git clone https://github.com/automazeio/ccpm.git .claude/
cd .claude/

# Initialize everything
/pm:init

# Start your first feature
/pm:prd-new your-feature-name

The system walks you through creating your first PRD, decomposing it into tasks, and syncing with GitHub.

What's Next

We're exploring a few directions:

• Smarter agent specialization for different parts of your stack
• Better acceptance criteria validation before work begins
• Automatic PR creation when tasks complete

But honestly, the current version already solves the core problem: keeping AI agents productive without losing your sanity, while letting your whole team see what's happening.

The Bottom Line

CCPM acknowledges a simple truth: AI agents need different workflows than humans, but they need to work together. It's the minimal system that makes this possible.

If you're tired of explaining context repeatedly, watching parallel work collide, or wondering what your AI agents actually accomplished, give CCPM a try. At worst, you'll have better specs. At best, you'll transform how your team ships software.

Check it out at github.com/automazeio/ccpm. The README has everything you need to get started.

Let's be honest: venture capital works when you're building a billion-dollar rocket company or curing cancer. But most of us? We're building solid, real businesses – SaaS tools, newsletters, digital products, games – that serve paying customers from day one.

The problem? The standard funding paths weren't designed for that. In startup circles, admitting you want a profitable, long-term business is almost taboo. Everyone's pitching “the next big thing” while quietly burning through millions.

VC is an all-or-nothing bet. If you don't swing for a massive exit, you're considered a failure. But what if you want to build a good business, earn a living, and stay in control? That's where the gap appears.

The profitable middle no one talks about

While Twitter debates unicorns, thousands of founders are quietly building profitable businesses. Solo developers, small teams, indie hackers – pulling in $50k, $500k, $5M a year. They don't want forced exits or a boss in their boardroom – they just want practical cash to grow.

The SaaS revolution and creator economy made this possible: a single developer can launch software or a course that serves thousands of paying customers. And these builders figured something out: you don't need to lose money for years to build something valuable. You can charge from day one and stay alive without giving away your company.

But sometimes you do need more fuel – a new hire, marketing push, or a spin-off product. And that's when the funding gap appears.

The funding squeeze

Traditional banks don't get it – they want trucks, buildings, or collateral they can repossess. Revenue lenders often load you with painful payback terms. VC wants moonshots and unicorns.

So where do you turn if you need $50k–$500k to grow a project that's already working?

What real builders actually need

It's not rocket science:

• Upfront support without selling control. Builders want funding, not new bosses.
• Shared upside. Supporters win when revenue comes in – not only at some distant exit.
• Project-based, flexible. Raise for what you need now, not the entire business.
• Clear, simple terms. Keep it standard. Keep it fair.

The fix: revenue-based royalties

This is where royalties fit in.

Imagine this: a few early backers put up cash for your new SaaS feature or next game. In return, you share a small slice of that project's revenue as sales roll in – until they're paid back with a fair return.

No new board seats. No equity dilution. No forced exits. Just a clear agreement: "You backed this, you get a fair piece of what it earns."

Reference price & fair exit

One key piece: a simple reference price. Everyone agrees upfront what the project is worth. If you sell, shut down, or merge the project before your backers are paid back in full, they get fair compensation based on that agreed number.

It's not about valuations and endless negotiations – it's just basic fairness. You stay in charge – they stay protected.

Why early-stage backers should love it

Unlike traditional “investing” that might take years to pay out – royalties flow when sales happen. Your supporters share in your upside immediately. The more you earn, the more they earn.

It's simple, aligned, and protects everyone if plans change.

Who this helps

Revenue-based royalties aren't for billion-dollar rocket ships. They're for:

• Indie SaaS with steady MRR.
• Creators selling courses, newsletters, and digital products.
• Game studios funding one title at a time.
• Makers with multiple small projects.
• Builders who want profit and freedom.

Making it real

This works best when it's easy to use. So we're open-sourcing two simple royalty agreement templates:

• Full version: includes a steering committee with a seat for your backers – so they can offer input while you keep control.
• Simple version: same structure but no formal seat – pure revenue sharing, minimal oversight.

Both use clear terms: what % of revenue is shared, what return supporters receive, and how to handle exits fairly.

Ready to try it?

Grab the templates, adapt them for your next launch, and share your feedback. If you're a builder who cares about staying profitable and treating your early supporters well – this might be the missing piece you've been waiting for.

Check out the Open Royalties repo →

It's called The Illusion of Thinking, and the main claim is simple:

Today's advanced AI models are all smoke and mirrors.

Except… the paper isn't really science. It's a signal. A red flag from a company that's lost its creative engine, stuck watching the world shift around it - fast. It's Apple, not innovating, but reacting. Not leading, but defending.

And they're scared.

Before we continue...

Let me be clear: I say all this as someone who genuinely wants to root for Apple. I've been in the ecosystem for years. I don't want to go back to Windows. But if Apple keeps losing the plot, we may not get a choice.

Now that we got that out of the way, let's continue.

The research is a smokescreen

The paper was obviously engineered to fail AI models. Tasks were deliberately impossible. The models weren't allowed to use code. It was set up so they'd look dumb. Why? To plant doubt. To confuse the market. To soften the blow just before Apple had to show how far behind it really is.

This wasn't science. It was strategy. And a desperate one.

The Jobs momentum is gone

Apple hasn't truly innovated in over a decade. That's not a hot take - it's just math.

Steve Jobs left them with a 15-year tailwind. A soft cushion of innovation. Under Tim Cook, they squeezed every drop from that lead: optimized the supply chain, maximized profits, and turned the iPhone into a cash machine. But they didn't use that time to invent the next act.

Now that cushion is gone.

And what do we get? A rebranded Siri with the buzzword "intelligence" slapped on it.

Apple Intelligence isn't a leap forward. It's a scramble to catch up. Worse - it locks core AI features behind a hardware paywall. Want the basics everyone else is offering for free? That'll be $1,200 for a new iPhone.

The walled garden that once protected the user is now locking them in.

The real threat? It's not Google or OpenAI – it's Johnny and Sam.

Apple knows the next big shift won't come from Cupertino.

It's coming from Johnny Ive - the guy who made Apple look like Apple - teaming up with Sam Altman - the guy who's redefining what software can be.

They're not building an app. They're building a new kind of device. One that might make the iPhone feel like a relic, just like the iPhone did to Nokia.

That's the existential threat. And Apple sees it.

A closer look at the "research"

If you're wondering why the AI community rolled its eyes, here's a quick breakdown of the paper's greatest hits:

Claim #1: "We created a clean test environment with no known solutions"

Reality: They used textbook problems like Towers of Hanoi – solved a million times, in every comp-sci course and all over the web. The models knew exactly what they were dealing with.

Claim #2: "The model collapses on hard tasks, so it's not really thinking"

Reality: That's not failure – that's resource management. The model knows the task is too long and complicated to be worth solving. That's efficiency, not a breakdown.

Claim #3: "We banned the use of code to test pure reasoning"

Reality: That's like testing a chef but banning knives. Translating problems into code is the reasoning method for machines. You can't strip it away and pretend the result means something.

Claim #4: "The models failed because of weak reasoning"

Reality: They failed because the test was physically impossible. The token limit was too small to contain the full solution. The test was rigged.

Claim #5: "This is a rigorous scientific study"

Reality: Real AI research happens across labs, universities, and companies. This was an Apple-only paper, published at a perfect PR moment. It's not science. It's marketing.

So where does that leave Apple?

When a company stops building the future, it starts defending the past.

And that's exactly what we're seeing here: a fear response. From a brand that once defined what's next, now trying to slow the train down with whitepapers and lock-in strategies.

"Apple Intelligence" isn't about insight. It's a brand patch. And the research that came with it doesn't tell us anything new – except that Apple's leadership doesn't get what's happening.

Are today's models perfect? Of course not.

Should we rely on them blindly? Definitely not.

But right now, millions of people, companies, and teams are using AI to get things done.

This isn't theory. It's happening.

And Apple is standing on the sidelines, publishing papers designed to convince you it's all fake.

But here's the thing: you don't release something like that unless you're scared.

And Apple seems to be terrified.

The truth is – I don't really use a framework.

What I do have is a system. One that lives in my head, was built through repetition and intuition, and has evolved over decades of building things fast, throwing most of them away, and keeping only what's worth refining.

Some people might call it instinct. I call it experience layered with systems thinking.

And in this post, I want to show you how I work through new ideas – not with a whiteboard or a Notion template, but with a long conversation.

This isn't "vibe coding". This is vibe brainstorming – and it's how I test ideas, challenge assumptions, and break down complex problems before executing, presenting, or writing a single line of code.

Step 1: It starts with a spark

Most of my ideas start the same way: a visual spark, a problem I face, or something I see that sets off a cascade of thoughts.

Could be a landing page. Could be a badly designed signup flow. Could be someone talking about a business they wish existed.

Once something clicks, I move fast. But not recklessly – I jump into a mode where I can explore it thoroughly.

That's when I open ChatGPT.

Step 2: Structured chaos

The first thing I do is tell ChatGPT the core idea. Then I list the specific aspects I want to dive into:

• target user
• pricing model
• technical stack
• project architecture
• user experience
• key features
• potential challenges
• distribution channels
• ...

This becomes a sort of agenda for the brainstorming session.

Then we go deep. One by one.

I ask questions, share thoughts, and request pushback. That part's important – I want the AI to challenge me, not just echo back. I ask it to highlight contradictions, suggest alternatives, or poke holes in my logic.

Every time we "close" a topic, I ask ChatGPT to summarize it into a Markdown doc. Those summaries pile up quickly: one for UX, one for data modeling, one for monetization, etc.

This part usually takes hours and occasionally might even span over a few days. We go through every single detail and leave no stone unturned.

By the end, I've got a full research dump ready to feed into a custom GPT or a project doc.

Step 3: (If it's a software project)

If the idea survives this gauntlet of questioning and reframing, I'll move on to Claude to turn the notes into a PRD (product requirements doc).

From there:

• I load the PRD into Cursor with Claude 4.0 Sonnet (or Opus for large projects).
• I use my Taskmaster MCP to break it into dev-ready tasks.
• I work with Cursor to tackle tasks one by one.

This is where past prep pays off. I have:

• A library of code snippets I've already documented and reused.
• A custom design system, fully specced and AI-readable.
• Clear standards that help AI produce outputs that match my style, preferences, and architecture.

So it's not "let's see what the AI generates". It's more like working with an extremely fast junior dev who already knows your whole stack.

I don't let the AI make architectural decisions. I watch it like a hawk and review its code before approving it. I also ask it to justify every function and every coding decision it's made (this usually results in cutting the code by at least 20%).

This works for me

This isn't meant to be prescriptive. I'm not saying you need to do things my way.

But I am saying that most productivity advice is garbage unless it helps you build a system that works for how your brain actually functions.

For me, writing things down isn't about creating a second brain – it's about clearing out mental RAM so I can think more clearly.

I don't use frameworks. But I do follow internal SOPs that are second nature by now (one of them is here.)

And I don't spend time wondering if a problem is too big. I just start breaking it down:

• What's the core problem?
• Who is it for?
• What's the simplest version?
• What are the dependencies?

Whether it's a product idea, a tech problem, or a business model – if you can decompose it, you can evaluate it.

Final note

There have been times I ignored my instinct. Times I didn't move fast.

One example is Tradologics. I waited too long, got caught up in trying to make it perfect, and the end result wasn't what I've set up to achieve. I'll write more about that in a future post.

But what I've learned is this: intuition is a muscle. You build it by thinking, building, evaluating, and repeating. If you do that long enough, you don't need a playbook.

You just need a spark – and a few hours to brainstorm the hell out of it.

The Problem with Retrofitted Solutions

The current landscape of AI agent frameworks is littered with solutions that weren't designed for the multi-agent future we're building. Most popular frameworks began as simple LLM wrappers or chain-of-thought implementations, with agent capabilities bolted on as afterthoughts. This fundamental architectural limitation creates several critical problems:

1. Excessive Boilerplate and Complexity

Current frameworks require developers to write hundreds of lines of boilerplate code for even basic agent interactions. What should be simple agent definitions become buried under layers of configuration, tool specifications, and memory management code. This complexity increases the barrier to entry and slows down development cycles.

2. Communication Protocol Limitations

True agent systems require sophisticated communication protocols. Agents need to discover each other's capabilities, delegate tasks efficiently, and share context appropriately. Yet most frameworks offer minimal support for inter-agent communication, treating it as an advanced feature rather than a core requirement.

3. Memory Architecture Shortcomings

Agents require tiered memory systems - from short-term buffers to long-term persistent storage with semantic retrieval. Current frameworks typically offer simplistic memory implementations as add-ons rather than integrated components, forcing developers to build complex memory systems from scratch.

4. Deployment and Scaling Challenges

Production-ready agent systems need to scale beyond single processes and machines. Yet many frameworks are designed primarily for local development, with distributed deployment treated as an enterprise feature or left entirely to the developer to implement.

5. The Demo-to-Production Gap

Perhaps most frustrating is the "works in demos" problem. Many frameworks showcase impressive capabilities in controlled environments but fall apart in production settings with real-world constraints, memory limitations, and reliability requirements.

What an Agent-Native Framework Should Offer

To truly enable the multi-agent future, we need frameworks built from the ground up with agents as first-class citizens. Here's what a truly agent-native framework would prioritize:

1. Declarative Agent Configuration

Agent definitions should be simple, declarative, and version-controlled. Developers should be able to define complex agent capabilities in minimal YAML or JSON without sacrificing power or flexibility.

2. Native Agent Communication

Agent-to-agent communication protocols should be built into the core architecture, not added as an extension. This includes capability discovery, task delegation, and context sharing with appropriate security boundaries.

3. Integrated Memory Systems

Tiered memory architectures should be a core feature, with built-in support for buffer memory, long-term storage, and domain-specific knowledge bases. The framework should handle the complexity of memory management, allowing developers to focus on agent logic.

4. Production-Ready Architecture

Agent frameworks should support multiple deployment models from development to production, with built-in authentication, security, observability, and distributed execution capabilities.

5. Standardized Tool Integration

Integration with external tools and services should follow standardized protocols like the Model Control Protocol (MCP), allowing for consistent interaction patterns regardless of the underlying model provider.

6. Multi-Modal Support

Modern agents interact through text, images, audio, and video. A true agent framework should provide native support for multi-modal interactions without requiring significant additional code.

The Path Forward

The future of AI isn't single models or isolated agents - it's collaborative systems of specialized intelligences working together to solve complex problems. Building this future requires frameworks designed specifically for agent orchestration, not retrofitted solutions that treat agents as an advanced feature.

Developers deserve tools that make building sophisticated agent systems accessible without sacrificing power or flexibility. We need frameworks that handle the infrastructure complexity so developers can focus on creating intelligent, useful agent systems.

The multi-agent revolution is already underway. It's time our frameworks caught up.

After nearly three decades building tech, launching products, and working alongside some of the smartest entrepreneurs out there — I've realized something that's been bugging me for a while:

The tech world has been leaving traditional businesses behind.

And that's a problem.

Because most of the economy aren't startups chasing funding. They're consultants, contractors, agency owners, service providers, and family-run shops. People who are brilliant at what they do, but weren't handed a playbook for navigating the modern digital world.

And the truth is: a lot of the technology out there is accessible, helpful, and ready to go — if someone shows you how to use it.

That's where this podcast comes in.

Why I'm doing this now

Over the past few years running Automaze, I've had a front-row seat helping non-technical founders adopt automation, integrate AI, and use modern tools to streamline operations and grow faster — without hiring a full dev team.

And the results are incredible.

• A solo consultant closing more deals with a follow-up sequence.
• A service business automating 20 hours a month of admin work.
• A traditional agency scaling without growing headcount.

But here's the thing: Nobody's telling these stories.

There are a million podcasts out there about SaaS startups, venture capital, and the latest dev frameworks. But almost none about what happens when a "regular business" gets smart about systems. And that gap is exactly what I want to fill.

Old School; New Tech isn't just a podcast — it's part of a mission to level the playing field. Because tech doesn't need to be intimidating. It just needs to be explained in plain language, with practical use cases and a sense of what really works (and what doesn't).

Introducing: Old School; New Tech

It's a podcast where I talk to real-world founders and operators who've modernized their businesses using simple tools — not code. Not VC funding. Just strategy, insight, and execution.

We break down how they did it, what tools they used, and what they learned along the way.

This isn't about billion-dollar exits or SaaS unicorns. It's about practical wins, smarter systems, and staying competitive in 2025 and beyond.

Some of these guests are using Airtable to replace spreadsheets. Others are integrating AI tools to generate content or automate repetitive tasks. And many are just figuring out the basics of getting their systems to talk to each other.

No fluff. No buzzwords. Just business owners sharing what's actually worked for them.

The trailer is live

Subscribe on your favorite platform here or by clicking the "share" link on the player above.

The first full episode drops at the end of this month.

There's some great stuff coming up — real conversations with founders who've cracked the code on getting tech to actually help their business, not slow it down.

Want to be a guest?

If you're a founder, owner, or operator who's using (or planning to use) technology to:

• Save time
• Improve operations
• Grow your business faster

… I'd love to hear from you.

You can apply to be a guest right here: 👉 Apply to be a guest on the podcast

The application only takes a minute, and I'll personally review every submission. If it looks like a match, I'll follow up with a call link to schedule your episode.

Whether you're a one-person show or running a company with a team of 50 — if you've found smart ways to leverage tech, I want to talk to you.

Let's level the playing field

Tech shouldn't be reserved for the people who already live inside it. Old School; New Tech is my way of helping more founders take advantage of what's already out there — and showing that you don't need to become a “tech company” to build a smarter business.

I truly believe this show can empower more business owners to make better, faster, more informed decisions about tech — and hopefully avoid some of the mistakes I've seen others make.

Hope you'll subscribe, share it with someone who needs it, and maybe even join me on the show.

PS. Please share this link with someone who needs it (or who you think needs it).

Thanks!

The premise

The idea is simple, but powerful:

Can I create a profitable service business – like a design, development, or marketing agency where the majority of the "staff" are AI agents?

These agents would handle everything from:

• Planning and project management
• Client communications and account management
• Scheduling and updates
• Quality assurance and testing
• Simple coding and repetitive dev tasks
• Reporting, follow-ups, and documentation

The goal is to offload most of the heavy lifting so that the human in the loop can focus on architecture, strategic planning, and creative direction.

MUXI: the AI core

At the heart of this vision is MUXI, a modular ecosystem for developing and orchestrating AI agents. It’s being designed as a lightweight alternative to platforms like LangChain or CrewAI, but with a focus on real-world use, automation, and custom workflows—not just demos.

MUXI will manage a network of agents with specialized roles: developer agents, project manager agents, account managers, schedulers, testers, etc. – and coordinate between them to execute tasks end-to-end.

These agents will be able to:

• Make autonomous decisions based on project context
• Communicate with clients via Slack, WhatsApp, or email
• Work with project tools like GitHub, Linear, Notion, and more
• Use LLMs, MCP, APIs, and scriptable workflows to get things done

Think of it as a command center that turns AI into your full-time team.

Rolling it out in phases

We’re approaching this in progressive stages to avoid overengineering and to get value quickly:

Phase 1: Personal assistant

MUXI will start as my personal executive assistant, helping me plan tasks, manage priorities, and track projects.

Phase 2: Project manager

Next, MUXI will handle internal project management, which includes creating tickets, following up, summarizing standups, etc.

Phase 3: Account manager

Once it’s reliable internally, MUXI will evolve into a client-facing account manager, providing updates, answering FAQs, and coordinating delivery milestones with minimal input from me.

Phase 4: Autonomous developer

In parallel, we’re building a dev agent to tackle repetitive tasks, set up new projects, run tests, and gradually take on more meaningful coding responsibilities with human review.

Human-in-the-loop

The idea isn’t to eliminate humans altogether but to give me, as a founder, the ability to operate at a larger scale with minimal headcount. Human interaction can still happen where it adds value – like onboarding, critical decisions, or creative brainstorming – but the day-to-day execution will be offloaded.

This makes the model scalable, affordable, and unique. For example, we could offer “Human CTO + AI team” packages that include weekly planning calls and a team of AI-powered agents who handle implementation, updates, and support.

Pricing and positioning

One interesting idea is to have transparent pricing and clarify that most of the work is done by AI. For some clients, that might be a dealbreaker. For those who care about price, speed, and outcomes - it could actually be a huge plus.

There’s even room for tiered pricing:

• Low-touch, AI-only plans
• Hybrid plans with light human oversight
• High-touch plans for those who want a dedicated manager

Building the right foundation

While plenty of automation tools and agent frameworks are out there, most are too general, brittle, or not customizable enough for production use. Furthermore, I only use tools that I know exactly how they work under the hood.

That’s why I’m building this in-house using a mix of:

• agent orchestrators
• custom-built agent infrastructure
• API integrations with tools we already use
• strong design systems and templates to keep quality consistent

This also gives me full control over behavior, reliability, and customization - especially important when you're planning to expose agents to clients.

Your thoughts?

This is still very much in the early days, and I’d love feedback.

• What sounds exciting here?
• What sounds naïve or risky?
• Any gotchas you think I might be missing?

Drop your thoughts in the thread. Always appreciate smart opinions 🙏

We're at the start of a major shift. Not just in how software works, but who it's built for.

I even tweeted today that we're turning Automaze into an AI-first company. That's how strongly I feel about this.

After building through multiple tech waves, this moment feels familiar. What's happening with AI today? It reminds me of the early internet. Or mobile in the 2010s. And like those waves, the gap between early adopters and everyone else is going to be huge.

This kind of shift shows up once every 10–15 years. You don't want to miss it.

Now here's the key point: this isn't just about slapping GPT into a chatbot. It's about rethinking your entire interface. Not just for humans — but for machines.

AI agents are becoming real users. They visit websites, read UIs, click buttons, and take actions for people. And just like human users, if your product is confusing or clunky, they'll fail.

That's why AX (AI experience) matters.

It's the next generation of UX.

3 Types of AI Traffic

AI agents are starting to interact with software in new ways. Each one brings a different kind of “traffic” to your product. Just like we had to rethink UX for mobile, we now need to rethink it for non-human users.

Here are the three big types to know:

1. Browser-based Agents

These agents use your site just like a person would. They open a browser, read HTML, click buttons, and fill out forms.

OpenAI's Operator is a good example. So are Browserbase and Browser.use — which just raised $17M. Tools like these are powering apps like Manus. And usage is growing fast.

The problem? Most websites aren't built for bots.

Some aren't even built for phones.

And AI agents don't guess. They won't assume “Learn More” is your key CTA. They just follow what's in the DOM.

To make your product agent-friendly:

• Simplify layouts
• Remove unnecessary clicks
• Surface important info right away
• Cut anything that's just visual fluff

It's not about adding more UX polish. It's about making your product accessible to machines.

2. API-based agents via MCP

The second type of AI traffic comes through APIs — via something called the Model Context Protocol (MCP).

MCP was suggested by Anthropic as the standard for AI agents to have a structured way to talk to your product instead of trying to scrape screens.

Think of it like the difference between guessing what a webpage says... and getting the clean JSON directly.

Big names like Stripe and Figma are already moving fast on MCP. As more agents adopt it, it'll become a baseline expectation — especially for API-driven products.

This is less about design, more about backend. But the impact is the same: if your app isn't machine-readable, agents will skip it.

3. Your own company agent

The third type of AI traffic is the one you control — your own branded agent.

Instead of waiting for agents to figure out your product, companies are starting to build their own. These agents sit on top of the app, offering users a simple, chat-based way to get things done.

You control the tone, the workflows, the features.

It's smoother for users. And it keeps them inside your ecosystem.

This isn't about replacing MCP — it's a complement. Different use cases, different channels. You'll want both.

What to do right now?

If you're building software in 2025, here's the deal:

You're no longer designing just for people. You're designing for machines, too.

Here's what to do:

1. Clean up your frontend

AI agents want clean, readable interfaces. This means:

• Clear HTML
• Fewer layers of interaction
• No visual clutter

Make your UI machine-friendly.

2. Introduce (or even prioritize) MCP

If your product already has APIs, turn them into MCP-compatible interfaces. This gives agents a formal, predictable way to access your features — and keeps you ready for what's coming.

3. Build your own agent

If you don't have a conversational front-end for your app yet. Now's the time to start. This is your chance to shape the experience before someone else does it for you.

Building for agents = new business opportunities

This isn't just a tech shift — it's a new market.

If you're a dev, indie hacker, or founder, here are some ways to tap in:

• Sell AI workflows - Tools like n8n let you design agent-powered flows. You can sell them as templates, offer them as APIs, or host them as a service.
• Create knowledge-based agents - Instead of selling static courses, create chat-based tools that use your expertise. Whether it's marketing, coding, or legal advice — people want AI that feels personalized.
• Build and sell model APIs - Customize open-source models on platforms like Replit. Package and sell them — whether they write in a certain tone, generate images, or produce clean code.
• Vibe code - Build micro-apps, games, or tools with AI at your side. The speed is wild — and yes, people are monetizing through ads, sharing, and sponsorships.
• Offer services - Not everyone wants to DIY. Companies are actively looking for consultants and agencies who can build AI systems for them.

This isn't hype. It's already happening.

Rethinking access and UX

Back in the day, we had one rule: people = good, bots = bad.

That's how we built our security, analytics, and access systems.

But now? That line is blurring.

AI agents are technically bots — but they're a good kind of bots. They're trying to use your product, not abuse it.

If you treat them like old-school scrapers, you'll block them... and the users relying on them.

And here's the twist: by optimizing for agents, we might make things better for humans too.

Agents don't need ads, popups, or gimmicks.

They just need clear paths to action. And so do people.

If you give AI a fast, clutter-free version of your product... people are going to wonder why they don't get the same.

Designing for machines might help us rediscover great UX.

So, is this the end of human-only traffic?

AI agents are already using your product. Not in some future. Right now.

This is another structural wave — like mobile, like the internet.

And if you're building software today, you need to support:

• Simple UIs for browser-based agents
• MCP endpoints for protocol-based access
• First-party agents to control the experience

Some users will be people. Some will be machines.

You need to serve both.

Ignore this shift, and you might fade into the background.

Embrace it, and you'll be way ahead.

The internet isn't just for humans anymore.

Time to build like it.

But here's the truth:

It's your fault.

And that's the best news you'll ever hear.

Why? Because if it's your fault, then you have the power to change it. If success, happiness, and progress are in someone else's hands, you're stuck waiting. But if they're in your hands, you can take action today.

Why taking full responsibility is a superpower

When you blame others, you give away your power. You become a passive participant in your own life, waiting for external forces to change before you can succeed. But when you accept full responsibility, you reclaim control.

Think about it:

• If your strategy isn't working, what are you going to do about it?
• If your co-founder let you down, how will you pivot and move forward?
• If family expectations feel overwhelming, how will you set boundaries and take ownership of your path?
• If life keeps throwing challenges at you, how will you adapt, learn, and turn setbacks into stepping stones?

By shifting your mindset from blame to responsibility, you stop reacting and start acting. You become the architect of your outcomes rather than a victim of circumstance.

The most successful people in the world are not the ones who never fail. They are the ones who take responsibility for their failures and keep moving forward. They don't wait for permission to succeed. They take it upon themselves to figure things out, make changes, and push through obstacles.

The difference between fault and responsibility

You can't control everything that happens to you. A bad economy, an unexpected betrayal, or a failed partnership may not be your fault. But how you respond to it? That's 100% on you.

Taking responsibility doesn't mean beating yourself up. It means owning the situation, learning from it, and making deliberate choices to improve things. The moment you say, “This is my responsibility,” you activate problem-solving mode. You stop waiting for rescue and start creating solutions.

It also means being honest with yourself. If something keeps going wrong, what are you doing - or not doing - that's contributing to it? Maybe you're avoiding a tough conversation. Maybe you're hesitating on a big decision. Maybe you're letting fear hold you back.

Facing these hard truths is uncomfortable, but it's also the key to unlocking real change.

The hardest (and most liberating) truth

Success isn't some magical stroke of luck. It's an equation. The inputs are your choices, your mindset, and your actions. The more responsibility you take, the more control you gain.

When you accept that everything in your life (your wins, your failures, your circumstances) is ultimately up to you, something incredible happens. You stop making excuses. You stop waiting for someone else to fix things. You take action.

And that's where real success begins.

People who take responsibility have an advantage: they don't waste time complaining. Instead of saying, “Why is this happening to me?” they ask, “What can I do about it?” And then they do it.

Every challenge you face is an opportunity to step up, learn, and become stronger. Every mistake is a lesson that can help you make better decisions in the future. Every setback is a chance to prove - to yourself more than anyone else - that you have what it takes to keep going.

Owning your story

Taking full responsibility also means owning your story. You are not just a character in someone else's narrative - you are the author of your own.

If you don't like how your story is unfolding, write a new chapter. If you're in a situation that's making you unhappy, change it. If you're feeling stuck, take one step forward-any step. The smallest shift in action can lead to the biggest transformation over time.

People will disappoint you. Plans will fall apart. Unexpected things will happen. But at the end of the day, your life is in your hands. You get to decide what happens next.

Final thought

Next time you find yourself complaining about a situation, pause and ask: What can I do to change this? The answer may not be easy, but it will always be empowering.

Own it. Solve it. Move forward.

Because it's your fault. And that's exactly why you have the power to fix it.

You know what’s almost guaranteed? Getting rich slow. And here’s the crazy part: that’s exactly how most wealthy people do it. They follow a simple but powerful formula: earn, invest, and let time do the heavy lifting.

The goal isn’t to look rich. Forget yachts, designer watches, and blowing money to impress people. True wealth is about something much simpler: not having to worry about money.

And the best part? Anyone can do this – if they’re willing to play the long game. Or as Charlie Munger famously put it: "The big money is not in the buying and the selling but in the waiting."

The younger you are - the more it matters

If you’re in your 20s or early 30s, this is especially relevant for you. Why? Because your biggest advantage isn’t money – it’s time.

It’s much easier to save and take smart risks before things like a mortgage, kids, or other major responsibilities start stacking up. But even if you’re in your 40s, 50s, or beyond, the same principles apply. The earlier you start, the easier it gets.

Compound interest is either your best friend or your worst enemy. The sooner you get it working for you instead of against you, the less effort it takes to build real wealth.

So let’s break down exactly how to get rich slow.

1. Get a job. Yes, really.

There’s a lot of noise online about quitting your 9-to-5 to become an entrepreneur, but here’s the truth: you need income first.

A job isn’t just a paycheck – it’s a launchpad. It teaches you how to manage money, develop skills, and build a network. Even if you dream of working for yourself (which I highly recommend), starting with a stable income makes everything easier.

Key takeaway: Your job is your first investor. Treat it as a stepping stone, not a life sentence.

2. Invest 50% of your income

If you’re young and don’t have major expenses, saving and investing 50% of your income can set you up for life. But let’s be honest - that’s not always doable.

The key is to be as aggressive as you reasonably can. Take advantage of your flexibility before mortgages, kids, and other obligations kick in. And no matter what, never let your savings rate drop below 10%.

Where should you invest?

Keep it simple. Set up automatic investments into:

• Index funds (S&P 500, world funds, etc.)
• Entire-sector ETFs (technology, healthcare, energy, etc.)
• Real estate (directly or via REITs)

Don’t try to time the market. Just be in the market.

Key takeaway: Save as much as you realistically can, but don’t stress. Just never go below 10%.

3. Be frugal – without being cheap

Frugality doesn’t mean depriving yourself. It just means spending intentionally.

Many people who look rich are drowning in debt. Meanwhile, genuinely wealthy people focus on:

• Buying high-quality things that last
• Avoiding lifestyle inflation
• Prioritizing investments over status symbols

Key takeaway: Spend on things that genuinely add value to your life. Ignore the rest.

4. Follow the 3-hobby rule

You should always have three hobbies:

1. One that keeps you creative (writing, music, coding, art)
2. One that keeps you in shape (gym, running, hiking, sports)
3. One that makes you money (side hustle, investing, business)

That last one? It might just turn into your full-time income one day.

Key takeaway: Hobbies aren’t just for fun – they can be your biggest wealth-building tool.

5. Life insurance is not just for death

Most people think of life insurance as something that only matters when you die. But smart people know it can be way more than that.

With the right policy, you can:

• Borrow against it while it keeps growing
• Access tax-free money later in life
• Use it as a safety net while keeping investments intact

It’s not death insurance – it’s life insurance.

Key takeaway: Life insurance isn’t just about protection – it’s a financial tool.

Great catch! I’ll add the Buy, Borrow, Die strategy as section #6 in both the blog post and the newsletter. Here’s the updated version:

6. borrow against your assets, don't sell them

Keeping on the theme as the life insurance, the truly rich don’t sell their assets - they borrow against them. Here’s why:

• Loans aren’t taxable
• Your assets keep growing
• You never trigger capital gains taxes

This method, also known as "Buy, Borrow, Die", gives rich people cash to live on while their investments keep growing. Then, when they pass away, their heirs inherit everything with a step-up in cost basis - meaning the original capital gains tax bill disappears.

Key takeaway: Never sell appreciating assets. Borrow, invest, and repeat.

7. Get a skill you can always monetize

This might be the most important advice here.

I don’t consider myself rich, but I never worry about money. Why? Because I’ve followed many of these principles (some of which I wish I had learned earlier), and I have a skill that people pay for.

No matter what happens in the economy, you'll always have options if you have a valuable skill. Learn to code, market, write, sell, or analyze data – something that businesses and people need.

Key takeaway: Your best investment is in yourself.

8. Learn the difference between good debt and bad debt

Not all debt is bad. There’s good debt and bad debt:

• Good debt: Anything that grows in value (real estate, business loans, skills that increase income).
• Bad debt: High-interest consumer debt (credit cards, car loans for luxury vehicles, financing gadgets you don’t need).

Key takeaway: Debt is a tool. Use it wisely.

Final thought: Play the long game

The path to wealth is simple, but it’s not easy. It takes patience, discipline, and a long-term mindset.

The best part? Anyone can do this.

Start early, stay consistent, and remember:

"The big money is not in the buying and the selling but in the waiting."
– Charlie Munger

So why not start today?

It is a proposed methodology for software development that prioritizes architectural design and leverages AI-driven automation.

I've also shared it on my GitHub page for feedback and discussion. https://github.com/ranaroussi/vibe-white-paper

VIBE: Visual Interactive Build Experience

Introduction

VIBE (Visual Interactive Build Experience) is a proposal aimed at the software development community, suggesting a novel methodology that prioritizes architectural design and leverages AI-driven automation. Traditional coding methods often require deep programming expertise, significant manual effort, and iterative testing, leading to inefficiencies and a high risk of errors.

VIBE endeavors to shift this paradigm by employing advanced AI techniques to transform detailed flowcharts and design assets into fully functional, platform-specific code. The overarching purpose is to enable architects, non-coders, and stakeholders to concentrate on high-level design and logic rather than boilerplate coding tasks.

Who Is the Target Audience?

• Software Architects and Engineers: Professionals seeking to streamline the progression from conceptual architecture to executable code.
• Technical Project Managers: Individuals requiring a strategic overview of the system without delving into low-level implementation details.
• Non-Coders and Stakeholders: Business analysts or domain experts who aspire to shape software design decisions without extensive programming knowledge.
• Educators and Researchers: Institutions or individuals exploring innovative strategies to teach or investigate software engineering.
• Open-Source Community: Developers eager to experiment with a local, AI-assisted methodology to foster collaborative improvements.

This white paper outlines the core ideas behind VIBE, including AI-assisted brainstorming, flowchart creation, backend service compilation, and frontend integration. It also details the role of open-source, locally deployable language models, underscores a fully output-agnostic compilation process, and provides structural guidelines for the flowchart format.

Problem Statement

Software development frequently necessitates translating conceptual designs and business logic into source code through a labor-intensive, error-prone method. This workflow often limits the contributions of individuals outside traditional developer roles, such as business analysts or UX designers.

VIBE aspires to mitigate these issues by advocating a more architectural, visual approach, where code generation is driven by robust flowchart documentation. Furthermore, existing AI-based solutions commonly depend on proprietary, cloud-hosted language models, which may entail limitations around privacy, financial costs, and control over the operating environment. VIBE suggests adopting locally deployable open-source models, thereby maintaining data sovereignty and supporting development settings that demand stringent security or offline capabilities.

Methodology

This proposal lays out a step-by-step strategy for harnessing AI-powered, flowchart-driven software creation. Below is an overarching summary of the methodology before diving into the intricacies:

1. AI-Assisted Brainstorming – Collaborate with an AI to specify the application’s features, user interactions, and logic.
2. Flowchart-Driven Architecture – Produce a machine-readable flowchart that operates as the foundational project blueprint.
3. Backend Compilation – Convert the flowchart into backend services, compiling them into WebAssembly or native libraries.
4. Frontend Integration – Construct a baseline user interface (when necessary) with essential functionality, deferring all styling or UI enhancements to developers.
5. Local Development & Open-Source LLMs – Emphasize the use of fine-tuned, open-source AI models running on local infrastructure.
6. Output-Agnostic Compilation – Retain full freedom to target any platform or framework without vendor constraints.

1. AI-Assisted Brainstorming

VIBE’s approach begins with a collaborative brainstorming phase, where an AI tool assists architects in cataloging the system’s features, pathways, and business logic. The AI functions as a knowledgeable guide, prompting deeper consideration of overlooked complexities and proposing best-practice alternatives for issues like user authentication, inventory handling, or payment processing.

Example Scenario: E-Commerce Application

• Architect Input: "I need an online store with product listings, a shopping cart, and a checkout process."
• AI Prompts:
  • "How will you handle out-of-stock items?"
  • "What is your approach for user authentication during checkout?"
  • "Would you like to integrate automated order confirmation emails?"
  • "Which payment gateways are required?"

---
config:
  theme: base
  themeVariables:
    fontFamily: 'PT Serif'
    fontSize: 13px
    lineColor: '#BB2528'
  flowchart:
    layout: fixed
---
flowchart TD
    Start --> DefineFeatures
    DefineFeatures --> AIQuestions
    AIQuestions --> RefineRequirements
    RefineRequirements --> GenerateInitialFlowchart
    GenerateInitialFlowchart --> ReviewWithArchitect
    ReviewWithArchitect --> FinalizeBlueprint

2. Flowchart-Driven Architecture

Once the brainstorming is complete, VIBE employs the AI to generate an exhaustive flowchart that captures the entire scope of the application. Unlike typical diagramming approaches, these flowcharts are machine-readable (e.g., JSON or XML) and intricately connected to code generation.

• Logical Nodes: Represent data flows and decision structures.
• UI Nodes: Provide placeholders for user-interface components, allowing design flexibility.
• Integration Nodes: Manage communication with external APIs, databases, or libraries.
• Conditional Nodes: Capture complex branching logic, states, and concurrency controls.

Widely Used Flowchart Schema

To guarantee compatibility with existing tools, VIBE encourages adopting recognized frameworks like BPMN (Business Process Model and Notation) or UML Activity Diagrams. Such schemas enjoy wide support across numerous visual editors and offer:

• Consistency: Standardized symbols to represent processes and data flows.
• Accessibility: An extensive ecosystem of editors and plugins for collaborative development.
• Scalability: The capacity to scale from simple sequences to elaborate, enterprise-level workflows.

---
config:
  theme: base
  themeVariables:
    fontFamily: 'PT Serif'
    fontSize: 13px
    lineColor: '#BB2528'
  flowchart:
    layout: fixed
---
flowchart TD
    Start --> FetchData[Fetch Data from API]
    FetchData --> DisplayUI[Display User Interface]
    DisplayUI --> UserAction[User Action Detected]
    UserAction --> APIRequest[Send API Request]
    APIRequest --> UpdateUI[Update UI with Data]
    UpdateUI --> End[Process Complete]

3. Backend Compilation

The AI compiler’s next step is to interpret the flowchart data and compile backend services. These services can be delivered as WebAssembly modules for browser contexts or packaged as native libraries for mobile and desktop environments.

Specific attributes of this phase include:

• API Endpoint Generation: The compiler automatically constructs endpoints derived from logical nodes in the flowchart.
• Event-Driven Logic: System behaviors are triggered by vibe-action directives that drive server-side operations.
• Data Management: VIBE’s backend approach centralizes caching, transaction handling, and synchronization.
• Service Variety: RESTful APIs, GraphQL, microservices, or serverless architectures are all viable outputs.
• SDK Integration: Flowchart nodes can outline how third-party tools (e.g., analytics, payment gateways) integrate.

---
config:
  theme: base
  themeVariables:
    fontFamily: 'PT Serif'
    fontSize: 13px
    lineColor: '#BB2528'
  flowchart:
    layout: fixed
---
flowchart LR
    Frontend --> |vibe-action| Backend
    Backend --> |API Response| Frontend
    Frontend --> |Data Binding| UIUpdate
    UIUpdate --> UserInteraction
    UserInteraction --> |vibe-action| Backend

4. Frontend Integration (For Applications with a UI)

Some applications do not require a graphical user interface—perhaps they are command-line tools or automated backend workflows. However, for those that do, VIBE assembles a rudimentary UI containing minimal elements and functional placeholders.

This bare-bones structure ensures the frontend can still operate end-to-end without imposing stylistic or design constraints. Developers are free to refine or replace these elements with any framework or design library.

Bare-Bones Output and Non-Destructive Updates

To empower developers, the compiler generates a baseline UI with event handlers and placeholders that reflect the flowchart’s logic. No styling, advanced interaction patterns, or visual flourishes are included. In iterative builds, VIBE updates only these AI-generated segments, leaving any developer-added code or stylistic changes intact.

<ul vibe-for="task in tasks">
    <li vibe-bind:key="task.id">
        <span>{{task.name}}</span>
        <button vibe-action="removeTask" vibe-bind:value="task.id">Remove</button>
    </li>
</ul>

5. Local Development & Open-Source LLMs

VIBE should prioritize local development by utilizing fine-tuned open-source Large Language Models (LLMs)—for example, Mistral or LLaMA—running on a user’s machine or within a confidential network. By advocating this setup:

• Data Privacy: Proprietary code, sensitive logic, and intellectual property remain entirely in-house.
• Cost Control: Teams avoid perpetual licensing or usage fees linked to cloud-based AI platforms.
• Customization Potential: Developers can adapt the LLM to project-specific domain knowledge or coding guidelines.
• Offline Capability: This approach suits locked-down or bandwidth-constrained environments where cloud access is restricted.

By suggesting the use of local, open-source AI, VIBE aims to address the diverse needs of industries where security, budget, or legal compliance demands an offline or fully private setup.

6. Output-Agnostic Compilation

A major pillar of VIBE is output agnosticism. The compiler is designed to target multiple runtime environments, ensuring developers can choose the best fit for each project. These options include:

• WebAssembly Modules: Deployed in modern browsers for near-native performance.
• Native Libraries: Integrated into mobile apps (iOS, Android) or traditional desktop systems.
• Intermediate Code: Allowing developers to add manual optimizations or incorporate specialized SDKs.

This flexibility means teams can select any technology stack—be it React Native, Swift, Kotlin, .NET, or frameworks like Next.js or Astro—without refactoring the fundamental architecture.

Key Benefits

1. Democratizing Software Development: By shifting emphasis to architectural design, VIBE creates opportunities for non-developers to engage meaningfully.
2. Cross-Platform Flexibility: Generated services are readily adaptable to web, mobile, or desktop platforms, giving developers broad freedom in picking frontend frameworks.
3. Enhanced Efficiency: Visual flowcharts and AI-driven code generation reduce overall development time and lessen the chance of manual errors.
4. Optimized Performance: Build-time strategies like code splitting, lazy loading, and minification can be automatically applied.
5. Scalability and Maintainability: Flowchart-driven logic offers a clear blueprint that remains comprehensible and modifiable as projects expand.
6. Local Development Focus: Emphasizing offline-capable, open-source AI models helps maintain security and lowers operational expenses.

Use Cases

• Enterprise Software: Larger companies with stringent data handling policies can adopt local LLMs for robust, scalable applications.
• Startup and MVP Development: Rapid prototyping and reduced coding overhead support accelerated go-to-market strategies.
• Educational Tools: Classroom or research environments benefit from a visual-first, architectural approach.
• Automation and Integration: Workflows and pipelines that require hooking into numerous external services can be orchestrated via explicit integration nodes.
• Privacy-Sensitive Industries: Hospitals, banks, and government agencies can operate fully offline with no external data exposure.

Challenges and Solutions

• Third-Party Integrations: Intermediate compilation layers accommodate custom code inserts or SDK usage without structural disturbance.
• UI Customizations: The compiler deliberately restricts re-generation to the AI-authored code, preserving user-defined components.
• Preventing UI Reset: A built-in diffing mechanism ensures new builds do not overwrite existing developer enhancements.
• Model Fine-Tuning Overhead: Training large language models locally can be hardware-intensive. VIBE suggests solutions like quantization or partial model loading to mitigate high resource demands.

Summary

VIBE represents a forward-looking proposal that envisions an AI-driven, flowchart-oriented approach to software development. By focusing on open-source, locally hosted LLMs, it addresses concerns regarding data privacy, cost management, and regulatory compliance.

Its commitment to output-agnostic compilation ensures developers retain complete freedom over their technology stacks. Through bare-bones frontend generation, VIBE encourages seamless integration of custom designs while minimizing the risk of code conflicts.

Ultimately, the objective is to democratize the development lifecycle by converting architectural insight—expressed via widely recognized flowchart standards—into functional, maintainable applications. If embraced by the broader software community, VIBE could catalyze a shift in how development processes are orchestrated, granting architects and stakeholders a clearer path from conceptual flowcharts to operational systems.

By uniting local AI models, standard flowchart schemas, and non-destructive compilation practices, this proposal aspires to reduce complexity while opening new avenues for collaboration and innovation.

Starting a business doesn't have to mean taking out a loan, hiring a team, or spending months building a product. Sometimes, the best businesses start with a problem, an idea, and zero budget. If you're a tech-savvy person looking to build something on your own, here are five business ideas you can start today with minimal investment—and they're ideas I'd personally love to see come to life.

These aren't just pie-in-the-sky concepts. They're practical, actionable, and designed to be launched quickly. Whether you want to start a side hustle, build a sustainable solo business, or just get your feet wet with entrepreneurship, each of these ideas offers a low-risk, high-potential path forward.

1. Curated newsletter with a specific focus

Imagine a newsletter around a niche topic—coding tips, productivity hacks, or a weekly roundup of indie maker projects. Personally, I'd sign up for a newsletter like this in a heartbeat. The best part? You can automate the entire process using tools that pull in content, format it, and distribute it through platforms like Substack or Mailchimp.

Real-world example: Check out PremarketBell.com, which curates pre-market stock news completely on autopilot. The setup is straightforward—define your content sources, set up automation to collect and curate, and let the system run while you focus on growth.

Monetization ideas: You can start with sponsorships, paid subscriptions, or affiliate marketing. As your audience grows, you could explore premium content or partnerships. A newsletter like this could build a tight-knit community of engaged readers—and if that's not a dream scenario, I don't know what is.

2. Bedtime story podcast for kids

I love this idea. Imagine a podcast that shares bedtime stories for children, all generated automatically. Your role would be to provide simple story outlines—something like “A bunny who learns to share” or “An adventure in a magical forest.” Then, let AI tools like ElevenLabs take over, generating the story and producing audio with different voices.

Why it works: You get to create something magical for kids and parents while leveraging automation to handle the heavy lifting. I'd probably listen to these stories myself—there's just something so soothing about a good bedtime story, right?

Monetization Ideas: You could offer a premium version with extra stories or themed story packs as a paid option. There's also the potential to build an audience for a related product or service.

3. Selling "boring" templates for important tasks

I'm a huge fan of templates. They save time, bring order to chaos, and make life just a bit easier. Whether it's budgeting, project management, or meal planning, templates can be lifesavers. Focus on those “boring” tasks that people struggle with—like creating a family budget or organizing freelance projects. You could create these templates in Excel or Google Sheets and sell them on Gumroad, Etsy, or even your own website.

Why it works: Digital products like templates require upfront effort but can generate passive income over time. And honestly, who doesn't love a good template? I'd buy one of these in a second.

Pro tip: Hang out in online communities to see where people are struggling, then create templates that solve real problems. Offer a free version of a simpler template to build an audience and then introduce paid offerings when the time is right.

4. A simple media kit web app

Here's an idea I'd love to see in the wild—a lightweight web app that helps startups create professional media kits with custom domains and branding. Many small businesses struggle to present their brand to potential partners, and a media kit app could fill that gap beautifully.

How to start: You could use no-code tools or a simple tech stack to build an MVP over a weekend. No need for anything overly complex—just a clean design, an easy-to-use interface, and a few customizable options to get started.

Monetization strategy: I could see this working well with a freemium model—offering a free tier and charging for premium features like custom domains or advanced analytics. It's the kind of tool I'd genuinely consider paying for if it made my life easier.

5. "Read It Later" with a twist

I'm all about efficiency, and a browser extension that lets users save articles to read later would be amazing. The twist? Use AI to summarize the content and automatically generate a personalized “weekend reading” newsletter. I'd use this in a heartbeat, especially on those weeks when my reading list feels endless.

Revenue opportunities: You could monetize through a freemium model, ads, or affiliate links. The automation potential here is fantastic—it frees you up to focus on refining and promoting the product while the extension does the work.

Final thoughts

These are not just ideas—they're starting points for real businesses you can build quickly, with minimal investment, and as a one-person operation. Whether you're automating a newsletter, launching a podcast, or building a simple web app, the barriers to entry have never been lower.

If I had the time, I'd be tempted to start one of these myself. And if you do, please let me know — I'd love to be your first customer!

What would you do if you had 10x more agency?

What is “Agency”?

Agency is the capacity to act.

Readiness meets ability.

It’s the power to control your destiny and influence the world around you.

Not just being a player in the game but setting the rules.

Not just reacting to events but creating reality.

If you had 10x more agency, what would your life look like?

How would you approach decisions differently? What goals would suddenly feel achievable? What obstacles that once seemed insurmountable would now feel like mere stepping stones?

The Time is Now

We live in a world where it often feels like we have no control over our lives. We wake up, follow routines, respond to external pressures, and adapt to the circumstances around us.

But what if we could flip the script?

Two days after seeing this tweet, I found out that Reid Hoffman (LinkedIn’s founder) just released a new book called Super Agency, all about this exact idea.

Looks like “agency” is about to be the word of 2025.

The Age of AI

We’re living in a time where AI is giving each of us 10x more power to shape the world around us.

From automating tasks that once took hours to generating insights at a scale no human could process alone, AI is fundamentally shifting our relationship with productivity, creativity, and decision-making. The rise of AI-driven tools has already changed how we work, think, and even create.

And in a few years, AGI—super-intelligent AI agents—will be here, working for us. These agents will be able to handle complex problem-solving, make autonomous decisions, and even execute strategies in ways that were once the exclusive domain of highly trained professionals.

If you’ve been playing the game of life with regular tools, it’s like suddenly getting three queens on a chessboard. The game has changed—have you adjusted your strategy?

But Here’s the Kicker…

10x more agency isn’t just some theoretical question.

We already have more agency.

The technology exists. The knowledge is out there. The resources are available. The only thing left is deciding what to do with it.

With Great Power Comes Time Pressure

When superheroes discover they have superpowers, they don’t usually keep spending their lives sitting in traffic and going to work every day, do they?

Yet, so many of us still operate as if nothing has changed. We hesitate. We second-guess ourselves. We wait for permission that no one is going to give us.

So the question I ask myself now is: What am I going to use it for?

What am I willing to bet on? What risks am I willing to take? What bold moves am I finally ready to make?

Suddenly, this tiny question turns into a question about purpose.

The Window is Closing

Here’s the thing: time is not on your side.

The ones who figure this out early will win big.

The advantage won’t last forever. Right now, we’re at an inflection point. A moment when those who recognize the opportunity can leap ahead, while others remain stuck in the status quo.

But in three years? Everyone will have these abilities. And if everyone is 10x more powerful, then no one really is.

This is the nature of progress. It moves in waves, and those who ride the early waves gain the most momentum. But once the wave reaches the shore, it’s just another part of the landscape.

I don’t remember the last time I felt like this. Maybe back when the internet was just starting. Back when having a website was a competitive advantage, before it became an expectation. Back when social media was an opportunity, before it became a requirement.

We are at a historic turning point for humanity.

This kind of stuff excites me. This is where my curiosity and creativity go into overdrive.

But Why Should I Be the Only One Dealing with This Mental Hurricane?

So now I’m passing it to you…

What would you do if you had 10x more agency?

Would you start the business you’ve been dreaming about? Finally write the book that’s been sitting in your mind for years? Change careers? Move cities? Solve a problem no one else is tackling?

Or would you let the moment pass and realize, too late, that you had more power than you ever imagined—if only you had chosen to use it?

The choice is yours. The clock is ticking.

I've made mine.

The plan was easy to follow: buy and hold at specific times, then sit back and let the seasons do the work.

The original strategy: Simple and straightforward

Here are the rules for the original strategy:

1. Hold GLD (SPDR Gold Trust ETF) from December 20 of every year through February 20 of the following year, and during August.
2. The rest of the time hold SPLV (Invesco S&P 500 Low Volatility ETF)

Before checking the latest results, let’s review how the strategy performed historically.

As you can see, over the years, it showed promising results by balancing gold’s seasonal strength with the market’s general upward trend.

Do simplicity still wins?

I wanted to see if these patterns would hold up over time, so I ran the numbers.

Here’s what I found:

Starategy Performace: 2011 to 2024

• Total Return: 381.6% (SPY: 459.64%)
• Average Annual Return: 8.27% (SPY: 9.1%)
• Sharpe Ratio: 0.85 (SPY: 0.82)
• Max Drawdown: -35.88% (SPY: -33.72%)

The Sharpe ratio measures risk-adjusted returns—higher is better.
Max drawdown shows the largest drop from peak to bottom—a key risk measure.

The numbers tell a story. The strategy worked but lagged behind SPY. What caused this underperformance?

Possible Reasons for Underperformance

Several factors may have hurt the strategy after 2020:

• The COVID-19 Crash: Market chaos disrupted typical patterns.
• Post-Pandemic Bull Run: The rapid rise in stocks broke the seasonal trends.
• Shifting Market Behavior: Patterns that worked for years started to weaken.

Even though the strategy recovered, it couldn’t match SPY’s fast growth. So, how could we adjust it for changing markets?

Tweaking the Strategy: Adding a VIX-Based Rule

Rather than abandon the strategy, I refined it. I added a simple rule using the VIX (volatility index)—a measure of market fear.

How it works:

• Keep GOLD during the usual seasonal periods.
• Switch between SPLV and SPY based on the VIX average from the past month:
  • VIX above 21 (suggests high volatility): Hold SPLV.
  • VIX below 21 (suggests low volatility): Hold SPY.

[Suggested Image: Decision tree showing the VIX rule.]

This rule helps the strategy adapt to the market’s mood. But did this adjustment improve performance?

How Did the VIX-Adjusted Strategy Perform? (2011–2024)

The results?

• Total Return: 496.87% (SPY: 461.81%)
• Average Annual Return: 9.45% (SPY: 9.11%)
• Sharpe Ratio: 0.87 (SPY: 0.83)
• Max Drawdown: -34.16% (SPY: -33.72%)
• Longest Drawdown: 618 days (Original: 842 days)

This version showed stronger returns and shorter slumps. What lessons can we draw from this experiment?

What Can We Learn?

• Markets change. No strategy lasts forever.
• Small adjustments matter. One extra rule improved results.
• Risk management counts. Reducing drawdowns can help you stay in the market longer.

Notable Metrics:

Metric               Strategy    S&P 500
-------------------  --------   --------
Cumulative Return   461.81%      496.87%
Yearly (ann.)          9.11%       9.45%
Sharpe                  0.83        0.87
Max Drawdown         -33.72%     -34.16%
Longest DD Days          708         618

Final Thoughts

This isn’t a trading recommendation. Instead, it’s an example of how to build and test strategies using data. Tools like Python let you explore ideas, test them, and improve them.

The lesson is clear: Simple ideas can work—if you test, tweak, and adapt them.

Want the Python code? Here you go:

"""
Implements a seasonal trading strategy combining GLD, SPLV and SPY based on VIX levels.

The strategy:
1. Holds GLD during seasonal periods (Dec 20-Feb 20 and August)
2. Otherwise switches between SPLV and SPY based on VIX levels
"""

import pandas as pd
import numpy as np
import yfinance as yf
import quantstats as qs

# Define ETFs to trade
tickers = ["GLD", "SPLV", "SPY"]

# Download historical data and calculate returns
assets = yf.download(tickers)["Adj Close"].pct_change().dropna()
assets.columns = tickers

# Calculate VIX indicator
vix = yf.download("^VIX")["Adj Close"]
vix = vix.resample('ME').mean()  # Get monthly average VIX
vix.index = vix.index + pd.DateOffset(days=1)  # Align index with trading days
vix = vix.resample('D').ffill()  # Fill missing days with last value
vix = vix.reindex(assets.index)["^VIX"]  # Match VIX index to asset data

# Initialize strategy column
assets["Strategy"] = np.where(vix > 21, "SPLV", "SPY")  # Base allocation on VIX
assets["Strategy"] = np.where(vix > 21, "SPLV", "SPY")  # Repeated for validation

# Implement final strategy rules:
# 1. Hold GLD during seasonal periods (Dec 20-Feb 20 and August)
# 2. Otherwise hold SPY when VIX < 13, SPLV when VIX > 13
assets["Strategy"] = assets["GLD"].where(
    ((assets.index.month == 12) & (assets.index.day >= 20)) |  # December 20 onwards
    ((assets.index.month == 2) & (assets.index.day <= 20))  |  # Until February 20
    (assets.index.month == 8),  # All of August
    np.where(vix > 13, assets["SPY"], assets["SPLV"])  # Non-seasonal allocation
)

# Calculate strategy metrics through 2024
qs.reports.metrics(assets["Strategy"], "SPY")

Between running Automaze (a full-scale CTO-as-a-service and development agency) and managing day-to-day tasks, it can often feel like I have too many things on my plate.

If you're anything like me, you, too, juggle countless responsibilities every day. With so much happening, it's easy for tasks to slip through the cracks. A reliable system is crutial to ensure nothing gets lost or forgotten.

Over the years, I've tried various productivity methods, but most felt too rigid or complicated. They didn't adapt well to my workflow, so I struggled to stick with them.

After much trial and error, I found a system that works for me. It's heavily inspired by David Allen's Getting Things Done (GTD) method, but it's simplified and much less rigid.

I use this framework to stay on top of work, ideas, and commitments without feeling overwhelmed.

Download a PDF version

What Is GTD?

David Allen's Getting Things Done (GTD) method is a productivity system designed to free up mental space by capturing tasks in a trusted place. The goal is simple: store tasks and ideas so your brain doesn't have to, then process them systematically.

While I appreciated the GTD method, I needed something more flexible. So, I created my own version—one that adapts to my workflow while keeping me organized and focused.

Step 1: Capture everything

Throughout the day, I collect tasks, ideas, and reminders however I can. At this stage, I don't worry about organizing them — I just focus on getting them out of my head and into a system.

I use multiple tools to do this:

• Apple Reminders for quick to-dos (especially with “Siri, remind me to…”)
• Emails to myself for longer thoughts
• WhatsApp messages to myself for ideas on the go
• A physical notebook for brainstorming sessions
• Voice memos for when I'm driving or away from a screen

If something crosses my mind, I capture it. No exceptions. This habit ensures that nothing important slips through the cracks.

Step 2: Clarify and organize

Once a day, I review everything I've collected. This step is about making sense of my notes. Often, they are incomplete or messy. Some items are duplicates. Others lack detail.

Here's what I do:

• Clean up messy notes by rewriting them clearly.
• Remove duplicates and combine similar tasks.
• Add missing details so future me knows exactly what to do.
• Move tasks into my task manager (I use Motion) for better tracking.
• Categorize tasks so I can group related ones together.

I also ask myself: Is this actionable?

• If the answer is yes, I determine the next steps and assign a priority.
• If no, I save it for later, archive it, or delete it.

This daily review keeps my system from becoming cluttered and helps me stay clear on what needs to happen next.

Step 3: Process and take action

Once my tasks are clear, I process them using this flow:

• If it takes less than 5 minutes, I do it immediately.
• If it's part of a bigger project, I break it down into steps.
• If someone else should do it, I delegate it.
• If it takes longer, I schedule it.
• If it requires deep focus, I block time for it on my calendar.

I also set reminders to follow up on delegated tasks. This ensures nothing gets stuck in limbo.

Additional rules

Beyond these core steps, I've added a few tweaks that help me work more effectively:

• The 5-Minute rule: If a task takes less than five minutes and will clear mental space, I still do it immediately.
• Daily Review & Weekly Planning: At the end of each day, I check what I accomplished and what still needs attention. Once a week, I plan ahead to avoid last-minute stress.
• Task Batching: I group similar tasks together (like emails or errands) so I can complete them more efficiently.

Why this works for me

This system works because it keeps things simple.

• I never forget tasks because I capture them immediately.
• I don't waste time organizing during the day.
• I clarify my to-dos daily, so I always know what's next.
• I take quick action on small tasks and plan ahead for big ones.
• I avoid decision fatigue by following a structured approach.

By sticking to this system, I keep my mind clear and my workload manageable. If you struggle with staying organized, give it a try! Start by capturing everything, then refine your process over time to fit your workflow.

Download a PDF version of my productivity framework ›

For decades, websites have been designed for human users—carefully structured layouts, sleek user interfaces, and intuitive navigation. But what happens when the primary visitors are no longer human?

With the rise of AI agents — smart tools capable of browsing, clicking, and completing tasks independently—the way we interact with the internet is changing dramatically. Instead of users manually visiting websites, AI will do the heavy lifting, returning only the final results. This shift challenges the very purpose of traditional websites.

AI Agents Are Changing How We Use the Internet

Imagine asking: "Where should I go today with my two kids?"

An AI assistant could:

1. Check the weather on one site
2. Look up open attractions from another
3. Find travel times elsewhere
4. Cross-check recommended kid-friendly activities

And then provide one final, well-researched answer—without you ever visiting a single site.

Clearly, this is far more convenient than manually browsing multiple websites to gather the same information.

Do Websites Even Matter Anymore?

If AI agents are handling most online interactions, why should businesses invest in UX and design?

Why would a national park’s website focus on user experience, navigation, and animations—when the majority of its "visitors" are AI bots simply extracting data?

In fact, human-friendly design might actually hinder AI agents. They don’t need visually appealing layouts, pagination, or interactive menus. All they want is raw, structured data.

We've already seen hints of this shift:

• People ordering food via DoorDash don’t care about restaurant websites.
• Travelers booking through Expedia may never visit individual airline sites.
• A decade ago, RSS users consumed blog content without ever seeing the original pages.

AI Will Replace Even Complex Apps

The impact goes beyond simple purchases. Imagine skipping a ClickUp dashboard entirely and just asking: "What’s the status of my team?"

Instead of logging into ClickUp, an AI could compile data from multiple platforms—HR software, time trackers, and project management tools—and present a single, clear response.

Or take Notion: Why manually check tasks when you could say, "I have two free hours. Show me my highest-priority assignments." Then later just type, "Mark task complete and update everything."

The Big Shift: From UX to AI Optimization

For years, companies have invested millions of developer hours in perfecting human-friendly UI—tweaking fonts, button placements, animations, and color schemes.

But if AI agents are the ones interacting with sites, all of that effort becomes unnecessary—or even counterproductive.

This marks a huge turning point in digital development.

1. Websites and apps will need AI-accessible endpoints. Beyond traditional interfaces, they’ll have to expose structured data in a way that AI can easily retrieve and modify—without worrying about human usability.
2. Eventually, human UIs may become redundant. If AI is doing most of the work, companies like Asana may deprioritize UI development, focusing instead on backend data management.
3. The role of web developers and UX designers will evolve. For decades, web developers have studied human psychology to create intuitive designs. But if AI agents are the new "users," human-centric UI might become a niche skill rather than the industry standard.

Final Thoughts

Back in 1997, a tech magazine described the "futuristic internet" where a dad checks:

• The weather on one site
• Movie listings on another
• Restaurant options elsewhere

At the time, this vision felt revolutionary. But today, the idea of manually visiting dozens of sites to plan an evening seems outdated.

Fast forward 30 years—will using a website yourself feel just as obsolete?

We’re on the brink of a massive transformation in web development. The next generation of "users" won’t be humans — they’ll be AI agents.

A New Chapter: London and Automaze

One of the biggest changes in my life recently has been relocating to London, UK with my wife and kids. Moving across the world is always a challenge, but doing it while juggling multiple projects and a growing family? That’s next level.

Shortly after settling in, we also welcomed our fourth child into the family — a huge milestone and an exciting (and sleep-depriving) addition to this new chapter.

On the work side, I started Automaze in 2023, offering CTO-as-a-service to businesses looking to scale their tech operations efficiently. After years of building products and companies, I realized that many businesses — especially startups — struggle to get their tech stack right. Automaze is my way of helping them navigate that challenge without needing a full-time, in-house CTO.

What Happened to Tradologics?

For those wondering about Tradologics, the cloud platform I built for programmatic traders, it’s currently in hibernation mode. It was an ambitious project that required significant resources, and while I still believe in the vision, I’ve had to put it on pause for now.

Why I Haven’t Been Writing Much

Between the move, launching Automaze, and working on various projects, I haven’t had much time to sit down and write long-form content. But if you’ve been looking for updates from me, I’ve been active on Twitter this whole time — sharing thoughts on tech, trading, and whatever else is on my mind.

📌 Follow me on X/Twitter: @aroussi

I also plan to start writing more regularly again, so if you’d rather get updates in your inbox, subscribe to my newsletter to stay in the loop.

📩 Join my newsletter: Subscribe here

What’s Next?

For now, my focus is on growing Automaze, helping companies streamline their tech, and settling into life in London. But I also plan to get back to blogging — so stay tuned.

If you made it this far, thanks for reading! Let’s see where the next four years take us. 🚀

Sure, hard work and grit count, but luck is the real game-changer.

The good news are that, like poker, you can optimize for luck and tilt the odds in your favor.

Here's how to optimize for Luck 🎲👇

Learn probability

To win with luck, you need to know when the odds are in your favor.

1. Compare opportunities based on expected value.
2. Operate under uncertainty with asymmetric strategies
3. Improve at predicting future outcomes.
4. The better you understand this, the smarter your bets.
5. Have something to bet with

Even if you spot an amazing opportunity, it’s useless if you have nothing to wager. This doesn’t just mean money. It means time and availability.

Keep parts of your life open to change so you can seize big opportunities when they come.

Get used to making small bets with incomplete information

Great opportunities often come with incomplete information. The longer you take to makde a decision, the more likely they’ll disappear.

Experiment daily with low-stakes decisions like picking a restaurant without overthinking) to build this habit.

Play the long game

The results are never linear. Sometimes nothing happens for a while. But when your “overnight success” moment comes, you’ll know it was no accident.

Here are my two cents...

I firmly believe that racism is, always was, and always will be, both evil and unbelievably stupid, but I also think that we should learn from history instead of rewriting it and pretending it didn't happen.

That's why I think that HBO's decision to add a disclaimer before showing "Gone with the Wind" is a good compromise - although I personally think that it's an over-hyped movie and couldn't care less if it was never shown again. But I digress...

A similar solution could be applied to Churchill's and other historical statues that some see as racists. Most of these figures were "normal" for their time and place in history and some, like Churchill, saved the world from much worse. That's why they should be moved into museums, where they can be preserved, protected, and presented with the entire context.

But when it comes to terms like white/blacklist, blackmail, database master/slave, etc.  —  I'm all for it!

This may sound like the least important thing on the list, but words do have power, and poisonous words can have damaging effects when heard enough times. If you need proof, watch this 1971 interview of Muhammad Ali, where he describes winning the Olympic medal during segregation and how words like that offended him since childhood.

Let's face it - the world is racist. But most racism is due to fear of "others," and the easiest way to detect "others" is using colors.

Don't believe people who "don't see color". That's a hard thing not to see.

The point is not to associate color (or sexual preference, gender, religion, or ethnicity for that matter) with good, bad, or anything other than "person". Some will be great, some will be assholes, and most will be something in between  —  just like the rest of us.

That's why I've decided that, in the upcoming weeks, we're going to change our git repository's "master" branch to "main", use "source/replica" database architecture instead of "master/slave", and use "allow" and "ban" lists instead of whitelist and blacklist.

I know it's a baby step, and that it won't change much in the short-term. But as more and more children grow up in a world where color isn't associated with good and bad - the more chance they'll have to "not see color".

Ever since I announced Tradologics last week, it’s been getting a lot of interest from traders, and even from some brokers 🤩.

Over 1,700 people have already signed up for the waitlist, which is both exciting and humbling! 🎉

Alas — along with that interest, I received a lot of questions from people wanting to know more about the services and trading scope

While Tradologics has many services to address every phase in the trading strategy business lifecycle, in this article, I’m going to go over the 4 core components of Tradologics, which are Tradelets, Tradehooks, Pipelines, and the Universal API.

Furthermore, this article will focus on the strategy deployment stage (I will address research and backtesting in a future post).

Traditional Trading

You’ve conducted your research and came up with a brilliant trading strategy.

Good for you!

Now you just need to:

1. Write a program to download real-time market data, store it, and feed it to your algorithm.
2. Filter out candidates that don’t match your universe criteria.
3. Have your algorithm work its magic and come up with trading signals.
4. Decide on your order size, based on your account balance, margin, and open positions.
5. Submit your orders to your broker, and monitor their status.
6. Manage your positions and scale or exit them based on the strategy’s goals and market conditions.
7. Get a server, configure it for maximum security, and put your code on it.
8. Monitor your trading server for errors and make sure it’s running without a glitch.

It’s as simple as that!

Trading with Tradologics

As stated earlier, the 3 core components of Tradologics, aside from the Universal API, are Tradehooks, Tradelets, and Pipelines.

1. Tradehooks

At the heart of your Tradologics’ trading setup are Tradehooks. These are webhook-style calls that push relevant data to your trading server.

Tradehooks eliminate the need to proactively connect to your broker or market data feed provider and request for information.

Tradehooks can push several types of data to your server, including market data, account information, positions status, and order status.

You can have Tradehooks push data to a trading server you own and manage, or, if you love life, use Tradelets.

2. Tradelets

Tradelets are encrypted, serverless functions that run your trading code — saving you from obtaining, configuring, and monitoring a trading server.

One of Tradologics’ core principles is that trades know what works best for them. We won’t tell you what language to write your algo in, which framework to use, or which broker to trade with.

Based on this philosophy, Tradelets can run code written in Python, Node.js, C#, Go, Ruby, Java, PHP, or Shell script (with R, Matlab, and EasyLanguage in the roadmap).

3. Pipelines

Another cool component of Tradologics is Pipelines. Pipelines act like stock screeners that filter out unwanted stocks from your trading algorithm, so you only get data for assets that match your universe criteria.

Putting it all together

The data flows like this:

A scheduler invokes a Tradehook, which fetches market data and passes is to a Pipeline for filtration. The filtered universe is then being sent back to the Tradehook.

Then, the data is pushed to your Tradelet, which parses it and passes it over to your Strategy. Depending on your strategy’s logic, you submit orders to any of the supported brokers using the Universal API.

The only part of this flowchart you need to take care of is the green box representing your strategy logic. Tradologics will handle everything else.

Here’s an example strategy:

You have an algorithm, written in Python, that buys stocks when the 10-day moving average is above the 50-day moving average, and vice-versa (amazing strategy, I know — send me the check later).

We only want to run this strategy on stocks that are:

1. members of the S&P500 index
2. released an earnings report on the previous trading day after market close, or today before the market opened
3. gapped up or down from the previous close

Now that we know what we want to do, let’s see how to do it…

To get this algo rolling we’ll need to:

1. Spin up a Python-enabled Tradelet, and add our code to it
2. Write our strategy logic (obviously)
3. Create a Pipeline to find stocks matching the above criteria
4. Setup a Tradehook to push market-data for filtered stocks every day, 5 minutes before the market opens, and select the broker accounts associated with it.

What would happen next, is that the Tradehook will send a JSON payload to our Tradelet, for the following events:

• Market data (daily, 5 minutes before market open)
• Account events (margin change, etc)
• Position updates (P&L, etc)
• Order status (for pending orders)

Here’s an example of the payload structure:

{
  /*
  event can be:
  - account, for account status events
  - position, position updates
  - order, order updates (filled, rejected, etc)
  - data, for market data
  */
  "event": "data",

  /* always sent, based on associated broker accounts */
  "accounts": [],

  /* always sent, based on associated broker accounts */
  "positions": [],

  /* pricing/pipeline data; sent when event == data */
  "data": {
    "AssetA": {...},
    "AssetB": {...},
    ...
  },

  /* order data; sent when event == order */
  "order": {...}
}

Let’s get started…

The first step would be to spin up a Python-enabled Tradelet. Here’s how to do it using our command-line tool, tctl (the Tradologics Controller).

Create a Tradelet named myalgo:

$ tctl tradelet create --name myalgo --lang python
Tradelet "myalgo" created with (req id: cb945f2d-103d-4092-95d4-a1024c9045dd)

Next, we’ll set up the Pipeline, this time using the dashboard:

Tradologics — Pipeline Setup Page

The next step is to configure our Tradehook:

Tradologics — Tradehook Setup Page

Finally, we’ll write the algorithm to handle the Tradehook’s payloads.

For example:

# mycode.py
import tradologics

def tradehook(payload):
  payload = tradologics.parse(payload)

  # is this a "data" payload?
  if payload.event == "data":

    for asset in payload.data:
      sma10 = asset.close.rolling(10).mean()
      sma50 = asset.close.rolling(50).mean()

      # buy signal ?
      if sma10 > sma50 and  # algo rule
         asset.last > asset.prev_close and  #  gap up
         data.positions[asset.id] <= 0:  # not in short position already
        tradologics.submit_order(
          asset=asset.id,
          qty=100,
          kind="market",
          side="buy",
          time_in_force="opg",
          accountId="my-ib-account",
          strategy="my amazing strategy"
        )

      # sell signal ?
      if sma10 < sma50 and  # algo rule
         asset.last < asset.prev_close and  # gap down
         data.positions[asset.id] >= 0:  # not in short position already
        tradologics.submit_order(
          asset=asset.id,
          qty=100,
          kind="market",
          side="buy",
          time_in_force="opg",
          accountId="my-ib-account",
          strategy="my amazing strategy"
        )

Notice how we didn’t have to fetch the data from anywhere or filter out any assets. It is all being taken care of by our Tradehook and Pipeline.

How cool is that? 😎

The final step is to push our code to the Tradelet. Again, we’ll use the tctl tool to do this:

$ tctl tradelet deploy myalgo --file mycode.py
File "mycode.py" was deployed to Tradelet "myalgo" (req id: 9d3e632e-7197-40d4-8d37-d0a34bf82171)

That’s it!

Your strategy is now live and you’ll be able to monitor its performance via the Tradologics dashboard or the tctl tool.

I’m really excited about all the innovations that Tradologics introduces and feel that it has the potential to help many traders who are "lost in the plumbing". But what’s more important is what do you think…

I'd love to get your feedback, questions, and ideas as we're getting ready to launch the platform. Also, please share this post to help us get the word out! 🙏

👨🏻‍💻 Finally, if you haven’t already, go to Tradologics.com and add yourself to the waitlist to be notified as soon as you can start using Tradologics.

Until then,

Happy trading 💪

- Ran

* Please note that actual syntax and UI may, and probably will, change a little by the time we launch.

It all started in 2016 with the release of QTPyLib. I was trying to shorten the time it takes to go from an idea to live trading by abstracting all the techie stuff as much as possible (while still allowing flexibility for developers).

Last year I shared my vision for the next version of QTPyLib in hopes of making the lives of programmatic traders ever easier. That vision led me to the idea of an open trading standard.

But the more I tried to simplify things, the more I realized that the programmatic trading landscape is a mess.

Think about this:

Being a programmatic trader requires skills that are entirely unrelated to trading!

Ridiculous.

Aside from generating trading signals, traders need to know how to work with streaming data, process “big data” in real-time, manage server infrastructure, parsing logs, etc.

Traders need to be transformed into a trading powerhouse with the skills of a Quant Researcher, a Quant Developer, a Programmer, DevOps Engineer, and a Database Administrator, to name a few.

Even if someone were to hold all those skills, they would still need to deal with the fragmented nature of the industry and familiarize themself with each broker’s API implementation, SDKs, and software.

This whole situation got me thinking...

What if there was a way for traders to focus only on the trading logic – without worrying about stuff like broker connectivity, data management, or infrastructure?

So, early this year, I’ve gathered a small team of ninjas and started working on Tradologics.

What is Tradologics?

Tradologics is the fastest way to go from idea to live-trading – bypassing all those infrastructure headaches.

Tradologics is the first cloud platform built with the specific needs of programmatic traders in mind. It lets traders research, test, deploy, monitor, and scale their trading strategies - allowing them to focus on the important things, like trading logic.

Tradologics’ goal is to make sure that the future of trading is frictionless by offering a myriad of tools and services aimed to solve every part of the trader’s business cycle, allowing them to focus on trading, while we take care of everything else.

We’ve just started a private beta phase with a small userbase. As we gradually grow, we’re going to allow more and more traders to use the platform.

Head over to Tradologics.com to learn more about the future of trading, and, if you want to be one of the first to try out the platform, join the waitlist using the form on Tradologics’ website.

Until then - Happy trading! 💪

Ran

While looking for a way to add support for multiple brokers and data vendors to my open-source Python trading library, I discovered that there's currently no way to communicate with various brokers without re-writing most of the code responsible for getting market data, sending orders, and do everything aside from generating trading signals.

Sure, financial institutions have had the FIX protocol since the '90s. It's a communications protocol designed to streamline communications in the financial services industry.

The problems with FIX is that, aside from being overly complicated, very few retail and online brokers support it, and the few who do are charging quite a bit for the privilege to use it — making it inaccessible (and frankly irrelevant) for most retail traders.

This led me to the idea of designing a new standard for communicating with online brokers by providing a modern trading interface using technologies like a REST API for polling data, HTTP/2 Server-Sent Events (SSE) for event notifications, and WebSockets for streaming live market data.

I've named this idea the Open Trading Initiative :)

Below is my (very rudimentary) vision for the Open Trading standard. It's far from complete, and it's basically in a “brain dump” status.

Naming Conventions

A crucial part of the Open Trading Standard is to have brokers use the same naming convention for tickers and symbols. One way of achieving this for all of them to support the Financial Instrument Global Identifier (FIGI) when referring to tradable instruments.

For example, the FIGI or the SPY is BBG000BDTG10, while Apple's is BBG000B9Y2J5.

In 2016, Bloomberg launched OpenFIGI.com to provide exchanges, data providers, custodians, and other organizations search for existing FIGIs, request identifiers for new securities and cross-reference, or map, FIGIs to other third-party identifiers.

Server Responses

Responses to API calls will be in JSON format and must use the same data structure and field names for compatibility with the Open Trading standard.

As an example, an account status response may look something like this:

{
    "account_number": "12345ABCD",
    "buying_power": 262113.32,
    "cash": -23140.20,
    "created_at": "2019-06-12T22:47:07.99658Z",
    "currency": "USD",
    "daytrade_count": 2,
    "daytrading_buying_power": 262113.32,
    "equity": 103820.56,
    "id": "e6fe16f364a44921-8928cadf02f92f98",
    "initial_margin": 63480.38,
    "last_equity": 103529.24,
    "last_maintenance_margin": 38000.832,
    "long_market_value": 126960.76,
    "maintenance_margin": 38088.228,
    "multiplier": 4,
    "pattern_day_trader": false,
    "portfolio_value": 103820.56,
    "regt_buying_power": 80680.36,
    "short_market_value": 0,
    "shorting_enabled": true,
    "sma": 0,
    "status": "ACTIVE"
}

SDKs / Libraries

SDKs and libraries will need to be available for multiple programming platforms and languages like Python, Node.js, Go, Java, .NET, etc.

These libraries will implement the standardized REST, SSE, and WS architecture, as described later in this post.

As a first step, these libraries will offer their own implementation of the Open Trading standard, served via localhost, while “translating” the trader-broker messages behind the scenes.

This obfuscation will help get people comfortable with the Open Trading standard and help gain traction.

REST API — for data polling:

The REST API will allow traders to request information from the broker, submit orders, download historical prices, and subscribe to SSE event notifications.

Connection:

• POST /connect — Authenticate using API credentials or connect to a locally running service (like IB's TWS). Query supports mode (live or paper/demo).
• POST /disconnect — Disconnect from a locally running service (unsubscribes from server events, and disconnects from socket if applicable — see below)

Account:

• GET /account — Get account information (balance, margin, etc..
• GET /positions — Get current positions
• GET /positions/{FIGI} — Get positions for instrument

Orders:

• GET /orders — List all orders (query supports status, date_range, etc)
• GET /orders/{FIGI} — List all orders for instrument
• DELETE /orders — Cancel all pending orders
• DELETE /orders/{FIGI} — Cancel all pending orders for instrument
• POST /orders — Submit new order(s). JSON body includes FIGI, qty, side (buy/sell), type (market/limit/stop/stop_limit), time in force (day/gtc/opg/moc/...), exchange, price (required if type is limit, stop, or stop_limit), rth (Regular Trading Hours — defaults to true)
• GET/orders/{orderId} — Get information for specific order
• PUT /orders/{orderId} — Modify an existing, pending order
• DELETE /orders/{orderId} — Delete an existing, pending order

Trades:

• GET /trades — List trades (query supports status, date_range, etc.)
• GET /trades/{FIGI} — List trades for instrument

Pricing:

• GET /prices/{FIGI} — Get OHLC(V) data bars for instrument (query supports resolution and lookback)
• GET /price/{FIGI} — Get latest price (inc. bid/ask info) for instrument

SSE — for event handling:

Server-Sent Events (SSE) is a server push technology enabling a client to receive automatic updates from a server via HTTP(S) connection. The SSE EventSource API is standardized as part of HTML5 by the W3C.

To subscribe to events, the protocol will listen for events on /events.

The suggested events are:

• account — receive account updates (balance, margin, etc.)
• positions — receive positions updates
• order — receive order updates (fills, rejections, cancellations, etc.)

Here's an example (using Javascript code):

const endpoint = new EventSource("/events");

endpoint.addEventListener('account', (event) => {
    const data = JSON.parse(event.data);
    console.log('Account:', data);
    // do stuff with the data
}, false);

endpoint.addEventListener('positions', (event) => {
    const data = JSON.parse(event.data);
    console.log('Positions:', data);
    // do stuff with the data
}, false);

endpoint.addEventListener('order', (event) => {
    const data = JSON.parse(event.data);
    console.log('Order:', data);
    // do stuff with the data
}, false);

WebSockets — for streaming data:

For streaming live tick, bid-ask, or order book data, the Open Trading standard will use WebSockets to subscribe to the ticks and/or the book channels.

Here's an example (using Javascript and SocketIO):

const socket = io.connect('//broker.com');

socket.on('connect', () => {
    socket.emit('subscribe', {
        "token": "AUTH_TOKEN",
        "events": ["ticks", "book"],
        "instruments": ["FIGI1", "FIGI2", ...]
    });
});

socket.on('tick', (event) => {
    const data = JSON.parse(event.data);
    console.log('Tick:', data);
    // do stuff with tick data
});

socket.on('book', (event) => {
    const data = JSON.parse(event.data);
    console.log('Book:', data);
    // do stuff with boot data
});

What now?

I'm looking for programmers and traders to establish the Open Trading initiative's consortium, bounce ideas off each other, and decide on the Open Trading standards, methods and, implementation.

If you're interested in joining me on this (unpaid and open-sourced) project, please subscribe here and join the Discord server to share your thoughts with me.

Thanks for reading!

⚠️ Read an updated version of this post (covers up to 2025) here

Active trading certainly isn't for everyone. Between spending time with family, going to work, running errands, paying bills, and not having the time or financial knowledge to invest wisely - it's easy to see why most people use the "Buy & Hold (Hope)" approach or choose not to invest at all.

But what if there's a way for you to beat the market, earn an average of 20%/year, reduce volatility by 40% and max drawdown by 70% using only four trades a year? Surely trading this kind of strategy should be attractive for anyone.

Here's a strategy that does just that.

Note: Past performance does not guarantee future results. I simply share my findings here not as a recommendation, but rather as back-tested results of a theoretical trading strategy, net of any commissions and fees.

The Lazy Strategy

The premise of this strategy is that (A) the market tends to go up over time, and (B) precious metals tend to display a seasonal up-trend during December-February, and around August (see the below GLD chart, adjusted for seasonality).

Legendary investor Warren Buffett once said (and then repeated) that "The trick is not to pick the right company, but rather to buy all the big companies through the S&P 500 and to do it consistently". Sound advice for 90% of people, indeed.

That advice takes care of item A (the market tends to go up over time). But combining that advice with a bit of hedging and two seasonality trades/year can yield more attractive results.

So, are you ready for this brilliant strategy? Ok, here it is:

1. Hold GLD (SPDR Gold Trust ETF) from December 20 of every year through February 20 of the following year, and during August.
2. The rest of the time hold SPLV (Invesco S&P 500 Low Volatility ETF)

That's it! (I told you it was simple)

I should point out that I haven't optimized this strategy at all. I simply "bought" Gold during its seasonal up-trend, and a low volatility "market" ETF the rest of the time.

So how a strategy like this performed over time? Here are the results from May 5, 2011 (date of SPLV inception) through today (October 3, 2019):

Metric               Strategy    S&P 500
-------------------  --------   --------
Cumulative Return    429.44%     117.45%
Yearly (ann.)          21.9%       9.67%
Sharpe                  1.73        0.71
Sortino                 2.65        0.99
Max Drawdown         -10.61%     -19.78%
Longest DD Days          258         416
Avg. Drawdown         -1.45%      -1.67%
Avg. Drawdown Days        15          20
Volatility (ann.)      11.9%      14.58%
Best Day               4.02%       4.96%
Worst Day             -3.75%      -6.66%
Best Month            12.27%      10.77%
Worst Month           -6.16%      -9.18%
Best Year             30.99%       29.6%
Worst Year             1.53%      -6.24%

To test how well this strategy would have performed before 2011, I've tested it using JKD (iShares Morningstar Large Core Idx) at 25% holdings, to (sort of) match the volatility of SPLV.

Here are the results from Jan 2, 2004 through today (Oct 3, 2019):

Metric               Strategy    S&P 500
-------------------  --------   --------
Cumulative Return     818.56%    161.09%
Yearly (ann.)          15.11%      6.28%
Sharpe                   1.33       0.43
Sortino                  2.02        0.6
Max Drawdown          -20.43%    -56.78%
Longest DD Days           349      1,996
Avg. Drawdown          -1.37%     -1.93%
Avg. Drawdown Days         18         33
Volatility (ann.)      11.03%     18.13%
Best Day                4.67%     11.58%
Worst Day              -3.98%     -9.03%
Best Month             12.27%     10.77%
Worst Month            -9.29%    -16.94%
Best Year              30.99%      29.6%
Worst Year             -2.56%    -38.49%

Note that aside from a ~20% drawdown in the peak of 2008's market crash, the maximum drawdown is around -10%, which fits most people's risk tolerance.

Check out the complete tearsheet for this strategy, generated by QuantStats, of course :-)

First, import yfinance and create a ticker object:

import yfinance as yf
aapl = yf.Ticker("AAPL")

Next, let's get information about the stock

aapl.info

Output:

{'language': 'en-US',
 'region': 'US',
 'quoteType': 'EQUITY',
 'quoteSourceName': 'Nasdaq Real Time Price',
 'currency': 'USD',
 'sharesOutstanding': 4601079808,
 ...
 ...
 'marketCap': 814805221376,
 'marketState': 'REGULAR',
 'priceHint': 2,
 'exchange': 'NMS',
 'exchangeDataDelayedBy': 0,
 'symbol': 'AAPL'}

Getting historical market data

hist = aapl.history(period="max")
hist.head()

Output:

            Open  High   Low  Close     Volume  Dividends  Stock Splits
Date
1980-12-12  0.02  0.02  0.02   0.02  117258400        0.0           0.0
1980-12-15  0.02  0.02  0.02   0.02   43971200        0.0           0.0
1980-12-16  0.02  0.02  0.02   0.02   26432000        0.0           0.0
1980-12-17  0.02  0.02  0.02   0.02   21610400        0.0           0.0
1980-12-18  0.02  0.02  0.02   0.02   18362400        0.0           0.0

Show only actions (dividends + splits):

aapl.actions

Output:

            Dividends  Stock Splits
Date
1987-05-11       0.12           0.0
1987-06-16       0.00           2.0
...
2019-02-08       0.73           0.0
2019-05-10       0.77           0.0

Show only dividents:

aapl.dividends

Output:

1987-05-11    0.12
1987-08-10    0.06
...
2019-02-08    0.73
2019-05-10    0.77

...or only splits:

aapl.splits

Output:

1987-06-16    2.0
2000-06-21    2.0
2005-02-28    2.0
2014-06-09    7.0

Dowloading fundamental data

Let's download Apple's financials:

aapl.financials

Output:

                                 9/29/2018  9/30/2017  9/24/2016  9/26/2015
Total Revenue                    265595000  229234000  215639000  233715000
...
Gross Profit                     101839000   88186000   84263000   93626000

Downloading the balance sheet is as easy as...

aapl.balance_sheet

Output:

                                  9/29/2018  9/30/2017  9/24/2016  9/26/2015
Cash And Cash Equivalents          25913000   20289000   20484000   21120000
...
Net Tangible Assets               107147000  134047000  119629000  110346000

Same goes for the cashflow:

aapl.cashflow

                                  9/29/2018  9/30/2017  9/24/2016  9/26/2015
Net Income                         59531000   48351000   45687000   53394000
...
Change In Cash / Cash Equivalents   5624000    -195000    -636000    7276000

Dowloading options data

To download option chains, let's first get the list of expirations:

aapl.options

('2019-05-31',
 '2019-06-07',
 ...
 '2021-01-15',
 '2021-06-18')

Now, we can download the option chain for a specific expiration date:

opt = aapl.option_chain('2019-06-07')

Let's look at the call options:

opt.calls

Output:

         contractSymbol  lastTradeDate  strike  lastPrice   ...  currency
0   AAPL190607C00150000     1559318324   150.0      27.05   ...       USD
1   AAPL190607C00152500     1558710976   152.5      27.80   ...       USD
2   AAPL190607C00155000     1559321089   155.0      22.06   ...       USD
...
34  AAPL190607C00242500     1557513401   242.5       0.04   ...       USD
35  AAPL190607C00245000     1557846185   245.0       0.01   ...       USD

Same goes for put options, of course:

opt.puts

Output:

         contractSymbol  lastTradeDate  strike  lastPrice   ...  currency
0   AAPL190607P00145000     1559320134   145.0       0.05   ...       USD
1   AAPL190607P00146000     1559243891   146.0       0.06   ...       USD
2   AAPL190607P00150000     1559322559   150.0       0.09   ...       USD
...
30  AAPL190607P00235000     1557415866   235.0      38.40   ...       USD
31  AAPL190607P00240000     1556642527   240.0      40.30   ...       USD

To install/upgrade yfinance using pip, run:

$ pip install yfinance --upgrade --no-cache-dir

The Github repository has more information and issue tracking.

Enjoy!

The first release of QTPyLib was a basic engine for live trading using Interactive Brokers. That's it. Nothing more. Nothing less. I have developed it for my own personal use and decided to release the code on Github for whoever finds it useful.

Over time the library had more features added and it even gained a decent amount of users, but, through it all, the development lifecycle remained pretty much the same: I was adding features that were specific to my own needs and releasing them to the public.

Using this approach, I've also released several other libraries, including fix-yahoo-finance, ezIBpy, PyStore, QuantStats, and a few others, which became the building blocks in my algo research & trading ecosystem.

My vision for QTPyLib moving forward is to have it combine all of these tools, among others, into a single, cohesive tool that lets you backtest, analyze, and trade anything. This is no small task, and it will going to take some time to complete.

So... here's what's in store for the next major release of QTPyLib:

1. Brokers & Data Vendors

The most significant change in the next major version of QTPyLib is the ability to work with any broker and any market data source. This is going to be achieved by converting both the blotter and the broker submodules to using a standardized extension/plug-in model.

While I initially only plan to release QTPyLib with support for Interactive Brokers as a broker, I will be providing a template for anyone who wants to add support for any broker or market data source.

For those without a real-time market data subscription, I will be adding the option to use EOD data from Yahoo! finance or EOD/intraday data from AlphaVantage out of the box.

This feature alone will allow QTPyLib users to trade Stocks, ETFs, Futures, Forex and Crypto on any broker they choose (as long as they have an API).

2. Backtester

Given the fact that QTPyLib was originally developed as a tool for live trading, I've never given the "backtesting-mode" the full attention it deserved. That's about to change.

The new QTPyLib's backtester will have a web-based progress visualizer, that, upon completion, will generate a detailed tearsheet and trade analysis - thanks to deep integration with QuantStats.

Lastly, I plan on introducing slippage and commission models to produce more realistic results.

2. Data Storage

QTPyLib will switch to use PyStore as the default storage engine. This will allow for enhanced portability and performance - especially on a single machine setup - by leveraging the power Dask and the Parquet file format.

Those wishing to use SQL databases will be able to use either MySQL or PostgreSQL, as the database access will be abstracted by using SQLAlchemy as the driver.

4. Other Changes

• New dashboard UI
• Scheduler module (inspired by Quantopian's)
• Rebalance module for easy portfolio rebalancing
• Option to submit orders as a faction of account value instead of quantity
• Support for IB sub-accounts (useful for Financial Advisors)
• Single on_bar() event when using multi-instrument algos
• Code speedup by converting core modules to Cython
• Various other minor code improvements
• Release of video guides and tutorials

That it for now :)

If you think of anything else that might benefit others, please submit a feature request on Github, and I try to include it.

Release Schedule:

Adding this many new features will take time. My goal is to release the next version by the end of the year. This means that the beta version will probably be released around October-November, and will be released on Github.

Help Wanted!

More than anything I need help writing unit tests and converting code to Cython, but I would appreciate any help. If you're a Python developer who also trades and want to help, I would be more than happy to get you on board.

Wish me luck! :)

Legal note:

Yahoo!, Y!Finance, and Yahoo! finance are registered trademarks of Yahoo, Inc.

yfinance is not affiliated, endorsed, or vetted by Yahoo, Inc. It's an open-source tool that uses Yahoo's publicly available APIs, and is intended for research and educational purposes.

You should refer to Yahoo!'s terms of use (here, here, and here) for details on your rights to use the actual data downloaded. Remember - the Yahoo! finance API is intended for personal use only.

fix-yahoo-finance aimed to offer a temporary fix to the problem by getting data from Yahoo! Finance and returning it in the same format as pandas_datareader's get_data_yahoo(), thus keeping the code changes in exisiting software to minimum.

The problem was, that this hack was a bit unreliable, causing data to not being downloaded and required developers to force session re-initialization and re-fetching of cookies, by calling yf.get_yahoo_crumb(force=True).

yfinance is a complete re-write of the libray, offering a reliable method of downloading historical market data from Yahoo! Finance's API, up to 1 minute granularity, in a more Pythonic way.

Introducing the Ticker() module:

The Ticker() module allows you get market and meta data for a security, using a Pythonic way:

import yfinance as yf

msft = yf.Ticker("MSFT")
print(msft)
"""
returns
<yfinance.Ticker object at 0x1a1715e898>
"""

# get stock info
msft.info

"""
returns:
{
 'quoteType': 'EQUITY',
 'quoteSourceName': 'Nasdaq Real Time Price',
 'currency': 'USD',
 'shortName': 'Microsoft Corporation',
 'exchangeTimezoneName': 'America/New_York',
  ...
 'symbol': 'MSFT'
}
"""

# get historical market data
msft.history(period="max")
"""
returns:
              Open    High    Low    Close      Volume  Dividends  Splits
Date
1986-03-13    0.06    0.07    0.06    0.07  1031788800        0.0     0.0
1986-03-14    0.07    0.07    0.07    0.07   308160000        0.0     0.0
...
2019-04-15  120.94  121.58  120.57  121.05    15792600        0.0     0.0
2019-04-16  121.64  121.65  120.10  120.77    14059700        0.0     0.0
"""

# show actions (dividends, splits)
msft.actions
"""
returns:
            Dividends  Splits
Date
1987-09-21       0.00     2.0
1990-04-16       0.00     2.0
...
2018-11-14       0.46     0.0
2019-02-20       0.46     0.0
"""

# show dividends
msft.dividends
"""
returns:
Date
2003-02-19    0.08
2003-10-15    0.16
...
2018-11-14    0.46
2019-02-20    0.46
"""

# show splits
msft.splits
"""
returns:
Date
1987-09-21    2.0
1990-04-16    2.0
...
1999-03-29    2.0
2003-02-18    2.0
"""

Available paramaters for the history() method are:

• period: data period to download (Either Use period parameter or use start and end) Valid periods are: 1d, 5d, 1mo, 3mo, 6mo, 1y, 2y, 5y, 10y, ytd, max
• interval: data interval (intraday data cannot extend last 60 days) Valid intervals are: 1m, 2m, 5m, 15m, 30m, 60m, 90m, 1h, 1d, 5d, 1wk, 1mo, 3mo
• start: If not using period - Download start date string (YYYY-MM-DD) or datetime.
• end: If not using period - Download end date string (YYYY-MM-DD) or datetime.
• prepost: Include Pre and Post market data in results? (Default is False)
• auto_adjust: Adjust all OHLC automatically? (Default is True)
• actions: Download stock dividends and stock splits events? (Default is True)

Mass download of market data:

You can also download data for multiple tickers at once, like before.

import yfinance as yf
data = yf.download("SPY AAPL", start="2017-01-01", end="2017-04-30")

To access the closing price data for SPY, you should use: data['Close']['SPY'].

If, however, you want to group data by Symbol, use:

import yfinance as yf
data = yf.download("SPY AAPL", start="2017-01-01", end="2017-04-30",
                   group_by="ticker")

To access the closing price data for SPY, you should use: data['SPY']['Close'].

The download() method accepts an additional parameter - threads for faster completion when downloading a lot of symbols at once.

* NOTE: To keep compatibility with older versions, auto_adjust defaults to False when using mass-download.

Using pandas_datareader:

If your legacy code is using pandas_datareader and you wand to keep the code changes to minimum, you can simply call the override method and keep your code as it was:

from pandas_datareader import data as pdr

import yfinance as yf
yf.pdr_override() # <== that's all it takes :-)

# download dataframe using pandas_datareader
data = pdr.get_data_yahoo("SPY", start="2017-01-01", end="2017-04-30")

To install/upgrade yfinance using pip, run:

$ pip install yfinance --upgrade --no-cache-dir

The Github repository has more information and issue tracking.

Enjoy!

In this webinar, I went over the basics of machine learning, and walked through an example of a trading strategy that leverages machine learning to achieve alpha.

Here's the webinar's recording, slides, and Jupyter notebook.

You can jump directly to the Jupyter notebook that's stored on this GitHub repository, along with a Python file which contains functions I've used during the webinars.

Webinar recording:

Webinar slides:

Open slides in a new window

When I first confronted this issue, my immediate go-to solution was to use a database like MySQL or PostgreSQL. But as a Python developer and a heavy Pandas user, I was hoping for a more "Pythonic" solution. I was looking for a solution that will allow me to store Pandas dataframes fast and fetch them even faster -- all while keeping the data itself as portable as possible.

The closest solution I found was the very impressive Arctic library by Man AHL, but it required me to run a MongoDB server, and the data wasn't very easily portable.

I finally ended up with a solution that may raise some eyebrows, but I feel that it works far better in the context of small to mid-sized trading operation.

The solution I chose was not using a database at all. 😲

You see, databases are designed to do a wide variety of things with data, many of which require checks and safety mechanisms to be implemented to do these things effectively and safely. This actually hurt the performance of what you are trying to do.

On the other hand, market timeseries data is unique, both in how it is used and how it is stored. The user drobertson explained it best in this Stack Overflow comment:

Market time series data is stored in a completely different way. In fact, I would say it is prepared rather than stored. Each data item only needs to be written once and after that never needs to be modified or changed. Data items can be written sequentially, there is no need to insert anything in the middle. It needs no ACID functionality at all. They have little to no references out to any other data. The time series is effectively its own thing.

So... the solution was to use a flat-file database, using a binary file format where I can store Pandas dataframes, and that supports compression to save on disk space and make portability easier. Luckily, the Parquet file format seemed to fit the bill just right :)

The next thing was to write a tool that will allow me to read and write such files in a "pythonic" way.

Enters PyStore...

I created PyStore to help me store and retrieve Pandas dataframes, and while it can store any Pandas object, it was designed with storing timeseries data in mind.

It's built on top of Pandas, Numpy and Dask and stores the data in the Parquet file format (via Fastparquet) in a hierarchical directory structure. Files are compressed using Snappy, a fast and efficient compression/decompression library from Google.

The end result?

A powerful, pythonic datastore for Pandas dataframes that can easily query millions of rows in sub-second speed.

PyStore provides namespaced collections of data. These collections allow bucketing data by source, user or some other metric (for example frequency: End-Of-Day; Minute Bars; etc.). Each collection (or namespace) maps to a directory containing partitioned parquet files for each item (e.g. symbol).

Getting started with PyStore

Let's get started with PyStore by first installing it using pip:

$ pip install PyStore

INSTALLATION NOTE: If installation fails, you probably need to install Snappy first (compression/decompression library). You can install Snappy C library with following commands:

• APT: sudo apt-get install libsnappy-dev
• RPM: sudo yum install libsnappy-devel
• Brew: brew install snappy

* Windows users should checkout Snappy for Windows and this Stackoverflow post for help on installing Snappy and python-snappy.

Next, let's get some market data to work with. We'll use Quandl's API to download 37+ years worth of historical data for Apple's stock.

import quandl

aapl = quandl.get("WIKI/AAPL", authtoken="your token here")
aapl.head()

Output should look something like this:

             Open   High    Low  ...  Adj. Close  Adj. Volume
Date
1980-12-12  28.75  28.87  28.75  ...    0.422706    117258400
1980-12-15  27.38  27.38  27.25  ...    0.400652     43971200
1980-12-16  25.37  25.37  25.25  ...    0.371246     26432000
1980-12-17  25.87  26.00  25.87  ...    0.380362     21610400
1980-12-18  26.63  26.75  26.63  ...    0.391536     18362400

Next, let's explore the PyStore library... We'll start by importing it to our code.

import pystore

Next, we'll tell PyStore where to save our datastore. This step is optional, and unless specified, the default path is set to ~/.pystore).

# Set storage path
pystore.set_path('/usr/share/pystore')

We can get a list of datastores found this location. Since we're just getting started, all we'll get is an empty list.

# List stores
pystore.list_stores()
# returns: []

Now it's time to create our first datastore.

# Connect to datastore (create it if not exist)
store = pystore.store('mydatastore')

Now when we call pystore.list_stores() we'll get a list with our new datastore listed.

pystore.list_stores()
# returns: ['mydatastore']

Before we can save our APPL timeseries data, we need ao create a Collection. As mentioned earlier, each collection (or namespace) maps to a directory containing partitioned parquet files for each item (e.g. symbol).

# Access a collection (create it if not exist)
collection = store.collection('NASDAQ.EOD')

# List all collections in the datastore
store.list_collections()

# returns ['NASDAQ.EOD']

Now we're ready to store our data. For demo purposes, we won't be storing the last row, which will be appended later. We'll also attach some metadata indicateing the data source.

# Store the data in the collection under "AAPL"
%time collection.write('AAPL', aapl[:-1], metadata={'source': 'Quandl'})

On my laptop (2015 Macbook Pro), saving 37+ worth of historical data took less than 16 milliseconds. Not too shabby.

CPU times: user 14.5 ms, sys: 2.75 ms, total: 17.2 ms
Wall time: 15.8 ms

To see all available items (symbols) in the collection, we'll use:

# List all items in the collection
collection.list_items()

# returns: ['AAPL']

Now let's see how long does it take to read the data:

# Reading the item's data
%time item = collection.item('AAPL')

CPU times: user 4.38 ms, sys: 1.11 ms, total: 5.49 ms
Wall time: 4.5 ms

4.5 milliseconds. NICE!

Let's take a closer look at the returned item object, specifically the data property, which returns a Dask dataframe and the metadata property, which returns, well, the metadata.

# Load AAPL Dask dataframe (see dask.pydata.org)
item.data

(TL;DR; A Dask DataFrame is a large parallel dataframe composed of many smaller Pandas dataframes, split along the index. These pandas dataframes may live on disk for larger-than-memory computing on a single machine, or on many different machines in a cluster. One Dask dataframe operation triggers many operations on the constituent Pandas dataframes.)

# Load AAPL metadata
item.metadata

{'source': 'Quandl', '_updated': '2018-06-05 16:04:56.203825'}

To get the entire data as a Pandas dataframe, we call:

# load data as Pandas dataframe
df = item.to_pandas()
df.tail()

We should get something like this:

              Open    High     Low  ...  Adj. Close  Adj. Volume
Date
2018-03-20  175.24  176.80  174.94  ...     175.240     19314039
2018-03-21  175.04  175.09  171.26  ...     171.270     35247358
2018-03-22  170.00  172.68  168.60  ...     168.845     41051076
2018-03-23  168.39  169.92  164.94  ...     164.940     40248954
2018-03-26  168.07  173.10  166.44  ...     172.770     36272617

To check how fast we can read the data as a Pandas dataframe, we can run this code:

%time collection.item('AAPL').to_pandas()

CPU times: user 7.28 ms, sys: 1.26 ms, total: 8.54 ms
Wall time: 7.57 ms

It took 7.57 milliseconds to read the data and convert it back into Pandas dataframe format on a 2015 Macbook Pro. Not too bad at all...

Let's append the last day (row) to our item:

# Append a row to AAPL
collection.append('AAPL', aapl[-1:])
collection.item('AAPL').to_pandas().tail()

We should see our new row added:

              Open    High     Low  ...  Adj. Close  Adj. Volume
Date
2018-03-21  175.04  175.09  171.26  ...     171.270     35247358
2018-03-22  170.00  172.68  168.60  ...     168.845     41051076
2018-03-23  168.39  169.92  164.94  ...     164.940     40248954
2018-03-26  168.07  173.10  166.44  ...     172.770     36272617
2018-03-27  173.68  175.15  166.92  ...     168.340     38962839

That's the basic stuff which should allow you get started using PyStore in no time.

But there's more...

After a while, you'll have many items stored, and you may want to look some of them up by metadata. To do this, simple add your metadata key to the list_items method:

# Query avaialable symbols based on metadata
collection.list_items(source='Quandl')

# returns: ['AAPL']

Snapshot functionality

When working with data, there will be times when you'll accidentally mess up the data, making it unusable. For that reason, PyStore allows you to create snapshots - a point-in-time, named reference for all current items in a collection.

Creating a snapshot is done using the create_snapshot method:

# Snapshot a collection
collection.create_snapshot('snapshot_name')

# List available snapshots
collection.list_snapshots()

# returns ['snapshot_name']

To see how snapshots work, let's change our original AAPL to only include the Close and Volume columns.

# Change the current dataset
collection.write('AAPL', aapl[['Close', 'Volume']],
                 metadata={'source': 'Quandl'},
                 overwrite=True)

# Load the "new" item
collection.item('AAPL').to_pandas().tail()

As we can see, we've lost all data except for the Close and Volume columns.

              Close    Volume
Date
2018-03-21  171.270  35247358
2018-03-22  168.845  41051076
2018-03-23  164.940  40248954
2018-03-26  172.770  36272617
2018-03-27  168.340  38962839

However, we can load our snapshot data at any time using:

# Get a version of a symbol given a snapshot name
snap_df = collection.item('AAPL', snapshot='snapshot_name')

snap_df.to_pandas().tail()

And, Voilà, we can see our data again.

              Open    High     Low  ...  Adj. Close  Adj. Volume
Date
2018-03-21  175.04  175.09  171.26  ...     171.270     35247358
2018-03-22  170.00  172.68  168.60  ...     168.845     41051076
2018-03-23  168.39  169.92  164.94  ...     164.940     40248954
2018-03-26  168.07  173.10  166.44  ...     172.770     36272617
2018-03-27  173.68  175.15  166.92  ...     168.340     38962839

We can, of course, restore our data from the snapshot:

collection.write('AAPL', snap_df.to_pandas(),
                 metadata={'source': 'Quandl'},
                 overwrite=True)

Lastly, we'll delete the snapshot:

# Delete a collection snapshot
collection.delete_snapshot('snapshot_name')

# To delete all snapshots, use:
# collection.delete_snapshots()

To delete the collection and the datastore, run:

# Delete the item from the current version
collection.delete_item('AAPL')

# Delete the collection
store.delete_collection('NASDAQ.EOD')

That concludes this quick tutorial of PyStore. I hope you'll find it useful as I do.

Speed test

In the above example, we've used EOD data (9,400 rows). As you recall, the write time was 15.8 ms and the read time (to Pandas) was 7.57 ms.

Let's try writing and reading 5 years worth of minute level data for the VIX Futures continuous contract (2,319,867 rows).

# Test write speed
%time collection.write('VX', vixdf)

CPU times: user 491 ms, sys: 148 ms, total: 639 ms
Wall time: 419 ms

Writing obviuosly takes longer here, as we're dealing with 246 times more data. But, still, 419 ms is not bad.

Let's see how long it takes us to read that amount of data.

# Test read speed
%time collection.item('VIX')

CPU times: user 4.19 ms, sys: 2.24 ms, total: 6.42 ms
Wall time: 5.32 ms

It took me 5.32 milliseconds to reading 2,319,867 records on my Laptop. But the big question, is how long will it take to read the data and convert it to Pandas dataframe?

Let's see:

# Test read speed
%time collection.item('VIX').to_pandas()

CPU times: user 170 ms, sys: 79 ms, total: 249 ms
Wall time: 179 ms

So... it takes PyStore 179 milliseconds to read and parse 2,319,867 records . Now this is Impressive!

Remember I mentioned portability earlier? Well, moving your datastore can't be easier. Simply copy your datastore directory (default is ~/.pystore/<DATASTORE>) to an external drive to move it to a new machine.

For peaking inside your Parquet files, I recommend Chip, a lightweight parquet viewer.

PyStore is now available via pip or directly from Github page.

It currently works with local filesystem, and I plan on adding support for Amazon S3, Google Cloud Storage and Hadoop Distributed File System in the future.

Please let me know what you think!

The problem with the VIX is that its available for a very limited number of indicies. There are a few Synthetic VIX indicators out there, invluding Larry William's VIX Fix (which probably is the most famous attempt) and this by PJ Sutherland.

I've beem using my own version of the Synthetic VIX for a while (based of the work of the above links) for Crypto Currencies (read Bitcoin) trading which great success, and I tought others can benefit from my work.

So over the weekend I've put up together a small website called CCVIX (Crypto Currencies Volatility Index) that shows the "VIX" for leading crypto-currencies, which I hope people will find useful.

The CCVIX calculates the expectation of volatility implied by daily price changes on an hourly basis, and is used as a measure of market risk.

Visit CCVIX.com »

PS. Merry Christmas and Happy Holidays to all :)

UPDATE (NOV 27, 2017): I've decided to remove this post, and won't be making the strategy's performance public anymore.

Q. Why did you stop publishing the stats?

A. My long/short Bitcoin startegy is performing very well (56% in October, 71% in November), and I'm now trading it on a larger scale for a few large investors.

Q. How can I invest in this strategy?

A. If you're interested in trading this strategy, please verify your qualified investor status by visiting BTCQualify.me and following the instructions. Once verified, I will be happy to provide more information, as well as an up-to-date performance report. Performance fee is 20% of month-end returns.

I showed how to scrape historical data for daily strategies, work with streaming data, and execute and monitor trades in real-time, and it was full of examples using Interactive Brokers and Oanda FX.

Here's the webinar's recording, slides, and Jupyter notebook.

You can jump directly to the Jupyter notebook that's stored on this GitHub repository, along with a Python file which contains functions I've used during the webinars.

Webinar recording:

Webinar slides:

Open slides in a new window

You can jump directly to the Jupyter notebook that's stored on this GitHub repository, along with a Python file which contains functions I've used during the webinars.

Webinar recording:

Webinar slides:

Open slides in a new window

Today I've releases a small Python library called fix-yahoo-finance that aims to offer a temporary fix to the problem by scraping the data from Yahoo! finance and returning a Pandas DataFrame/Panel in the same format as pandas_datareader's get_data_yahoo() method.

Here's how to use it

from pandas_datareader import data as pdr
import fix_yahoo_finance  # <== that's all it takes :-)

# download dataframe
data = pdr.get_data_yahoo("SPY",
                          start="2017-01-01", end="2017-04-30")

# download Panel
data = pdr.get_data_yahoo(["SPY", "IWM"],
                          start="2017-01-01", end="2017-04-30")

I've also added some options to make life easier, like groupping by ticker instead of OHLC and auto-adjustment of data and option to return a Pandas Panel or a MultiIndex DataFrame.

=> Visit the Github repository for more info and installation instructions.

* Note that this library in intented to be a temporary fix until the good fellas of pandas-datareader find a solution, or while you update your code to work with a different data provider.

Enjoy!

Legal note:

Yahoo!, Y!Finance, and Yahoo! finance are registered trademarks of Yahoo, Inc.

yfinance is not affiliated, endorsed, or vetted by Yahoo, Inc. It's an open-source tool that uses Yahoo's publicly available APIs, and is intended for research and educational purposes.

You should refer to Yahoo!'s terms of use (here, here, and here) for details on your rights to use the actual data downloaded. Remember - the Yahoo! finance API is intended for personal use only.

After going over the documentation and Stack Overflow I was finally able to get this working. To save others from the headache, I decided to post a working demo here as a public service.

First, here's a quick example:

Peaked your interest? Good! Let's get started...

We'll start with a simpler example than shown above.

In our example, we'll use ZeroMQ's pub-sub architecture using 2 files:

1. server.py will download SPY daily market data from Yahoo! finance and then will "publish" using a socket
2. client.py will listen on our server's port and will plot every new data point

Here's the code:

The server (streamer)

#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""
server.py
download SPY data from Yahoo finance and stream it using ZeroMQ
"""

# import libraries
import zmq
import time
from pandas_datareader import data

# create the zmq context and socket and bind the socket to port 1234
socket = zmq.Context(zmq.REP).socket(zmq.PUB)
socket.bind("tcp://*:1234")

# get market data from yahoo
data = data.get_data_yahoo("SPY", start="2017-01-01")

# iterate over rows
for ix, _ in data.iterrows():
    # get row as dataframe
    row = data[data.index==ix]['Adj Close']

    # stream row as python object
    socket.send_pyobj(row)

    # wait 1 second
    time.sleep(1)

The Client (plotter)

#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""
client.py
listens on ZeroMQ's port and plot every new data point
"""

# import libraries
import zmq
import time
import matplotlib.pyplot as plt
import pandas as pd

# create the zmq client and listen on port 1234
socket = zmq.Context(zmq.REP).socket(zmq.SUB)
socket.setsockopt_string(zmq.SUBSCRIBE, '')
socket.connect('tcp://127.0.0.1:1234')

# create an empty dataframe that will store streaming data
df = pd.DataFrame()

# create plot
plt.ion() # <-- work in "interactive mode"
fig, ax = plt.subplots()
fig.canvas.set_window_title('Live Chart')
ax.set_title("SPY, 2017")

# act on new data coming from streamer
while True:
    # receive python object
    row = socket.recv_pyobj()

    # append new row to dataframe
    df = pd.concat([df, row])

    # plot all data
    ax.plot(df, color='r')

    # show the plot
    plt.show()
    plt.pause(0.0001) # <-- sets the current plot until refreshed

    # be nice to the cpu :)
    time.sleep(.1)

Once you run both scripts you should see somehting like this:

* I recommend you run client.py first, so you won't miss plotting any data points :)

You can, of course, use any of the formatting options available in Matplotlib, so let your imagination run wild.

I've created a new GitHub repository to store the Jupyter notebooks for this and future webinars in this series, or jump directly to first webinar's notebook.

Webinar recording:

Webinar slides:

Open slides in a new window

The bot's Twitter account is was @spxfeelslike and, before I continue to explain what I did there, here's one of its actual tweets:

twitter.com/spxfeelslike/status/832907537188057090 https://twitter.com/spxfeelslike/status/832907537188057090

While my bot queries Twitter and CNN's Fear & Greed Index, the heart of the code is the part that analyzes the sentiment of recent tweets. As it turns out - it's a very small piece of code :-)

The two main libraries used here are:

1. TweetPy - for querying / posting to Twitter
2. TextBlob - for text processing

I won't go into too much details on the Twitter querying part of the code as it is pretty self-explanatory.

Rather, I'll focus on the sentiment part, which is basically 1 line of code (not counting the import section):

from textblob import TextBlob
sentiment = TextBlob("Gotta love Python").sentiment

Once ran, sentiment will have 2 properties:

1. subjectivity - indicates whether a sentiment was even detected a sentiment in the provided text
2. polarity - ranks the positive sentiment of the text, and ranges from -1 (extremely netagive) to 1 (extremely positive)

As you can see, once we have a list of tweets, all that's left to do is to count the total number of tweets with determined sentiment and the total number of positive tweets, and then simply calculate the ratio of positive tweets to total valid tweets.

Here's a full working code:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import tweepy
from textblob import TextBlob

# your Twitter app credentials
_CONSUMER_KEY = "..."
_CONSUMER_SECRET = "..."
_ACCESS_TOKEN = "..."
_ACCESS_TOKEN_SECRET = "..."

# keyword to query
keyword = "$SPX"

# -----------------------------------
if __name__ == "__main__":

    # twitter authentication
    oauth = tweepy.OAuthHandler(_CONSUMER_KEY, _CONSUMER_SECRET)
    oauth.set_access_token(_ACCESS_TOKEN, _ACCESS_TOKEN_SECRET)
    twitter_api = tweepy.API(oauth)

    # get latest 100 tweets containing the phrase $SPX
    tweets = twitter_api.search(keyword, count=1000)

    # parse sentiment
    valid = 0 # counter for tweets with a determined sentiment
    positive = 0 # counter for positive tweets

    for tweet in tweets:
        text = TextBlob(tweet.text).sentiment
        if text.subjectivity != 0:
            valid += 1
            positive += (text.polarity > 0)

    # sentiment ratio
    sentiment = positive / valid

    # construct tweet
    tweet = "Sentiment for %s is %.2f%%" % (keyword, (sentiment * 100))

    # to actually tweet, uncomment this line:
    # twitter_api.update_status(status=tweet)

    # for now, just print out the tweet
    print(tweet)

Output would look something like this:

Sentiment for $SPX is 52.12%

* Use the above code with caution and enjoy...

On one hand, I occasionaly feel the need to write something longer than a tweet, but on the other hand I didn't want to commit to blogging, and the last thing I want is another wasteland of a website.

So, I made a compromise... I'll try writing every 1-2 weeks and, if I can't hack it, I'll just shut the whole thing down.

Best of luck to me!