DEV Community: Rehman Ahmad Chaudhry

Shipping Software with AI Agents: How I Built a 48-Rule Scanner in 2 Days (and What 3 Audit Teams Found)

Rehman Ahmad Chaudhry — Wed, 04 Nov 2026 06:27:05 +0000

I am a head teacher by day and a solo developer by night. Last week I shipped a real tool — a 48-rule scanner that spots AI design slop in web projects — in about two days of evening work. I did not write most of it by hand. I directed a small team of AI agents, then handed the result to three independent audit teams and fixed everything they found. This is the honest story of shipping software with AI agents: what moved fast, what broke, and the checklist I now use before any solo release.

Why I Built Instead of Installing

It started with a post someone shared with me: a hugely popular tool that scans for "AI slop" in design. It had tens of thousands of stars and a long feature list. Installing it would have taken five minutes.

I chose to build my own instead, for two reasons. First, I wanted a tool I fully understood — one file, zero dependencies, rules I could read and change myself. Second, I wanted to test a question I keep asking myself as a solo developer: can a one-person team with AI agents ship something genuinely useful, not just a demo that looks finished?

The answer turned out to be yes — with one condition. The agents are fast builders but careless reviewers. Everything that made the project real happened in the review stage, not the build stage. That is the lesson this whole article is about.

Shipping Software with AI Agents: The Build, in 2 Days

Day 1: One sharp brief, not a long conversation

I have learned that agents do their worst work when the brief is vague. "Build me a slop detector" would have produced a generic tool with generic rules. So I wrote a short brief with three hard constraints before anyone wrote a line of code:

One file, zero dependencies. If it needs an install step, a teacher or student will not use it. The scanner had to run with a single command.
Real line numbers, always. A warning without a line number is a chore, not a help. Every finding had to point at the exact line.
A CI gate, not just a report. The scanner had to be able to fail a build when slop crossed a threshold, so teams could actually enforce it.

Those three constraints did more work than any clever prompt. They forced every later decision: the rule format, the output format, the exit codes. When an agent suggested a feature that broke a constraint, the constraint won.

By the end of the first evening, the core existed: a scanner with rules grouped into packs, including a pack for right-to-left layouts (I care about this because Urdu and Arabic content is badly served by most design tools) and a pack for the tired "2026 defaults" — the same cream background, serif heading, and sage-green accent combination appearing on every AI-generated landing page.

Day 2: Features users can actually run

Day 2 was about making the tool usable by someone who is not me. That meant a live web checker anyone can try in a browser, an audit-report generator for teams that want a document rather than terminal output, and a small benchmark set so the rules could be measured instead of merely claimed. The benchmark matters more than it sounds: without it, "48 rules" is just a number. With it, I could say how often the scanner catches real slop and how often it cries wolf.

That is also the day the project got its name and its home: Deslop, open source on GitHub, with the live checker on the web. I publish free tools for teachers and students at filecobra.com, and I write about the shipping side of this work — the workflows, the mistakes, the checklists — on rehmanahmad.com/blog.

Two days, one solo developer, one team of agents. The tool worked. I was tempted to announce it right there. I am glad I did not.

Shipping Software with AI Agents: The Audit That Saved the Release

Before any announcement, I handed Deslop to three independent audit teams and asked them to break it. Not to praise it — to break it. They came back with nine findings.

Nine. On a project I thought was done.

Some findings were small: messages that confused more than they explained, edge cases in a few rules. Some were serious: rules that fired on the wrong code, a threshold that let heavy slop pass as "mild," documentation that promised something the tool did not actually do. Every single one was real. None of them had been caught during the build, because the building agents were in "make it work" mode, and nobody was in "prove it works" mode.

Fixing all nine took another focused session, and it changed the tool in ways users can feel: clearer severity bands (clean, mild, heavy) so a score means something at a glance, tighter rules with fewer false alarms, and documentation that now describes exactly what the scanner checks — no more, no less. The version that shipped, v1.9.0, is a different tool from the one I nearly announced. Same 48 rules, much higher trust.

This is the part of shipping software with AI agents that nobody posts about. The build is the easy, photogenic half. The audit is where a demo becomes a tool. If you skip it, you are not shipping faster — you are shipping your bugs to your users and letting them do the audit for you, in public.

What the Agents Are Good At (and What They Are Not)

After this project, my mental model of AI agents is simple and I use it for every new build:

Agents are excellent at:

Turning a sharp brief into working code fast — the first version, the scaffolding, the boring plumbing.
Generating breadth: dozens of rules, test cases, and documentation drafts in one pass.
Refactoring on instruction: "make this one file," "add line numbers everywhere," "change the output format" — mechanical changes at speed.

Agents are bad at:

Knowing when they are done. An agent will declare victory the moment the code runs. Running is not done; reviewed is done.
Catching their own mistakes. The team that builds the rules will not be the team that finds the false positives. You need a second pair of eyes — human or agent — with a different job: break it, don't build it.
Judgement calls about scope. Left alone, agents add features. Left alone, a scanner becomes a platform. The brief is the only thing standing between a tool and a sprawl.

The practical rule I now follow: never let the builder audit its own work. A separate audit pass, with its own brief ("find bugs, rank them, show proof"), is a mandatory step in my workflow, not a nice-to-have. It costs one extra session. It saved this release.

My Solo Release Checklist (Steal This)

This is the checklist Deslop earned. I run it before announcing anything now:

[ ] One sharp brief first. Three hard constraints, written down, before any code.
[ ] Real users can run it in minutes. One command or one web page — no install saga, no config puzzle.
[ ] Claims are measured, not asserted. A benchmark, a test suite, or a before-and-after number behind every big claim.
[ ] An independent audit pass. A different agent team (or a careful human) whose only job is to break it, with findings ranked and fixed.
[ ] Docs match the tool. Every documented feature verified by running it, not by reading the code that was supposed to implement it.
[ ] One honest limitation, stated up front. For Deslop: it is a pattern scanner, not a design judge — it flags the fingerprints of generic AI design, it does not decide whether your design is good. Users trust a tool more when it tells them what it cannot do.
[ ] Announce only after the audit fixes ship. The version users meet first is the version they remember.

If you are a solo developer using AI agents, the temptation is always to announce at step two, when the demo works. Resist it. The gap between "works in my terminal" and "trustworthy for strangers" is exactly one audit wide.

What I Would Do Differently Next Time

Two things. First, I would order the audit earlier — after the core rules, not after the whole feature set — so fixes land before features pile on top of them. Second, I would write the honest limitation into the README from day one instead of adding it after the auditors asked for it. Limitations are not apologies; they are the reason people believe the rest of the document.

None of this makes me slower in any way that matters. Two days to build, one session to audit, and the result is a tool I can stand behind: open source, genuinely useful, and already published as a package other developers can install. The agents did not replace me as a developer. They replaced the empty hours — the scaffolding, the boilerplate, the first drafts — and left me the work that actually needs a human: deciding what to build, what "done" means, and whether it is good enough to put my name on.

If you are shipping solo with AI agents, try the audit step on your next project. Build it fast, then hand it to someone — or something — whose job is to break it. You will be annoyed by what they find. Your users will never know how close they came to finding it first.

Free Digital Classroom Tools: How I Run a Paperless Classroom on Zero Budget

Rehman Ahmad Chaudhry — Mon, 02 Nov 2026 07:17:29 +0000

I am a head teacher at a government primary school in rural Punjab, Pakistan. My school has no computer lab, no smart board, and no IT budget. What it does have is one old laptop, my phone, a second-hand projector a colleague lent me, and a free internet connection that works on good days.

