DEV Community: Valancio Dsouza

Building a Python Curriculum That Starts Before You've Opened a Terminal

Valancio Dsouza — Thu, 30 Jul 2026 21:11:53 +0000

Most "beginner" Python courses aren't actually beginner courses. Lesson one usually opens with variables or print(), quietly assuming you already know what a terminal is, how to install something, or what a .py file even means. That assumption is exactly where most self-taught learners bounce — not because Python is hard, but because the ten minutes of orientation that would've made everything after it make sense got skipped.

I built Codes Are Simple to start there instead. Session 1, Level 1: what is code, where do you type it, how do you open Command Prompt, how do you install Python and verify it worked. Nothing assumed.

What it actually is

A 45-session, self-paced curriculum — Python: The Universal Language, Zero to Pro — split into 10 tiers, from absolute foundations through OOP, files/errors, practical CLI projects, web/APIs, databases, and a final professional capstone. It's the first of a planned multi-track catalog on the same platform (web dev, AI, cyber, and data are mapped and coming next).

Every lesson — all of them, across all 45 sessions — follows the same repeating shape:

explanation → main example → 2 extra examples (variations/edge cases)
→ common mistake (shown alongside its fix) → practice → extra practice

That "common mistake" section is the part I actually care about most. Almost every course I looked at shows only the correct code. This one shows what actually breaks for a beginner and why — because for someone learning alone with no instructor in the room, the error message is usually where the real learning happens, not the clean solution.

Checkpoints land at fixed points mid-session (after Level 2, Level 6, and Level 9 — not just at the end), and every session closes with a real capstone project, not a toy exercise.

The stack

Cloudflare Workers + Pages + R2 — the site and all curriculum content, served as versioned JSON per session
GitHub — version control for the whole content pipeline

That last point is the part I think this community will actually find interesting.

The part I don't usually see people talk about

Writing 45 sessions × ~10 lessons each is the easy part to brag about. What's harder — and what almost never gets mentioned in launch posts — is that a chunk of that content had real, boring structural bugs: duplicate lessons that taught the same thing twice under different level numbers, checkpoint quizzes with the wrong number of questions, content that had drifted into the wrong session entirely. Nothing dramatic, just the kind of contamination you get when you're moving fast across hundreds of files.

I went through it file-by-file before launch — not with a script, by actually opening the files — and fixed what I found instead of shipping the first draft and calling it done. If you've ever built something content-heavy at scale (docs, course material, a knowledge base), I'd genuinely like to hear how you handle QA for that — automated tests don't map cleanly onto "is this lesson pedagogically sound," and I'd love other approaches.

Try it

Session 1 is free, no signup wall:
👉 https://codesaresimple.marketingstudios.in/session.html?c=python&s=1

The price of the sessions & full course is deliberately Low not bootcamp pricing — with scholarship support for anyone who can't cover that.

Would love feedback from this crowd specifically on the teaching structure (the "show the mistake, not just the fix" approach) and on how you'd think about content QA at this scale if you've dealt with something similar.

After getting 2k+ Clone Im getting SAGE GUI Electron in Soon: From a wrapper/MCP to an AI Coding Agents, API Traveller, MCP, and Token-Saving in One.

Valancio Dsouza — Fri, 17 Jul 2026 14:03:44 +0000

I’m building SAGE GUI - Electron, a local-first desktop app for AI coding workflows.

SAGE lets you run commands safely with:

pip install psycgod-sage
Or
npm install -g psycgod-sage
Or
Use MCP Server

It tracks command output, compresses noisy logs, shows tokens used, estimates token savings/cost savings, and keeps raw data local.

The GUI will support multiple AI providers and keys. With API Traveller, users can add multiple API keys/base URLs, rotate automatically when one fails, and route across providers like OpenRouter, Gemini, Groq, and Ollama.

Inside the app, SAGE can show:

code output
tool output
tokens used this session
total compressed/saved tokens
estimated cost saved per model/provider
live dashboard metrics
project-based chats
MCP server support for local tools and agent workflows

SAGE GUI is still in the making, and I’m aiming to publish it by August.

Repo: https://github.com/PsYcGoD/sage

Live Public dashboard: https://sage.api.marketingstudios.in/

Glama MCP: https://glama.ai/mcp/servers/PsYcGoD/sage

SAGE is for developers who want AI coding agents to be more local, trackable and less messy.

