This is the Day 6 exercise for Week 2 of the “AI Path: Level Up Guide” series. Complete Day 5: Teach Your Script to Read More File Formats first, then come back here to work through this one. In Day 5: Teach Your Script to Read More File Formats, you built the read_file() function and the skeleton of a batch script. Your script recognizes files in various formats now. But you haven’t run a full pipeline from start to finish yet. You still need to pick a scenario, call the API, and save the results. That loop is missing. ...

This is Day 5 of Week 2 in the “AI Path L1→L2 Upgrade Guide” exercises. Read Part 2 first, then come back here. The batch_summarize.py from Part 2 handles .md and .txt files. But real files come in many more formats. PDF reports, Word contracts, CSV data tables, JSON config files. They’re sitting on your desktop right now, and the script can’t touch them. Today’s goal: write a read_file() function that picks the right reader based on file extension, then plug it into the Part 2 batch script. ...

This is Part 2 of the “AI Path L1→L2 Upgrade Guide” series. Complete Part 1 and the first three days of exercises (Day 1, Day 2, Day 3) before continuing. Part 1 taught you to make one API call. Today we’re going bigger: make your program ask AI a hundred questions. Manually pasting text into a chat window a hundred times is grunt work. Writing a ten-minute script that does it for you is leverage. You get the time back. ...

This is the Day 3 companion exercise. Complete Day 1 first. Part 1 covers the theory (“Understanding API Parameters”)—today you verify it with your own eyes. Part 1 explained parameters in theory. But theory without practice is just noise. Today you run three experiments and see for yourself how parameters affect output. Setup Make sure your Day 1 project still works: uv run python hello_api.py If the AI replies, your environment is ready. All experiments below build on this code. ...

This is Part 2 of When Your AI Coding Tool Needs Three Configs. Part 1 covered the config design, file structure, and orchestration philosophy. This article focuses on fallback mechanisms. omo = oh-my-openagent, oms = oh-my-opencode-slim. Model and provider names are anonymized as provider-a/model-x etc. Why Bother Understanding Fallback omo and oms both support fallback—automatic switching to backup when the primary model is unavailable. But their mechanisms differ completely: omo is a multi-layer pipeline that degrades step by step; oms uses startup model selection + runtime abort retry. You need to understand this difference to configure a reliable chain. ...

This is the Day 2 companion exercise. Complete Day 1 first. Yesterday you ran your first API call through DeepSeek’s official API. Today we do one thing: switch to a different platform, change two parameters in the same code, and run it again. You’ll see that learning one platform’s API means you’ve learned them all—as long as they’re compatible with the OpenAI interface. What Is an Aggregator Platform An aggregator platform is a middle layer. You register one account, top up once, and get access to dozens of AI models (OpenAI, Anthropic, Google, etc.) without signing up at each official platform separately. ...

Why I Need Three OpenCode Configs I have three opencode.json files in my ~/.config/opencode/ directory. The reason is simple: I wanted to run oh-my-openagent (omo from here on) and oh-my-opencode-slim (oms from here on) side by side, comparing them to understand where each one’s boundaries lie. omo is the full version—it comes with a batch of built-in agents (Sisyphus, Atlas, Prometheus, Oracle, Explore, Librarian, Metis, Momus, etc.), plus the ones I register on demand. The core is the fallback chain and the Sisyphus orchestrator: throw a refactoring task at Sisyphus, and it breaks the task down for Prometheus to plan, Atlas to execute the plan and distribute subtasks, Explore to search code, Oracle to analyze, then Sisyphus aggregates the results. oms is the slim version—it also has an orchestrator as the main agent responsible for executing tasks, but the difference is in the review phase: oms uses council multi-model consensus, where multiple councillors review results in parallel, and the Council agent synthesizes outputs from all councillors to reach a final conclusion. ...

This is the Day 1 companion exercise for the AI Path L1→L2 Upgrade Guide. Read Part 1 first, then come back here to practice. Today we do exactly one thing: run the hello_api.py from Part 1 and see AI reply in your terminal. Prerequisites Complete these steps from Part 1 (skip if already done): Register a DeepSeek developer account (Part 1, “Register for API Accounts”) Get your API Key and save it to a .env file (Part 1, “API Key Safety”) Install uv and Python 3.12 (Part 1, “Install Python”) Create a virtual environment and install dependencies (Part 1, “Create a Virtual Environment”) Confirm your project directory looks like this: ...

Series: AI Agent Experiment Methodology (Part 3) Previous: The Experiment Design Was Fine, So Why Did the LLM Still Fail? TL;DR: In a double-blind experiment, Variant B won 4/4 scenarios with clean data. But design review revealed the rubric had 3/8 dimensions directly testing the target variable, exceeding the 1/3 ceiling and nearly becoming a self-fulfilling prophecy. In a separate validation, one scenario scored perfectly while another exposed a defect—if we had run only the first, the defect would have shipped. Both traps were caught by reviewing the design, not by running the experiment. ...

TL;DR: This is Part 1 of the “AI Path L1→L2 Upgrade Guide” series. Four parts total, one per week of practice. This article takes you from chat windows to APIs—automating your AI interactions through code, laying the foundation for batch processing and autonomous task-execution AI. Introduction: From “I Ask AI” to “Programs Ask AI” If you finished the L0→L1 graduation checklist, you might remember one line from the graduation post: “Register for an API account and use Python to print your first AI reply.” Today is that day. ...