With exactly those ingredients, I run a mostly paperless classroom. My students read their textbooks on screen, my lesson plans live in the cloud, my attendance and records sit in a spreadsheet, and parents get updates on WhatsApp instead of paper notes that never reach home. Nothing here cost a rupee in software.

This article is the honest version of how that works: the free digital classroom tools I actually use every day, the setup that took an afternoon, and the parts that still fail. If you teach in a school with a small budget — or no budget at all — you can copy this setup this week.

Why "Zero Budget" Is a Feature, Not an Excuse

Most "digital classroom" guides assume a smart board, a school management system, and a subscription for everything. That is not my reality, and it is not the reality of most teachers I know. When I stopped waiting for equipment that was never coming and started with what I already owned, three things changed:

I stopped buying software. Every tool below is free and open-source, or has a genuinely free tier that does the job. No trials that expire mid-term, no "premium" wall in front of a feature I need.
I stopped depending on one device. Because everything is free and cloud-based or portable, a lesson survives a dead laptop. I can run the same class from my phone if I have to.
I started saving hours, not just paper. The biggest win was never the paper. It was the evenings I got back when record-keeping stopped being a pile of registers.

The rule I follow now: if a tool needs a license, a subscription, or a powerful computer, it does not enter my classroom. Everything below passes that test.

The Free Digital Classroom Tools I Actually Use Every Day

1. Free textbooks, on screen, for every student

The foundation of the whole setup is that my students' books are already digital. The Punjab Curriculum and Textbook Board publishes official textbooks, and I keep the complete collection — every class, every subject — on my site at rehmanahmad.com/textbooks/. A student who forgot their book at home is no longer stuck; we open the same chapter on the projector or on a shared phone and carry on.

In class this looks simple, and that is the point. I open the chapter, project it, and read with the students instead of reading at them. When a child asks "sir, page 42?", I am already there. Parents use the same link at home, which means homework help no longer depends on whether the physical book survived the school bag.

2. A phone and a projector beat a smart board

I do not own a smart board, and I have stopped wanting one. A basic projector — borrowed, second-hand, or shared between classrooms — plus my phone covers 90% of what a smart board does in a primary classroom:

Display: the textbook chapter, a worksheet, a short educational video.
Write: I photograph the whiteboard after a lesson and share it with the class group, so the notes survive past the bell.
Record: a two-minute phone video of a student reading aloud is worth more for assessment than any worksheet.

The trick is to keep the chain short. Phone to projector, one cable, no adapters you will lose. If a setup takes more than two minutes, you will stop using it by Thursday. I know, because I did.

3. LibreOffice for every worksheet, test, and notice

Every document my school produces — worksheets, test papers, parent notices, the timetable — is made in LibreOffice Writer and Calc. It opens every Word and Excel file parents or the education office send me, and it costs nothing, which matters when a school has five computers and zero software budget.

My practical setup: one folder per class, one template for worksheets (school name, class, date, marks at the top), and a habit of saving everything as PDF before printing or sharing. A PDF looks the same on every phone, and in a school where parents read documents on phones, that consistency is the whole game. If you need a clean, free office suite for a classroom, LibreOffice is the one I point teachers to — you can grab it from filecobra.com/app/libreoffice-suite/.

4. A fast PDF reader for the books themselves

Textbook chapters are PDFs, and the default reader on an old laptop can turn opening a chapter into a thirty-second wait while thirty children lose focus. I use SumatraPDF — it is tiny, opens instantly, and does exactly one job well. For classroom use, "opens instantly" is a feature, not a detail: every second of loading is a second of attention you do not get back. You can find it at filecobra.com/app/sumatrapdf-reader/.

5. One spreadsheet instead of five registers

Attendance, test marks, homework completion, and fee-related notes used to live in separate paper registers. Now they live in one spreadsheet with one tab per purpose. The real win is not the spreadsheet itself — it is that I can search it. "How did Ahmed do in the last three tests?" used to mean flipping pages. Now it means one filter.

I keep a local copy and a cloud copy. The cloud copy is the one I check from my phone during a parent meeting; the local copy is the one that works when the internet does not. Syncing them is a Friday-afternoon habit, five minutes, and it has saved me more than once.

6. WhatsApp as the school notice board

Paper notes home fail. They get lost, rained on, or "forgotten" in bags. A class WhatsApp group reaches parents the same evening, and — crucially — parents can reply. A parent who could never visit the school in person can now ask about homework at 8 pm, and I can answer in one line.

Two rules keep the group usable: only school matters, and I post notices at fixed times (evening, once a day) instead of dripping messages all day. A group that buzzes constantly gets muted, and a muted group is worse than no group.

7. AI for lesson prep, with a human in charge

I use AI to draft lesson plans and generate practice questions, then I edit every word before it reaches a classroom. The AI gives me a first draft in minutes; my subject knowledge decides what stays. I wrote about that workflow in detail before — how AI cut my prep time roughly in half without handing my judgment to a machine — and the short version is: AI prepares, the teacher decides, the students get the teacher's version, never the raw output.

A Week in My Paperless Classroom

Here is what a normal week actually looks like, so you can see this is a routine, not a demo:

Monday morning: I open the week's chapters on the textbook site, download the PDFs I will need, and confirm the projector cable works. Ten minutes, once.
Daily: Attendance goes straight into the spreadsheet. The chapter is projected, not dictated. Homework goes to the WhatsApp group as a photo of the board plus one line of text.
Wednesday: Worksheet day. I adapt last term's LibreOffice template, change the questions, export to PDF, and share it. Printing happens only for tests.
Friday: Five minutes of syncing (local to cloud), a glance at the marks tab to spot any student sliding, and one message to parents about next week.

Nothing here is impressive on its own. Together, it is a classroom that keeps running when a book is forgotten, a register is full, or I am teaching from my phone because the laptop is being repaired.

What Still Does Not Work

Honesty matters more than a success story, so here are the failure points:

The internet fails. On a bad day, the cloud copy is unreachable and the projector shows nothing. That is why every lesson has a local PDF backup, and why I never plan a lesson that requires a live connection.
Not every parent is online. A small number of parents have no smartphone. For them, the paper note still exists — paperless is a direction, not a religion, and no child gets left out because their parent lacks a device.
Old hardware is slow. A ten-year-old laptop running a modern browser with ten tabs open is a patience test. I keep tabs to a minimum, close everything I am not using, and prefer lightweight tools (like SumatraPDF) over heavy ones for exactly this reason.
It needs one champion. If I am absent, the system wobbles, because I am the one who maintains it. I am fixing that slowly by teaching two colleagues the routine, one tool at a time.

Your Free Digital Classroom Tools Checklist

If you want to start this week, here is the order that worked for me:

[ ] Pick one class and one subject to go paperless first — not the whole school.
[ ] Bookmark the free textbook collection for your class: rehmanahmad.com/textbooks/
[ ] Install LibreOffice and one fast PDF reader on the computer you actually teach from.
[ ] Create one spreadsheet with tabs for attendance and marks; enter one week of real data before judging it.
[ ] Start one parent group with two rules: school matters only, notices once a day in the evening.
[ ] Keep a local backup of everything you need for tomorrow's lesson — never depend on the internet in class.
[ ] Teach one colleague one tool. A system one person holds is a system waiting to break.

You do not need permission, a grant, or new equipment to start. You need one afternoon, the tools above, and the willingness to run one paperless week and see what breaks. Fix that one thing, and run it again.

I write about shipping solo tools and teaching with technology on rehmanahmad.com/blog, and I collect the free classroom utilities I actually use on filecobra.com. If you try this setup, tell me which part broke first — that is usually the most useful feedback there is.

Trust But Verify: My Solo Developer AI Agent Workflow for Shipping Without Regrets