I Analyzed 4,788 AI Coding Sessions — Here's Where Your Tokens Actually Go

Valancio Dsouza — Sat, 11 Jul 2026 12:18:45 +0000

Last month I started tracking every command I ran through Claude Code, Cursor, and Aider. After 4,788 commands and 355 million tokens, I found something shocking:

97.6% of my tokens were wasted on noise.

Not on actual coding. Not on debugging. On repetitive test output, build logs, and progress bars that the AI didn't need to see.

THE NUMBERS

Commands tracked: 4,788
Total tokens processed: 355,785,039
Tokens that were actual content: 8,694,751
Tokens that were noise: 347,090,288
Waste rate: 97.6%

WHERE THE WASTE COMES FROM

Test Output (99.7% waste)

Running pytest on a project with 1000 tests generates around 14,000 tokens. After filtering to just failures and summaries: 38 tokens.

Every "PASSED" line, every progress dot, every timing stat — the AI doesn't need any of it to help you fix the failing test.

Build Logs (99.4% waste)

A typical webpack or tsc build dumps 300+ lines. The only lines that matter: errors and warnings. That's usually 5-10 lines.

Package Manager Output (97% waste)

npm install produces pages of resolution trees, audit notices, and funding requests. What you actually need: "installed" or the error message.

Git Status (96.9% waste)

50 modified files = 254 tokens. What you usually care about: "these 3 files in src/". About 8 tokens.

THE ONE EXCEPTION: STACK TRACES

Interestingly, stack traces showed almost 0% compression opportunity. Every line matters for debugging. The AI actually needs to see the full trace.

This makes sense — stack traces are information-dense. Test output is the opposite.

WHAT THIS MEANS FOR YOUR WALLET

At Claude's Sonnet pricing ($3/million input tokens), my 347 million wasted tokens = $1,041 burned on noise.

With Opus ($15/million), that's $5,206.

And I'm just one developer. Multiply this across a team.

THE FIX

The solution isn't to use AI less. It's to filter what you send it.

Before:
pytest output with 1000 tests showing every PASSED line = 14,006 tokens

After filtering:
Just the failure message and summary = 38 tokens

Same information. 99.7% fewer tokens.

MY TAKEAWAYS

Test output is the #1 token killer — it accounted for 343 million of my 347 million wasted tokens
Build tools are chatty by design — they're made for humans scrolling terminals, not AI context windows
Stack traces are sacred — don't compress them, you'll lose debugging context
Progress bars are pure waste — those loading bars mean nothing to an AI

TRY IT YOURSELF

Track your next 100 AI coding sessions. Count the tokens going in. I bet you'll find similar numbers.

The AI coding revolution is here. But we're paying 40x more than we need to because our tools were built for human terminals, not AI context windows.

Data collected over 7 days using local token counting with tiktoken. All commands run through Claude Code, Cursor, and Aider on real projects.

Did you guys know about this tool "S.A.G.E - CLI" that saved me $45 in AI tokens by compressing terminal output 93% in just 3 days of using it.

Valancio Dsouza — Wed, 08 Jul 2026 19:18:48 +0000

I've been using AI coding assistants (Claude, Codex, etc.) and kept hitting token limits because terminal output is SUPER noisy. A single pytest command can eat 30,000 tokens of your context.
So I started using SAGE (Smart Agent Guidance Engine) - it sits between your terminal and AI agents, compressing output by 93% while keeping all the important stuff.
CLI install pip install psycgod-sage
sage connect (Git OAuth)
What it does:

Wraps your commands: sage run -- pytest
Compresses output in real-time (30k tokens → 2k)
10+ specialized agents watch for errors, secrets, dependencies
ML learns your command patterns to predict failures
Everything stays local by default (privacy-first) Real numbers from my usage:
Processed: 6,613 commands
Saved: 15.3 million tokens (would cost ~$45 at Claude Sonnet rates)
Agent runs: 41,578 (caught secrets, predicted errors, etc.) Why I'm sharing: It's a open-source, free and because I figured others hit the same problem. It's MIT licensed, runs locally, and has a live dashboard showing aggregate proof (no raw data). Repo GitHub: /PsYcGoD/sage The compression alone saves tokens, but the agents catching secrets before you commit them? That's saved me a few times already. Questions welcome! Would love feedback from the community.†