.png&w=256&q=75)
🤓 Latest Submissions
Upgrade Copilot
The problem: Dependency upgrades stall inside teams not because upgrading is technically hard, but because assessing safety is slow and manual. Before bumping a version, someone has to read the changelog line by line, guess which breaking changes actually touch the codebase, grep for every call site, check whether those sites are even tested, and only then decide whether to proceed. That triage tax is why teams sit on outdated — sometimes vulnerable — dependencies for months, only upgrading once a CVE forces the issue. It's a maintenance workflow with high manual effort and high error risk: it's easy to miss a call site, and easy to assume "we probably don't use that function" without actually checking. The solution: Upgrade Copilot is a multi-agent workflow built in IBM Bob 2.0 that automates this entire triage process for a given dependency + target version. Given a project and an upgrade target, it: (1) reads the dependency's migration notes via document understanding to extract a structured list of breaking changes; (2) scans the codebase in parallel to find every call site touching that dependency; (3) cross-references the two — the key step existing tools skip — so a breaking change in a function the codebase never calls is correctly ignored, while a breaking change in a function it does call is flagged as real risk; (4) checks whether each at-risk call site has test coverage, flagging untested risk separately from tested risk; (5) drafts the actual code fix for each flagged site, and adds missing tests for previously-untested ones. Target users: engineering teams doing routine maintenance — the people who currently avoid dependency bumps because assessing them eats a day of manual work, and the people who inherit "big bang" upgrades once a security issue forces the question. How they interact with it: a developer opens their project in Bob, states the dependency and target version, and lets Bob's Plan mode explore the repo and migration docs to propose a task breakdown. Independent sub-tasks (fixing separate source files) run without depending on each other, while dependent steps (adding tests, bumping the manifest) run last, after the code fixes land. The developer reviews Bob's plan before handing it to Agent mode to execute, keeping a human decision point in the loop. What makes it unique: most AI dev-tool demos analyze a single repo in isolation — explain this codebase, review this PR, score this release. Upgrade Copilot instead targets a routine but chronically neglected maintenance task, and its core insight is the cross-reference step: correctly separating "breaking changes in the library" from "breaking changes that actually affect this specific codebase." That distinction is exactly the tedious, error-prone part a human currently has to do by hand — and it's the part that determines whether an upgrade takes an hour or a week. Demonstrated impact: on our sample project (10 lodash 3.x call sites, only 3 originally tested), Bob correctly identified all 10 breaking call sites, correctly separated tested from untested ones, and produced a full migration plan — in minutes, via a task decomposition and file-scan process that would otherwise take a developer significantly longer to do manually and with higher risk of missing a call site.
27 Sep 2026
SentinelTrade
SentinelTrade is a modular, risk-gated trading agent built entirely on Alpaca's paper trading environment for the Alpaca AI Trading Agents Hackathon. The system is structured as a pipeline of independent components: 1. Market Scanner — pulls live daily bar data for a watchlist of symbols (SPY, QQQ, AAPL, MSFT, NVDA) via Alpaca's Market Data API. 2. Strategy Engine — calculates 5-day and 20-day moving averages, RSI, and a composite momentum score from the raw price data, then converts these into a transparent BUY/HOLD/SELL signal per symbol. 3. Risk Manager — acts as a hard, independent safety boundary that the strategy cannot override. It enforces a maximum position size (10% of account equity per symbol), a maximum total portfolio exposure (60%), a daily loss circuit breaker (2%), and a minimum trade size, rejecting or resizing any trade that breaks these rules. 4. Position-Aware Execution — before submitting any trade, the agent checks existing paper account holdings via Alpaca's Trading API, so it never re-buys a position it already holds, and calculates exposure against real account state rather than assuming a fresh start each run. 5. Dry-Run / Live Modes — every run defaults to a dry-run mode that prints exactly what would be submitted without sending any orders, with a `--live` flag required to actually route orders to Alpaca's paper trading endpoint. The core design principle is separation of concerns: the strategy proposes, but only the risk manager can approve. This makes the system's safety guarantees auditable independent of whatever logic drives the trading signal itself — a foundation we intend to build an LLM-based reasoning layer on top of next, where an AI model reviews each proposed trade's context and can add a layer of judgment before the risk manager has final say. All trading in this build was tested exclusively in Alpaca's paper environment with simulated funds — no real capital was placed at risk at any point.
4 Sep 2026