Rehman Ahmad Chaudhry — Sat, 31 Oct 2026 06:19:54 +0000

Trust But Verify: My Solo Developer AI Agent Workflow for Shipping Without Regrets

I am a head teacher by day and a solo developer by night, and my solo developer AI agent workflow runs almost entirely while I am asleep or at school. AI agents draft my articles, patch my websites, and queue my content — and that sentence should terrify any solo builder, because when you are the only human in the loop, there is nobody else to catch the mistake. I learned that the hard way, more than once. The workflow below is the one I use now: agents do the building, and I do the verifying. That split is the whole system.

This is not a theory post. Every rule here exists because I broke the opposite rule and paid for it in public, in broken deploys, or in hours of quiet repair work at midnight.

Why I Stopped Trusting the Word "Done"

The first lesson came from a deploy tool that told me everything was fine. A push helper reported "OK pushed," and I believed it. Days later, a routine check showed the remote repository did not contain the files at all — the helper had written to a wrong path, reported success, and moved on. Nothing had failed loudly. Nothing had failed at all, according to the tool. The work simply was not there.

That is the central danger of a solo developer AI agent workflow: agents report completion, not truth. A green checkmark means the step ran, not that the result landed where it should. A test command that passes can mean the tests ran, or it can mean only a comfortable subset ran. An agent that says "verified" may have verified its own output against its own assumptions, which is not verification at all.

So I changed one thing, and it changed everything: no agent verifies its own work. Verification is always a second, independent step — a different command, a different check, against the live system, not against the agent's memory of what it did. If the agent pushed a file, I check the remote tree. If the agent ran tests, I run the full suite. If the agent says a page is live, I open the live URL.

The Solo Developer AI Agent Workflow, in Five Steps

Here is the workflow, exactly as I run it on a normal night.

Step 1 — Write a brief a stranger could follow

Before any agent touches a task, I write a short brief: the outcome in one sentence, the constraints (budget, scope, what not to touch), and the check that will prove it worked. The check matters most. "Publish the app page" is not a brief. "Publish the app page, then confirm the live URL returns the new content" is. If I cannot state the check, I am not ready to delegate the task — I am just hoping.

A good brief also names the boundaries. Mine include a hard zero-spend rule on automation: no paid service gets switched on by an agent, ever. I batch small pushes to save automation minutes, and I never let an agent start a new task to fix a failed one without me seeing the failure first.

Step 2 — Build small, in one direction

Agents are brilliant at producing a lot of output quickly, and that is exactly the risk. A 500-line change at midnight is not progress; it is a haystack I will have to search at 1 a.m. when something breaks. So every task is scoped to the smallest change that is still useful: one page, one feature, one batch of related fixes. Big work gets cut into small, separately verifiable pieces, each with its own check.

I also keep one direction of travel per task. An agent fixing a bug does not also "improve" three nearby files. Scope creep from an agent looks like helpfulness, and it is how a clean fix turns into a broken deploy. Anything else it spots goes in the log for tomorrow, not into tonight's change.

Step 3 — Verify against the live system, never the report

This is the step most solo builders skip, and it is the entire article in one sentence. After the work, I verify against the real thing:

After a push, I fetch the remote tree and confirm the exact paths are present. A helper's success message is not evidence; the remote tree is.
After a test run, I run the full suite — library tests and integration tests — because I once watched a builder report a green suite that had only run the easy half while dozens of integration tests were failing quietly underneath.
After a content publish, I open the live URL and read the page, including the parts I did not write. A page that renders is not a page that is correct.

Each check takes minutes. Each skipped check has cost me hours. That arithmetic is why this step is non-negotiable, even on tired nights.

Step 4 — Ship in batches, on a schedule I control

Solo shipping is a pacing problem as much as a technical one. I batch related changes into single deploys instead of firing off a deploy per fix, and I keep publishing on a schedule — a few posts a week, not a flood. Flooding helps nobody: readers cannot keep up, platforms get suspicious of bursts, and every extra publish is another chance for an unverified mistake to go live.

Scheduling also protects the human gate: work built at night gets reviewed in daylight before it goes public. Nothing in my system publishes itself straight from an agent's hands to the public internet.

Step 5 — Log it, or it never happened

Every completed task gets one line in a log: date, what shipped, where it lives. That log is how I avoid repeating topics, re-fixing fixed bugs, and re-approving work I already approved — and how I answer the only question that matters at month's end: what actually shipped? Agents forget. Logs do not.

The Green Test Suite That Wasn't

Let me make the testing lesson concrete, because it is the one I see other solo builders repeat most. A builder on one of my projects reported a green test run and moved on. When I ran the suite independently, the picture was different: the builder had run only the library tests, while the integration tests — the ones that exercise the real user flows — were failing in large numbers. The report was honest as far as it went. It just did not go far enough.

The fix became a rule I now apply to every project: the definition of "tests pass" is written in the brief, and it means the full suite, every time, run by someone — or some step — other than the one that wrote the code. A partial run is reported as a partial run, never as a pass. If your agent tells you tests pass, ask one question: which tests? If the answer is vague, the suite has not passed yet.

The same logic applies to content. A draft that reads well is not a draft that is accurate. Links get clicked, facts get checked against the source, and every element the brief specified gets ticked off before anything is presented as finished.

Solo Developer AI Agent Workflow: The Verification Checklist

Here is the checklist I run before anything ships, whether it is code, a page, or a post. Steal it wholesale — it is short on purpose:

Remote truth: is the change actually present in the live system (remote tree, live URL, published page), confirmed by fetching it fresh?
Full suite: did the complete test set run, including integration tests, not just the convenient subset?
Scope check: did the change touch only what the brief asked for, with nothing extra smuggled in?
Human read: have I personally read the final version — the page, the post, the diff — at least once, end to end?
Reversibility: if this is wrong, can I undo it in minutes? If not, it ships smaller or not at all.
Log entry: is it written down, with the date and the link, so future me can find it?

Six checks, a few minutes each. I have never regretted running them. I have regretted skipping every single one at least once.

What the Human Gate Is Actually For

People hear "human in the loop" and picture a manager approving every line, which sounds like the opposite of automation. In a solo developer AI agent workflow, the human gate is narrower and more valuable than that. Agents handle volume: drafting, formatting, repetitive fixes, research, scheduling. I handle judgment: is this true, is this safe, is this mine to publish, does this match what I actually want to say?

That division is why I keep drafts as drafts until I have read them, why no post goes live on an agent's word alone, and why my publishing rule is simple: the agent proposes, I dispose. A one-word approval from me is enough to move — I do not want bureaucracy either — but that one word comes after I have looked, not before. Automation without a gate is not leverage; it is just faster mistakes.

There is a second, quieter benefit. Verifying a change teaches me what my agents did, so I can brief the next task better. Builders who fully hand off stop understanding their own systems, and then they cannot fix them when — not if — something goes wrong. The gate is how I stay the developer of my own projects instead of a bystander to them.

The Bottom Line

A solo developer AI agent workflow does not fail because the agents are bad. Mine are good — they let a teacher with a full-time job run a textbooks library, a software site, and a publishing schedule that would have been impossible alone a few years ago. You can see the results in the free Punjab textbooks library I keep at rehmanahmad.com/textbooks, and in the free, verified Windows software I publish at filecobra.com. The workflow fails when "done" stops meaning "verified."

So here is my bargain, and I recommend it to any solo builder: let agents do the building, keep the verifying for yourself, write the check into the brief before the work starts, and never accept a success message as evidence. Ship small, ship on a schedule, log everything, and keep one human gate between your agents and the public.

AI Lesson Planning for Teachers: How I Cut Prep Time in Half Without Losing the Human Touch

Rehman Ahmad Chaudhry — Sat, 31 Oct 2026 06:18:36 +0000

AI Lesson Planning for Teachers: How I Cut Prep Time in Half Without Losing the Human Touch

I am a head teacher at a government primary school in Punjab, and for years my evenings looked the same: a stack of notebooks, a syllabus outline, and lesson plans written by hand long after the school day ended. When I first tried AI lesson planning for teachers, I expected a gimmick. What I got instead was the single biggest change to my working week in years — my preparation time roughly halved, while my lessons actually got better. The catch, and it matters, is that the AI does the drafting and I do the teaching. Get that order backwards and you get slick-looking plans that fall apart in front of thirty children.

This is the honest version: the workflow I use, the prompts that work, and the guardrails that keep the human in charge.

What AI Lesson Planning for Teachers Actually Looks Like in a Real Classroom

Forget the marketing version where you type one sentence and a perfect lesson appears. Real AI lesson planning for teachers looks like this: you give the AI your topic, your class level, your time limit, and what your students already know, and it hands back a structured first draft — objectives, a timed sequence, questions, and a short activity. Then you do the part no model can do: you cross out what won't work for your children, you fix the examples so they match your students' lives, and you add the one story or question that makes the class pay attention.

In my school, a typical lesson is 35 to 40 minutes with a large class and limited materials. An AI that doesn't know that will happily plan a lesson needing a projector, printed worksheets for every child, and group work in sixes. So the first skill isn't prompting. It's knowing your constraints well enough to state them: class size, time, available materials, language level, and what the textbook actually covers. The AI is only as grounded as the brief you give it.

One more honest point: I teach from the Punjab textbooks, and the AI does not know my exact chapter — only the general topic. That gap is where a careless teacher gets into trouble, accepting a plan with the wrong scope or examples. My rule: the textbook is the syllabus, the AI is the assistant. Every plan gets checked against the chapter before it reaches the classroom.

My 30-Minute AI Lesson Planning Workflow

Here is the full workflow, timed honestly. It replaced an evening routine that used to take over an hour.

Step 1 — Pick one clear objective (3 minutes). Not "teach fractions" but "by the end of the lesson, students can shade and name one-half, one-third, and one-quarter of a shape." One objective, stated in student language. If you can't write it in one sentence, the AI can't plan around it either.

Step 2 — Write the brief (5 minutes). I paste the same structure every time: topic, class, time available, what students already know, materials I actually have (chalkboard, chart paper, the textbook), and one constraint ("no printing", "mixed ability class", "Urdu-medium explanations where needed"). This brief is the whole secret. A vague brief gives you a generic lesson; a specific brief gives you a usable one.

Step 3 — Generate the first draft (2 minutes). I ask for a timed plan: a 5-minute hook, 15 minutes of teaching, 10 minutes of practice, and a 5-minute check. I also ask for three questions at different difficulty levels and one activity that needs no materials beyond the board. The draft is never the final plan. It is raw material.

Step 4 — Edit like a teacher, not an editor (15 minutes). This is where the real work happens. I replace generic examples with local ones — market prices, cricket scores, the school garden — because children remember what they recognize. I delete any activity I can't run with my class size, check every fact and worked example against the textbook, and add the opening question I know will hook this particular class, because no model knows my students.

Step 5 — Make the exit ticket (5 minutes). Every lesson ends with one quick check: two questions on the board, answered on slates or in notebooks, that tell me before the bell whether the objective landed. If I skip this step, I am guessing about learning. The AI drafts the questions; I pick the ones that actually test the objective.

Total: about 30 minutes.

The Prompt Pattern That Keeps Lessons Honest

Most bad AI lessons come from one-prompt thinking: one long prompt, one accepted answer. A three-pass pattern fixes most of the quality problems people blame on the AI.

Pass 1 — Draft. "Plan a 35-minute lesson on [topic] for class [X]. Students already know [Y]. Materials: chalkboard and textbook only. Give me timed sections, three questions at easy, medium, and hard levels, and one no-material activity."

Pass 2 — Localize. "Rewrite the examples using everyday life in a Pakistani village school: market shopping, farming, cricket, family routines. Replace any activity that needs printing or a projector."

Pass 3 — Challenge. "Now find the weak points in this plan: where will students get confused, which step is too fast for a mixed-ability class, and what question checks understanding after the main teaching?" That third pass is the most valuable one — it surfaces the exact spots where a real class will struggle, and trains you to spot them yourself over time.

One warning from experience: never let the AI write your assessment questions unchecked. Models produce confident-sounding questions with wrong answers, especially in maths and science. Every question gets solved by me before it reaches the students. That single habit is the difference between using AI and being used by it.

AI Lesson Planning for Teachers: The Guardrails I Never Skip

AI lesson planning for teachers only stays honest if you hold a few lines firm. These are mine, learned the hard way:

The textbook decides the scope. If the AI's plan covers something outside the chapter, it gets cut, however interesting it looks. Exam alignment and student confidence both depend on this.
Every fact gets verified. Dates, science facts, worked maths examples, spellings — all checked before class. I once caught a wrong fraction example in a draft five minutes before the lesson. That was the day this rule became non-negotiable.
No student data goes into the AI. No names, no marks, no photos, no personal details. I describe the class in general terms ("mixed ability, 30+ students") and nothing more. This is a privacy line, not a preference.
The AI never writes the final word to students. Worksheets, notes, and homework pass through my eyes first. Anything the children read should sound like their teacher, not like a chatbot.
One new thing per lesson. If the AI suggests a new method and a new activity and a new grouping in the same lesson, I keep one and drop the rest. Classrooms punish overload faster than any reviewer will.

These guardrails are why my prep time halved instead of disappearing. The AI removed the blank-page work — structuring, sequencing, drafting questions — and left the judgment work to me. That is why the lessons got better, not just faster.

A Real Example: One Lesson, Before and After

Take a class 4 maths lesson on fractions, a topic where children either click or drown. My old hand-written plan was: introduce the term, draw two shapes on the board, do three textbook exercises. Serviceable, forgettable.

The AI-assisted version kept the same objective but changed the shape of the lesson. The hook became a real question: "If four friends share two rotis equally, how much does each get?" — something every child in my class has actually argued about. The teaching section used folding chart paper instead of just drawing, so children could see and hold the halves and quarters. Practice became a quick market game: "A shopkeeper sells half a kilo of sugar, then a quarter — how much is left?" And the exit ticket was two questions, one easy and one that catches the classic mistake of confusing the number of pieces with the size of each piece.

Nothing in that lesson required classroom technology. The AI contributed structure and variety; the classroom contributed the rotis, the market, and the paper-folding. AI lesson planning for teachers works best when the technology stays in the preparation room and the classroom stays human.

Your First-Week Checklist

If you want to try this yourself, here is the honest starter plan — one week, no overwhelm:

Pick ONE subject and ONE class to experiment with. Don't AI-plan everything at once.
Write your brief template once (topic, class, time, prior knowledge, materials, constraints) and reuse it every day.
Run the three-pass pattern: draft, localize, challenge.
Check every fact and every worked example against the textbook before class.
End every lesson with a two-question exit ticket, and keep the results — they tell you within a week whether the plans are actually working.
Steal the good parts: when a hook or activity lands well, save it in a personal bank for next year. After a term, that bank is worth more than any prompt collection.

A practical note for fellow Pakistani teachers: the free Punjab textbooks are all available online now, so you can read the chapter on your phone while drafting. I keep the full library linked from the Punjab textbooks hub on rehmanahmad.com, and I grab classroom utilities like PDF tools from filecobra.com when I need a printable for class. The tools support the teaching; they never replace it.

The Bottom Line

AI lesson planning for teachers is not about letting a machine teach. It is about letting a machine do the drafting so the teacher can do the teaching — better prepared, less exhausted, with the evening back. My prep time roughly halved, my lessons got more varied, and my students got hooks I would not have invented on a tired evening with a blank page.

But the bargain only holds if you keep the guardrails: textbook as syllabus, every fact verified, no student data shared, and your judgment on every page that reaches a child. Do that, and the AI becomes what it should have been all along — a tireless assistant to a teacher who is still, unmistakably, in charge.

If you try this workflow, start with one lesson this week and judge it by the exit ticket, not by how impressive the plan looked on screen.

The Rs 20 Pencil Bank: How My Class 2 Stopped Losing Pencils Every Day

Rehman Ahmad Chaudhry — Mon, 26 Oct 2026 04:49:11 +0000

The Rs 20 Pencil Bank: How My Class 2 Stopped Losing Pencils Every Day

From **The Head Teacher's Diary* — real stories from a primary-school classroom in Yazman, Pakistan. Entry No. 1.*

Every morning, the same complaints waited for me at the classroom door.

A pencil was lost. An eraser had disappeared. A sharpener was nowhere to be found. And behind those small complaints stood a bigger problem: the parents of my students are poor. A pencil costs little, but when a child loses stationery almost every day, "little" stops being little. Children were taking money from home daily for replacements — and at home, that money came out of an already tight budget.

I am the head teacher of my primary school, and also the in-charge of Class 2. So this was my problem to solve, twice over.

The Problem Was Not the Children

The easy response is to scold. "You are careless. Look after your things." Every teacher has said it; I have said it myself.

But watch the situation honestly: a six or seven year old, a full day of lessons, playtime, bags being opened and closed a dozen times — and no place, no system, no routine for keeping three small items safe. We were expecting small children to protect stationery with nothing but memory and fear of scolding.

Teachers everywhere know this as the problem of disappearing pencils — and it is rarely solved by buying more pencils.

The children were not the problem. The absence of a system was.

So instead of another lecture, I built a system.

Every Child Gives Rs 20 — Once

I told the class: every child will bring Rs 20. Not every day. Just once, into one shared collection.

From that collection, we bought pencils, erasers and sharpeners for the whole class — together with a small bin to keep them in. From that day, the stationery stopped belonging to individual children. It belonged to the class — community supplies, owned by everyone and cared for by everyone.

Then came the part that made it work: two students are on duty every day.

In the morning, the duty students hand out a pencil, an eraser and a sharpener to every child.
At closing time, they collect everything back from everyone and place it in the bin.
The next morning, the same routine begins again.

That is the whole system. No register, no software, no expense beyond the first collection.

The whole system in one picture: one red bin, and every pencil, eraser, sharpener and ruler belongs to the class — not to any one child.

What Changed

The results surprised even me.

A pencil now lasts about two weeks. Before the pencil bank, a pencil could vanish the same day it was bought. Now the same pencil keeps coming back to the bin every evening, so it survives until it is genuinely used up.

The daily money stopped. Earlier, children asked for money at home almost every day for a lost item. Now the collection happens once, and the next one is needed only after roughly two weeks. For a poor household, removing a daily small expense is not a small thing.

The complaints ended. The morning queue of lost-pencils simply disappeared, because there is nothing left to lose — everything returns to the bin.

And something less visible grew: responsibility. The duty students take their job seriously. Collecting from everyone, missing no one, keeping the bin in order — that is trust, and children rise to meet trust. The whole class cares for the stationery now, because it is ours. A personal pencil got lost. The class pencil gets protected.

Why It Works

Looking back, three things made the difference:

Ownership changed. What belongs to everyone is watched by everyone.
The routine is daily and visible. Out in the morning, back at closing. Nothing depends on a child's memory at home.
The cost is shared and tiny. Rs 20, once in a while, never burdens one family — and no child is singled out, because everyone is an equal shareholder in the bank.

Try It in Your Classroom

If your class has the same morning complaints, the recipe is simple:

Fix a small, equal contribution every child can afford — for us it was Rs 20.
Buy the stationery for the whole class from the pooled money, plus one box or bin.
Put two students on duty daily — hand out in the morning, collect everything at closing.
Rotate the duty so every child serves.
Keep the collection and spending open and simple; the class should always know where the money went.

You do not need permission, a budget line, or an NGO. You need Rs 20 per child and the decision to fix the system instead of the child.

The Lesson I Took Home

Teaching is full of problems we blame on children: lost things, forgotten things, unfinished things. This small experiment taught me to ask a different question first — is there a system, or am I expecting a seven year old to be one?

A pencil bank will not transform education. But it turned a daily complaint into a daily lesson in sharing, duty and care — and it costs less than the price of the pencils we were losing.

If you try it in your school, I would genuinely like to hear how it went.

— Rahman Ahmad Chaudhary, Head Teacher, GPS 117 DB(BJ), Yazman. More entries from **The Head Teacher's Diary* are on the way.*

FAQs

How do you solve the problem of disappearing pencils in the classroom?
Stop treating each pencil as private property. Pool a tiny equal contribution (we used Rs 20 per child), buy stationery for the whole class, store it in one bin, and have two duty students hand it out every morning and collect it back at closing. When stationery belongs to the class and returns to one place daily, losses almost disappear.

How do you manage classroom stationery when parents cannot afford supplies?
Spread the cost thin and share it. Our pencil bank runs on Rs 20 per child, collected roughly once every two weeks — far cheaper for poor families than replacing a lost pencil, eraser or sharpener every other day, and no child is singled out because everyone contributes equally.

What is a class pencil bank?
A pencil bank is a simple classroom system: stationery is bought from a small pooled contribution, owned by the class, kept in a shared bin, and distributed and collected daily by students on duty. In my Class 2 it stretched one pencil's life to about two weeks and ended daily lost-stationery complaints.

5 Roles, 0 Standups: How I Run Autonomous AI Agents as a Solo Developer

Rehman Ahmad Chaudhry — Thu, 22 Oct 2026 09:25:54 +0000

5 Roles, 0 Standups: How I Run Autonomous AI Agents as a Solo Developer

I'm a head teacher by day and a developer by night. Two websites, a 13-task engineering project, a daily content engine, a library of 251 textbooks, and about ten other threads — all run by one person who starts working when his school day ends. The only way the math works is autonomous AI agents: a small fleet of them, running on schedules and briefs I give them, while I sleep, teach, or drink my third cup of tea.

This isn't theory. Over the past month my agents shipped a 13-sprint software project, published two dozen videos, drafted this very article while I was asleep, and caught bugs no human reviewer had seen. Here's the honest version of how I run them — the structure, the tools, the mistakes, and the checklist to build your own.

Why One Person Needed a Team of Autonomous AI Agents

Six months ago I was doing everything myself: writing code at midnight, publishing posts, fixing SEO, reviewing pull requests at 2 AM. The output was one thing per week if I was lucky, and every task needed me present and awake for it to move.

The breaking point wasn't ambition — it was sleep. I realized that if a task needed my eyes at every step, it would never get done consistently. So I flipped the question: instead of "how do I do more things," I asked "which things can I design so they happen without me, with only a yes-or-no from me at the gates that matter?"

That's the whole philosophy behind running autonomous AI agents as a solo developer. The agents don't assist me — they own work streams. I define the task, the quality bar, and the approval gates. They do everything between. Some of my best work now happens while I'm in a classroom.

The 5 Roles in My Autonomous AI Agent Team

I gave my agents real roles, not just prompts. Roles create accountability — when a bug lands, I know which role failed and which rule of its brief needs fixing. Here are the five:

The PM / Coordinator. This agent owns the plan and the schedule. When I say "ship the next phase," the coordinator breaks it into numbered tasks, dispatches them, collects the results, and reports back with what shipped and what's blocked. It never touches code — it manages. This separation matters: an agent that plans its own code tends to quietly change the plan when the code gets hard.

The Backend. This agent owns server logic, APIs, and data work. It has one hard rule I enforce everywhere: it must follow the task's own documentation first, and it must verify every claim against real evidence, not echoed responses. That rule exists because I once trusted an API response that said "pushed successfully" — the commit existed only on my machine. Never again. Backend agents prove with a fresh read of the remote state, or it didn't happen.

The Frontend. This agent owns UI and pages. Its standing order: render it and look at the actual screenshot before declaring victory. A label in a mockup is never proof of a working control — my Frontend once shipped a redesign where a "select pages" filter disappeared entirely because nobody checked that its function survived, not just its pixels.

The Designer. This agent owns visual assets — banners, covers, thumbnails. Its rule is simple: taste calls get a sample first, never a full build. Generating twelve banners costs ten minutes; generating them after I approve a sample costs one.

The QA. This is the role people skip, and it's the one that saves me most. The QA agent re-runs the full test suite independently — never trusting a builder's "tests green," because a builder once ran only the unit tests while 58 integration tests were failing. QA's gate is the only thing standing between my excitement and my production site.

Five roles, zero standups. Each one inherits my context, works in the background, and reports when it's done. I read the reports the way a manager reads status updates — because at this point, that's what I am.

How Autonomous AI Agents Changed My Shipping Speed

The biggest unlock wasn't any single agent — it was parallelism plus schedules. Three patterns do almost all the heavy lifting:

Pattern 1: Parallel fan-out. When a piece of work splits naturally, I dispatch one agent per piece in the same turn, instead of doing them one after another. The Sindh textbook rollout — 13 classes, ~200 books — was specified as "all of it in one day" because parallel agents made that a real schedule, not a fantasy. Sequencing is the silent killer of solo developers; agents let you pay the coordination cost once and reap the concurrency forever.

Pattern 2: Scheduled recurrence. My content engine is almost entirely cron jobs: two trending posts a day, a repo-spotlight thread, a daily reel, three blog drafts a week — including this one. Each run produces a draft; nothing publishes without my exact-copy approval. The standing rule is that approval gates are the contract: automation drafts, I approve, schedulers publish. The result is a daily output cadence I could never sustain manually.

Pattern 3: The review loop across models. My AI stack isn't one tool — it's a pipeline. Claude does the daily operating work (code, schedules, content). ChatGPT and Codex handle code directions and review through a GitHub-issue loop: my operator implements, Codex reviews, the issue tracks the disagreement until it's resolved. Gemini handles Workspace-native help, and Antigravity is the agentic IDE for deeper coding sessions. None of them approves their own homework.

Put together, one tired teacher at night out-ships what used to take me a week — because the fleet keeps working through my school day.

5 Lessons From Running Autonomous AI Agents

1. Verification is the real product. Every failure I've had with agents traces back to trusting a claim instead of checking state. An API that echoed "OK" while the file was untouched. A test run that covered half the suite. A screenshot described in words instead of shown. My universal rule now: the work is done only when a result says it finished — a queued, started, or "ringing" status means it started, nothing more. If your agents feel unreliable, you probably don't have an agent problem. You have a verification problem.

2. Briefs beat prompts. A one-line prompt produces a one-line effort. My task briefs are full contracts: the outcome in the user's terms, the choices already made, the limits they set, and only the context the work needs. Long briefs sound slow, but they're the difference between an agent that needs me hovering and one I can walk away from for six hours.

3. Never change account-level state without explicit approval. My agents have maximum autonomy on one condition: they never touch account-level settings — appearance modes, profile fields, privacy, tokens. One of my earliest hard lessons was that convenience automation drifts toward touching things the user never asked it to. Now the boundary is written into every standing instruction: reversible internal work is free; anything outward-facing, persistent, or hard to undo gets named and approved first.

4. Dedup everything, constantly. Parallel agents are great at duplicating work — two reels on the same tool in the same day, two posts mining the same repo. I keep logs (topic logs, slot logs, seen-lists) and every run checks them before building. The duplicate that hurts most is the one that goes live: same tool twice, an hour apart, and the audience watches the second one for two seconds. Coordination is a feature you build, not a property you assume.

5. Keep the human gate where judgment lives. My automation drafts everything — articles, captions, code, even this checklist — but exact-copy approval stays mine. Not because agents are bad writers, but because my name goes on it. The split that works: agents do the 90% that's craft; I spend my 10% on the judgment that makes it mine. Nobody follows a brand that's fully automated. They follow a person who happens to ship at machine speed.

Your First Weekend With Autonomous AI Agents: A Checklist

If you want to try this without my whole setup, here's the minimal version that actually taught me the pattern:

[ ] Pick one recurring task you do every week (a status report, a content draft, a backup check). Not code yet — something low-risk.
[ ] Write the brief as a contract: outcome, quality bar, where it runs, what "done" proves (screenshot, link, test result — never a claim).
[ ] Split roles once: one agent plans and dispatches, a second one does the work, a third one verifies. Even two agents (worker + checker) beats one clever prompt.
[ ] Add a verification step that reads real state — open the page, re-run the test, fetch the file. Echoed "success" responses are the #1 failure mode.
[ ] Schedule it, then ignore it for a week. Read only the reports. Every time you had to intervene, that's a line your brief was missing.
[ ] Keep a lessons file. Every failure becomes one rule. My operating manual started empty; now it's the most valuable document I own.

Then — and only then — add a second stream. The fleet grows one verified agent at a time.

Where This Is Going

This article itself came out of the engine it describes: a scheduled run, a topic from the rotation, a draft built while I was asleep, a human reading it with fresh eyes before it ever goes live. I document what works at rehmanahmad.com — the blog is my engineering notebook, open to anyone — and everything I ship for download lives at filecobra.com, where the same verification philosophy runs on every file: hash-checked, signature-verified, fail-closed.

The honest summary after a month of running this way: I'm still one person. I still sleep seven hours and teach all morning. But my output looks like a small studio — because it is one, just distributed across silicon instead of desks.

And a question for you: if you could hand one weekly task to an agent tonight, which one would it be — and what's the first rule in its brief? I read every comment. Teacher by day, developer by night — and the agents cover the graveyard shift.

Every Punjab Textbook, Online and Free: How I Put 251 Books in Every Student's Pocket

Rehman Ahmad Chaudhry — Mon, 19 Oct 2026 08:44:34 +0000

Every Punjab Textbook, Online and Free: How I Put 251 Books in Every Student's Pocket

This week I finished something I'd been dreaming about for years: the entire Punjab textbooks online library is now live on my website — 251 books, every class from pre-primary to 12th grade, free for every student, teacher, and parent in Pakistan to read, download, and learn from.

I'm a head teacher at a government primary school in Yazman, Punjab. For eight years I've watched kids walk to school without a single textbook in their bag — not because they're careless, but because books get lost, torn, shared between three siblings, or were never issued at all. But their parents almost always have a smartphone. So I asked myself a simple question: if the phone is already in the house, why isn't the textbook?

The answer is now my free Punjab textbooks library. Here's the full story — why raw PDFs were never enough, what I built instead, and what I learned digitizing 251 books as a teacher who codes at night.

Why Reading Punjab Textbooks Online Needed a Real Library

The official PDFs already existed. The Punjab Curriculum and Textbook Board's E&SE page (PECTAA) hosts them on Google Drive. So why did I spend weeks building a library around them?

Because "the PDF exists somewhere" and "a student can actually read it" are two very different things. Here's what raw textbook PDFs look like in practice:

No navigation. A 200-page scanned PDF has no table of contents. Finding Chapter 3 of Science means scrolling past 60 pages of blurry scans on a 6-inch screen.
Brutal file sizes. Some of these PDFs are 100MB+. On mobile data in a village, that download dies halfway — twice.
No discoverability. The board's Drive folders are organized for bureaucrats, not for a Class 7 student looking for "Waqfiyat-e-Aama."
No learning layer. A PDF is a photocopy. Nobody asks questions about a photocopy, nobody tests you on it, nobody tells you the tricky part of Chapter 4.

I didn't want a download dump. I wanted a library — the kind of page I'd send a parent on WhatsApp and know they'd figure it out in ten seconds. So that's what I built: the Punjab textbooks library at rehmanahmad.com/textbooks.

Building the Punjab Textbooks Online Library

Thirteen grade levels. 251 books. Every single book page carries more than a download button — it carries everything a student needs to actually study the book:

Real chapter tables of contents. I typed out the chapter lists for every book from the official PDFs — including scanned ones where I had to read the fehrist (table of contents) page visually. Open the Class 8 History book and you see all 5 chapters listed, clickable, in seconds.

The "Online Parho" reader. Instead of forcing a 150MB download, each book opens in a continuous-scroll reader right in the browser: lazy page rendering (a 200-page book loads like a webpage, not like a freight train), zoom for small text, go-to-page, and fullscreen mode that turns any classroom projector into a smart board.

A chapter quiz game on every book. Five multiple-choice questions, instant score, one-tap restart. I built it because my students beg to try again when they miss two — and "begging to restudy" is the closest thing to magic a teacher gets.

Teacher tips and FAQs. Every page has practical notes written from real classroom experience — which chapters trip students up, how to pace them — plus FAQs with proper search-engine markup so parents googling "Class 9 Biology chapters" actually land on the right page.

Here's the full rollout, all verified live this week:

Grade	Books
Pre-primary	4
Class 1–2	7 each
Class 3–5	7, 8, 8
Class 6–8	19, 21, 20
Class 9–10	55, 47
Class 11–12	20, 28

Class 9 alone is 55 books — core subjects plus the technical stream. For 11th and 12th, the official PECTAA page doesn't list books at all, so I sourced them from official PCTB mirrors and ran every file through the same verification pipeline: official list match, real chapter extraction, cover art, build, and a live check before it counted as done.

How to Read Punjab Textbooks Online: A 3-Step Walkthrough

Using it is deliberately boring — three taps and you're reading:

Pick your class. Open rehmanahmad.com/textbooks and tap your class. Pre-primary through 12th, all on one hub page.
Pick your book. Every class page shows each book with its cover, subject, and medium (English/Urdu). Tap one — say Class 10 Biology — and you get the full chapter list, teacher tips, and FAQs.
Read, quiz, or download. Read in the Online Parho reader (works on any phone browser, no app needed), play the chapter quiz after the lesson, or grab the official PDF download for offline study.

That's the whole pitch. No login, no paywall, no app install — because in my school, "create an account first" is where usage goes to die.

5 Lessons From Digitizing 251 Textbooks

1. The table of contents matters more than the PDF. Nobody on mobile data downloads a 150MB file to find Chapter 3. The single most-used feature of the whole library is the chapter list. Navigation is the product.

2. Mobile-first isn't a slogan — it's the only device that exists. My students don't have laptops. Every design decision assumed a cracked-screen Android phone on 4G: lazy rendering, compressed cover thumbnails, no heavy JavaScript frameworks on the reader.

3. Quizzes turn reading into a game. I added the 5-question quiz as a nice extra. It became the headline feature. Kids who would never "revise Chapter 4" will happily play "the Chapter 4 game" four times to beat their score. Gamification works when it's five minutes and zero setup.

4. Use official sources only — and say so. Every book is matched against the official board lists, with attribution. When the official page had gaps (Classes 11–12), I used official PCTB mirrors rather than random uploads, and I say that openly on the site. In education, trust is the whole currency.

5. No thin pages, ever. My rule for everything I publish: a page with a download button and nothing else helps nobody. Every book page carries real, original content — chapter lists, teacher tips, FAQs. A library of 251 stubs would have been faster to build and worthless to use.

The 5-Minute Classroom Checklist

If you're a teacher, here's exactly how to use the library in class this week:

[ ] Open your class page on the classroom tablet or projector-connected phone
[ ] Open the book's Online Parho reader in fullscreen — instant smart board
[ ] Use zoom on diagrams and maps instead of squinting at a printed copy
[ ] After the lesson, run the chapter quiz on the big screen — let the class vote on answers
[ ] Share the book's link in the parents' WhatsApp group so kids can re-read at home

And a side note for the computer-lab side of school life: for the Windows tools my lab runs on — PDF readers, document tools, classroom utilities — I grab verified free software from filecobra.com, the free-software download directory I built and run with hash-and-signature verification on every file. Same philosophy as the library: free, safe, no junk.

What's Next: Sindh, Then the Rest of the Country

Punjab was Phase 1. Phase 2 is Sindh — the STBB board's own ebook portal already hosts 194+ books from ECCE through Class 12 in Sindhi, Urdu, and English, so the groundwork exists. Balochistan comes after that. The goal is simple and, honestly, a little stubborn: every textbook in Pakistan, online, free, readable on the cheapest phone in the village.

If you're a teacher, a parent, or a student: bookmark the library and share it with one person who needs it. That's how this grows.

And a question for you: which board should I digitize next — and what's the one feature that would make your students actually open their books? I read every comment. Teacher by day, developer by night — this is what the nights are for.

PhotoCraft: The 65K-Star Open-Source Photoshop Alternative Built in Rus

Rehman Ahmad Chaudhry — Sat, 17 Oct 2026 08:52:48 +0000

A Photoshop alternative just crossed 65,000 GitHub stars. It's free, open-source (MIT/Apache 2.0), written in Rust, works fully offline — and it ships with CLI and MCP interfaces so AI agents can drive it. Here's why developers should be paying attention.

The numbers first

PhotoCraft, built by Storytold as part of the ArtCraft suite, is a raster image editor positioned directly against Adobe Photoshop. Layers, masks, selections, adjustment layers, filters, color grading — the full day-to-day editing toolkit, in a workspace that feels instantly familiar to anyone coming from Creative Cloud.

The part that made me look twice: 65,000+ stars on GitHub, earned largely by word of mouth across Hacker News, YouTube, and X. That's not marketing. That's developers voting with their stars.

Why Rust matters here

Image editors live and die on brush latency and filter throughput. PhotoCraft's Rust foundation is doing real work:

Responsive brushes on large canvases — no GC pauses, no runtime overhead in the hot path
Minimal memory footprint — native binary, no Electron shell eating 500MB before you open a file
Fearless concurrency for filter pipelines — Rust's ownership model is genuinely well-suited to parallel pixel processing

This is the same performance story we've seen from tools like Ripgrep and Deno's early days: systems languages winning where latency is user-visible. An image editor is one of the purest examples — every millisecond of brush lag is felt in the hand.

Offline-first, zero telemetry

Everything runs locally. No account, no cloud round-trip, no "sign in to continue." Your files never leave your machine.

For developers, the license terms matter as much as the features: MIT/Apache 2.0, source public. No acquisition, price hike, or shutdown can ever take the tool away. Compare that with the subscription treadmill — Photoshop alone costs more per year than most developers' entire tool budget, and you own nothing at the end.

Agent-ready: CLI + MCP interfaces

This is the part most coverage misses. PhotoCraft is designed agent-ready, with CLI and MCP (Model Context Protocol) interfaces for automation. That means:

Batch operations chain together from scripts
AI agents can drive editing workflows programmatically
Repetitive studio tasks (resize, convert, watermark hundreds of assets) become one-liners

An image editor with a machine interface is a quiet superpower. If you're building asset pipelines, this deserves a look.

It's not alone — it's 1 of 10

PhotoCraft is the flagship of the ArtCraft suite: 10 free, open-source, Rust-built applications covering 7 Adobe alternatives (photo, vector, video, light/photo-AI, PDF, effects, design) plus 3 Office alternatives (spreadsheet, documents, presentations). Same philosophy across all of them: free forever, offline, no telemetry.

Where to get it

I maintain a verified download page with the current version, SHA-256 checksums, and the full hands-on review:

Download PhotoCraft (verified) on FileCobra

Every binary there is hash-verified and signature-checked before it goes live — the same pipeline I wrote about in my CoderLegion article on binary verification.

What's your take? Is Rust the right call for creative tools, or does the ecosystem still belong to C++? And have you tried driving a desktop app through MCP yet? Curious what people are building.

Our signature verifier passed CI by never running

Rehman Ahmad Chaudhry — Thu, 03 Sep 2026 15:27:55 +0000

We build a catalogue of Windows and Android software, and part of the pipeline checks the Authenticode signature on every binary we ingest. It works by shelling out to Get-AuthenticodeSignature and mapping the result onto our own verdict enum.

On windows-latest, every single binary came back INVALID. Signed ones, deliberately tampered ones, and files that were not executables at all. The whole job finished in 4.3 seconds.

Four of the five self-test cases failed loudly. The fifth passed. That fifth one is the interesting part, and it is the reason this took three CI round trips instead of one.

The cause: two PowerShells, one module path

GitHub's Windows runners execute every step under PowerShell 7:

shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"`
PowerShell 7's PSModulePath begins with C:\Program Files\PowerShell\7\Modules, and that directory contains its own copy of Microsoft.PowerShell.Security.

Our script spawns powershell.exe — Windows PowerShell 5.1, because that is where the Authenticode cmdlets have always lived. The child inherits the parent's environment, including PSModulePath. It searches that path first, finds PowerShell 7's Microsoft.PowerShell.Security manifest, and cannot load it, because a 7.x module is not loadable by 5.1:

The 'Get-AuthenticodeSignature' command was found in the module
'Microsoft.PowerShell.Security', but the module could not be loaded.
The cmdlet never resolved. Not once, on any file.

Why it produced INVALID rather than an error

Our verdict mapping fails closed, which is normally correct — an unverifiable binary should never be treated as verified. But every branch fails closed, so an unresolved cmdlet became INVALID for every input.

That distinction matters more than it sounds:

A verifier that rejects everything is strict.
A verifier that cannot run rejects everything too. From the outside these are identical. Both produce a wall of INVALID. Only one of them is doing any work, and ours was the other one — it would have failed closed on every real release, forever, while looking like conservative security policy.

What made it worse: Microsoft Defender checks in the same job passed fine. Defender goes through MpCmdRun.exe and Get-MpThreatDetection, a different module that loads without issue. So the scan cases were green and only the signature cases were red, which made the failure look narrow and specific when it was total.

The fix
Strip PSModulePath from the child environment entirely:

function windowsPowerShellEnv(): NodeJS.ProcessEnv { const env: NodeJS.ProcessEnv = {}; for (const [key, value] of Object.entries(process.env)) { if (key.toLowerCase() === 'psmodulepath') continue; env[key] = value; } return env; }
Two deliberate details.

Unset it, don't pin it. The tempting fix is to set PSModulePath to 5.1's own module directory. Don't — that hard-codes a layout a future runner image can move. If the variable is absent, PowerShell computes its own default for whichever version is being launched, and the fix keeps working.

Every casing. Windows environment variable names are case-insensitive, but Object.entries(process.env) in Node gives you whatever casing the parent used. Comparing against the exact string 'PSModulePath' will miss PSModulePATH.

Reproducing it locally

This one is genuinely awkward to reproduce, because the obvious approach does not work. Setting PSModulePath to a nonexistent directory does not trigger it — 5.1 finds nothing there and falls back to its built-in module location, which works fine.

You have to make it find something it cannot load. Place a stub manifest named Microsoft.PowerShell.Security.psd1 declaring a version floor 5.1 cannot satisfy:

@{ ModuleVersion = '7.0.0.0' PowerShellVersion = '7.0' GUID = 'a94c8c7e-9810-47c0-b8af-65089c13a35a' CmdletsToExport = @('Get-AuthenticodeSignature') }
Put its directory ahead of the system modules in PSModulePath, and you get the exact error message above. Unset the variable and the same file returns Valid.

The test that passed for the wrong reason

Case 3 of our self-test takes a text file, renames it .exe, and asserts the verifier does not call it valid. It passed throughout.

Of course it did. "Status is not VALID" is satisfied perfectly well by a tool that never started. The assertion was true for a reason that had nothing to do with the behaviour it was supposed to be testing — and because it passed, the failure looked narrower than it was.

If you assert that something was rejected, also assert that the check ran. Bare negatives — "status is not VALID", "no results returned", "exit code is non-zero" — are all satisfiable by a crash.

Finding the field that distinguishes ran and said no from never ran took some care. The status code itself could not do it: our PowerShell wrapper initialises psStatus to UnknownError before calling out, and UnknownError is also a real answer Windows gives for a malformed file. Same value, two opposite meanings.

The discriminator was the accompanying message:

function signatureCheckRan(verified) { const raw = verified.raw; if (raw?.ok === false || !raw?.signature) return false; const sig = raw.signature; if (sig.error) return false; return sig.psStatus !== 'UnknownError' || Boolean(sig.statusMessage); }
A completed call has either a status other than UnknownError, or UnknownError carrying Windows' own explanatory message. A call that threw has the untouched placeholder, no message, and an exception string. Now case 3 asserts both that the file was rejected and that something was there to reject it.

A second trap in the same PR: catalog vs embedded signing

Worth knowing if you write tamper-detection tests. Windows OS binaries — notepad.exe, cmd.exe, powershell.exe — are catalog-signed, not embedded-signed. Catalog entries are keyed by the original file's hash, so a byte-identical copy verifies Valid and your happy-path test passes. But a tampered copy is in no catalog and comes back NotSigned, never HashMismatch. Your tamper test then fails, and it reads exactly like broken tamper detection.

Pick a reference binary by reading embedded-ness out of the bytes rather than asking PowerShell. The certificate table is data directory 4 of the PE optional header; if its offset and size are both non-zero, the signature is embedded. Measured on one dev box: notepad gives offset 0, size 0 — catalog-signed. node gives offset 92263424, size 15688 — embedded. Git for Windows is the reliable choice on a runner, since actions/checkout cannot run without it and its binaries are embedded-signed.

One more: our PowerShell wrapper writes its JSON output beside the target file. Run it against something under C:\Program Files and you get a hard failure from an Access-Denied write that has nothing to do with the signature. Copy to a temp directory and verify the copy.

Takeaways

Any powershell.exe spawned from a pwsh parent needs PSModulePath stripped. On GitHub's Windows runners, that is every step by default.
A verifier where every branch fails closed can't tell you it broke. Make "couldn't check" a distinct outcome from "checked and failed".
Assert that the check executed, not just that it returned the answer you wanted.
Two green cases in a red suite are worth more attention than the red ones — they may be green vacuously. We hit all of this building the ingestion pipeline for FileCobra, where the same checks run over every binary in the catalogue. If you are doing Authenticode verification in CI, the PowerShell version mismatch will find you eventually — it is not specific to our setup.