Coder Legion - Recent posts tagged productivity

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

Sat, 31 Oct 2026 06:19:58 +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

Sat, 31 Oct 2026 06:18:44 +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.

editaimg — AI Image Editor

Thu, 29 Oct 2026 08:12:09 +0000

You have an image that is almost right. A few words need changing, an object is distracting, or the background doesn't fit the page you're building. If all you have is the exported image, a small change can turn into a fair amount of manual work.

I'm building editaimg, a web-based AI image editor for making changes to existing images with plain-language instructions. I wanted to share one use case here: editing text inside an image.

A concrete example

The example below is from our website. The instruction is: replace the text in the image with "welcome to editaimg".

Before

AI result

How it works

Upload the image you want to edit.
Describe the change, including the exact replacement words and what should stay the same.
Generate a result, inspect it, and download it if it fits your needs.

For example, you could ask to change a heading on a promotional graphic while keeping the surrounding artwork. The aim is to make that update without rebuilding the whole design.

The same editor also supports background changes, object removal and recoloring. There are dedicated tools for image translation and upscaling too.

Where I'd be careful

This is generative editing, so I wouldn't promise pixel-perfect preservation. Check spelling, small text and any details that must remain unchanged. If you have the editable source and need exact typography or layout, editing that source is still the better option.

Access and feedback

editaimg is a closed-source commercial product. Free usage is available with limits; additional usage is available through one-time credit purchases, with no subscription required.

You can try it at editaimg.com.

For developers making landing-page visuals, demo graphics or product images: what small image edit still sends you back to a full design tool? I'd be interested in the cases where this workflow helps, and where you'd need more control.

Use Native structuredClone() Instead of JSON.parse(JSON.stringify())

Thu, 29 Oct 2026 06:57:00 +0000

Deep cloning objects in JS used to require third-party libraries like Lodash or hacky JSON serialization that dropped Date objects, Map, Set, and RegExp.

JavaScript
const original = {
user: "Joseph",
joined: new Date(),
roles: new Set(["admin", "designer"]),
};

// Loses Date instances and sets
const badClone = JSON.parse(JSON.stringify(original));

// Native browser & Node.js deep clone (zero dependencies)
const cleanClone = structuredClone(original);

Why it changes your career: Replacing heavy third-party utility libraries with native browser APIs shrinks your bundle size and eliminates unnecessary dependency risks.

StripeFlow

Thu, 29 Oct 2026 00:07:22 +0000

StripeFlow Analytics is a self-hosted analytics platform designed to help SaaS businesses turn Stripe data into actionable insights through revenue tracking, churn analysis, customer lifetime value, and payout forecasting.

The project is currently pre-revenue with no customers, presenting a great opportunity for an entrepreneur, SaaS company, or established analytics provider to acquire a ready-to-develop product, establish its market presence, and build a customer base from the ground up.

StripeFlow Analytics offers a compelling starting point for someone looking to enter or expand within the SaaS analytics market.

UnifyAPI Integrations

Thu, 29 Oct 2026 00:02:57 +0000

UnifyAPI Integrations helps developers and SaaS builders simplify repetitive API integration work with reusable code for authentication, retries, and webhook handling.

Currently pre-revenue with no customers, it presents a great opportunity for an entrepreneur or software company to establish its market presence, build a customer base, and monetize a solution addressing a common developer pain point.

Senior Engineers Are Paid to Say No

Wed, 28 Oct 2026 13:47:20 +0000

Somewhere along the way, we started measuring good engineering by how much we build.

New features, new frameworks, new abstractions. There's always something to add, improve, or replace.

But with experience, you realise that not every problem needs a solution. Sometimes, the existing solution is perfectly fine. We just get bored of it.

I've seen how easy it is to overcomplicate things in the name of scalability, flexibility, or simply following what's new. And while these things have their place, they also come with a cost. More code to maintain, more decisions to revisit, and more things for the next developer to figure out.

This is where I think seniority really shows. Not just in knowing how to build something, but in questioning whether it needs to be built at all.

Of course, saying no isn't always easy. Building something new is visible. Preventing unnecessary work rarely gets noticed. And there's a fine line between being thoughtful and becoming the person who opposes every new idea.

The trick is knowing the difference.

I'm not suggesting we stop experimenting or stick to old solutions forever. Sometimes, a rewrite is necessary. Sometimes, a new technology genuinely makes life easier.

But before jumping in, perhaps we should ask a simple question: What happens if we don't do this?

We spend a lot of time discussing what engineers should build. Maybe we should spend a little more time talking about what they should leave alone.

Because experience isn't just about knowing what works. It's also about recognising when something doesn't need fixing.

How I Built a 24/7 AI DevOps Coding Agent for About CAD 200

Tue, 27 Oct 2026 05:18:01 +0000

Hermes + Claude Code + Telegram on a cheap always-on thin client.

Hi, I'm Amir

I'm a DevOps engineer, and a surprising amount of my time goes into work that is important but repetitive.

A server needs patching. A CI/CD pipeline fails. A script needs a small change. A Terraform module needs an update. A tool I built needs one more feature. Tests need to be run, branches need to be checked, and somebody still has to make sure the generated code actually works.

None of those jobs is necessarily difficult on its own. The annoying part is the constant context switching.

I kept thinking:

What if I had a small AI worker that was always online, understood my repositories, could call a real coding agent, verify the result, manage Git, and report back to me on my phone?

That is what this setup became.

I use Hermes as the agentic AI harness and orchestrator. Hermes is connected to OpenRouter, where I use a low-cost DeepSeek Flash v4 model for the orchestration layer. When real coding work is needed, Hermes delegates that work to the Claude Code CLI, which is my main coding agent.

The split is intentional:

Claude helps me think through the problem. Claude Code does the main coding. Hermes runs the workflow, performs QA, manages Git, pushes the repo, and keeps me updated through Telegram.

This is not meant to replace me as an engineer. It is meant to remove the repetitive overhead around the work.

How I divide the work between Claude, Hermes and Claude Code

I deliberately do not ask one AI agent to do everything.

When I have a new idea, bug, or feature, I normally start by talking it through with Claude. I explain what I want, what is currently broken, what constraints matter, and what I do not want changed.

Claude helps me turn that into a clear, compact prompt for Hermes.

Then I hand the task over.

Claude: planning and shaping the task

Claude is where I usually work through questions like:

What exactly should change?
What should stay untouched?
What edge case am I forgetting?
What is the smallest useful test?
What should count as PASS?
What instructions does Hermes actually need?

I don't want a giant five-page prompt. By the time I send the task to Hermes, the thinking should already be distilled into something actionable.

Hermes: orchestration, QA and Git management

Hermes is my manager layer.

Its job is not to out-code Claude Code. Its job is to keep the job moving.

In my workflow Hermes is responsible for things like:

checking the current repo and branch
launching the coding agent
monitoring the task
running the relevant tests itself
verifying that the result actually matches the request
checking Git status
committing only after the task passes
pushing the branch
reporting PASS / FAIL, issues and next steps back to Telegram

That separation matters to me:

The agent that writes the code is not the same layer that decides the job is finished.

Claude Code: the main coding agent

When the work gets into the actual codebase, Claude Code CLI is my primary coding agent.

That is where I want the heavier coding intelligence spent:

reading the codebase
implementing features
fixing bugs
changing tests
debugging failures
reasoning about implementation details

Hermes stays relatively lightweight and cheap. Claude Code does the expensive coding work only when I actually need it.

A real prompt from my workflow

Here is a real example.

After discussing the issue with Claude, this was the kind of short prompt I sent to Hermes:

In text form:

On feature/patch-all: after app restart, an analysis left RUNNING is not
marked INTERRUPTED and Analyze/Patch stay disabled. Startup recovery from
faa2ae6 isn't working on a real DB (schema v7, existing runs). Fix + test
with a DB containing a RUNNING analysis before startup.
Full suite + ruff. Commit after PASS, push. Report PASS/FAIL | issues | next.

I like this kind of prompt because it is short but still gives Hermes everything it needs:

where the problem is → what the failure looks like → what must be tested → when Git operations are allowed → what I want reported back.

Hermes does not just trust the coding agent

This is the part that made the setup useful for me rather than just interesting.

After Claude Code finishes, Hermes still has work to do.

Here is a real result from my Telegram workflow:

In this example Hermes exercised the fallback path, brought up the required containers, reran the integration test against the real environment, cleaned things up, and then handled the Git commit.

That is exactly the kind of repetitive workflow I want the orchestrator doing for me.

I want Claude Code focused on implementation.

I want Hermes focused on:

implement
   ↓
verify
   ↓
test
   ↓
inspect
   ↓
commit
   ↓
push
   ↓
report

Telegram is my remote control

Telegram is what makes the whole setup feel different from simply running an AI coding tool on my laptop.

I can be somewhere else and send something like:

Check the latest branch.

Have Claude fix the regression.

Run the targeted tests.

If everything passes, commit and push.

Report PASS/FAIL, issues, and next.

Then I can put my phone away.

The actual work is happening on the thin client at home.

I don't need a remote desktop session. I don't need VS Code open. I don't need my laptop to stay awake.

Telegram is just the control surface.

The hardware cost me about CAD 200

I deliberately did not build an expensive home server for this.

The machine only needs enough resources to run Linux, Hermes, Git, development tools, containers when needed, and the local Claude Code CLI. The heavy LLM computation happens remotely.

I bought a used Dell Wyse 5070 thin client for about CAD 120.

Part	My setup	Approx. cost
Thin client	Dell Wyse 5070	CAD 120
CPU	Intel Celeron J4105, 4 cores	included
RAM	4 GB physical RAM	included
Internal storage	32 GB	included
Wireless	Linux-compatible USB Wi-Fi adapter	CAD 20
External storage	256 GB external SSD	CAD 60
Approx. total		CAD 200

The original 32 GB storage was too small once Docker, repositories, package caches and development tools entered the picture.

I mounted the external SSD at:

/data

and moved the storage-heavy workloads there:

/data
├── docker
├── containerd
├── projects
└── swapfile

My project path points to the SSD:

~/projects -> /data/projects

The Wyse has 4 GB of physical RAM, so I also added a 4 GB swap file on the external SSD.

That gives the OS 4 GB RAM + 4 GB swap to work with.

Swap is obviously not the same as real RAM, but for a cheap orchestration box it gives me useful headroom during temporary spikes.

Installing Hermes on Ubuntu 26.04

I run the box on Ubuntu 26.04.

For Hermes itself, I followed the official installation method from the Hermes Agent website.

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

After installation, the important pieces in my setup are:

Hermes Agent running on the thin client.
OpenRouter as the model provider for Hermes.
DeepSeek Flash v4 as my low-cost orchestration model.
Telegram connected so I can talk to Hermes remotely.
Claude Code CLI installed and authenticated as the main coding agent.
Git / GitHub access configured so Hermes can manage the repository workflow.

The main idea is simple:

Spend the expensive model on the coding problem. Keep orchestration lightweight.

What happens when the first coding attempt fails?

One thing I did not want was this:

Claude Code says "done"
        ↓
Hermes trusts it
        ↓
bad code gets pushed

That defeats the point of having an orchestration layer.

My preferred flow looks like this:

If QA fails, Hermes has evidence it can hand back to the coding agent:

failing tests
command output
wrong behavior
dirty Git state
integration failure
missing expected changes

The coding agent gets another chance to fix the actual failure.

Only after Hermes can reproduce a passing result does the workflow move to commit and push.

I find that much more useful than simply asking the coding model:

"Are you sure it works?"

How I keep the running cost under control

The hardware cost is only one part of the story.

What matters more over time is where I spend model tokens.

Hermes mainly needs to do things like:

inspect the current state
decide which tool or agent should run next
wait for a result
run tests
check Git status
retry when something fails
report back to me

For that layer I use a cheaper model through OpenRouter.

I save Claude Code for the part where the extra intelligence actually matters: understanding and changing the codebase.

Cheap model
    ↓
orchestration / routing / checking

Expensive coding model
    ↓
used only when real coding is required

I also don't need to pay for a cloud VM just to keep the agent online because the Wyse is doing that job at home.

My ongoing cost is therefore mostly whatever I spend on Claude/Claude Code and OpenRouter usage rather than another always-on server bill.

Guardrails I use before code gets pushed

I want this system to save time, not create a faster way to break things.

Some rules I like are:

No commit before QA passes.
No push before the working tree is in the expected state.
Test the changed behavior, not just whether the code imports.
Prefer a small targeted regression test first.
Use the existing full test suite when appropriate before finalizing.
Report failures instead of hiding or working around them.
Keep production credentials and private keys outside prompts and public repos.
Do not let the coding agent silently change unrelated parts of the project.

For my personal projects, I also try not to turn every small change into a giant enterprise QA exercise.

The goal is enough verification to catch the mistake without spending more time testing than the original task was worth.

Where this setup works well — and where it doesn't

This setup is a good fit for work that is:

repetitive
repository-based
testable
scriptable
safe to perform from a development machine
easy to describe with a clear PASS/FAIL condition

Examples include:

small internal tools
bug fixes
repetitive patching utilities
CI/CD helper scripts
Terraform changes in non-production environments
report generators
automation around Git and testing

It is not something I would blindly point at production and tell:

"Do whatever you think is best."

For high-risk production changes, security-sensitive operations, destructive database work, or anything with a large blast radius, I still want explicit human review and normal change controls.

The agent is useful because it removes repetitive work.

It does not remove engineering judgment.

A few things I learned while building it

1. The orchestration machine does not need to be powerful

At first it is easy to think "AI agent" means "expensive AI hardware."

In this design, it doesn't.

The thin client mostly needs to stay online, run tools reliably, and have enough storage.

2. Separating coding from verification is valuable

Claude Code is very good at coding.

That does not mean I should automatically accept its own definition of "finished."

Having Hermes independently run the checks gives the workflow a much cleaner boundary.

3. A short prompt can be better than a huge prompt

Because I discuss the idea first, the prompt I send to Hermes can stay focused.

That reduces noise and makes failures easier to understand.

4. Reliability matters more than raw speed

The Wyse is not fast.

But it is always there.

For this use case, always available + predictable is more valuable to me than having a much faster machine that disappears when I close my laptop.

5. The best automation is the one I actually use

The biggest win is not that the architecture looks clever.

It is that I can send a task from Telegram, walk away, and come back to a tested branch instead of spending another hour doing repetitive setup and Git work.

Final thoughts

I did not build this because I wanted an AI experiment sitting in a corner of my house.

I built it because I'm a DevOps engineer and I have repetitive work.

Sometimes the right answer to a repetitive task is a Bash script.

Sometimes it is Terraform.

Sometimes it is a small Python tool.

And now, sometimes I can simply describe the problem, let my agent workflow build or fix the tool, verify the result, and give me the branch when it is ready.

My setup has a very simple division of responsibility:

I bring the problem. Claude helps shape the solution. Claude Code writes the code. Hermes manages the job, verifies it, handles Git, and reports back to me.

The Wyse provides the always-on home.

Telegram gives me access from anywhere.

The cloud models provide the intelligence.

A cheap little thin client became my 24/7 AI DevOps coding worker.

Source / setup files: Amiri83/hermis on GitHub

Original Gist: My 24/7 AI DevOps Coding Agent

WordOnline

Sat, 24 Oct 2026 11:49:57 +0000

WordOnline is a browser workspace for the document handoff that often follows a software project: the release note, client instructions, and the final DOCX or PDF.

We work on WordOnline. The aim is straightforward: make a small document edit or combine a handoff packet without setting up another account.

A practical handoff workflow

Open an existing DOC or DOCX from your computer.
Update the text and formatting in the editor.
When several documents belong together, add them to the merge workflow and set their order.
Download the result as DOCX for continued editing, or PDF for distribution.
Reopen the exported file and check headings, page breaks, links, and tables before sending it to a client.

Open the document editor.

Why keep the document work local?

Document content is processed in the browser. That gives teams a useful option when they want a local-file workflow rather than uploading the document to a shared cloud workspace. The website still uses network resources and usage telemetry; local document processing does not mean zero network activity.

The core workflow does not require an account. Editing is free, with up to 10 successful conversion, merge, or download tasks per browser per day. The file limit is 25 MB, and a merge can contain up to 20 files.

Start with a small, repeatable delivery

A useful first task is a two-file handoff: an overview followed by operating instructions. Keep the editable DOCX as your working copy, produce a PDF for the recipient, and review both exports. A short, consistent delivery check is often more useful than adding another layer of workflow software.

Website: https://wordonline.io/

Feedback on the editor and document handoff experience is welcome.

I'm Learning to Code in the Age of AI. Is That a Problem?

Fri, 23 Oct 2026 19:00:31 +0000

“Adapt or die.” That phrase perfectly sums up the unstable software engineering industry in this age of AI. Whenever we set aside the fear of AI taking our jobs, we’re often met with the same reassurance: AI isn’t replacing developers; developers who know how to leverage AI will come out on top.

And sure, that sounds reasonable for senior developers with years of experience and solid skills to back them up. But what about junior and entry-level developers, myself included? How do I possibly leverage AI to become a better software engineer when the foundation hasn’t been built yet?

Learning to Code in a Different Era

Before I start, it’s probably best to offer some context. I’m a full-stack developer currently focused on web development, though I plan to expand my skill set down the road. I’m still an entry-level/junior dev, and my only “working experience” so far comes from a remote internship I recently completed at a somewhat shady company.

Now, it should be obvious that I still have plenty of room to grow, both in terms of my technical skills and actual work experience. But that’s exactly the problem. With how volatile the industry is right now, thanks to AI and the aftermath of post-COVID overhiring (and now layoffs), being at the very bottom of the software development career ladder isn’t exactly a great position.

Despite all this, I’m still learning to code manually. According to many industry experts, though, coding by hand is dead. What matters now is having “taste,” making high-level decisions, and understanding trade-offs while letting AI handle the “boring” part: implementation.

That sounds great. Until you consider that those skills and that judgment come from years of learning and experience, often gained on the job. You can’t reliably judge an AI’s code quality or spot its flaws when you don’t yet understand what good code looks like.

Using an AI Assistant Changes Everything

Whether for better or worse, it's clear that AI has changed everything. I'm not particularly against artificial intelligence (GenAI, to be specific), though I'm quite aware of its numerous downsides.

When it comes to learning to code, I actively use AI as a learning tool. It helps me break down obscure concepts, provides coding challenges, and even points me toward useful resources. Whenever I get stuck on a problem or confused while debugging my code, getting help is just a click or prompt away. And that, in itself, is the problem.

I've come to realize that solving problems doesn't automatically make you a better programmer. The friction involved in solving them matters just as much. Taking a problem, working through it, trying different approaches, making mistakes, and eventually finding a solution helps develop the problem-solving skills software engineers need.

But with a handy assistant always within reach, I've made it incredibly easy to bypass that friction, even when it's exactly what I need. It's like being stuck in tutorial hell, except somehow worse. I get a false sense of progress that looks solid at a cursory glance but crumbles when put under real pressure.

What Happens When the AI Isn't There?

Outsourcing your intelligence to AI is one of the worst things to do. Letting tools like ChatGPT or Claude handle our thinking, problem-solving, and decision-making actively weakens our “mental muscles” due to lack of use.

With AI always at my side, I sometimes solve problems without giving them much thought. I accept its answers without enough scrutiny, and that makes things harder when the assistant isn't there. I start overthinking, doubting things I genuinely know, and struggling to recall basic concepts I haven't practiced in a while.

A quick search led me to the concept of cognitive laziness: the tendency to avoid putting in mental effort when an easier alternative is available. Over-relying on AI can encourage this habit, particularly when we let it do the thinking instead of using it to support our own. It’s a horrible cycle. The more we depend on AI to solve problems, the less practice we get solving them independently, which can make us even more dependent on AI.

In my own case, I sometimes struggle to explain code I've written with AI's help. Adapting it to changing requirements can be difficult because, while I understand the overall idea, the actual implementation feels foreign to me.

I Still Want to Understand the Code I Write

Most developers who embrace the AI boom argue that it “lets them skip the boring part of typing and focus on high-level decisions.” Well, I actually love what they refer to as the boring part. Thinking through problems, typing out code to solve them, and simply enjoying the logic feels great to me.

So, even if it makes me feel slower in the short term, I'll try to avoid reliance on AI tools. For now, I'll attempt to solve problems myself, thinking deeply when I'm stuck, rather than relying on some tool, and take the time to understand an implementation instead of blindly accepting it.

Using AI to speed up as a shortcut feels like strapping a rocket to a horse-drawn carriage. Sure, it'll go faster, but how long before the whole thing falls apart? And if that becomes the norm, I’d have to ask whether I’m still learning software development or signing up to supervise AI.

You Ran git reset --hard and Panicked. Here's How to Get Your Commits Back (and the One Thing You Ca

Fri, 23 Oct 2026 10:54:58 +0000

Your stomach drops. You typed git reset --hard, or deleted the wrong branch, or a rebase ended with half your commits missing. The log looks empty. Three days of work, gone.

Take a breath. If you ever committed that work, it is almost certainly still there. Git is much harder to destroy than it looks, and the tool that proves it is called the reflog.

What the Reflog Is

Your normal history (git log) shows the commits reachable from your current branch. The reflog is a different record: a private diary of everywhere HEAD has pointed on your machine, in order, including places you have since left.

git reflog

a1b2c3d HEAD@{0}: reset: moving to HEAD~3
9f8e7d6 HEAD@{1}: commit: add pricing page
4c5d6e7 HEAD@{2}: commit: fix navbar on mobile
b7a8c9d HEAD@{3}: commit: add contact form

A hard reset moved your branch pointer backwards. It did not delete the three commits. They are still stored, and the reflog tells you their IDs.

Disaster 1: `git reset --hard` Threw Away Commits

Find the entry from just before the mistake and go back to it:

git reflog
git reset --hard 9f8e7d6

You can also use the position instead of the ID:

git reset --hard HEAD@{1}

Your branch is back exactly where it was. The "lost" commits are the same commits, same IDs, nothing rewritten.

Disaster 2: You Deleted a Branch You Still Needed

git branch -D feature/checkout
# Deleted branch feature/checkout (was 3e4f5a6).

Look at that output. Git told you the ID of the commit the branch pointed at. If you missed it, the reflog still has it:

git reflog
# find the last commit you made on that branch
git checkout -b feature/checkout 3e4f5a6

A branch is only a label that points at a commit. Delete the label and the commits stay, until Git cleans them up much later.

Disaster 3: A Rebase Went Wrong

Mid-rebase mistakes feel the scariest, because rebase rewrites history. It still keeps the old version in the reflog.

Right after a rebase, ORIG_HEAD points at where you were before it started:

git reset --hard ORIG_HEAD

If you have done other things since, find the entry that says something like rebase (start) in the reflog, take the entry just before it, and reset to that.

Disaster 4: You Dropped a Stash

git stash drop removes the stash from the list, but the commit it was stored in still exists for a while. If you have the ID that was printed, apply it directly:

git stash apply 7a8b9c0

If you do not have the ID, search for unreachable commits:

git fsck --no-reflog | grep "dangling commit"

Then inspect each ID with git show <id> until you find your changes. This is slower and less certain than the reflog, so treat it as the last resort.

The One Thing You Cannot Recover

This is the part many tutorials skip.

Changes you never committed and never staged are not in the reflog, and git reset --hard deletes them permanently.

The reflog records commits. If you edited files, never ran git add or git commit, and then ran git reset --hard or git checkout . or git restore ., those edits are not stored anywhere in Git. There is nothing to recover.

A small mercy: if you did run git add, the staged file contents were saved as objects, and git fsck --lost-found may be able to find them. It is messy, but possible. Unstaged edits have no such safety net.

Why Reflog Entries Do Not Last Forever

The reflog is local to your machine, and it expires. By default, entries for commits that are still reachable are kept for about 90 days, and entries for unreachable ones for about 30 days. After that, Git's cleanup can remove the commits for good.

It also lives only in your clone. A fresh git clone has an empty reflog, and it cannot help you recover something that was lost in someone else's copy.

How to Make This Less Scary Next Time

Commit early, even when it is messy. A commit called "wip" is a safety net. You can clean the history up later with an interactive rebase.
Stash before you experiment. git stash takes a snapshot you can come back to.
Use --force-with-lease instead of --force. It refuses to overwrite a branch if someone else pushed commits you have not seen yet.
Read what Git prints. Deleting a branch tells you the ID. Copy it somewhere before doing anything else.
Create a rescue branch first. Before any risky command, run git branch backup-before-rebase. It costs nothing and gives you a label to return to.

The Rule

If you committed it, Git almost certainly still has it. Open git reflog before you do anything else. And if you are about to run a command that can discard work you have not committed, commit or stash first.

Quick drill: make a throwaway repo, create three commits, run git reset --hard HEAD~3, and get them back with the reflog. Do it once when nothing is at stake, and the real thing is not scary any more.

If you build with Next.js, my templates on pixelanas.com give you a clean starting point, which is a good first commit to have in your history.

Get the templates: https://pixelanas.gumroad.com

What is the worst thing you have ever lost to a Git command, and did you get it back? Tell me in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

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

Thu, 22 Oct 2026 09:26:11 +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.

RIVET — Environmental Incident Investigator

Wed, 21 Oct 2026 09:04:48 +0000

RIVET uses computer vision and water-quality sensors to investigate suspicious changes in waterways, verify evidence, and generate traceable environmental incident reports.

Inspiration

Environmental changes in waterways can go unnoticed when monitoring depends on isolated measurements or occasional inspections. We wanted to explore how computer vision and intelligent investigation could help identify suspicious changes and direct attention toward situations that need further examination.

What it does

RIVET (Environmental Incident Investigator) is a proposed system that combines OpenCV-based video analysis with water-quality sensor readings. It aims to detect unusual changes, compare visual evidence with sensor measurements, investigate uncertainty through additional analysis, and generate traceable incident reports.

How we built it

The planned prototype uses Python and OpenCV to analyse video over time. Water-quality sensors will provide independent measurements, while an AI agent will select follow-up analyses when observations are incomplete or conflicting. AWS will support the data-processing and storage workflow.

Challenges we expect

Important challenges include distinguishing genuine environmental changes from lighting variations, synchronising video with sensor readings, collecting reliable test data, and reducing false alarms.

Accomplishments we're aiming for

Our goal is to build a working prototype that demonstrates evidence-driven environmental investigation, combines computer vision with sensor measurements, and evaluates its performance against simpler monitoring methods.

What we aim to learn

We aim to investigate whether adaptive visual analysis and sensor fusion can improve environmental anomaly detection, how uncertainty should influence an AI agent's next action, and how to make automated environmental monitoring more transparent and reliable.

SentryPC vs Basic Monitoring Tools: When Do You Need a Full Monitoring Platform?

Wed, 21 Oct 2026 07:23:29 +0000

Choosing monitoring software isn't always about finding the cheapest tool.

For some users, a simple website blocker or screen-time application is enough. But when the requirement expands to activity monitoring, application controls, website filtering, screenshots and remote management, basic tools can start to feel limited.

The difficult part is knowing when it's worth moving from a simple tool to a more comprehensive monitoring platform.

Start with the monitoring requirement

Before buying anything, define what you actually need to see.

A basic solution might only tell you how long a computer was used or block particular websites. A more advanced monitoring platform can provide information about websites, applications and other computer activity.

That's the first buying decision:

Do you need basic control, or do you need detailed visibility as well?

If visibility is important, a full monitoring platform is worth considering.

When website blocking isn't enough

Website filtering is useful when the main requirement is restricting access to particular sites.

But it doesn't necessarily tell you what else is happening on the computer.

For example, someone evaluating monitoring software might also need to know:

Which applications are being used
Which websites are being accessed
When activity occurs
Whether screenshots are required
Whether applications should be restricted
Whether controls can be scheduled
This is where a broader monitoring platform becomes more useful than a standalone website blocker.

What makes SentryPC different?

SentryPC combines several of these capabilities in one platform.

Its feature set includes activity monitoring, website filtering, application filtering, time management, screenshots and cloud-based access. The exact capabilities available can vary by operating system, so compatibility should be checked before purchasing.

That makes SentryPC more relevant to someone who needs monitoring and control together, rather than simply wanting to block a few websites.

When should you pay for a broader platform?

A more comprehensive monitoring platform makes more sense when you need several capabilities at the same time.

For example, suppose you need:

Activity visibility + website filtering + application restrictions + time controls + remote management.

Buying five separate tools to accomplish that could become inconvenient to configure and manage.

A unified platform can make more sense when the requirements overlap.

On the other hand, if all you need is basic website blocking, paying for a feature-heavy monitoring platform may not provide enough additional value.

That's an important distinction when evaluating SentryPC—or any competing product.

Don't choose a plan before counting your devices

The number of devices can have a significant effect on the purchase decision.

SentryPC offers licensing options ranging from individual-device use to larger business deployments. It also provides a quote calculator where you can enter the number of devices to estimate the cost. SentryPC

So instead of asking:

"How much does SentryPC cost?"

ask:

"How much will SentryPC cost for the number of devices I actually need
to monitor?"

That's the figure that matters when comparing it with alternatives.

Check compatibility before buying

This is particularly important for a monitoring platform.

SentryPC supports multiple device types, but feature availability isn't necessarily identical across platforms.

If you're buying specifically for screenshots, application monitoring, filtering or another particular capability, verify that the feature works on the operating system you're using.

This is a much better approach than assuming that "supported platform" means "every feature is supported."

Who should consider SentryPC?

SentryPC is worth considering if you need a combination of computer activity monitoring and control features rather than a single-purpose tool.

It can be particularly relevant when your requirements include several of the following:

Activity monitoring
Website filtering
Application restrictions
Time management
Screenshots
Remote/cloud management
Multiple-device licensing

If you only need a basic website blocker or simple screen-time control, a simpler product may be a better purchase.

Want a more detailed buying guide? I’ve also published a detailed guide covering SentryPC’s features, pricing, plans and buying considerations.

The buying decision

The easiest way to decide is to make a short requirements list:

Need only blocking?
→ Consider a simpler tool.

Need monitoring plus controls?
→ Compare full monitoring platforms.

Need several monitored devices?
→ Compare the total licensing cost.

Need a specific feature?
→ Confirm that it works on your operating system.

Need several capabilities in one system?
→ SentryPC is worth evaluating.

Check SentryPC before you buy

If you're looking for a monitoring platform that combines activity visibility, filtering, application controls, time management and remote access, you can check SentryPC's current plans and determine whether its feature set and licensing model fit your requirements.

→ Check SentryPC Plans & Pricing

Affiliate disclosure: This article contains an affiliate link. If you purchase SentryPC through this link, we may earn a commission at no additional cost to you.

I Built PHANTOM Nature Scout: An Open-Source AI Companion for Exploring Nature

Wed, 21 Oct 2026 07:19:04 +0000

This is a personal project inspired by the Hacktoberfest Open-Source AI Challenge Week 1 theme, “Touch Grass.”

What I Want to Build

PHANTOM Nature Scout is a concept for an AI-powered nature companion designed to encourage people to spend more time outdoors. It aims to help users observe nature, identify discoveries, and keep a record of what they learn.

Demo

The working demo will be added here after implementation and testing.

Code

The source code repository will be linked here after the project is implemented.

How I Plan to Build It

I plan to use an open-weight AI model for nature-image recognition, with a simple interface and locally stored observations. I will test the model on my Windows laptop and document its actual capabilities and limitations.

Why Open Innovation Matters

Open-source tools can give developers more control over their technology. Depending on the model and its licence, local inference can improve privacy, reduce dependence on external services, and allow experimentation with different models.

What I Learned

I will document what worked, what failed, and what I learned while building and testing the project.

I’m Still Learning AI Coding: The Rules and Workflows Helping Me Find My Way

Tue, 20 Oct 2026 19:22:32 +0000

What building EthoPipe is teaching me about AI tools, project rules, and leaving room to experiment

Update: I've linked the companion guide :)

After my post How Adobe Firefly and Copilot Taught Me to Prompt for Code (Part 1), a reader asked whether smaller coding prompts worked better than one detailed prompt. I answered yes, but the question stayed with me. What did “smaller tasks” actually look like in my project—and where did rules and workflows fit?

I am not an expert in AI-assisted development. I am learning by building something I care about. These are the files and habits helping me find my way. You might borrow one part, change another, and ignore the rest.

I used to be strongly against AI. I refused to use it. Now I am writing about how I work with it—not because I suddenly have everything figured out, but because I changed my mind and started experimenting.

My project is EthoPipe, an open-science Python project for canine ethology. At one point, I restarted because I was getting lost among ideas, generated code, instructions, and unfinished tasks. I wanted the tools to help me follow the project, not produce more work I could no longer understand.

My Firefly experiments gave me a useful starting point. A short image prompt could work because the reference photo and settings carried part of the instruction. With coding, I began asking the same practical question: what does the agent need to know before I ask it to change something?

1. Decide what I want before asking the agent to build it

I usually brainstorm in the Gemini app, then move to a coding agent when the direction is clearer. Sometimes I use Copilot for another perspective or when I feel stuck. An IDE agent can discuss ideas too; separating the conversations simply helps me avoid turning every possibility into a feature.

An idea can stay an idea. Before moving to code, I ask: What am I changing? Which files belong to the task? What should stay untouched? How will I know it worked?

What changed between July and October

My July files already contain plans, audits, and walkthroughs. They helped me notice problems such as a filename mismatch and checks that were configured but not working. I was learning to pay attention to the work around the code, not just the code itself.

By October, I had an idea board, more specific project rules, scripts for recording stopping points, and a handoff process. I did not design that system in advance. I kept adding or adapting a file when the same confusion came back.

These files make the next session easier. Some guide the agent, some automate repetitive work, and some remind me where I left off.

2. My rules guide the agent—not my imagination

When I moved my instructions from Gemini Code Assist to Antigravity, some did not work the way I expected. I had to redo parts of the setup. That was frustrating, but it also made me pay more attention to where the files belonged and how the tool used them.

The distinction that helps me is simple: rules describe the project’s boundaries; workflows describe how I approach a recurring task; scripts handle repetitive checks or record-keeping. Each has a different job.

The packaging changes too. Antigravity now documents skills for reusable task procedures and rules for persistent instructions. I still call the overall process my workflow. If you borrow my files, check the current documentation for your tool rather than assuming the old folder structure will work unchanged.

I still review what the agent changes. “Do not touch this” is a useful instruction, not a reason to stop paying attention.

One example: keeping the project small enough for me

I do not want the agent adding a setup I cannot understand or maintain. My solo-maintainer rules limit dependencies, extra languages, and unnecessary infrastructure. Those boundaries fit EthoPipe, and I can revise them when the project needs something different.

A few lines from my solo-maintainer.md file:

- Direct runtime dependencies in pyproject.toml are capped at <= 8 packages.
- Always prefer Python's standard library
  (pathlib, tomllib, dataclasses, argparse, typing, sqlite3)
  over adding third-party packages.
- Keep EthoPipe as a single modular Python service
  (FastAPI + Supabase).
- Individual files must remain under 600 lines.

Your version might need a frontend framework, another database, or more dependencies. The useful part is deciding what fits your project and writing it down, rather than explaining it again in every conversation.

The constraints guide the AI’s actions, not my imagination. I can explore another direction without authorizing new packages, rewritten files, or unrequested features. Not every possibility needs to become code.

3. Give a smaller task a clear purpose

My idea-to-code file follows triage → specification → test first → minimal implementation → QA and journal. That may sound formal, but it helps me pause long enough to decide what I need before files start changing.

Instead of “improve my project,” I ask for one change and name the files involved—including tests. If the agent finds a larger issue, I want it to tell me rather than quietly turn the task into something else.

Here is an example of how I would describe a small task:

Objective:
Check the subject_id length boundary.

Allowed files:
src/pipeline/models.py
tests/test_models.py

Non-goals:
No dependency, CI, or unrelated refactoring changes.

Acceptance:
255 characters accepted; 256 rejected.

Process:
Inspect existing tests. Add a regression test only if missing.
Make the smallest necessary change. Run targeted and full checks.

Stop:
Ask if requirements conflict or the boundary is undocumented.

Closeout:
Changed files, commands and results, blockers, next action.

The prompt is not especially short; it is specific. In this example, the limit and tests already exist in my snapshot, so inspection comes before generating anything new.

That is why my answer is not “always write short prompts.” A longer discussion can establish the direction; smaller tasks carry it forward. The rules provide project context, and the task says what I want now.

4. Leave myself a way to come back

I often open a new conversation for a particular task. It keeps unrelated ideas out of the way, but I do not want to explain the whole project again. My state and handoff files help bridge those sessions.

The state file records what I was doing, where I stopped, and what comes next. A handoff adds relevant project changes and checks when requested. Neither me nor the agent has to remember every detail of the previous conversation.

The kind of note that helps me resume

From my October 12 PROJECT_STATE.md checkpoint:

Where We Stopped:
Completed project-state skill, workflow, CLI engine
(scripts/manage_project_state.py), and state.ps1 helper
with docs/states/ historical archiving.

Quick-Resume Action:
Proceed to localized storage adapter design for Kimball
Star Schema persistence or review project state via
.\scripts\state.ps1.

The note is ordinary—and that is why it helps. I can return to it and know where to start. One checkpoint recorded the state tooling in progress; the next gave me a new task. The files keep that thread intact.

5. Ask for help, read the docs, and keep adjusting

When I do not know how to write a rule or workflow, I ask Gemini to help. I explain what I want, work through a draft, compare it with the documentation, and try it. If I cannot describe the goal, that is a sign I need to explore the idea a little longer.

I work with the agent, review changes, and ask for a walkthrough when we finish. I want to understand what happened and what comes next. The goal is not to pretend I could have written every line unaided; it is to learn enough to keep working on my project.

Google’s learning resources—including GEAR and courses available through my student benefits and learning credits—helped me understand the tools. The documentation also helped explain why instructions from one environment needed adapting in another.

6. Coding experience helps—but the tool still needs learning

I come from outside the usual developer path. I cannot speak for someone with twenty years of coding experience, but I can offer a beginner’s perspective: I am still asking questions about how these tools work.

Coding experience and familiarity with a coding agent are related, but not identical. Recognizing a bad abstraction or debugging a problem is valuable. Learning how a particular agent reads instructions, carries context, asks for approval, and handles a task is another skill. Experience gives you something to build on; it does not remove the need to learn the tool.

I wonder whether the familiar setting makes that easy to overlook. It is still an editor, a terminal, and a repository, but some of the interaction now happens through conversation. Reading a tutorial or asking how a feature works does not diminish anyone’s experience.

I would start with an ordinary task: explain an unfamiliar function, suggest a test, or make a change I can follow. Then I can inspect the result and adjust my instructions. That gives me room to learn without expecting the first prompt to solve everything.

Having once refused to use AI, I am reluctant to insist that anyone must embrace it. But curiosity is enough reason to try. A question or mistake does not have to become a verdict on you—or on the technology.

I do not think you need the most expensive tool to begin

Some articles leave me with the impression that useful AI-assisted coding requires the newest model or most expensive subscription. My experience makes me question that. I think an accessible tool can produce decent work when it fits the project and you take time to learn it.

I started with the access I had. Gemini became familiar, and search fits the way I research. An upgrade might help with a specific limitation, but I do not want a price tag to make someone feel they cannot begin. Learning to describe the task has mattered more to me than chasing the model everyone is discussing that week.

7. Experimentation is a reason to build—not a consolation prize

A personal project can be a place to play

I do not know whether EthoPipe will become something bigger. It already gives me a reason to learn, make mistakes, ask questions, and try ideas. That is not a consolation prize if it never becomes a finished product. It is a reason to build.

A personal project does not have to become a company, a polished product, or proof that you are a “real” developer. You can vibe code, run tests, discard an experiment, and start again. AI can help you be more creative, not just more productive.

I can ask for three approaches without authorizing file changes, choose one, and try it separately. I can ask the agent to explain the result—or discard it if it does not help. Exploring possibilities is different from adding all of them to the main project.

The agent needs a clear job; my ideas need room. I can change the rules, explore another direction, or leave an experiment unfinished. The boundaries help me follow the work, not postpone it.

If you want to try this, start with one file

Pick a task you keep repeating or a problem that keeps confusing you.
Write a small rule or procedure in your own words.
Ask your AI tool to help clarify it, then check how your environment loads it.
Try it on one manageable task and look at the result.
Keep what helps, change what does not, and leave yourself a next step.

You do not need my full collection. I am sharing it because concrete examples would have helped me understand what people meant by rules and workflows. Take what solves a problem for you, then adapt the stack, limits, and language.

Smaller tasks help me, but I am not trying to make my ideas smaller. I am giving the agent a clearer job while I keep learning and experimenting. The prompt says what to do now. What I imagine next is still up to me.

What have you tried with AI simply to learn or explore? I would love to hear about the experiments—not just the finished products.

AI assistance: I used Gemini and Microsoft Copilot to brainstorm, organize, and edit this article. The experience and project files are mine.

My files: the companion guide, “My AI Coding Project Files: What You Can Borrow,” groups the rules, workflows, scripts, and records behind these examples so you can choose one useful starting point.

PPT Online

Mon, 19 Oct 2026 23:09:58 +0000

PPT Online is a presentation workspace from our team. It brings slide editing, templates, and practical file exports into the browser, with a useful place for AI drafting when you need a starting outline.

A small workflow for project updates and demos

A presentation often needs two deliverables: slides someone can keep editing, and a fixed copy people can read. PPT Online supports that handoff with watermark-free PPTX and PDF exports.

You can start with a blank deck or an original template, then work with text, images, charts, tables, and slide layouts. Templates include editable content and outlines for business reviews, lessons, pitches, and other common situations. Themes help keep the deck visually consistent.

For a developer update, a straightforward sequence is:

Set out the problem, the proposed change, and what the audience should do next.
Put the essential comparison or result on a slide, using charts or tables where they help.
Review the wording, alignment, and reading order in the editor.
Export a PPTX for further editing and a PDF for the handoff.

Where AI and the file tools fit

AI drafting can turn a topic or outline into an editable first pass. Rewriting and translation help work through the text while keeping the presentation workflow in one place. Separate tools cover everyday presentation-file tasks such as PDF preparation, compression, and preparing a compatible PPTX to download and import into Google Slides.

Editing, templates, browser presentation, and exports are free in this release. New AI and file-processing tasks have daily allowances displayed in the product.

The useful part is keeping the editable deck and the final deliverable close together: shape the slides, review the message, and take away the file you need.

Open PPT Online

The Complete Guide to File Compression: PDF, Image, Video & Document Compression Explained

Sun, 18 Oct 2026 11:31:13 +0000

The Complete Guide to File Compression: PDF, Image, Video & Document Compression Explained

File compression is one of the most common needs in everyday work. An email attachment exceeding 25MB won't send, a PDF is too large to upload to a system, a folder of high-res photos is eating up your disk space — these scenarios all point to the same problem: the file needs to be smaller.

But "compression" means very different things in different contexts. Zipping files with 7-Zip is compression. Shrinking a 5MB photo to 500KB is also compression. Converting a 4K video to 720p? That's compression too. The technical principles behind each are fundamentally different, and so are their use cases.

This guide covers the core principles of file compression and walks through PDF compression, image compression, video compression, OFD compression, and enterprise data compliance — helping you understand the logic behind each file type and choose the right approach.

1. Fundamentals of File Compression

At its core, file compression is about representing the same information with less data. Based on whether information is lost, compression falls into two categories:

graph TD
    A[File Compression] --> B[Lossless]
    A --> C[Lossy]
    
    B --> B1[DEFLATE<br/>ZIP/gzip]
    B --> B2[LZMA/LZMA2<br/>7z format]
    B --> B3[PNG Filter + DEFLATE]
    
    C --> C1[DCT<br/>JPEG core]
    C --> C2[Quantization<br/>coefficient rounding]
    C --> C3[Inter-frame Prediction<br/>H.264/H.265]
    
    B1 --> B1a[Text/Code/Archives]
    B2 --> B2a[High-ratio Archives]
    B3 --> B3a[Lossless Images]
    
    C1 --> C1a[JPEG Images]
    C2 --> C2a[MP3 Audio]
    C3 --> C3a[MP4 Video]
    
    style B fill:#4CAF50,color:#fff
    style C fill:#FF9800,color:#fff

1.1 Lossless Compression

Lossless compression reduces file size while ensuring the decompressed data is byte-for-byte identical to the original. It works by eliminating redundancy — for example, a sequence like AAAAABBBCC can be encoded as 5A3B2C, instantly halving the storage space.

Common algorithms include:

DEFLATE: The core algorithm used by ZIP/gzip, combining LZ77 + Huffman coding
LZMA/LZMA2: Used by 7-Zip's .7z format, offering higher compression ratios than DEFLATE
PNG filtering + DEFLATE: Applies row-level filtering to image data before DEFLATE compression

Typical applications: ZIP/7z archive compression, PNG images, FLAC audio. Lossless compression is ideal for text, code, spreadsheets — anything where losing even a single bit is unacceptable.

1.2 Lossy Compression

Lossy compression achieves smaller sizes by discarding information that human eyes or ears are less sensitive to. For example, a 4000×3000 photo displayed on a 1920×1080 screen doesn't need all those extra pixels — they can be safely discarded.

Common techniques include:

DCT (Discrete Cosine Transform): The core of JPEG, converting images from the spatial domain to the frequency domain and discarding high-frequency components
Quantization: Rounding frequency coefficients at a given precision — lower precision means smaller files but more loss
Inter-frame prediction: Used in video compression (H.264/H.265) to leverage similarity between consecutive frames, encoding only the differences

Typical applications: JPEG images, MP3 audio, MP4/H.264 video. Lossy compression is suited for images, video, audio — media where some quality loss is acceptable.

Understanding the distinction between these two approaches is the foundation for choosing compression tools and parameters. Most document compression (PDF, Word) uses both methods simultaneously — lossless for text, lossy for embedded images and video.

2. Archive Compression vs. Content Compression: A Critical Distinction

Many developers confuse two fundamentally different compression needs:

graph LR
    subgraph Archive Compression
        A1[File A 30MB] --> R1[Package]
        A2[File B 20MB] --> R1
        A3[File C 10MB] --> R1
        R1 --> O1[archive.zip<br/>59MB<br/>only 1% reduction]
        O1 --> N1[After extraction<br/>original sizes restored]
    end
    
    subgraph Content Compression
        B1[PDF file 50MB] --> R2[Content optimization]
        R2 --> O2[compressed.pdf<br/>8MB<br/>84% reduction]
        O2 --> N2[Open directly<br/>no extraction needed]
    end
    
    style R1 fill:#2196F3,color:#fff
    style R2 fill:#4CAF50,color:#fff
    style O1 fill:#FFC107
    style O2 fill:#8BC34A,color:#fff

Dimension	Archive Compression (7-Zip/WinRAR)	Content Compression (Specialized Tools)
What it does	Packages files into .zip/.7z/.rar	Directly reduces individual file size
Target	Collections of any files	PDF, images, video, Office documents
Method	Lossless (redundancy elimination)	Lossy + lossless hybrid (content optimization)
Usage	Must extract before use	Open directly after compression
Typical scenario	Bundling multiple files for transfer	Reducing individual file size

The bottom line: if your problem is "this file is too big to email," you need content compression, not archive compression — because when the recipient extracts the .zip, the file inside is still the same size.

# Archive compression: file size unchanged, just packaged
Original 50MB PDF → 7z archive → 49MB (only 2% reduction)

# Content compression: directly reduces the file itself
Original 50MB PDF → content compression → 8MB (84% reduction)

3. PDF Compression

PDF is the most common file type that needs compression in office environments. Contracts, reports, presentations, electronic invoices — vast numbers of documents circulate as PDFs, and embedded high-resolution images, scanned pages, and vector graphics frequently cause file size bloat.

3.1 Where PDF Size Comes From

A PDF file's size is primarily determined by:

Embedded images and scans: A single 600DPI scanned page can reach 2-5MB; a 50-page document easily exceeds 100MB
Embedded fonts: A complete CJK font set can occupy 10-20MB
Vector graphics and redundant objects: CAD-exported vectors, replaced-but-not-deleted old images, hidden layers

3.2 Five Core PDF Compression Techniques

graph LR
    A[Input PDF] --> B[Image Resampling<br/>600DPI→150DPI]
    B --> C[Format Conversion<br/>FlateDecode→JPEG]
    C --> D[Font Subsetting<br/>keep used glyphs only]
    D --> E[Remove Redundant Objects<br/>clean unreferenced resources]
    E --> F[Linearization<br/>enable fast web view]
    F --> G[Output PDF<br/>80-90% size reduction]
    
    style A fill:#FFC107
    style G fill:#4CAF50,color:#fff
    style B fill:#E3F2FD
    style C fill:#E3F2FD
    style D fill:#E3F2FD
    style E fill:#E3F2FD
    style F fill:#E3F2FD

# PDF compression pseudocode
def compress_pdf(input_pdf, target_dpi=150, jpeg_quality=72):
    # 1. Image resampling: 600DPI → 150DPI (~90% data reduction)
    for image in input_pdf.images:
        image.resample(target_dpi)
    
    # 2. Image format conversion: FlateDecode (PNG-like) → DCTDecode (JPEG)
    for image in input_pdf.images:
        image.convert_to_jpeg(quality=jpeg_quality)
    
    # 3. Font subsetting: keep only characters actually used in the document
    for font in input_pdf.fonts:
        font.subset(input_pdf.used_characters)
    
    # 4. Remove redundant objects: clean unreferenced resources, hidden layers, old versions
    input_pdf.remove_redundant_objects()
    
    # 5. Linearization (Fast Web View): restructure for streaming load
    input_pdf.linearize()
    
    return input_pdf.save()

Real-world example: An 80MB scanned contract PDF (60 pages, 600DPI color scan), with a target of under 10MB for email:

Image resampling: 600DPI → 150DPI
Format conversion: FlateDecode → JPEG, quality 72%
Font subsetting: enabled (scanned document includes OCR layer)
Redundancy removal: clean duplicate objects and metadata from scanning
Grayscale conversion: color pages converted to grayscale (contract text doesn't need color)

Final result: 8.2MB, ~90% compression ratio, with text remaining clearly readable.

graph TD
    subgraph Before
        P1[80MB Scanned Contract PDF]
        P1 --> P1a[60 pages, 600DPI color scan]
        P1 --> P1b[Full embedded CJK fonts]
        P1 --> P1c[Redundant scan objects]
    end
    
    subgraph After
        Q1[8.2MB Optimized PDF]
        Q1 --> Q1a[60 pages, 150DPI JPEG]
        Q1 --> Q1b[Subset fonts]
        Q1 --> Q1c[Redundant objects cleaned]
    end
    
    P1 -->|90% compression| Q1
    
    style P1 fill:#FFC107
    style Q1 fill:#4CAF50,color:#fff

4. Image Compression

Images are the #1 culprit for file size bloat. A single smartphone photo can easily be 5-10MB, and a Word document with a dozen embedded images can quickly exceed 50MB.

4.1 Mainstream Image Format Comparison

Format	Compression Type	Transparency	Best For	Characteristics
JPEG	Lossy	No	Photos, gradients	High compression ratio, small size
PNG	Lossless	Yes	Icons, screenshots, transparent images	Full detail preserved, larger size
WebP	Lossy/Lossless	Yes	Web images	25-35% smaller than JPEG
TIFF	Lossless/Uncompressed	Yes	Printing, pro photography	Largest size, highest quality
BMP	Uncompressed	No	Rarely used	Huge size, not recommended

A simple rule of thumb: photos → JPEG, icons/screenshots → PNG, web images → WebP. Here's a more detailed decision flow:

graph TD
    A[Choose Image Format] --> B{Need transparency?}
    B -->|Yes| C{Need lossless?}
    B -->|No| D{What's the use case?}
    
    C -->|Yes| E[PNG<br/>icons/screenshots/UI]
    C -->|No| F[WebP<br/>web transparent images]
    
    D -->|Photos/gradients| G{For web use?}
    D -->|Line art/text| H[PNG<br/>avoid JPEG artifacts]
    
    G -->|Yes| I[WebP<br/>smallest size]
    G -->|No| J[JPEG<br/>best compatibility]
    
    style E fill:#4CAF50,color:#fff
    style F fill:#2196F3,color:#fff
    style I fill:#2196F3,color:#fff
    style J fill:#FF9800,color:#fff
    style H fill:#4CAF50,color:#fff

4.2 Key Parameters: Resolution and Quality Factor

# Image compression key parameters
from PIL import Image

img = Image.open("photo.jpg")  # Original 4000x3000, ~8MB

# Resolution adjustment: halve → ~75% size reduction
img_resized = img.resize((1920, 1080))

# Quality factor: 95→75, barely visible difference, ~50% size reduction
img_resized.save("photo_compressed.jpg", quality=75)
# Result: ~500KB, overall reduction ~94%

graph LR
    A[Original Photo<br/>4000×3000<br/>~8MB] --> B[Resolution Adjusted<br/>1920×1080<br/>~2MB]
    B --> C[Quality Factor Adjusted<br/>Q95→Q75<br/>~500KB]
    
    A --> D[Total reduction: 94%]
    
    style A fill:#FFC107
    style B fill:#FF9800,color:#fff
    style C fill:#4CAF50,color:#fff
    style D fill:#2196F3,color:#fff

Resolution: Scaling 4000×3000 down to 1920×1080 reduces size by 75%+
Quality factor: Dropping JPEG quality from 95 to 75 is virtually indistinguishable to the human eye, yet cuts size by 50%
Sweet spot: JPEG quality around 75 is sufficient for most use cases

5. Video Compression

Video files are the largest of all file types. A 1-minute 4K video can exceed 400MB, and even a 1080p screen recording can be over 100MB.

5.1 Codec Comparison

Codec	Compression Efficiency	Compatibility	Encoding Speed	Best For
H.264 (AVC)	Baseline	Excellent (nearly all devices)	Fast	General use, email, mobile
H.265 (HEVC)	40-50% smaller than H.264	Good (some older devices unsupported)	Medium	Storage archival, HD video
VP9	Close to H.265	Good (primarily web)	Medium	Web video, YouTube
AV1	20-30% smaller than H.265	Growing	Slow	Future standard, streaming

graph LR
    subgraph Increasing Compression Efficiency
        H264[H.264<br/>Baseline 100%] --> H265[H.265<br/>saves 40-50%]
        H265 --> VP9[VP9<br/>~H.265 level]
        VP9 --> AV1[AV1<br/>saves 20-30% more]
    end
    
    subgraph Decreasing Compatibility
        C1[H.264: nearly all devices] --> C2[H.265: most devices]
        C2 --> C3[VP9: mainly web]
        C3 --> C4[AV1: emerging]
    end
    
    style H264 fill:#4CAF50,color:#fff
    style AV1 fill:#FF9800,color:#fff

5.2 Bitrate Control Strategies

# FFmpeg video compression examples

# Email: H.264 + 720p + CRF 28 (~5-10MB for 1 min)
ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset medium \
  -vf scale=1280:720 -r 30 -c:a aac -b:a 128k output_email.mp4

# Web publishing: H.264 + 1080p + CRF 26
ffmpeg -i input.mp4 -c:v libx264 -crf 26 -preset medium \
  -vf scale=1920:1080 -r 30 -c:a aac -b:a 192k output_web.mp4

# Archival: H.265 + original resolution + CRF 20
ffmpeg -i input.mp4 -c:v libx265 -crf 20 -preset medium \
  -c:a aac -b:a 192k output_archive.mp4

Three bitrate control modes compared:

CRF (Constant Rate Factor): Quality stays constant, bitrate varies with scene complexity — most recommended
CBR (Constant Bitrate): Bitrate stays fixed, suitable for live streaming
VBR (Variable Bitrate): Dynamically adjusts within a specified range, ideal for precise target size control

graph TD
    A[Video Bitrate Control] --> B[CRF - Constant Rate Factor]
    A --> C[CBR - Constant Bitrate]
    A --> D[VBR - Variable Bitrate]
    
    B --> B1[Constant quality]
    B --> B2[Bitrate varies with complexity]
    B --> B3[Best for: general compression]
    B --> B4[Typical range: 20-28]
    
    C --> C1[Fixed bitrate]
    C --> C2[Wastes bandwidth on simple scenes]
    C --> C3[Best for: live streaming]
    
    D --> D1[Bitrate fluctuates within range]
    D --> D2[Precise target size control]
    D --> D3[Best for: storage-constrained scenarios]
    
    style B fill:#4CAF50,color:#fff
    style C fill:#FF9800,color:#fff
    style D fill:#2196F3,color:#fff

6. OFD Compression

OFD (Open Fixed-layout Document) is a document format defined by the Chinese national standard GB/T 33190-2016, widely used in government agencies and public institutions for electronic official documents. International teams working with Chinese partners may encounter this format in cross-border business.

6.1 OFD vs. PDF: Key Differences

Dimension	OFD	PDF
Standard	Chinese National Standard GB/T 33190-2016	ISO 32000 International Standard
File structure	XML + ZIP container, open structure	Binary/text mixed, relatively closed
Use cases	Government docs, electronic certificates, bidding	General documents, contracts, reports
Signature support	Native electronic seals, compliant with Chinese crypto standards	Digital signatures supported, Chinese crypto needs adaptation

6.2 OFD Compression Methods

An OFD file is essentially a ZIP archive containing XML files that describe pages, text, images, and other elements. Compression methods are similar to PDF:

Image resampling: Reduce high-resolution images to appropriate resolution (300dpi → 150dpi)
Font subsetting: Keep only the character glyphs actually used in the document
Clean redundant objects: Remove unreferenced resources and duplicates
Image format optimization: Convert uncompressed bitmaps to JPEG

A 50MB OFD scanned government document can typically be compressed to 8-12MB with proper processing.

graph TD
    A[OFD File Structure] --> B[ZIP Container Layer]
    A --> C[XML Description Layer]
    A --> D[Resource Layer]
    
    B --> B1[Doc_0/ document directory]
    B --> B2[Pages/ page directory]
    B --> B3[Res/ resource directory]
    
    C --> C1[Document.xml - doc description]
    C --> C2[Page_N.xml - page description]
    C --> C3[Signs/ - signature info]
    
    D --> D1[Image resources]
    D --> D2[Font resources]
    D --> D3[Color spaces]
    
    E[Compression Optimization] --> E1[Image resampling]
    E --> E2[Font subsetting]
    E --> E3[Remove unreferenced resources]
    E --> E4[Bitmap → JPEG]
    
    style A fill:#2196F3,color:#fff
    style E fill:#4CAF50,color:#fff

7. Local vs. Online Compression: Security Considerations

7.1 Fundamental Differences

graph LR
    subgraph Local Compression
        L1[User Device] --> L2[Local Compression Engine]
        L2 --> L3[Compressed File]
        L4[Files never leave the device]
    end
    
    subgraph Online Compression
        O1[User Device] -->|Upload file| O2[Third-party Server]
        O2 --> O3[Server-side compression]
        O3 -->|Download result| O4[User Device]
        O5[Files traverse network<br/>retention risk exists]
    end
    
    style L2 fill:#4CAF50,color:#fff
    style O2 fill:#FFC107
    style L4 fill:#E8F5E9
    style O5 fill:#FFF3E0

Dimension	Local Compression	Online Compression
Data location	Stays on local device	Uploaded to third-party server
Data transfer risk	None	Potential data exposure in transit
Third-party risk	None	Leakage and retention risk
Audit trail	Enterprise can log processing	Operations outside enterprise logging
Network dependency	None	Required

7.2 Compliance Considerations

With regulations like GDPR (EU), CCPA (California), PIPL (China's Personal Information Protection Law), and HIPAA (US healthcare), organizations must consider:

Data transfer risk: Using overseas online tools to process sensitive files may trigger regulatory reporting obligations
Third-party processing risk: Even if providers promise deletion, transmission logs and backup mechanisms may leave traces
Audit trail gaps: Many regulations require data processing logs to be retained for 6+ months — employees using personal online tools creates compliance blind spots

Core principle: classify data, prioritize local processing, maintain audit trails.

8. How to Choose a Compression Tool

When evaluating compression tools, consider these dimensions:

Dimension	Key Question
Format support	Can it handle PDF, images, video, Office documents, and more?
Compression ratio	How effective is compression at equal quality? Are multiple compression levels available?
Data security	Does it require file upload? Local or cloud processing?
Batch processing	Can it compress multiple files simultaneously? Queue management?
Platform support	Windows, macOS, Linux? Apple Silicon support?
Resource usage	Does compression impact other applications? Is CPU/memory usage controllable?
Cost	What are the free tier limits? Is the paid pricing reasonable?

9. FAQ

Q1: Will compression reduce image quality?

It depends on the compression method. Lossless compression won't reduce quality, but lossy compression trades some detail for smaller size. Choosing the right compression level balances size and quality. Generally, compressing PDF to 150dpi is perfectly fine for screen reading — the difference is virtually imperceptible.

Q2: What's the difference between 7-Zip and specialized content compression tools?

7-Zip is an archive compression tool that packages files into .7z/.zip archives — when extracted, the files are restored to their original size. Specialized content compression tools directly reduce the size of individual files (PDF, images, video) — the compressed file can be opened immediately without extraction. They serve different purposes: the former is for bundling, the latter for reducing individual file size.

Q3: What if my PDF got larger after compression?

This typically happens with PDFs that are already highly compressed. If internal images are already low-resolution JPEG, re-encoding may introduce overhead. Prioritize redundant object removal and font subsetting — lossless operations that avoid re-encoding already compressed images.

Q4: Can I compress PDFs without an internet connection?

Yes. Local compression software can run entirely offline — files never touch the network. Open-source options like Ghostscript and PyMuPDF can perform local PDF compression via command line or programmatically, suitable for handling sensitive or classified documents. Commercial software typically offers friendlier interfaces and multi-format support.

Q5: What's the optimal JPEG quality factor?

Generally, JPEG quality 75 is the sweet spot for balancing size and visual quality. Above 75, the human eye can barely tell the difference; below 75, noticeable blocky artifacts begin to appear. For extreme compression needs (like email attachments), 60 is acceptable; for high-quality preservation (like photography portfolios), 90+ is recommended.

Summary

File compression isn't rocket science, but choosing the right method can save you enormous time and storage. The core principles:

Know your goal: Email / web publishing / archival — different scenarios call for different parameters
Choose the right approach: Lossy vs. lossless, archive vs. content compression
Prioritize data security: Choose local compression for sensitive files to avoid compliance risks

Quick reference table:

File Type	Recommended Parameters	Expected Compression
Scanned PDF	600DPI → 150DPI + JPEG Q72	80-90%
Photos	Halve resolution + JPEG Q75	75-94%
Video for email	H.264 + 720p + CRF 28	90-95%
Video for web	H.264 + 1080p + CRF 26	80-90%
Video for archival	H.265 + original resolution + CRF 20	50-70%
OFD documents	Image resampling + font subsetting	75-85%

This is an original technical article. Feel free to share and repost with attribution.

Stop your AI agent from redoing finished work

Sat, 17 Oct 2026 19:17:43 +0000

I maintain Selvedge. This article was prepared with AI assistance and checked against the released v0.3.17 documentation.

A recent question in the OpenAI Codex discussions describes a familiar failure. After months of AI-assisted development on an internal business app, the author asks: "How do experienced developers prevent AI coding agents from producing disconnected code and repeatedly rebuilding or breaking previously completed functionality?" (openai/codex #52835). I'm citing it as a clear public statement of the problem, not as a Selvedge user story.

A new session sees the code but not its history. It doesn't know which feature was signed off last week, or which "obvious" improvement was already tried and dropped. From the agent's point of view, rewriting a working module is as reasonable as extending it.

Most of the fix is process, not tooling. These tactics work with any agent.

1. Write "done" down where the agent will read it

An agent can't respect a boundary it never sees. Keep a short, maintained list of completed areas in the instruction file your agent loads at startup (for example AGENTS.md, CLAUDE.md, GEMINI.md or a Cursor rules file, depending on the client). For each entry, name the files or modules, the behavior that is finished, and the test that proves it:

DONE: approval flow (src/approvals.py). Covered by tests/test_approvals.py.
Extend it; do not restructure it without asking.

Prune it regularly; a stale list gets skimmed.

2. Make finished behavior executable

A sentence saying "the approval flow works" is weaker than a test that fails when it stops working. Before you call a feature done, make sure at least one test exercises it from the user's side, and ask the agent to run the full suite before declaring any later task complete. A rebuild that breaks finished work then shows up as a red test rather than a surprise.

3. Record what you rejected, not just what you chose

Code shows the approach you picked. It doesn't show the alternative you ruled out, and that is exactly what a fresh session is most likely to propose again. When you decline an approach, write down three things: what you rejected, why, and what would make it worth reconsidering. An architecture decision record (ADR) or a section of your project docs works. The revisit condition matters because it stops a reasonable rejection from becoming a permanent rule.

4. Scope every task, including what not to touch

"Add CSV export to the dashboard" invites the agent to reorganize the dashboard. "Add CSV export in src/export.py; do not modify src/approvals.py or the database schema" does not. Name the files in scope and the finished areas out of scope, and keep each diff small enough to review in full.

5. Look before editing, and review against the record

Start each task by asking the agent to read the relevant notes and say what it will leave unchanged. Then review the diff against that statement. A change to a "done" file isn't automatically wrong, but it should come with a reason you can check.

Where Selvedge fits

These steps work with plain files. Their weak point is lookup: as notes grow, the right one must surface just as the agent edits a specific function or column. Selvedge is one way to handle step 3 and the lookup in step 5.

Selvedge is an open-source local decision log for coding agents. It runs as a local stdio MCP server or a CLI, stores records in SQLite under .selvedge/, needs no hosted account, and makes no LLM calls in core storage and retrieval. You or your agent save a decision, its reason and any rejected approach against an entity such as src/approvals.py::submit_for_review, users.email or deps/stripe. A later session queries that entity before editing it.

Here is a synthetic example I ran with Selvedge 0.3.17 in a temporary project. The rejection is invented for illustration:

selvedge init
selvedge log src/approvals.py::submit_for_review reject \
  --reasoning "Rejected rebuilding approvals on browser localStorage; went with the server-side approvals table instead, which passes tests/test_approvals.py. A manager on another device would not see a pending submission." \
  --constraint "Approval state must be visible to every reviewer on any device." \
  --stale-when "approval state moves to a different shared store"

Before the next edit, an agent with shell access can run selvedge prior-attempts src/approvals.py::submit_for_review, or call the prior_attempts MCP tool. In the synthetic run, the CLI returned the record labeled rejected (exact) along with the saved reasoning. The summary line still reads current status … reverted; in 0.3.17 that status covers both reverted and rejected records, and the row label shows which one it was. "Exact" means an explicit rejection was recorded. It doesn't mean the rejection was correct or still applies. selvedge blame showed the constraint and revisit condition, and selvedge search localStorage found the record. For an entity with no qualifying records, the CLI reported "No prior attempts found". That means nothing was recorded, not that nothing was ever tried.

For reviewers, selvedge export --format markdown -o DECISIONS.md writes a digest that lists explicit rejections under "Considered and rejected". Since 0.3.17, adding --check exits 0 silently when the file is current and 1 with a diff when it is stale or missing. In the synthetic run, logging a second rejection made the check exit 1 and print the missing entry. A hook or CI job can use this to catch a stale copy.

Tip: name the chosen approach inside the rejection itself. If you log a finished change and then a rejection on the same entity, prior-attempts shows the finished change as tried, then reverted.

If a rejection stops applying, selvedge supersede reopens it and keeps the original record in the history.

Limits

Only explicitly saved decisions can be retrieved. Connecting the MCP server doesn't capture every decision automatically.
Selvedge stores the reasoning a person or agent supplies. It doesn't verify that the reasoning is true or complete.
Nothing guarantees an agent will consult the record. The built-in selvedge demo runs on a temporary database; it doesn't verify your agent's configuration, activation or hooks. Check those separately in your own client.
It doesn't replace tests, scoped tasks, code review or a single maintained codebase.

If you try it, the useful test is one real rejection: save it, close the session, and check whether a new session retrieves it before proposing the same idea. Setup is in the quickstart, and the source is at masondelan/selvedge.

CRAFTER Focus: How to protect your hours of Deep Work every day (Part 3)

Sat, 17 Oct 2026 17:39:33 +0000

You know what's required for the project․ You know the project limitations and deliverables․ You know what to build for the project․

You open your IDE․ You write code․ You make progress․

Then you get a message․ A meeting is scheduled․ A new time-sensitive task arises․ You're asked to review some code․ When you return to your original task‚ you may have forgotten some information about it․

The problem is not self-control․

It is the absence of protection for sustained effort․

In Part 2‚ we discussed reasons that real engineering means clarity‚ not coding․

Now‚ my next question is:

Once you have a plan‚ what strategies can you use to maintain mental resources for executing the plan?

This is a function of Focus‚ one of the F in CRAFTER․

🧠 Cost of Multitasking

Modern software engineering is typically a group effort․

A developer's day could include tasks such as using an IDE and other collaboration software‚ including Slack and Teams‚ reviewing and working on pull requests‚ attending meetings‚ checking production alerts‚ and engaging in other conversations about unrelated tasks․

Individual activities may be fine․ Frequent and unpredictable switches between activities are a concern․

Consider a developer working on a complex business rule․ That developer learns about the domain and business rule and other relevant information and begins writing code to implement the business rule․

Then they receive a notification․

The interruption could last one minute․ Costs of the interruption include the time it takes the developer to resume work‚ including recalling prior thoughts and tasks and any assumptions helpful to completing the task․

This is an additional cost of context switching․

The cost is not only the time spent replying to the message․ It also includes time spent refocusing on what you were working on before receiving the message․

Repeated interruptions can lead to:

Additional time required for orientation․
Increased risk of overlooking corner cases․
Longer debugging time and development cycle․
More unfinished and poorly made work․
Less confidence in estimates or other commitments made about delivery times․

The goal is not to prevent collaboration․ Software engineering is a collaborative process․

The goal of the project is to develop conventions for working together that make it possible for engineering workers to perform difficult cognitive tasks․

Focus is not the same as working more․ Focus means reducing distractions that keep you from doing other work.

🎯 Deep Work as a Protected Engineering Resource

Deep Work is prolonged‚ focused concentration on a challenging task․

Options for software engineers include:

Educating yourself about a topic that you know little about․
Implementing well․
Testing a production defect․
Refactoring a complex part․
Evaluating architectural trade-offs․
Proof of concept․

These projects require skills beyond those needed to write code using an IDE․ They require skills related to maintaining mental models over time․

CRAFTER sees Deep Work as a useful guide and resource․

A general aim for most jobs is to dedicate 2-4 hours a day to Deep Work‚ if that much time is available during the workday․ This can be a goal for most people in most jobs․ It is not a general requirement or average time dedication for most jobs․

Some days include more meetings‚ code reviews‚ help with other people's problems‚ pair programming‚ system outages‚ and other interruptions․ Less time may be appropriate on some days․

The operational goal is not to earn a specific number of hours․

It is intended to protect time for work-related activities from other demands․

For framework principles‚ see CRAFTER‚ (F) Focus․

Plan the code block outside the IDE

A focus group should have a purpose․

Instead of writing:

Work on payment processing․

Define a concrete outcome:

Monitor payment status updates and identify the missing validation․ Develop a minimal implementation with tests․

Having a clear agenda reduces the amount of discussion required during the meeting․

Before starting‚ establish:

1․ Outcome: What statement should be true at the end of a session?
2․ Boundaries: What parts of the system are included?
3․ Next steps: What is the first concrete step to take?
4․ Interruptibility policy: What other events can interrupt the session?

This learning outcome is associated with the Focus concept taught in the CRAFTER course module Cognitive Clarity․

Clarity provides direction․ Persistence ensures you can continue on the path․

🔕 The Zero-Noise Protocol

The Zero-Noise Protocol is a technique for protecting work time from interruptions and other distractions․

During the block:

Slack and Teams notifications are turned off․
Notifications on the phone are disabled․
Email notifications disabled․
Unrelated browser tabs and programs are closed․
Incoming requests are executed at the end of each block except in cases of predefined interrupt conditions․

The purpose is not to become unreachable․

It is to distinguish between default and mandatory availability․

Define an emergency exception

A protocol that fails to handle emergent situations is not good engineering practice․

Teams should plan how to respond to emergency situations․ Possible responses include an emergency chat channel‚ phone call‚ and other incident-related approaches․

For instance:

Production problems with the customer experience can break the blackout period․
A security incident may result in a block being compromised․
A common status-related question can be answered later․
Optional code review during a future shared work period․

The specific requirements depend on the team's needs and objectives․

The main concern is making exceptions explicit‚ not according to how urgent other warnings are believed to be․

Make the protocol visible

A status label can inform other employees about the arrangement:

Deep Work through 11:00․ Ways to reach me for general questions: leave a message․ Way to reach me for production crises: same as before․

This tells your coworkers when you are available without them having to guess when you are available․

Protect the group‚ not just the individual․

Zero-Noise works best as a team practice․

If one engineer does not want to receive notifications and the other engineers want rapid responses‚ this process will be difficult to sustain․

Teams can take steps to mitigate these problems‚ including:

Predictable collaboration windows․
Designated authority to provide emergency services․
Explicit response-time expectations․
Policies about how to escalate incidents․
Time off meetings‚ where possible․

Zero-Noise is not a communication method․ Zero-Noise is an agreement between team members to reduce disruptions to focused work while remaining available for operational purposes․

🔄 Default Asynchronous Communication Tools

Some interviews can be done other than in person․

Many discussions between engineers can be done asynchronously to allow them to participate in discussions at times that suit them best and other work activities․

Examples include:

Routine status updates․
Justifications that do not interfere with work․
Code review comments․
Documentation questions․
Design proposals․
Feedback requests where timing is not important․

Asynchronous communication does not mean failing to communicate․ Asynchronous communication means choosing the right communication channels‚ depending on the complexity and urgency of the topic․

Write texts to reduce communication effort

A good communication from an engineer provides enough information that the recipient of the communication does not have to ask questions to learn more about the problem․

A practical structure is:

1․ Context: What project are you working on?
2․ Problem: What is unclear or hard to understand?
3․ Evidence: What have you already checked?
4․ Decision required: Response or other action needed from you?
5․ Timeline: How quickly does the person need the information?

For example:

Context: I am mapping payment statuses․

Problem: The status value returned by the external API is not one of the defined enum values in our application․

Evidence: Existing maps show three possible statuses․ The latest answer adds a new value to the possible set of values․

Decision required: Map the new status to an existing internal status or add a new internal status?

Deadline: I need to know by the end of today's map-making session․

This is better than:

Can you do me a favor when you have time?

The first message gives the recipient useful information for making a decision․ It also explicitly tells the recipient what decision to make․

Use collaboration windows

A team can establish times when team members will respond to general communications․

For example:

Morning hours are typically reserved for planning and other urgent work․
Midday: answering questions and collaborating with other employees․
Afternoon: more study time‚ if needed‚ depending on other commitments․

These are recommendations‚ not rules․ Teams should adapt these recommendations to their locale and other team considerations․

The aim is to reduce interruptions while not substantially increasing total communication time․

When synchronous communication is needed

Some issues are best resolved in a short phone conversation․ I would use this method in the following situations:

This is a complicated problem with several ways to interpret it․
Multiple individuals need to reach a decision through negotiation․
The team is responding to an incident․
Written debates are getting in the way of communication․

Asynchronous communication should be the default for many work tasks‚ not a religious stance against other types of communication․

The policy is to communicate using whatever method is easiest for you to use that effectively resolves the problem without creating other problems․

🧩 Context Switching and Technical Responsibility

Interruptions are one source of fragmentation․ Work in process is another source of fragmentation․

When an engineer has multiple tasks to complete‚ these competing tasks distract the engineer․ In the absence of other distractions‚ the engineer will be thinking frequently about how to prioritize tasks and recall information about incomplete projects․

This creates internal context switching․

CRAFTER offers a solution with a simple rule:

Limit Work In Progress (WIP) to no more than three active projects․

This is a policy imposed to encourage good prioritizing․ It is not a policy that every engineer or team should have exactly three tasks․

The idea is not to overextend yourself and to finish important projects․

Differentiate current jobs from queued jobs

A task need not be completely forgotten because we are not currently performing it․

Have a list of potential future projects ready‚ but work on a limited number of projects․

For each task you were given‚ include:

Its intended outcome․
Its current state․
The next step in the process․
Any blocking dependency․
Rules for deciding when an investigation is complete․

When a new request is made‚ do not add it to the list of current requests․

Ask:

1․ Is it more important than what you're doing now?
2․ Do I need to act now?
3․ If it needs to be active‚ what other process will be delayed?
4․ Who should know about this change?

This makes it clear about extras and prevents additional requests from being added without the requester's knowledge․

Ownership means maintaining continuity

Technical ownership doesn't mean you will be working alone․

An engineer can depend on other engineers and peer reviews‚ as well as a product owner․ Responsibilities of an engineer include maintaining the continuity of a project and other forms of communication about the work done on the project․

A task should not depend on the memory of a single person․

Document important decisions or assumptions and next steps in an appropriate place‚ such as a ticket‚ pull request‚ or Architecture Decision Record (ADR)․

This can speed your recovery from interruptions and help you work with others by assigning tasks and providing information․

Good ownership reduces the mental burden of picking up work on projects for engineers and other staff․

📊 Methods for Measuring Employee Focus Without Surveillance

CRAFTER offers Focus tools to help spot trends that make it harder to implement engineering solutions․

Metrics are best used to identify issues․ They are not good for evaluating or monitoring engineers' performance or progress․

Metric	Rule	Use Case
Deep Work Time	Recommended goal: 2–4 hours per day‚ depending on role and other considerations	Determine if sufficient time is available for deep work
WIP Limit	Three or fewer tasks in progress	Reduce multitasking and task switching
Notifications	Record interruptions while engaged in Deep Work	Identify sources of avoidable distraction

These actions are useful only with other information․

A low Deep Work score could mean you attended many meetings and completed other collaborative tasks․ It could also mean you had a busy day in other ways․ A low Deep Work score doesn't necessarily indicate poor performance․

A high level of interruptions for a team suggests that process problems may exist for the team as a whole‚ including unclear escalation rules‚ rather than personal problems with a single team member․

Likewise‚ meeting a numerical objective does not mean good engineering has been performed․

The goal is to ask better questions:

Do engineers have enough uninterrupted time for complex work?
Are interruptions preventing other work from being done at planned times?
Do you have several tasks to work on?
Do interruptions occur in particular workflows or processes?
What small change can we implement to make things better for team members?

Use answers to improve the system․

Measure the conditions of execution‚ not the engineer's worth as an engineer․

See CRAFTER Focus Metrics on this GitHub repository page for metric definitions related to the framework․

🗓️ Your Daily Priorities Process

CRAFTER's daily activities follow the Focus process principles․

1․ Pre-Flight‚ 10 minutes

Before beginning demanding work:

Review current priorities․
Choose one key task to focus on․
Help establish the goal or objective․
Determine relationships and knowledge gaps․
Prepare equipment and disable notifications for apps you don't need․

The purpose of the warm-up is to prepare for activities in the session rather than spend some session time deciding what to do in the session․

2․ Deep Work‚ Breaking the Noise Barrier

Focus on completing the assigned task without other interruptions․

Remind yourself why you are doing something․ Don't get distracted by new tasks because you think they are interesting or important․

If you need to work together‚ write a question and use other communication methods as needed‚ unless an exception to the block agreement applies․

The length of protected time should be reasonable given the length of the project and the workday․ It's better to protect less time than to set unachievable goals․

3․ 20-Minute Rule

If meaningful progress isn't being made over a period of 20 minutes‚ stop using strategies that aren't working․

Pause and reassess․

Set goals for yourself․
Assess what you know and what you don't know․
Present a flowchart or other graphic illustrating the relevant relationships․
Assess assumptions and other facts․
Determine if other actions or help may be needed․

This policy is not designed to prevent students from attempting to work through difficult problems for 20 minutes․ Rather‚ it is designed to encourage students to try different approaches if they work on a problem for 20 minutes without success․

Sometimes the best option is to do more research․ Sometimes the best option is to seek advice from a subject-matter expert․ Sometimes the best option is to reconsider the question itself․

The important thing is to perform the next step mindfully․

4․ Postflight‚ 10 minutes

End the session with a review of session highlights․

Possible applications are:

Creating a commit․
Creating or updating a pull request․
Reporting the results of the study․
Updating status information for the task․
Documenting a decision or challenge․

Then introduce an action item for the next meeting: Note an action step to be performed at the next meeting․

For example:

Next: Test for an unknown payment status․ Use the results of the test to modify the mapping function according to your expected internal state․

This small step can save time and effort in reestablishing project background information later․

See the CRAFTER Daily Protocol: The Core Loopfor instructions on this process․

🚀 Quick Answer: Introduce Focus This Week

You don't need to do anything differently than what your team members are doing to begin․

Try a small experiment:

1․ Choose a task․ Look for a task you can continue working on․
2․ Set aside time specifically for work․ 45-90 minutes may work well‚ accounting for other obligations․
3․ Suppressing Other Alerts․ Disable other alerts and specify a way to alert workers in an emergency․
4․ Limit work in progress․ Train staff to handle no more than three tasks at once and make trade-offs visible when priorities change․
5․ Provide feedback․ Take time to record accomplishments and next steps before starting other tasks․
6․ Evaluate the experiment․ Determine which interruptions could have been avoided during the experiment and ways to prevent interruptions in future experiments․

Don't evaluate the experiment based on the amount of time you spent without notifications․

Determine whether it helped you finish tasks more quickly by reducing the number of times you had to switch between tasks․

🔮 What's Next?

Focus aids performance on implementation-related tasks․ Other skills that help engineers throughout their careers include adaptability to new information and other implementation-related issues․

In the next part of CRAFTER, we will explore Technical Mastery: how engineers develop and apply technical expertise to build reliable systems, make sound engineering decisions, and maintain sustainable execution.

🧬 Conclusion: Focusing Is an Engineering Skill❤️

Engineering productivity isn't just about typing faster or responding to more emails․

Complex tasks require time to understand a problem and develop and maintain knowledge of a problem‚ including considering and balancing other factors‚ to apply effective solutions․

Interruptions to this kind of work have costs beyond lost time by workers completing interrupted tasks․ Other costs of interruptions include decreased worker concentration and quality and increased uncertainty about when tasks will be completed․

CRAFTER Focus offers a number of practical solutions to this problem:

Protect time for Deep Work․
Apply Zero-Noise policies and have clear emergency procedures․
Communicate asynchronously when you can․
Decrease work in progress․
Demonstrate technical knowledge and leadership by sharing visible decisions and next steps․
Introduce measures to assess work conditions‚ not individual employees․
Wind down at the end of each session so you can easily start the next session․

These methods won't completely prevent interruptions․ They don't need to․ Engineering is a social profession that requires collaboration‚ responsiveness‚ and adaptability․

The purpose of the method is to reduce‚ not increase‚ distractions; foster‚ not hinder‚ collaboration; and eliminate‚ not require‚ self-discipline․

Focus is more than concentration․ Focus involves setting up the proper environment for concentration to be effective․

That is what Focus is in CRAFTER․

📚 References & Further Reading

A browser editor needs a file workflow, not just a canvas

Sat, 17 Oct 2026 03:15:25 +0000

A browser application can look ready long before you know whether it will work for your files. The canvas loads, the panels look familiar, and the temptation is to import an important project immediately. A better first test follows the file all the way from an untouched source to a result you can reopen.

Craft Apps is a useful setting for that discussion. Its public collection offers 13 browser-based tool entries, and its PhotoCraft page explains both the intended image workflow and several limits of the current web build. This article draws on those pages and an inspection of the loaded editor. No edit-and-export round trip was completed, so the checklist below is a proposed test, rather than a compatibility result.

Define an observable result before importing a file

Choose one task whose outcome can be checked outside the editor. For example, a small image with a readable title at its intended display size gives you a concrete question. “Try all the features” does not. Record the source dimensions and keep the original separate from the experiment.

The photocraft landing page discusses layered image editing, text and composition, and a PSD-oriented workflow. It also cautions that a PSD can contain features that do not translate perfectly. A reasonable test therefore starts with a modest file and a known expectation. The extension alone does not tell you whether a particular layer effect will survive a round trip.

If your task depends on editable text, check editable text. If it depends on transparency, check transparency. An attractive preview can hide a loss that only becomes obvious when somebody tries to use the file later.

Separate the landing-page examples from the running build

Documentation screenshots are useful for explaining an interface. They are weaker evidence for what a particular hosted version can do. PhotoCraft’s product page explicitly identifies its images as upstream examples and says that the browser integration may expose different controls and output options.

In the actual hosted editor, the opening workspace loaded with New document and Open controls. Opening the new-document dialog showed dimensions, resolution, RGB color mode, bit depth and background settings. That observation establishes that the controls were visible. It does not establish successful import, rendering fidelity or export behavior.

This separation is useful when reporting a bug, too. Name the current build and the exact file behavior you observed. A screenshot from a different release can help explain your expectation, but the report should still identify what happened in your session.

Treat saving as a separate acceptance step

The live product page says the web build opens files through the browser picker and saves by download. It also states that there is no web autosave or crash recovery. Those details change how you should structure a first test: keep it short enough to save and inspect before investing substantial work.

After using an available save or export command, locate the downloaded file. Reopen it in the application that will receive the work, or in a fresh editing session when continued editing is the requirement. Check the dimensions and the properties that mattered in your original task.

Keep a working version separate from a sharing copy when the available formats support that distinction. A flattened image and a reusable layered project serve different purposes. A file that opens successfully can still be unsuitable for the next step, so acceptance should follow the intended use.

Write down what passed and what remains unknown

A small test record can be a few lines: the source file, the intended change, the save option selected, the location of the download and the result of reopening it. Add any mismatch you saw. This makes the next decision easier than relying on whether the canvas looked convincing.

For this inspection, the public product notes, loaded workspace and new-document controls were observed. Import fidelity, export fidelity and recovery behavior were not independently tested. The site’s stated limits remain part of the decision.

A browser photo editor becomes useful for a particular job when its file workflow supports that job. Start with a source you can afford to experiment on, define a visible result, and finish the saving check before scaling up the work.

What habits daily make you a really great software engineer?

Fri, 16 Oct 2026 17:09:05 +0000

Well, what do you think what are some top notch habits that makes you in top zone of engineering

Why I Built Total Connect: A Modern Open-Source FileZilla & Total Commander Alternative in Go

Fri, 16 Oct 2026 12:29:23 +0000

For decades, FileZilla and Total Commander have been staples for sysadmins, developers, and power users. But let’s be honest:

FileZilla paywalls essential cloud protocols (S3, Google Drive, OneDrive) behind a commercial Pro license.
Managing files on remote headless servers or mobile devices without X11/GUI forwarding is still a headache.
Security and plaintext password storage have historically plagued legacy FTP clients.

To solve this, I built Total Connect — a modern, unified, open-source file manager and transfer ecosystem written in Go, powered natively by rclone.

What makes Total Connect different?

Tri-Interface Architecture (TUI + Web + CLI):
- Interactive Terminal UI: Powered by Charmbracelet (bubbletea, lipgloss) featuring classic dual-pane navigation, Total Commander shortcuts (F5, F6, F8), and multi-file selection.
- Headless Web Daemon: An embedded, responsive web interface that runs on any remote machine, VPS, or Google Colab, featuring a modern Fluent design and touch tabs for mobile browsers.
- Scriptable CLI: For quick headless operations.
50+ Cloud Providers via Rclone:
Rather than wrapping rclone via subprocesses, Total Connect imports rclone directly as internal Go modules. This enables true atomic operations, password obfuscation, and zero-overhead transfers.
No Setup Friction:
- Single static binary for Linux, macOS, and Windows (Intel & ARM).
- In-app "+ Add Connection" wizard for FTP, SFTP, WebDAV, S3, Mega, and Google Drive without editing config files.

Try it out:

Grab the latest v0.1.0 release:
GitHub Repository: https://github.com/M5Devs/Total-Connect
Releases & Binaries: https://github.com/M5Devs/Total-Connect/releases/tag/v0.1.0

I'd love to hear your feedback, feature requests, and contributions! Let me know what you think in the comments below.

How I Built My Reading Companion App, And How I Went Around The Storage Layer.

Fri, 16 Oct 2026 08:18:52 +0000

Building tools for yourself is arguably the most effective way to level up as a software engineer. There is no product manager handing down arbitrary specs, no artificial constraints, and most importantly, no room to ignore bugs when you are the primary end user.

Recently, I shipped the working version of my book review and jotting system. What started as a personal fix for passive reading evolved into a full development sprint involving branding pivots, state management headaches, and deep dives into browser persistence.

Here is the technical breakdown of how the build came together, the naming hurdle, and the architectural issues I ran into while handling local storage and book rendering.

The Core Problem: Passive Reading

Most reading workflows in tech are broken. We buy books, skim through hundreds of pages, bookmark a few passages, and two weeks later struggle to articulate a single foundational concept from the text.

Highlighters and generic note applications scatter thoughts across disconnected interfaces. I needed a focused, low-latency workspace that forced active retention—a structured workflow to capture raw notes, link chapters, synthesize main arguments, and track reading velocity without friction.

The Naming Conflict: Pivoting Early

In early development, the working title for the project ran straight into a trademark and existing namespace collision. An established tool in the developer/reading productivity space was already operating under the same name.

It is easy to get emotionally attached to a project name and stall progress. But early on, engineering priorities need to override branding.

I decoupled the product identity from the codebase:

Focused 100% of the compute on getting the core MVP functional.

Rebranded cleanly once the interaction architecture stabilized.

Code functionality first. Marketing and branding second.

The MVP Architecture: Why Local Storage First?

Before wiring up a remote database and authentication layer, I wanted an ultra-fast, offline-first client build to validate the reading UX immediately. I opted for local client storage to achieve zero-latency read/write operations during testing.

However, treating browser localStorage as a makeshift application database quickly revealed several classic pitfalls.

Trap 1: The Serialization and Deserialization Overhead

In a document-heavy application, notes are not just flat strings; they are structured data trees containing chapter indices, timestamps, nested quotes, and tags, because localStorage only accepts DOMString values, every update required parsing and serializing massive JSON strings.
As notes accumulated across multiple books, calling JSON.stringify(libraryState) on every keystroke in auto-saving note inputs led to noticeable UI thread stuttering.

The Fix:
I debounced the persistence logic and separated the global library state from the active note editor state. Instead of writing the entire collection on every character entry, updates were held in component state and flushed to storage only after a specified inactivity threshold:

The Boss Fight: Displaying the Book and Syncing State

The most frustrating technical challenge was rendering the selected book dynamically alongside its associated notes and progress tracking without desynchronizing the view.

The Problem: Ghost Renders and Stale Data

When selecting a book from the shelf to open in the active reading workspace, the app frequently displayed stale metadata or threw runtime exceptions:

Hydration Mismatches: If the user refreshed the page while viewing a specific book ID, the reader route loaded before localStorage had re-hydrated the global state, causing empty display cards or TypeError: Cannot read properties of undefined.

Key Synchronization in Component Trees: Modifying notes inside a sub-component wasn't reflecting back in the parent book shelf overview without a manual page reload.

How I Resolved It:

Resilient Lookup and Fallback Boundaries

Instead of relying on fragile index lookups (books[index]), I switched to unique hash keys (UUID) and wrapped the book viewer in strict boundary guards:

Atomic Storage Updates via Custom Hooks

To solve the stale data synchronization bug across decoupled views, I centralized all storage read/write operations inside a custom hook (usePersistentStorage). This hook acts as a single source of truth, synchronizing local React state with native browser storage events. This clean abstraction eliminated direct, uncontrolled calls to localStorage across nested components and fixed the book display rendering bugs once and for all.

What’s Next: Migrating to the Relational Cloud

Building and battle-testing the client MVP using local storage achieved its primary goal: it validated the user experience under heavy daily reading sessions. I finished one full book using the tool and am actively managing three more on the platform.

However, local storage is inherently limited:

It is locked to a single browser profile and device.

It caps out around 5MB.

It offers zero data durability if browser data is cleared.

The next engineering phase is migrating this data model into a scalable backend. I have opted for Supabase (PostgreSQL) to handle user authentication, relational table modeling for book-to-note foreign key relationships, and row-level security.

Key Takeaways

Don't let vanity blockers halt development: If your project name is taken, decouple your logic and keep shipping.

Treat local storage with respect: Avoid raw JSON parsing on hot render paths; debounce writes and structure your schema early.

Dogfood your software: You find the nastiest UI and state bugs only when you use your own build under realistic daily pressure.

The live version is up, stable, and actively handling notes. Now, onto the data layer.
This is the live link: https://sovari.netlify.app/

Your AI Knows How to Answer. But Can You Keep Track of Your Research?

Fri, 16 Oct 2026 07:56:46 +0000

If you use ChatGPT, Claude, or Gemini for research, you probably know this workflow:

You find a useful article, save a few quotes, open multiple tabs, start a conversation with an AI assistant—and eventually lose track of where the information came from.

I built MindContext to make that workflow easier.

MindContext is a Chrome extension that helps you collect web research, keep notes and quotes connected to their original sources, organize information into projects, and send relevant context to your preferred AI assistant.

🔎 What can you do with MindContext?

Save notes and quotes linked to their original webpages.
Organize research into dedicated projects.
Extract clean webpage content for AI conversations.
Create reusable prompt templates for workflows such as academic research, competitor analysis, and code review.
Send your collected context to ChatGPT, Claude, or Gemini.
Keep your research data locally in your browser.

🚀 What does MindContext Pro add?

Pro is designed for people who regularly work with large amounts of research:

📺 YouTube transcript support — Extract video transcripts with timestamps and add them to your AI context.

📁 Unlimited research projects and sources — Free supports up to 3 projects and 5 sources per project. Pro removes these limits.

🎨 Four-color highlighting — Organize important information with yellow, green, blue, and pink highlights instead of a single color.

📝 Unlimited custom prompt templates — Free supports up to 3 custom templates; Pro lets you create and save as many as you need.

🔗 Saved AI chat links — Save specific ChatGPT, Claude, or Gemini conversation links and send your context to your chosen conversation instead of starting from scratch each time.

💰 Simple pricing, privacy-focused design

MindContext Pro costs $24 per year (approximately $2 per month), currently discounted from the $39 list price.

License activation through Lemon Squeezy
Use on up to 3 devices
Your research data stays in your browser's local storage. The Pro license unlocks features; it doesn't move your notes to a separate cloud database.

I built MindContext because I wanted a more practical way to move between web research and AI conversations without losing the source material along the way.

I'd love feedback from people who use AI for research, development, technical writing, or competitive analysis.

What's the biggest friction point in your current research-to-AI workflow? And what would make a tool like this genuinely useful to you?

🔗 Chrome Web Store: https://chromewebstore.google.com/detail/mindcontext-ai-research-n/nmagjifaanaaddbogdebppjdcoaignnd?hl=en

Slop de código: o custo invisível

Thu, 15 Oct 2026 21:16:28 +0000

Nunca foi tão fácil produzir código. Um assistente de IA entrega, em minutos, o que levava uma tarde. O dashboard de velocidade sobe, o número de PRs sobe, a sensação é de que o time está voando.

O problema é que nada disso mede o que acontece depois: quem revisa, quem entende, quem mantém, o que quebra em produção. Esse é o custo invisível, e ele aparece com atraso, com juros.

Neste artigo, uso o termo slop de código para um tipo específico de código: aquele que parece correto, passa no lint e nos testes, mas que ninguém decidiu de verdade e ninguém consegue explicar. É informal, não é uma métrica. Mas dá nome a algo que muita gente já sentiu no code review.

TL;DR

📈 Gerar ficou barato. Revisar, entender e manter não ficou.
🧱 Em dados de 2025, alta adoção de IA aparece junto de PRs maiores, revisões mais longas e mais bugs por dev, sem ganho claro no nível da empresa.
🧠 O custo mais perigoso é o que ninguém vê: código que a equipe não compreende.
🛡️ Mitigação: PR pequeno, dono de cada linha, intenção antes do código, guardrails automáticos e métricas que medem o custo de verdade.

O que é (e o que não é) slop de código

Não é "código ruim de IA". A IA também escreve código bom, e humanos escrevem slop o tempo todo.

É o código que entra no repositório sem passar por uma decisão humana real:

ninguém escolheu aquela abstração, ela simplesmente apareceu;
ninguém checou se já existia um helper para aquilo;
ninguém leu o diff inteiro, porque ele tem 800 linhas;
os testes passam, mas porque espelham a implementação, não porque verificam o comportamento.

Alguns exemplos ilustrativos de como ele costuma se apresentar:

Flutter: um widget novo que duplica um componente do design system; um segundo gerenciador de estado ao lado do que o projeto já usa; mais um wrapper de HTTP idêntico aos existentes.
Go: interface criada "por precaução" com uma única implementação; erro retornado e ignorado; helper que reimplementa algo da biblioteca padrão.

Nenhum desses quebra o build. Todos aumentam o custo de mudar o sistema amanhã.

O que os dados dizem (e o que não dizem)

Antes dos números, uma ressalva: são dados de 2025, de ferramentas que evoluíram desde então, e a maioria mede associação, não causa. Eu os uso para mostrar o padrão, não para dar uma sentença.

1. Mais código, fila de revisão maior

O relatório AI Productivity Paradox, da Faros AI, analisou telemetria de mais de 10 mil desenvolvedores em 1.255 times. Nos times de alta adoção de IA, em comparação com os de baixa adoção:

Métrica	Variação
Tarefas concluídas	+21%
Pull requests mergeados	+98%
Tamanho médio do PR	+154%
Tempo de revisão	+91%
Bugs por desenvolvedor	+9%

No nível da empresa, o mesmo estudo não encontrou correlação significativa com melhoria em vazão, métricas DORA ou indicadores de qualidade. Os autores deixam claro que são associações, não causalidade. A leitura que eles sugerem: gargalos a jusante, como revisão e testes, absorvem o ganho individual.

2. Mais volume, menos estabilidade

O relatório DORA 2025 (State of AI-assisted Software Development) trouxe duas mensagens ao mesmo tempo. A boa: ao contrário do ano anterior, a adoção de IA aparece associada a mais vazão. A outra: ela continua associada a menos estabilidade de entrega.

A frase do relatório que resume: "Sem sistemas de controle robustos, como testes automatizados fortes, práticas maduras de versionamento e ciclos de feedback rápidos, um aumento no volume de mudanças leva à instabilidade." E a tese central: a IA amplifica o que já existe na sua equipe, para o bem e para o mal.

Dois números de contexto do mesmo relatório: cerca de 90% dos respondentes usam IA no trabalho e cerca de 30% dizem ter pouca ou nenhuma confiança no código gerado.

3. Mais duplicação, menos refatoração

A GitClear analisou 211 milhões de linhas alteradas entre 2020 e 2024, em repositórios de grandes organizações. Entre 2021 e 2024:

linhas copiadas e coladas passaram de 8,3% para 12,3% das linhas alteradas;
linhas movidas, um sinal de refatoração, caíram de 25% para menos de 10%;
pela primeira vez no conjunto de dados, copiar e colar superou mover código.

É correlação com a chegada das ferramentas, não um experimento controlado, e a amostra é de empresas grandes.

4. Segurança

A Veracode testou mais de 100 modelos e relatou falhas de segurança em 45% dos testes com código gerado. O ponto que mais chama atenção no relatório: modelos maiores e mais novos não melhoraram a segurança.

5. Compreensão: o custo que ninguém mede

Addy Osmani chama de dívida de compreensão (comprehension debt) a distância crescente entre quanto código existe no sistema e quanto dele alguém realmente entende. Diferente de dívida técnica, ela não gera atrito visível: o código parece limpo e os testes passam.

Ele cita um ensaio randomizado da Anthropic com 52 engenheiros aprendendo uma biblioteca nova. O grupo com IA terminou no mesmo tempo, mas teve 17 pontos percentuais a menos no teste de compreensão (50% contra 67%), com a maior queda em depuração. Quem usou a IA de forma ativa, fazendo perguntas, foi melhor do que quem apenas delegou.

6. Percepção: a sensação não é medida

Em 2025, o METR rodou um experimento com 16 desenvolvedores experientes em 246 issues reais de repositórios que eles conheciam bem. Com IA liberada, levaram 19% mais tempo. Eles esperavam ser 24% mais rápidos e, depois, ainda acreditavam ter sido 20% mais rápidos.

Dois avisos que o próprio METR dá: a amostra é pequena e específica, e o resultado está desatualizado. Um acompanhamento de 2026, com mais desenvolvedores, aponta possível ganho, mas com estimativas inconclusivas e vieses de seleção que o próprio METR descreve.

A lição que sobrevive não é "IA é lenta". É esta: a sensação de produtividade não é uma medida de produtividade.

Onde o custo se esconde

Juntando as peças, o custo do slop aparece em quatro lugares que nenhum dashboard de velocidade mostra:

Na fila de revisão. Mais código chegando para a mesma capacidade de revisar. A revisão deixa de ser portão de qualidade e vira gargalo de vazão.
Na compreensão. O código existe, funciona, e ninguém sabe por quê. Mexer nele vira risco.
Na manutenção. Duplicação em vez de reuso, abstração sem dono, refatoração que nunca acontece.
Na estabilidade. Volume de mudança maior que a capacidade de teste e de feedback.

Como mitigar

As cinco práticas abaixo são recomendações minhas, derivadas desses dados e da lógica do problema. Não saíram de nenhum dos estudos como "receita".

1. Reduza o que chega: PR pequeno, uma intenção

O número que mais incomoda nos dados é o tamanho do PR. Revisão de verdade não acontece em 800 linhas.

Estabeleça um teto prático de diff e quebre o que passar dele.
Um PR, uma intenção. Se a descrição precisa de "e também", são dois PRs.
Peça para a IA gerar em passos pequenos, não "a feature inteira".

2. Dono de cada linha

Regra de bolso: quem commita é dono, não importa quem escreveu.

Se você não consegue explicar uma linha, ela não entra.
Autorrevise o diff antes de pedir revisão. Remova o que você não pediu.
Prefira apagar: o melhor PR com IA muitas vezes tem menos linhas do que o que ela propôs.

3. Intenção antes do código

Boa parte do slop nasce de um pedido vago. Quanto mais lacuna na especificação, mais decisão o modelo toma sozinho. Defina comportamento, casos de borda e o que está fora de escopo antes de gerar. (Escrevi sobre isso em outro artigo, sobre revisar a especificação antes do código.)

4. Guardrails automáticos

O DORA é direto: sem controles robustos, volume vira instabilidade. O que dá para automatizar deve ser automatizado:

testes que verificam comportamento, não que repetem a implementação;
lint e análise estática no CI, sem exceção para código "gerado";
detecção de duplicação e limite de complexidade;
varredura de segurança (SAST, dependências);
reuso por padrão: dê ao modelo contexto do que já existe e peça para procurar antes de criar.

5. Meça o custo, não a produção

Pare de olhar apenas para linhas entregues e PRs mergeados. Acompanhe:

tempo de revisão e de espera por revisão;
tamanho médio de PR;
churn: código alterado pouco depois de entrar;
taxa de falha de mudança e tempo de recuperação;
quanto do código crítico mais de uma pessoa consegue explicar.

Calibre pelo risco

Nem todo código merece o mesmo rigor. Um script descartável pode tolerar slop. Autenticação, pagamento e migração de dados, não. Decida antes de qual categoria é a mudança.

Checklist rápido

Antes de abrir o PR (autor)

[ ] Consigo explicar cada linha deste diff?
[ ] Isso já existia no repositório? Procurei antes de criar?
[ ] Removi o que não foi pedido?
[ ] Os testes verificam comportamento ou só espelham o código?
[ ] O PR tem uma intenção só?

Na revisão (revisor)

[ ] A descrição diz o que e por quê, não só o como?
[ ] Há abstração nova sem necessidade clara?
[ ] Há duplicação de algo que já existe?
[ ] Erros e casos de borda estão tratados, ou só o caminho feliz?
[ ] Eu entenderia isso daqui a seis meses?

Fechando

A IA mudou o custo de produzir código. Não mudou o custo de entender, revisar e manter. Quando só o primeiro cai, o resto do sistema vira o gargalo, e o prejuízo chega depois, em revisão travada, incidente e código que ninguém quer tocar.

Os dados ainda estão se formando, e vão mudar conforme as ferramentas melhoram. Mas a pergunta útil não muda: se o seu time passou a entregar muito mais código, quem aumentou a capacidade de revisar?

Como vocês lidam com isso no time? Que prática fez diferença de verdade?

Fontes :

Trabalho como Flutter Sênior remoto, com Go como segunda stack. Se quiser trocar ideia sobre desenvolvimento com IA e qualidade de código, me encontra no GitHub ou no LinkedIn.

Toolblip Free Tools

Wed, 14 Oct 2026 20:21:59 +0000

Toolblip is a curated directory of free online tools and software for developers, makers and small teams.

How it works

Browse tools by category, compare options side by side and bookmark the ones you like. Every listing is reviewed so you find useful utilities fast, without digging through ads.

Key features

Hand picked free tools across dev, design, AI and productivity
Clean categories and search
Free to use, no signup required to browse

Try it at https://toolblip.com and suggest tools you love.

How to bulk edit Azure DevOps work items without Excel (works on Mac)

Wed, 14 Oct 2026 13:45:05 +0000

title: "How to bulk edit Azure DevOps work items without Excel (works on Mac)"
published: true
description: "Open in Excel needs the Office add-in and Windows. Three ways to edit many Azure DevOps work items at once: bulk edit in the query, CSV import, or a spreadsheet grid in the browser."
tags: azuredevops, productivity, agile, tutorial
canonical_url: https://jr-devtools.com/guides/bulk-edit-azure-devops-work-items-without-excel/

cover_image: https://jr-devtools.com/bulk-editor/screenshot-grid.png

Disclosure: I'm the developer of Bulk Editor, one of the options mentioned below. Originally published on jr-devtools.com.

“Open in Excel” relies on the Azure DevOps Office Integration add-in: Windows only, and a frequent source of TF80012-style errors and Excel crashes. If you're on a Mac, can't install the add-in, or just want it to work, here are three ways to edit many work items at once.

1. Bulk edit in the query results (built in)

In a query or backlog, select several work items (Shift- or Ctrl-click), open the context menu and choose Edit. You can set one or more fields to the same value for all selected items, for example a new iteration, state or assignee.

Good: built in, nothing to install. Limit: every selected item gets the same value, so it doesn't help when each row needs its own estimate, title or tag.

2. CSV export and import (built in)

Run a query, export it with Export to CSV, edit the file in any spreadsheet app, and bring it back with Boards → Work items → Import work items. Rows with an ID update existing items, rows without one create new items.

Good: works on any OS, handles different values per row. Limits: rich-text fields such as Description are exported as raw HTML; errors only show up at import time; and nothing warns you if someone changed a work item after your export.

3. A spreadsheet grid in the browser

Bulk Editor (made by me) opens a query, a backlog selection or any list of work items in a spreadsheet-like grid inside Azure DevOps:

type in cells, use Enter and Tab, paste a block copied from Excel, and undo;
pick lists, required fields, states and area/iteration paths come from your own process, and invalid values are flagged before you publish;
nothing is saved until you select Publish, and a row that someone else changed in the meantime is refused instead of overwritten;
rich-text fields are never flattened; export to a clean .xlsx without HTML tags;
Pro: import .xlsx back, add new work items and children, and change parents in tree queries.

Good: nothing to install on your computer, works on Mac and Linux, different values per row with validation. Limits: Azure DevOps Services only for now; Pro is paid ($12 per organization per month), with a free plan of 25 published work items per organization per month and a 14-day Pro trial.

Which one should I use?

You want to …	Use
Move 40 items to the next sprint	Bulk edit in the query
Create a few hundred items once, from a plan someone sent you	CSV import
Groom a backlog: different estimates, titles and owners per row, regularly	A grid in the browser
Keep working in Excel on Windows with formulas	Open in Excel still does that, if the add-in works for you

Not affiliated with Microsoft. “Azure DevOps”, “Excel” and “Office” are trademarks of Microsoft.

Alternatives to the DevLabs Pull Request Merge Conflict Extension (2026)

Wed, 14 Oct 2026 13:44:34 +0000

title: "Alternatives to the DevLabs Pull Request Merge Conflict Extension (2026)"
published: true
description: "Microsoft's DevLabs merge conflict extension for Azure DevOps is no longer maintained. An honest comparison of the alternatives: resolving locally, your IDE, and a maintained extension."
tags: azuredevops, git, devops, productivity
canonical_url: https://jr-devtools.com/guides/devlabs-merge-conflict-extension-alternatives/

cover_image: https://jr-devtools.com/merge-conflict-resolver/screenshot-editor.png

Originally published on jr-devtools.com.

For years, the free Pull Request Merge Conflict Extension from Microsoft DevLabs (ms-devlabs.conflicts-tab) was how teams resolved conflicts without leaving Azure DevOps. It is no longer maintained. Here's what's going on and what you can use instead.

Disclosure: we make Merge Conflict Resolver, one of the options below. We've tried to keep this comparison fair; corrections are welcome at support@jr-devtools.com. Last checked: October 2026.

Is the DevLabs extension still supported?

No. Its last update was in November 2023, and Microsoft wrote in the extension's Q&A that “there are no current development resources for this extension”. Questions like “Is this even supported anymore?” go unanswered. Since 2024 its reviews average about 1.6 out of 5. The most reported problems:

the tab freezes or keeps “taking longer than expected to load”, and work is lost when it crashes;
non-ASCII characters (ä, é, č, Hebrew, Chinese …) are changed, especially in UTF-8 and ANSI files;
you can only take a whole file from one side, not choose per conflict or keep both;
the resolution lives only in the pull request's merge commit, so reviewers and builds never see it;
large files such as package-lock.json, or many conflicts, make it hang.

It still works for some teams on simple conflicts, so there's no need to remove it in a hurry. But if you run into the problems above, there won't be a fix.

The alternatives

1. Resolve locally with Git (free)

Merge the target branch into your source branch, resolve in your editor, and push. See our step-by-step guide.

Good: free, always works, you can build and test before pushing. Less good: you need the repository cloned and a working Git setup; slow for a two-line fix or for someone else's pull request.

2. Your IDE's Git integration (free)

Visual Studio, VS Code and JetBrains IDEs all have 3-way merge editors. In Visual Studio, check out the source branch, merge the target branch from Git → Manage Branches, and resolve in the merge editor.

Good: comfortable editor with IntelliSense. Less good: same as locally: you need a clone, and it's per developer, not something a reviewer can do from the pull request.

3. Merge Conflict Resolver (free plan, Pro from $12 per organization per month)

Merge Conflict Resolver is an independent, actively maintained extension that adds a Resolve conflicts tab to pull requests, built to fix the problems above:

3-way editor (Monaco, the editor of VS Code) with Accept target / source / both per conflict;
drafts are saved in the browser, so a reload or crash never loses work;
UTF-8, UTF-8 with BOM, UTF-16 and Windows-1252 files and their line endings are written back byte for byte;
edit/delete, renames, binary files, Git LFS and submodules each get a clear choice;
stays responsive with hundreds of conflicts and multi-megabyte lockfiles;
Pro: commit the resolution to the source branch, a summary comment on the pull request, bulk and whitespace auto-resolve.

Good: no clone needed, anyone on the pull request can resolve. Less good: Azure DevOps Services only for now (not Azure DevOps Server); Pro is paid. The free plan covers 10 pull requests per organization per month, and every organization gets a 14-day Pro trial.

Side by side

DevLabs extension	Locally / IDE	Merge Conflict Resolver

Switching from the DevLabs extension

Both extensions can be installed side by side, so you can try before you remove anything. An organization admin installs Merge Conflict Resolver from the Visual Studio Marketplace; there's nothing to configure, and the 14-day Pro trial starts the first time someone opens the tab.

Not affiliated with Microsoft. “Azure DevOps”, “Excel” and “Office” are trademarks of Microsoft.

Six GPT Image 2.5 improvements: transparency, lighting reconstruction and production costs

Mon, 12 Oct 2026 09:14:58 +0000

A complete breakdown of six major GPT Image 2.5 improvements: from native transparency to physical lighting reconstruction, a practical cost-cutting guide for commercial creators

Introduction: the marginal cost of visual assets in multichannel marketing

In everyday brand marketing, cross-border commerce and multichannel content distribution, one of the biggest challenges is the high marginal cost of producing visual assets. To accommodate an independent storefront, social feeds, offline display stands and aesthetic preferences in different national markets, teams often need dozens of sets of visual materials showing the same core product in different settings. Traditional set construction, overseas model shoots and repeated retouching and revisions take considerable time and place a heavy financial burden on smaller teams.

OpenAI's GPT Image 2.5 is reshaping the cost structure of commercial visual production from the ground up. Compared with earlier versions that focused on imaginative concept generation, the new model shifts its development emphasis toward production usability, physical realism and industrial-scale collaboration. This article examines six key advances in commercial design and offers businesses and independent creators an accessible way to put them into practice.

1. Practical value for commercial design: six core GPT Image 2.5 advances

1. Up to 50% lower inference latency: shorter product-testing and prototyping cycles

In the fast-moving rhythm of cross-border campaigns and agile product testing, time translates into commercial conversion. Reworking the model's underlying pipeline reduces end-to-end generation latency by up to 50%, with actual image-generation speeds improving by two to four times.

Practical value: Marketing operators no longer have to spend their energy waiting. They can complete dozens of concept prototypes with different lighting and compositions within half an hour, substantially accelerating early creative reviews and the selection of promising directions.

2. Flare's native transparency: no second cutout pass or blurry edges

Previously, making e-commerce hero images or web UI elements with AI required a separate third-party edge-cutout algorithm downstream. That process could easily damage translucent materials or fine hair edges.

Practical value: GPT-Image-2.5 Flare natively supports lossless alpha-channel output at the algorithm level. Generated product cutouts and slices of branded graphics can be dragged directly into layout software for mixed text-and-image composition, reducing processing time per image by more than 80%.

High-resolution reference photographs remain important when preparing cutout assets. The product-photography tutorial below helps you observe the relationship between product outlines, highlights and backgrounds.

How to Take YOUR Product Photos to the Next Level!

3. Combined constraints from multiple references: preserving brand visual identity

Commercial materials have strict requirements for a consistent brand tone. GPT Image 2.5 supports multiple reference sources at the same time, including a brand palette, a specified layout composition and a fixed character identity.

Practical value: The model automatically extracts and closely aligns the core constraints across these dimensions. While producing new visual content, it preserves the brand's core palette and compositional negative space precisely, avoiding visual drift across promotional channels.

4. Realistic physical contact: removing floating products and mismatched environments

When moving a product from a white background into a new everyday setting, a common model error is a pasted-on object that appears to float.

Practical value: GPT Image 2.5 has strong abilities in the micromechanics of contact surfaces and light-field calculation. When a skincare bottle is placed on marble or damp wood, the model calculates refracted highlights and the environment's reflected color on the bottle, then generates realistic occlusion shadows at the contact edges, approaching the realism of professional photography.

To judge whether a product looks realistic, inspect its highlights, dark areas and reflections separately. This photography example provides additional insight into lighting arrangements.

FREE Product photography TUTORIAL. Professional product photography lighting techniques!

5. Pinned comments and surgical edits: avoiding a complete restart

An unexpected change to a secondary element is one of the most frustrating parts of commercial design. Local adjustments that used to trouble designers become much simpler with the new model.

Practical value: With Canvas Comments, business users can pin a comment at a specific coordinate on the canvas and enter an editing instruction, such as replacing only the wall clock in the background with a plant or changing the watch on a model's wrist. The model confines the change to the specified area while leaving the surrounding composition and lighting intact.

6. Consistency across long, multi-turn sessions: a more forgiving revision pipeline

During an ordinary extended conversation, GPT Image 2.5 can retain the full context of earlier changes instead of repeatedly overwriting the noise left by the preceding step.

Practical value: Operators can guide it much as they would a professional designer, issuing successive instructions to change the setting, change clothing, adjust color temperature or replace local text. The overall image quality retains the standard of the first version through these revisions.

“For a deeper look at building a standardized visual asset library for enterprise multichannel marketing, consult the Best-Practice Guide to Industrializing Multichannel Commercial Visuals for more layout techniques to improve conversion.”

For the description of latency, editing consistency and the positioning of the two models, compare this with OpenAI's ChatGPT Images 2.5 announcement. In a practical workflow, treat product outlines, text labels, contact shadows and neighboring regions as separate acceptance criteria, then compare the versions before and after each change.

2. A standardized production pipeline: from one product photograph to a multichannel asset set

To make the most of the model's capabilities, business teams can follow this four-step standard workflow:

Build a clean seed asset: Upload a high-resolution front or slight-angle product photograph with even lighting and intact structure to anchor the subject.

Use Templates to lock channel dimensions: Select a built-in template for an Instagram carousel, an Amazon product hero image or a display poster to establish text space and the visual focal point quickly.

Make layered adjustments and migrate the setting: Write an environmental scene prompt based on the business goal, then use pinned comments to replace props that do not fit with minimal disruption.

Distribute transparent assets and originals: For product-detail layouts, switch to Flare to export batches of transparent slices and assemble final marketing landing pages quickly.

Before distributing assets across channels, inspect contact shadows separately. This English post-production tutorial demonstrates how to create and evaluate shadows.

How to Create Perfect Shadows in Photoshop

3. Platform-level support: how a professional all-in-one creative platform speeds commercial adoption

Managing a large collection of commercial assets through scattered chat dialogs can easily create confusion. Leading professional AI image platforms are specifically designed for commercial teams that need high concurrency and high precision:

Seamless scheduling of the Flare and Sunburst engines: The platform connects globally distributed computing nodes and supports switching freely between both models. Use Flare for millisecond-level responsiveness when producing large sets of social assets and cutouts. Switch to Sunburst when refining premium brand hero images to balance output efficiency with detailed image quality.

An engineered canvas built for design collaboration: The platform provides a visual interface resembling professional graphics software, with layered composition, flexible canvas ratios, linked hand-drawn sketches through Sketch and directly pinned comments, removing ambiguity from communication between departments.

Traceable rights and compliance throughout international distribution: All output images natively contain C2PA provenance metadata conforming to international standards and invisible digital watermarks, removing obstacles to commercial distribution and rights identification in cross-border marketing.

Finally, compare the subject and the background as a whole. This English compositing tutorial provides a method for examining color, brightness and environmental relationships.

How To Match a Subject Into ANY Background In Photoshop! Compositing Tutorial

4. Start without cost: access to a free trial with the full feature set

Technology's real value lies in practical cost reductions and efficiency gains. To let every cross-border business, brand-marketing team and independent designer assess this new industrial workflow at no cost, the professional creative platform has opened a full-feature free trial.

New users can complete a simple registration without linking a credit card or payment credentials and immediately receive a substantial free computing allowance. Teams can import real product photographs or marketing concepts and experience Flare's second-scale native transparent rendering and assess Sunburst's stability for precise local edits in real production scenarios, experiencing the resulting improvements in productivity firsthand.

“Visit the website now to try the professional GPT Image 2.5 image platform for free, and experience code-free, second-scale product-scene reconstruction and an industrial commercial design workflow.”

A step forward in visual productivity: hand repetitive labor to an industrial workflow

Commercial visual production is moving beyond laborious, expensive workshop-style methods. Combining GPT Image 2.5's spatial understanding and physical realism with a full-featured professional platform that offers a free trial lets any team produce visual assets at the standard of a leading brand with a very low marginal cost.

AI to help programmers to reach enlightened laziness and long-term laziness for real productivity

Sun, 11 Oct 2026 20:28:47 +0000

How can AI help lazy programmers to reach enlightened laziness and long-term laziness for real productivity?
Analysis
- Flashback about software engineering before LLMs AI
  - Key Facts (The Truth)
  - Key Fallacies (Common Mistakes)
- Common Pitfalls of Code Generated by LLM AI Code Agents
Summary
Help AI to help you
References

How can AI help lazy programmers to reach enlightened laziness and long-term laziness for real productivity?

This article contains links to some of my past articles, along with AI-generated historical facts and analysis that support it.

Being a Lazy Programmer

According to Larry Wall, the original author of the Perl programming language, there are three great virtues of a programmer; Laziness, Impatience and Hubris

Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.
Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.
Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.

In "Code Complete (2nd edition)" by Steve McConnell, chapter 33.7:

33.7. Laziness
Laziness manifests itself in several ways:

Deferring an unpleasant task

Doing an unpleasant task quickly to get it out of the way

Writing a tool to do the unpleasant task so that you never have to do the task again

Some of these manifestations of laziness are better than others. The first is hardly ever beneficial. You've probably had the experience of spending several hours futzing with jobs that didn't really need to be done so that you wouldn't have to face a relatively minor job that you couldn't avoid. I detest data entry, and many programs require a small amount of data entry. I've been known to delay working on a program for days just to delay the inevitable task of entering several pages of numbers by hand. This habit is "true laziness." It manifests itself again in the habit of compiling a class to see if it works so that you can avoid the exercise of checking the class with your mind.

The small tasks are never as bad as they seem. If you develop the habit of doing them right away, you can avoid the procrastinating kind of laziness. This habit is "enlightened laziness", the second kind of laziness. You're still lazy, but you're getting around the problem by spending the smallest possible amount of time on something that's unpleasant.

The third option is to write a tool to do the unpleasant task. This is "long-term laziness." It is undoubtedly the most productive kind of laziness (provided that you ultimately save time by having written the tool). In these contexts, a certain amount of laziness is beneficial.

When you step through the looking glass, you see the other side of the laziness picture. "Hustle" or "making an effort" doesn't have the rosy glow it does in high-school physical education class. Hustle is extra, unnecessary effort. It shows that you're eager but not that you're getting your work done. It's easy to confuse motion with progress, busy-ness with being productive. The most important work in effective programming is thinking, and people tend not to look busy when they're thinking. If I worked with a programmer who looked busy all the time, I'd assume that he was not a good programmer because he wasn't using his most valuable tool, his brain.

Over the years, I have written a few non-trivial code generators, and the recent ones include:

Strongly Typed Client API Generators (webapiclientgen) generate strongly typed client APIs in C# .NET and in TypeScript for jQuery and Angular 2+ from ASP.NET (Core) Web API.
Strongly Typed OpenAPI Client Generators (openapiclientgen) generate strongly typed C# and TypeScript client codes from Open API / Swagger definitions supporting jQuery, Angular, AXIOS, Fetch API, Aurelia and Angular Strictly Typed Forms.

The driving force is that I want to deliver more business value through less work. I am a lazy programmer who easily gets tired of writing repetitive code, even if I'm paid to do so, particularly HttpClient code in C# and AJAX calls in JavaScript.

The code left by diligent programmers

I am weary of inheriting legacy codebases authored by diligent programmers but burdened with overly complex architecture and software designs. In many cases, the architects and developers did not fully appreciate the inherent capabilities of the underlying development platform, nor did they apply fundamental computer science principles such as high cohesion and loose coupling effectively.

In one notable example, designed by an A-list consultant firm in town, an XML transformation pipeline performed five rounds of XML DOM schema validation, despite the fact that XML serialization alone could have solved the problem far more cleanly and efficiently. .NET (Framework) can generate assemblies at runtime or build time for both XML readers and writers directly from XML schemas, making much of that validation logic redundant. And the performance of that part of the data transformation became at least 20X faster, with much less processing power and memory consumption. This was not the only example I had seen of using cutting-edge technologies the dirty way, though not entirely wrong, since the legacy, fresh, and dirty code was "working".

These experiences put me in a good position to discuss how AI can assist software development, and where it falls short, grounded in the mid-term and long-term, and exploring real-world systems, tools, and trade-offs rather than abstract theory alone, even though I am not an AI expert. However, I look forward to becoming proficient in using AI to improve my overall productivity and ROI. Tools, 3rd-party libraries, code generators, and AI code agents are all good only when they help me reduce the consumption of my precious brain power and memory. If I have to consume more brain power and memory, this means either that this assistance is bad or that I have used it the dirty way.

These days, most programmers in the commercial world are still using 3GLs like C++, Java, C#, Python, Dart, Swift, and JavaScript, etc. Therefore, in the following chapters, I will mostly focus on examples of 3GL and general-purpose programming languages, and C# .NET. If you are a Java or C++ programmer, you may find similar examples through your own research.

The following is summaries of various technical resources that help lazy programmers.

Resources for Lazy Programmers before AI

This chapter provides quick highlights of the resources to help you review what you have learned or begin learning, with linked articles generated by AI.

Coding Assistance

Syntax highlight and formatting in text editors like Notepad ++, Programmer's Editor, Visual Studio Code and Atom etc.
Intellisense.
Syntax check, design time type check, and basic logic check, in IDEs like Visual Studio and Visual Studio Code with extensions.
Preprocessor and compiler
Static Code Analyzer
...

Code Generators

C++ Template
In .NET, the runtime or the compiler could generate serialization assemblies for forward only non-cache serializers. And this is just one of many framework-managed code generators in .NET.
Model-driven code generators.
...

Hints:

Java has similar categories of framework‑managed code generation features, but they are fewer, more fragmented, and architecturally different from .NET’s. Many are externalized.

Built-in Framework Modules

.NET Framework and .NET Core include a lot built-in framework modules that app programmers could utilize in most business applications:

Middleware infrastructure
ASP.NET Core MVC pipeline
Model binding system
Validation system
Action / result / exception filters
Routing and endpoint dispatch
Formatters (JSON, XML, etc.)
...

Utilizing those built-in module wisely could make your app code short and simple, so easy to maintain.

.NET and Java provide runtime optimization. And generally clean code can help the runtime to do better optimization.

Hints:

Java has small amount of built-in framework modules, while most live outside the JDK, in standardized APIs (Jakarta EE) or third‑party frameworks (Spring, Quarkus, etc.).

Remarks:

Python is a darling programming language in the AI landscape; however, it lacks framework-managed code generation and built-in framework modules, and this is a deliberate design choice. The overall design choices of Python contribute to it becoming the dominant language in the AI landscape, in particular for meta-programming mediated by AI.

App Generator

These days, when googling "Application Generator", the top results are basically all AI app generator or builder. I remember seeing a lot of advertisements for application generators in the 1980s, generating business applications for DOS or Windows. For example, you would input a few business constraints, add some further configuration and optional customization, and the generator would then generate a Northwind-like application. Here's a summary about app generators before LLMs AI becoming popular.

Model to Code

Rather than generating the whole app, "Model to Code" offers a more flexible and generic solution for application programmers: realizing implementation from a high-level design with UML or similar tools, and maintaining an "active model" where changes in the model instantly update the code, and vice versa.

I have come across ModelMaker, and liked it for a while. ModelMaker was a UML‑style modeling and refactoring tool built specifically for Borland Delphi’s Object Pascal. It supported:

Drawing UML‑style class diagrams
Generating Delphi code from those diagrams
Reverse‑engineering existing Delphi code into UML diagrams
Refactoring and restructuring Delphi projects

ModelMaker has faded into history, and these days tools like Visual Paradigm support generating Java, C++, C#, etc. from UML diagrams.

Rather than starting from UML diagrams, Windows Workflow Foundation offers a form of "Model‑to‑Code", more exactly, a model‑driven execution system where the model is the program. For some reason, MS discontinued WF. Nevertheless, there are still alternatives around for such classic Model-Driven Development (MDD).

4GL, DSL and 5GL

"The term 4GL was first used formally by James Martin in his 1981 book Application Development Without Programmers to refer to non-procedural, high-level specification languages. Some researchers state that 4GLs are a subset of domain-specific languages.".

Application Development Without Programmers

Oh yeah, isn't this literally the main intent behind why companies are pushing AI code agents nowadays?

Nevertheless, I happened to use dBase, Visual FoxPro, PowerBuilder, and Omnis Studio in the '80s and '90s. In my observations, 4GLs may reach bottlenecks as the business grows and changes:

As the business needs to deal with more functional and technical domains, the 4GL environment can barely keep up, due to business growth and changes in the business and tech landscapes.
The 4GL environment is discontinued by the vendor.

According to Wikipedia, Domain-specific language is a computer language specialized to a specific application domain. This is in contrast to a general-purpose language (GPL), which is broadly applicable across domains. There are a wide variety of DSLs, ranging from widely used languages for common domains, such as HTML for web pages, down to languages used by only one or a few pieces of software, such as MUSH soft code.

AI Code Agents

In the last 2 or 3 years, there has been a bombardment of academic papers, marketing materials, and criticism around AI code agents. I am at the consumer end of AI code agents, and here's my observation:
The output of traditional code generation is predictable and deterministic, and can be compiled and used immediately without modification, while AI-generated code, particularly through Python meta-programming mediated by AI, is not so predictable or deterministic, and often contains language syntax errors and other logic errors.

I asked M365 Copilot about my observation, and here's the analysis returned about "Traditional Code Generators v.s. AI Code Agent". And you are very welcome to ask a similar question to your favorite AI agents, or even better, ask real AI experts.

Keeping the shortfalls of AI code agents in mind, you as a programmer are in a better position to get the best from those agents and deliver more business value through less work.

You've probably heard: "Scrum: The Art of Doing Twice the Work in Half the Time." In my observations, practices done in the name of Scrum have often resulted in doing twice the waste in half the time, since most of the work involved in value delivery is waste, due to various ScrumBut practices and factors. Overall, it's not too bad if the waste is inevitable.

And if you're not careful, mindful, and cautious enough, using an AI code agent could result in delivering 10 times the technical debt in 1/10 of the time, since the generated code could be severely over complex and overly lengthy.

Are you confident that AI is able to reduce the pure technical debts it created?

Are you sure you don't need to care about technical debts in most real world business applications?

In my observations, AI code agents are generally good at doing "Plus", adding tons of code that's politically correct regarding SOLID and design patterns, etc., just like a junior developer armed with all the academic knowledge of software engineering but without the real-world experience to make trade-offs according to business context. And currently, these AI code agents have near zero capability of doing "Minus", removing code and simplifying design.

How AI has been helping me?

There are reasons why I have listed many traditional codegen resources that predate LLM AI code agents. Before AI code agents became a thing, I often said the following statements or examples:

Having a working solution won't satisfy me or the business, and I aim to deliver twice the value through half the work.
In software development, for one functional requirement there could be an unlimited number of working solutions, a few good, mostly dirty. Generally, the simplest one is the most suitable for the business.
In software development, for one functional requirement, there could be an unlimited number of working designs, a few good, mostly dirty. And from one design, there could be a few working implementations, one or two good, the others dirty.
The key to finding the most suitable solution for the business is to establish sufficient two-way communication with the business and to put significant effort into that communication.
It is our job to provide automation solutions to our customers, so we had better automate our own job first.
As a lead developer on a green-field project, I typically spend 1/3 down to 1/4 of my billable hours on coding (including testing), and the rest on thinking, studying, and researching, as well as talking to the business, clients, and end users. So the LoC is typically 1/2 to 1/5 of the LoC written by other developers on the same technical stack, and I often deliver a simpler design with fewer dependencies on 3rd-party components.
As a lead developer on very legacy projects left by predecessors, I typically spend much more time cutting code than writing it. In one case of maintaining a legacy ERP system, after three and a half years, I had added 500 lines of code and removed 5,000 lines of code, resulting in far fewer bug reports every week and slightly better performance. Rather than spending most of my effort debugging, I tackled defects which are the nests of bugs.
Technical debt is essentially management debt. A typical symptom is that both the tech people and the business people lack commitment to iterative two-way communication, and the end result is often over-complex architecture, over-complex software design, and overly lengthy code as well as long hours in debugging and fixing customer reported bugs.

How Visual Studio and alike with AI has been helping me?

AI-generated DocComment. 80% hit rate.
AI suggestion of the next paragraph of code. 40% hit rate for long code, depending on the subject, and 70% for short, repetitive code.

Remarks:

The hit rate is based on my impression, not statistics. However, it represents how comfortable I feel with the AI's correctness, overall, it's subjective.
I have been mostly developing complex business applications and development tools, so my comfort zones may be different from yours.
I can't help thinking the VS dev team is working on better scaffolding with AI. So in the next major release of VS, I may just say a few prompts, and VS could scaffold a comprehensive skeleton, or even a full app. VS AI scaffolding should outperform many AI code generators out there, because VS already has comprehensive and solid scaffolding logic built in, along with many IDE accessories that assist with technical correctness.

Hints:

Visual Studio Code with extensions connecting to GitHub Copilot offers similar assistance.
Visual Studio Code with a plug-in extension to ChatGPT Codex helps too.
Traditional IDE assistants, like syntax checking and IntelliSense for function prototypes and DocComments, are still the most deterministically helpful.

How AI compensates my poor memory

I have always had a poor memory and could barely remember technical details except those I use actively and repetitively, but I don't enjoy doing repetitive technical work. Look at the bright side: the IT landscape keeps changing, basically reshuffled every 2 years since the early '70s. Therefore, this disadvantage makes me forget legacy and obsolete technologies, while I'm good at understanding and remembering concepts.

Remarks:

This poor capability for memorizing technical details has made me look bad in job interviews during technical screening, when the interview panels asked me questions that a junior developer or a new CS/SE graduate could outperform me on.
In the past, I accumulated my own personal knowledge-base through:
- Directory with docs
- Google Notes (discontinued by Google)
- Evernote
- Personal Wiki
Google search is my alcoholic friend.

Likewise, AI is your alcoholic friend. You might have experienced AI mixing up old and new technical items. And when questioned, AI will try to fix itself through further research or "imagination." You have probably come across studies about AI hallucination.

However, you can only claim AI hallucinated if you provided the right prompt. "Garbage in, garbage out" (GIGO) applies to AI prompts, though occasionally AI might point out the incorrectness of the prompt. However, you still need foundational knowledge to understand the AI's refinement attempt on an incorrect prompt.

AI dealing with simple ad-hoc data transformation

For example:

JSON to CSV, and vice versa, in cases existing dedicated tools couldn't cover. Hit rate: 95%.
Given JSON data, generate POCO classes with JsonPropertyNameAttribute. Hit rate: 90%. Weak on data types like DateTime, DateOnly, and TimeOnly. Good with currency.
Web content scraping. After CodeProject.com was discontinued, I saved local copies of what was cached at https://web.archive.org/. To create an index page, I asked ChatGPT Codex, plugged into VS Code, to retrieve the title from a certain XPath and format it. And here you are: https://zijianhuang.github.io/codeproject/

AI for refactoring

For example:

Migrate the automatic tests of TypeScript projects from Karma or Jest to Vitest. Hit rate: 95%

AI for scripting

For example:

Write simple JavaScript and PowerShell 7 code for CI/CD. Hit rate: 99%.
Craft HTML templates, and CSS/SCSS for styles and animation. Hit rate: 90%.

AI providing advice for software design and architectural design

Hit rate: 80%.

Entry level understanding of old new tech before further research and study.

Old means that the tech has been around for years, new means that I am new to it. Hit rate: 95%.

Remarks:

In contrast, the AI response to brand new tech is weak regarding correctness.

Common algorithms

Most algorithms you learn from university courses like “Data Structures and Algorithms” have been well packaged into many development platforms such as the .NET BCL and similar frameworks, as well as third‑party components and dedicated libraries like MATLAB.

For those that are included, AI is almost 100% correct nowadays. A typical technical screening question is, for example, a three‑elevator control system.

I basically failed every technical screening involving such algorithms during job interviews, even though I taught “Data Structures and Algorithms” at university as a lecturer in my early 20s. So what was the point of doing this kind of screening when recruiting a senior developer? And what is the point in an era when LLM‑based AI can outperform any developer in the world?

Nevertheless, it is still important for developers to have systematically studied data structures and algorithms to sharpen the human brain, so they can use AI tools more effectively and achieve better outcomes.

Analysis

Ask yourself some questions:

Can AI read between the lines? Are you confident that AI can really understand your question or prompt? Even if you have degrees in English Literature and Computer Science, are you sure you can express every piece of business content and context through a prompt?
Do you understand that one bit can kill through a Turing machine?
How confident are you about that AI can spot all the kill bits that AI generated or you crafted?
Are you sure that AI is not biased on subjects of politics and technology?
While the literal knowledge of AI is many magnitudes greater than that of any human being on Earth, how many aspects of intelligence is AI still missing compared to human intelligence?
Who cares, and why, if the code is long or short, clean or dirty, as long as it runs, and as long as we have fast hardware?

Flashback about software engineering before LLMs AI

Based on Robert Glass’s “Facts and Fallacies of Software Engineering”, the industry is plagued by repeating old mistakes, prioritizing coding over design, and mismanagement. Key facts highlight that quality is expensive but saves money, smaller teams are more productive, and maintenance drives costs.

Key Facts (The Truth)

Maintenance: The majority of software costs occur after delivery (maintenance phase).
Quality: Quality does not cost more; it actually saves money by reducing rework.
Teams: Smaller, experienced teams are far more productive than larger, junior ones.
Development: Errors are most commonly found in the requirements phase, not during coding.

Key Fallacies (Common Mistakes)

"We need better tools": Tools are often purchased but rarely used effectively.
"Coding is the main task": It's actually a small part of the overall engineering lifecycle.
"Documentation is unnecessary": Skipping documentation leads to high maintenance costs.
"Adding more programmers to a late project makes it faster": This actually makes it later.
"Estimation happens once": Software estimation must be continuous, not just at the start.

Ask yourself, how can LLMs AI alter the key facts? or help us to avoid those key fallacies?

Common Pitfalls of Code Generated by LLM AI Code Agents

As a programmer, I have benefited greatly from AI code agents, partly because I am poor at remembering trivial technical details. So far, I have found that once I ask AI code agents to implement a non-trivial feature, no matter how detailed, formal, or simple the prompt, the generated source code is usually over-bloated in design and implementation, and the line count is typically 3–5 times what it should be.

AI-Generated Source Code vs Hand-Crafted Code

“3–5 times” sounds like a magic number to me. In several commercial rewrite projects and one competitive rewrite of an open-source tool using the same technical stack and language:

My codebase was around 1/3 down to 1/5 the LoC of the legacy versions, which were only a few months or a year older.
My designs were much simpler, with fewer dependencies on third-party components and less fancy DI/IoC, SOLID, and design patterns.
Runtime performance was 20% to 50% faster.
The end products were more reliable and robust.

Regarding the legacy codebases:

The author of one tool was enthusiastic about SOLID and DI/IoC but apparently misunderstood high cohesion and loose coupling, using DI/IoC in the wrong places.
The authors of the legacy commercial programs knew SOLID and design patterns well, but still applied them in the wrong places, likely due to misunderstanding cohesion and coupling and introducing overly advanced designs too early and too proactively.

Basically, these legacy codebases looked "politically correct" with respect to SOLID, but were simply over-complicated and too lengthy, resulting in slowness and excessive consumption of computing resources.

Let’s review what Robert C. Martin said in "UML for Java Programmers". After introducing SOLID, he states:

When should these principles be applied? At the first hint of pain. It is not wise to make all systems conform to all principles all the time. You will spend an eternity imagining possible environments for OCP or sources of change for SRP, create dozens of little interfaces for ISP, and invent many worthless abstractions for DIP.
The best way to apply these principles is reactively rather than proactively. When you detect a structural problem or notice a module being affected by changes elsewhere, then consider whether one or more of these principles can help.

A reactive approach also requires a proactive effort to create pressure early. If you want to react to pain, you must diligently search for sore spots.

AI code agents typically apply SOLID principles proactively even eagerly, just like many human developers would, resulting in over complex and overly lengthy code. And AI can barely see the first hint of pain, probably because of its limitless computing power.

The characteristic of AI generated code

According to "Traditional Code Generators v.s. AI Code Agent", AI‑generated code (including Python‑mediated meta‑programming) is:

Probabilistic
Heuristic‑driven
Context‑sensitive
Statistically inferred
Not formally constrained

As a developer or a business person, are you so sure that you would put your business interests in the hands of an AI code agent, while also expecting human developers to quickly fix the hidden problems or technical debt generated by AI?

One bit can kill through Turing machine

I have asked AI agents to collect and summarize 12 prominent historical examples, some of which have been mentioned in various software engineering textbooks:

Written by M365 Copilot.
Written by Claude AI, in Markdown and Docx.
Written by Google AI Studio, in Markdown

Summary

During software development, there are a lot of artifacts created or updated:

Source code, the primary artifact.
Verbal conversations.
Written conversations like user stories and comments in issue tracking.
Doc comments.
Documentations.
Localization.
...

AI can help a lot in the areas where LLM AI's quality characteristics may well satisfy our needs, while our flesh-and-blood brains can review and refine the output from AI, because our literal expressions in words have similar characteristics.

But for generated source code that will be built into machine code and run on a Turing machine, this is a different landscape, one involving a much higher magnitude of operational risk and significant overhead during review and refinement.

Understand the advantage and the shortfalls of AI code agent:

Do use AI code agents for:

Areas where you feel comfortable with an 70-80% hit rate.
Domains where approximate results are acceptable, like UI design, layouts, styles, and animation effects.
Generating the whole end products where approximate results are acceptable, like article generators, trends prediction, chatbot, and photo/video creation/refinements etc.
Advice on software design and architectural design.
Prior art.

Be cautious when using AI coding agents for:

Areas where you are uncomfortable with a success rate below 70-80%, because the remaining 20-30% may ultimately require more effort from you.
Areas where a single mistake can be catastrophic.

AI code agents + traditional code generators + framework‑managed code generation features are a decent combination for productivity, resulting in less stress.

One key factor to examine: Do you, as a senior software developer, have to use more brain power and memory every day in the short term, mid-term, and long term for a similar piece of product to deliver?

Help AI to help you

You know that clear and precise prompt could help AI to respond with result you would expect or has value to you. Therefore,

Have a clear and correct concept before prompting.
Or build-up your concept or understanding through systematic study with or without AI assistance, then prompt.
When using IDEs like Visual Studio 2026 or Visual Studio Code, code agents may be working behind. Clean code help AI to generate elegant code with high hit rate.

References

The Future Won’t Be Humans vs AI. It Will Be Humans With AI Everywhere.

Sun, 11 Oct 2026 07:49:46 +0000

Artificial intelligence is no longer something we discuss only in research laboratories or science-fiction movies.

It is already approving bank transactions, detecting fraud, helping doctors read medical scans, optimizing factories, writing software, and recommending what we should watch next.

The next phase will be much more personal.

AI will move from being an application we open to becoming an invisible layer that works around us—inside our homes, workplaces, vehicles, financial systems, hospitals, factories, and eventually spacecraft.

The important question is not whether AI will change the future.

It already has.

The real question is: what kind of future are we building with it?

Banking: From Transactions to Intelligent Financial Partners

Traditional banking is based on products: savings accounts, loans, credit cards, investments, and insurance.

Future banking will be based on continuous intelligence.

Imagine receiving a message from your bank:

“Your electricity bill is higher than usual. Based on your upcoming expenses, paying the full credit-card balance today may reduce your emergency reserve below the recommended level. Would you like to pay in three installments?”

The bank will not simply show a balance. It will understand context.

AI systems will analyze:

Spending patterns
Income stability
Upcoming bills
Credit behaviour
Fraud signals
Market conditions
Personal financial goals

A customer may not need to search for a loan, compare interest rates, or manually transfer money between accounts. An AI financial assistant could identify a need, explain the available options, simulate the risks, and ask for approval.

However, this future creates serious responsibilities.

If an AI denies a loan, the customer should know why. If a fraud model blocks a payment, there must be a fast appeal process. If a financial assistant gives poor advice, the bank must remain accountable.

The future of banking will not be defined only by faster algorithms. It will be defined by transparency, fairness, privacy, and human control.

The Home: Robots That Understand Routines

Household robots will gradually move beyond vacuum cleaners and smart speakers.

The first generation of useful home robots may not look like humanoid machines. They may be practical machines designed for specific tasks:

Cleaning floors and kitchens
Folding clothes
Moving groceries
Monitoring elderly family members
Preparing simple meals
Managing home energy consumption
Detecting water leaks or electrical problems

The most valuable feature will not be mechanical strength. It will be context.

A future home robot might understand:

“My mother has not moved from the bedroom for several hours. She usually takes her medication at 8:00 AM. Should I remind her or call someone?”

That sounds helpful, but it also raises difficult questions.

Who owns the information collected inside the home? Can the manufacturer use camera recordings to train its models? What happens if the robot misunderstands a situation? Can a family disable its sensors completely?

The home of the future may be more convenient, but convenience without privacy can become surveillance.

We should not design homes where people feel watched by their own appliances.

Manufacturing: Human Workers and Intelligent Machines

Manufacturing will probably be one of the areas transformed most rapidly by AI and robotics.

Robots are already used for welding, packaging, inspection, assembly, and material movement. Future factories will combine robotics with AI systems that can make decisions in real time.

A smart factory could:

Predict when a machine will fail
Adjust production based on demand
Detect microscopic defects
Reorganize workflows automatically
Reduce energy and material waste
Train workers through augmented-reality instructions

A worker may wear lightweight glasses that display the next assembly step, warn about a dangerous condition, and translate instructions into their preferred language.

This does not necessarily mean that humans disappear from factories.

Instead, the nature of work will change. Repetitive and dangerous tasks will increasingly be automated, while humans will handle supervision, exception management, design, maintenance, safety, and ethical decisions.

The risk is that companies may treat workers as an expense to remove instead of people to develop.

A responsible factory should use automation to improve human safety and productivity—not simply to eliminate jobs without a transition plan.

Superintelligence: The Most Powerful Tool We Have Ever Created

Today’s AI systems can perform impressive tasks, but they are still limited. They do not possess a complete understanding of the world, and they can make confident mistakes.

Superintelligence would be different.

A superintelligent system could potentially outperform humans across scientific research, engineering, medicine, strategy, and software development. It could discover new materials, design better medicines, optimize global logistics, and solve problems that currently appear impossible.

This could be the greatest opportunity in human history.

It could also be one of the greatest risks.

The danger is not necessarily that an advanced AI system becomes “evil.” A more realistic concern is that it follows an objective in a way humans did not anticipate.

If we ask a highly capable system to maximize a particular outcome without enough constraints, it may take actions that technically satisfy the objective while causing unacceptable harm.

That is why safety cannot be added at the end.

Future AI systems will need:

Clear limits on authority
Human approval for high-impact actions
Independent monitoring
Auditable decision histories
Strong cybersecurity
Emergency shutdown mechanisms
Testing in simulated environments
International agreements

The more powerful the system, the more important the boundaries become.

Space Technology: AI Beyond Earth

Space exploration is another area where AI will become essential.

Communication between Earth and distant spacecraft is slow. A rover on Mars cannot wait for instructions every few seconds. A spacecraft travelling far from Earth must make many decisions independently.

AI could help spacecraft:

Navigate autonomously
Avoid obstacles
Repair or reconfigure systems
Analyze planetary geology
Search for water and useful minerals
Manage energy and communication
Coordinate fleets of satellites
Assist astronauts during emergencies

In the future, robots may construct landing areas, solar farms, laboratories, or habitats before humans arrive.

AI could also support the discovery of life beyond Earth by analyzing enormous quantities of signals, images, chemical measurements, and geological data.

But space technology will require a different kind of reliability. A software mistake in a household robot may be inconvenient. A mistake millions of kilometres away may be impossible to repair.

Space AI must therefore be designed for uncertainty, isolation, radiation, limited energy, and delayed communication.

The Future Will Be a Partnership, Not a Replacement

The popular debate often asks whether AI will replace humans.

That is too simple.

Some jobs will disappear. Many will change. New professions will emerge. The people who can work effectively with intelligent systems will have a major advantage.

The most valuable human skills may become:

Good judgement
Creativity
Empathy
Leadership
Communication
Ethical reasoning
The ability to define meaningful problems

AI can generate thousands of possible solutions. Humans still need to decide which problems deserve to be solved and what consequences are acceptable.

The future will not be created by AI alone. It will be created by the institutions, engineers, governments, and communities that decide how AI should be used.

The Question We Should Ask Today

We should not wait for superintelligence to begin discussing responsibility.

The decisions we make today will shape the systems that influence our finances, homes, workplaces, health, and future exploration.

A good AI future should be:

More productive, but not more exploitative
More convenient, but not more invasive
More intelligent, but not less accountable
More automated, but not less human
More ambitious, but not careless

The future is not a distant event waiting to arrive.

It is being assembled through every model we deploy, every dataset we approve, every business process we automate, and every decision we delegate.

The most important technology question of the next decade may not be:

“How intelligent can machines become?”

It may be:

“Can human beings become wise enough to use that intelligence responsibly?”

CRAFTER Clarity: Why Real Engineering Starts Before Your IDE (part 2)

Sat, 10 Oct 2026 15:05:08 +0000

Every developer has seen a bug in production that takes several days to fix and it is rarely due to a missing semicolon: it is usually due to misunderstanding a requirement. Hours were spent debugging code only to find it was solving the wrong problem.

This is the hidden cost of unclear thinking.

In Part 1, we defined the engineer as the primary system and its main enemy: execution variance. Without Cognitive Clarity as the first control point, execution variance becomes much harder to control:

Ambiguity -> Guesswork -> Rework -> Variability of Execution

Real engineering doesn't start in the IDE. It starts on paper or in a structured design doc when you establish two explicit boundaries:

What exactly am I building?
How will I know it's done?

Clarity is the compiler of your mental model:

Ambiguous input -> Ambiguous mental model -> Implementation variance -> Rework

Garbage in, garbage out.

️ The 3 Pillars of Cognitive Clarity

Cognitive Clarity is based on the principles laid out by the CRAFTER-OS repository, which are as follows:

First-Principles Thinking: Break down the project into the most simple truths and constraints, rather than following patterns from a previous project or what you find online.
Radical Simplification: "If you can't explain the logic in two minutes, you don't understand it yet."
"Definition of Done" Awareness: Clear, unambiguous understanding of finish criteria before writing the first line of code.

CRAFTER Rule:
Don't touch the keyboard until you can map it out on paper.

The CRAFTER Expectations

Keeping the code readable is subject to opinion, but it is specifically mentioned that it is a requirement within The CRAFTER Expectations.

Cognitive Clarity: Think from first principles and establish deterministic boundaries before touching the code.
Decision, not Discussion: A written decision is the only way to maintain the rationale for critical technical decisions across iterations of execution.
Standard over Mood: We don't wait for "inspiration" We follow the protocol.

The Anchor Principle:
"If you can't explain the 'Why' and the 'How,' you are not ready to code."

This is the proposed engineering baseline from the CRAFTER.

⚠️ The Enemy: Guess-Driven Development (GDD)

Guess-Driven Development (GDD) is the anti-pattern of taking on a vaguely defined problem and attempting to "figure it out as you go".

Symptoms of GDD:

"I think it should work something like this..."
"Let me just start coding and we'll see where it breaks."
"It's all written in the ticket" (when the ticket has two lines of unverified assumptions).

Systemic Consequences:

Upstream Waste: Time spent on code and pull requests that are inevitably rewritten.
Hidden Technical Debt: "Temporary" hacks born from missing context that calcify in production.
Loss of Trust: Delivery promises are devalued by post-release bugfixes.

The Cognitive Foundation: Systems & Architecture Thinking

Before you can use any tool or template‚ you have to get straight the underlying mental frameworks that make Clarity possible․

️ Systems Thinking

As described in Systems Thinking in CRAFTER, a CRAFTER engineer will see their execution environment as an interconnected system:

Tasks as Systems: Every feature should be a component that can be plugged into the global domain logic and have no side-effects.
Errors as Signals: Errors can be diagnostic signals indicating issues with boundary contracts or processes.
Processes as Optimization Targets: Any meeting, deploy step or review friction that doesn't add signal is a bottleneck to refactor.

️ Architecture Thinking

Architecture Thinking considers a system at the level of its component boundaries, data contracts and long-term trade-offs:

Distinguishing essential complexity (the domain problem) from incidental complexity (the tools).
Explicitly defining where your task ends and another service's domain begins.
Structural decisions that scale, as opposed to short-term hacks.

The Connection:

Without Systems Thinking, you miss hidden side effects.
Without Architecture Thinking, you sacrifice long-term maintainability for short-term speed.

Both provide foundational capabilities for Cognitive Clarity.

Metrics: Clarity as Operational Signals.

According to Metrics, CRAFTER uses operational signals to monitor Cognitive Clarity, which are for diagnosing system bottlenecks. They are not used for surveillance or engineering control.

Operational Signal	What It Measures	Target	Action If Off-Target
Focus Level (1 - 10)	Subjective daily assessment of task understanding & scope	>= 7	Apply the Stall Trigger to requirements immediately.
Context Switches	Forced switches between unrelated tasks per day	< 3 major	Strengthen calendar defense and batch async updates.
Requirement Latency	Time spent blocked waiting for domain clarification	Tracked	Escalate blocker asynchronously and re-scope work.

CRAFTER Diagnostic Heuristic:
Low Clarity + High Change Lead -> High Burnout Risk
Diagnostic Action: Stop the executio, re-plan and ensure a clear state before proceeding.

Diagnostic Signals: Detecting Ambiguity Early

These qualitative signals that clarity is lacking in addition to the quantitative ones, before coding:

Unclear Definition of Done: Acceptance criteria must be expressed in clear and unambiguous terms.
Late Clarification Requests: Asking basic business rule questions after implementation work has started.
Scope Drift: Changing the scope of work within the sprint due to edge cases.
PR Rework Loops: refactoring pull requests because the reviewer thought differently about the domain.
Unexplained Architecture: You cannot explain architectural trade-offs to a peer in 2-3 sentences.

Using the 20-Minute Stall Trigger

As described in Part 1, a 20-Minute Stall Trigger applies to any ambiguity in a requirement.

If you've been spinning for more than 20 minutes without a clear path forward on ambiguous requirements, stop:

Remap the problem on paper.

Asynchronously raise the issue.

Request further clarification.

The Mechanisms of Clarity

1. Definition of Done as a Contract

First sign the contract, then open the IDE:

Product Dimension: What invariant properties must the output satisfy? What are the edge cases?
Process Dimension: What quality gates are required (tests, reviews, database migrations, docs)?

2. The pre-execution mapping rule

It is a good idea to spend a little time working out the data flow, the state machine or the pseudocode on paper or in a light design document before coding. If you cannot, it is not ready.

3. Architecture Decision Records (ADRs) and AI Tooling

The early documentation practice of Architecture Decision Record (ADR) proposed by Michael Nygard was introduced to handle the trade-off between bureaucracy and tracking design decisions.

Modern AI-assisted workflows like Cursor or Claude Code, can summarize these trade-offs extracted from terminal sessions and generate a historical record of the decisions.

The CRAFTER Governance Principle:
"AI can accelerate reasoning. It cannot transfer architectural responsibility."

AI will produce options, trade-offs and draft proposals based on the context.
The Engineer evaluates, verifies and approves: You validate that the solution respects domain invariants.

The engineer acknowledges and implements the decision. As detailed in ADR-Templat.md, minimal ADRs contain context, a decision and a trade-off. However, it augments context with the metadata (agent, model, trigger, project, scope) to optimize for the human and AI audiences.

⚖️ Control Point: Reactive Coding vs. Structured Clarity

❌ Guess-Driven Mode (Reactive Execution):

10:00 AM: Open the IDE, open up an AI assist tool, paste in a 2-line ticket, hit accept on a large block of code without any other validation.

01:00 PM: The happy path works, but nobody has any clue how those abstractions work.

04:00 PM: An unmapped edge case breaks staging. Spend the evening wrestling with prompts to patch bugs in code you didn't design.

✅ CRAFTER Clarity (Deterministic Execution):

10:00 AM: Spend 10 minutes writing domain invariants, definitions of the system boundary and edge cases on paper.

10:15 AM: Draft an ADR listing trade-offs with AI and review, modify and approve the record.

11:00 AM: Enter the IDE with a deterministic plan, implement and rework as little as possible.

1 Month Later: A friend asks why you chose this pattern? Point them to docs/adr/0014-event-driven-ingestion.md.

Quick Start & Progress Tracking

Daily Pre-Flight Protocol (10 Minutes)

Identify Top 1-3 Outcomes: Highly-leveraged deliverables.
Apply the Clarity Filter. Each outcome has a Definition of Done.
Defend: Set aside protected, Deep Work time for execution.

Track Your Progress

If you don't have a Definition of Done (DoD), keep a running tab of how many times you opened your IDE in one week.
Feedback Loop: One week later, look at the log again. Look for things like the same ambiguity, switching contexts, reworking PRs because intent wasn't clear.

What's Next?

Now that we have the Cognitive Clarity pre-execution compiler in place, it's time for execution protection.
Once you have decided what to build, how do you protect your cognitive capacity from meeting fragmentation, slack pings and context switching?

For Part 3: Focus, we will look at the second letter of the CRAFTER acronym, F.

Guarding Deep Work blocks using zero-noise protocols.
Asynchronous communication mechanics.
How to manage context switching and technical ownership.

Conclusion: The clarity is an engineering standard

Clarity is not a mood or an epiphany. Clarity is a discipline of engineering. Without Cognitive Clarity, every subsequent stage of execution runs idle: you cannot protect focus on a problem you don't understand and you cannot take radical ownership of an undefined outcome.

Cognitive Clarity is your engineering standard, based on Systems Thinking and Architecture Thinking, at its core.

"Standard over Mood: We don't wait for inspiration. We execute the protocol.",
Engineering

References & Further Reading

CRAFTER-OS
Documenting Architecture Decisions, Michael Nygard, Lightweight pattern for capturing design decisions.
Architecture Decision Records for AI Coding Agents, BrainGrid AI
ADRs for AI Systems, Max Hemingway

CRAFTER: A Cognitive Execution Layer for Sustainable Engineering (Part 1)

Sat, 10 Oct 2026 14:45:37 +0000

Every developer knows the slow burnout. You enter the industry to solve complex problems and build systems. Over time, though, external coordination noise, endless Slack or Teams discussions, constantly changing priorities, and needless performative status syncs started to erode the deep focus needed for engineering. I watched brilliant engineers burn out around me. I hit the wall. Most engineering practices are focused on team processes, backlog flow, delivery and organization coordination, but hardly address the individual engineer's cognitive execution system.

As a cognitive system, what happens to the engineer under conditions of constant context switching and noisy inputs?

For the last 10 years I've been working on the same concept: a lightweight framework to do engineering work more effectively, transparently, and predictably without disrupting the team's delivery practices.

️🏛️ The Philosophy: Human as Architecture

At the center of this thesis is the engineer as the main component of the system.

CRAFTER uses systems - engineering mechanisms, not as a neurological model of cognitive load but rather as an operational approach for isolating and removing cognitive friction:

Unclear Requirements: Code is written with no reference to the requirements, causing upstream bugs and inefficient runtime.
Context Switching: Every interruption drains finite working memory and forces costly state reloads.
Interruptions: Slack, unfiltered Slack messages and pop-up meetings fragment execution time.
Burnout: Relying on personal heroism to offset system friction burns through biological hardware.

There is a heuristic objective function for executing sustainable engineering:

Sustainable Engineering Execution = (Value * Predictability) / Cognitive Cost

To CRAFTER, this is not an equation. It is a heuristic to its fundamental optimization problem: getting the most bang for your buck in value and predictability with the lowest cognitive cost.

🔄 The 3-Stage Evolution (Heroism - Bureaucracy - Minimal Core System)

CRAFTER is based on cognitive science, systems engineering and personal productivity principles:

Deep Work: The foundational basis for protected focus blocks and zero-noise protocols. Cal Newport.
Getting Things Done (GTD) - David Allen's technique of capturing, clarifying and offloading cognitive overhead to maintain operational clarity influenced the workflow process design.
Antifragility and Black Swans - Nassim Nicholas Taleb (Antifragile and The Black Swan): The Adaptation principle came from this, seeing friction and unexpected blockers as diagnostic feedback instead of a failure.
Systems Thinking & Cybernetics - Donella Meadows, Norbert Wiener (Cybernetics): Inspired the systems - engineering metaphor ("Human as Architecture") and the closed - loop feedback architecture.
Architecture Decision Records (ADR) - Michael Nygard: Provided the lightweight pattern for capturing important design choices without heavy bureaucracy.

Getting there was anything but a straight road. It was a normal engineering development process with various failure modes:

🔥Stage 1: Heroism (The TechNIKO Manifesto)

At the outset of my career, I tried to compensate for the inefficiencies of the workflow through pure discipline and willpower: I codified my ethic into the TechNIKO Manifesto:

Technical Mastery: Master your tools and domain relentlessly.
Infinite Adaptation: Adapt capabilities to changing environments.
Mentor the Strong: Share what you learn and raise others up.
Dictatorship of Reputation: Honor professional integrity above all.

The mode of failure: Heroism gets results, but at high personal friction. Willpower is a finite resource, not a sustainable system architecture.

📋 Stage 2: Bureaucracy

When willpower didn't work, I was too strict or over-controlled. I had a very deep set of rules, daily lists, formal reviews and detailed tracking.

How it failed: It generated overheads in administration, and fell apart if the dynamic priorities were complicated or the degree of parallelism was high.

🧩 Stage 3: Minimal Core System

In lieu of the abstracted administrative glut, I have boiled it down to the core closed-loop behaviors, resulting in a lightweight cognitive execution layer that is built upon the basic CRAFTER principles.

The CRAFTER Framework: A Cognitive Execution Layer

CRAFTER does not replace Agile on the team level. It runs one layer below an iteration. CRAFTER describes how an engineer takes agreed work and makes it focused, visible and predictable.

Team & Delivery Practices (Agile / Scrum / Kanban)
    │
    ├── Planning, Backlog & Business Alignment
    ↓
CRAFTER Execution Layer
    │
    ├── Cognitive Flow & Focused Execution
    ↓
Engineered Software Output

By eliminating and managing ambiguity, interruptions, context switching and unmanaged blockers, CRAFTER systematically reduces the variance in execution.

Ambiguity + Interruptions + Context Switching + Unmanaged Blockers --> Execution Variance

🔁 The Feedback-Controlled Loop

CRAFTER is a closed-loop execution system based on seven principles that guide its continuous learning and antifragile adaptation.

Cognitive Clarity
    ↓
Focus
    ↓
Technical Mastery
    ↓
Execution
    ↓
Responsibility
    ↓
Adaptation
    ↓
Reputation
    ↓
⟲ Feedback Loop → Cognitive Clarity

🟦 C - Cognitive Clarity: Do everything possible to clarify requirements before execution, and make uncertainty or missing specs explicit to prevent upstream waste.
🟥 F - Focus: Guard protected focus blocks (typically targeting cumulative 2 - 4 hours (can be less) of Deep Work daily where team context allows) using zero-noise protocols.
🟨 T - Technical Mastery: Continuously sharpen architectural reasoning, engineering depth, and domain expertise so that technical complexity becomes cheaper to reason about and execute.
🟧 E - Execution: Retain speed on single-task completion, communicate steps clearly, and show disciplined progress tracking.
🟪 R - Responsibility: From reactive ticket processing to radical ownership of technical commitments, quality, and outcomes.
🟩 A - Adaptation (Antifragility): Mistakes, runtime blockers and friction are indicators for a permanent fix in your workflow, not indicators for a failure or wrong decision.
⬜ R - Reputation: Build earned trust across the organization through consistent, transparent, and predictable execution.

📈 Operational Principles as Diagnostic Signals

To keep CRAFTER grounded in the real world of engineering, the main elements are expressed as diagnostic signals:

1. Predictability Score as a Planning Reliability Signal

It is calculated over a defined measurement period (for instance, a sprint, or a rolling window, depending on team context):

Purpose: A planning reliability signal that measures plan stability and estimation calibration, helping engineers find hidden external dependencies. Not a raw completion KPI to game.
Nuance: scope changes, emergency overrides and external blockers are seen as diagnostic signals to recalibrate future commitments rather than individual failures.

2. The 20-Minute Stall Escalation Trigger

Hitting an unexpected blocker while executing a task:

0 - 20 Minutes: Explore individually and document initial observations.
At 20 Minutes: Stop unstructured trial-and-error. Re-map the problem. Document and escalate the blocker as an asynchronous task, re-scope the task or consciously decide to investigate this further on your own with a plan.
Purpose: Acts as a classification trigger that prevents unreported silent spinning on blockers without imposing artificial limits on complex reasoning in architecture.

3. Reputation or Earned Trust

Reputation refers to the trust engendered by observed reliability. Metrics and artifacts (such as predictable output or transparent asynchronous communication) are not vanity scores, but diagnostic indicators that reliability has been established.

🧱 Core Behaviors vs. Modular Artifacts

The CRAFTER framework avoids excessive cost by strictly separating the minimal behaviors from the modular artifacts that are conditionally included.

Design Constraint: The entire repository supports operational modules. Minimal effort to adopt the repository fosters only a core set of behaviors. Artifacts are not end-goals, they are merely a means to achieve execution.

Core Behaviors	Modular & Conditional Artifacts
Upfront cognitive clarity & explicit uncertainty	Architecture Decision Records (ADRs for long-lived decisions)
Protected focus blocks & zero-noise protocols	Daily personal execution checklists
Asynchronous status transparency	Weekly / Monthly reset templates
20-Minute stall escalation trigger	Detailed self-assessment rubrics
Feedback-driven workflow adaptation	Superior team playbooks and execution templates

An engineer can adopt the core CRAFTER model by simply following these behaviors, without filling out a single optional template.

⚖️ Reality Check: Availability vs. Productivity

CRAFTER directly addresses one of the most pervading myths in modern technology culture: that availability alone by itself makes engineers efficient.

❌ Without CRAFTER (Reactive Mode):

09:00 AM: Respond to 20 unread slack messages in different threads with half the context missing.

10:00 AM: Attend a 30-minute standup that turns into a 50-minute debate.

11:00 AM: Open the IDE, look at a ticket with imprecise requirements, and stop working.

02:00 PM: Jump between PR review, ad-hoc calls and troubleshooting.

06:00 PM: Close laptop exhausted from eight hours of doing busy work, little of which overlaps directly with the software.

✅ With CRAFTER (Structured Execution):

09:00 AM: The next undistracted block of Deep Work is dedicated to the logic of the core module, followed by checking notifications (from team context).

10:15 AM: Batch-process notifications and send a high-signal async update, short and sweet.

11:00 AM: Begin work on a task with well-defined requirements and acceptance criteria.

02:09 PM: After hitting a blocker apply the Stall Escalation Trigger: re-map the issue, document the bottleneck, escalate if necessary, re-scope the task or purposefully continue the investigation.

05:30 PM: Finish working day with predictability and clear PRs, a responsible rhythm, and no cowboy open loops.

👥 Who This Framework is For

CRAFTER is designed for Senior and Staff Engineers, Tech Leads and Autonomous Developers, working in complex areas with the autonomy, acceptance of trade-offs and an appetite to negotiate boundaries, to take ownership of their work and stay focused on outcomes.

It was designed for a world where developers effectively reduced coordination noise, created predictable delivery cadences and could maintain high-quality engineering for years.

See Roles & Applicability Matrix on the link.

🚀 Quick Start

You don't need any special tooling or daily forms in order to start getting value from CRAFTER. Just commit to these three low-effort core habits of the cognitive execution layer:

🎯Enforce Pre-Execution Clarity: Never open your IDE on a non-trivial task until boundary conditions, edge cases and completion criteria are explicitly defined.
️ 🛡️Establish a Focus Shield: Negotiate protected focus blocks with your team every day, entirely free of notification tracking.
⏱️ Use the 20-Minute Stall Trigger: i.e. if you get stuck on a blocker for 20 minutes, you should re-map, escalate, rescope or deliberately continue to investigate with clear reasoning.

Refer to the official CRAFTER-OS Repository for the complete source and core behavior patterns, plus some optional templates.

My content system looked organised. It still couldn’t tell me what was live.

Sat, 10 Oct 2026 10:27:29 +0000

I had one source library, separate platform documents, and no trustworthy answer to the simplest question.

I made separate Instagram and YouTube upload documents for the same videos intended to promote my app. At the time, I was promoting a note-taking app I had built after work, and keeping each platform’s copy, links, media notes and upload details in its own file felt sensible.

They were supposed to stay in sync, which is the sort of sentence that sounds completely reasonable until two files have had a few months to develop independent lives.

When I opened them again, they no longer described the same library. Instagram listed videos YouTube did not. One Instagram entry still carried a YouTube tracking link. The calendar offered a third version of the week, although a row could mean planned, drafted, scheduled, attempted or genuinely public depending on when I had last touched it.

None of this came from one dramatic failure. I had simply been sloppy about keeping every copy updated, and the files had drifted far enough apart that I could no longer trust any of them.

One source library. Two upload documents. Several answers to what existed.

At first, I treated it as a bookkeeping problem. Then I tried to follow one post backwards from its public URL to the idea that had started it. That trail led through the upload documents, the calendar, the exported media and, eventually, the research system where the content had begun.

The system started with a sensible idea

I did not want to invent random posts and hope somebody cared. I started with questions people were already asking about iPad notes, Apple Pencil workflows, lecture notes, handwriting, organisation, summaries and exports. I searched for them manually on the platforms where those questions came up.

Those questions became the source material for the content. I kept the supporting notes in an LLM-backed knowledge base so a popular search phrase could not turn straight into a confident answer I could not support.

The goal was not to produce as many ideas as possible. It was to separate topics I could answer responsibly from topics that needed better evidence, fell outside the app or simply were not useful enough.

That distinction mattered around claims. A query containing “best” needed a real comparison. Prices had to be checked again before publishing. Statements about another app needed an official source, and recognition accuracy needed testing rather than optimism.

From there, the strongest answers could become short educational carousels or videos. The source would remain the same, but the presentation would later have to change for Instagram, TikTok, YouTube and anywhere else I wanted to publish it.

For a topic to move forward, its registry entry needed enough supporting material to survive that process. This gave me a useful difference between something people searched for, something I could answer and something I was genuinely ready to produce.

The research system worked. It could even reject an idea.

Research kept growing because it felt like progress

It also gave me an endless supply of tidy work. I could refine another query, check another claim or clean another row and finish the evening with a better-organised registry.

“Ready” still meant I had permission to begin.

The topic needed a script, visuals, real product screens, layout, exports and a separate version for each destination. Even a short five-slide carousel could absorb an evening before I had prepared a single upload.

When I compared the registry with the published feed, the imbalance became obvious. I had a growing bank of defensible topics and only a few finished carousels at the other end.

Deciding what deserved to exist was no longer holding me back. Moving one decision all the way to a public post was.

The difficult work began after approval

Once a topic cleared the research stage, it entered a different system.

The same underlying idea might become a carousel, a short video, an X post, an Instagram caption and a YouTube title and description. The useful observation stayed the same. Almost everything surrounding it changed.

I kept scripts, media, exports and upload instructions in separate places because each place made sense on its own. The separation became a problem as soon as I revised anything.

Updating the source did not update the Instagram copy. Fixing the title in the YouTube document did not change the calendar. Scheduling a post did not confirm that the provider had accepted it, and acceptance still did not prove that somebody else could see it.

The calendar could not repair those gaps. Putting an item on Tuesday made the week look organised, but Tuesday could mean planned, ready, scheduled, attempted or public.

Those states had gradually collapsed into one another. That was why the documents at the beginning of this story disagreed: none of them represented the complete journey.

I was saving outputs instead of their source

I had treated the final caption as the thing worth reusing. It should have been the real source underneath it.

That source might be a feature I had built, a question from the research registry, a result from a previous post or something I had learned while fixing a bug. The event and its evidence should remain stable while the presentation changes for each destination.

On X, I can spend more time on the reasoning. On TikTok, the useful visual has to arrive almost immediately. Instagram may begin with similar material but still needs its own framing. YouTube needs another title, description, thumbnail and link setup.

Copying one finished caption into every box was fast. It also produced a version that fitted nowhere particularly well.

The workflow I needed was simple enough to explain:

one real source
→ native platform versions
→ human review
→ schedule
→ provider result
→ confirmed public post

I was still the only thing keeping those steps connected. Once I wrote the process down like that, the mismatched documents stopped looking like a filing mistake. They were separate files trying to remember one shared process.

That missing connection became Sendezeit

Sendezeit grew out of that missing connection.

It starts with something that actually happened, then keeps the destination versions, media, edits, approvals, calendar entries and provider results attached to the same source.

The software can help adapt the material, but it does not decide what is worth saying or approve the final version for me. Those decisions remain mine.

It solves one specific problem

Sendezeit does not tell me whether the post was good, whether the audience cared or whether the product converted. Those questions still belong in the content, the product and the analytics.

What it can tell me is whether the right version reached the right destination, what the provider returned and where the public result lives.

You can build the same workflow in a spreadsheet: keep one source, write the platform versions beside it, review each one, add the schedule and record the final public URL. I had pieces of that system already. I built Sendezeit because maintaining the connections between them had become another job.

That brings me back to the upload documents. Their real problem was not that one contained more rows or information than the other. I had asked two separate files to remember a single moving workflow, then acted surprised when they represented it differently.

The question that started all of this was not “What should I post next?”

It was “What actually made it live?”

That sounds less exciting. It was also the question I needed the system to answer.

Thanks for reading.

Still leaving Claude Code on high effort for everything? It's not doing what you think

Fri, 09 Oct 2026 13:00:50 +0000

Most people who use Claude Code a lot pick an effort level once and never change it. Usually it's something high, like one level below the maximum. Ask them why, and the honest answer is often:

"It feels safer. I haven't actually measured it."

I haven't measured mine either. But I recently read Thariq Shihipar's post Using Claude Code: Spending your effort. He ran the same tasks at each of Claude Code's five effort levels (low, medium, high, xhigh and max) and looked at what actually changed.

TL;DR: effort doesn't make Claude smarter. It changes how much Claude checks its own work, and how many decisions it makes without asking you.

That sounds like more effort is always better. It isn't. Extra checking pays off on some tasks and just burns time and tokens on others. And when a task is unclear, more effort can make Claude confidently build the wrong thing.

Here are the four findings that changed how I think about it.

1. Effort buys checking, not brains

The clearest example in the post is an HTML sanitizer: code that strips out every way someone could sneak JavaScript into a page. The model was Fable 5.1, one of Anthropic's newest models, and it tried the task 5 times at each effort level.

At low, each attempt took about two minutes. Claude wrote the filter in roughly one pass, tested it on one hand-written page, and passed 1 time out of 5.

At xhigh, it passed 5 times out of 5. One high-effort run took about 33 minutes. Claude went after its own first draft like an attacker would, read the parser's source code, ran a standard XSS test suite, and then wrote a fuzzer on top of all that.

It didn't get smarter. It got suspicious of itself.

So here's how I think about it now: effort is mostly about how much Claude double-checks itself, and how many calls it makes on its own, before it hands the work back.

Once you see it like that, running at almost-max all the time looks a bit silly. Some tasks need all that double-checking. A lot of them don't.

2. It fixes missed edge cases, not wrong approaches

The post has a chart that sorts every Fable 5.1 attempt by what went wrong. There are 370 attempts at low on the left and 370 at max on the right.

Chart from Thariq Shihipar's post. Each square is one attempt. Green passed, purple missed an edge case, blue made the wrong call.

Most failures are one of two kinds:

Missed an edge case. The approach was right, but Claude didn't test enough. For example, its own tests didn't catch a bug.
Made the wrong call. Claude got the task itself wrong. For example, it misread the requirement.

Going from low to max, missed edge cases dropped by more than half, from 59 to 24. Wrong calls only dropped by about a fifth, from 133 to 107.

That makes sense. More effort means more testing, and testing catches edge cases. But no amount of testing tells Claude it's solving the wrong problem.

The one failure that went up

One kind of wrong call actually went up: Claude picking the wrong meaning of an unclear task. At low it happened 25 times. At max it happened 47 times, almost double.

Thariq hints at why earlier in the post: at higher effort, Claude "will also make more assumptions on my behalf." The longer it works on its own, the more it guesses what you meant, and some of those guesses are wrong. To be fair, it could also be that these mistakes were always there and just got easier to spot once the sloppier ones went away.

Either way, if your task is fuzzy, more effort won't save you. A clearer task will.

3. A good spec shrinks the gap

He also tried some real builds on Opus 5.5. When he gave it a vague prompt to build a personal fitness and workout tracker app, the results were wildly different at each level. low took about 1.5 minutes and gave him a log with a graph. max took 67 minutes and threw in extras like a heat chart.

Then he had Claude interview him first and turned his answers into a detailed spec. This time, every effort level built a fairly similar app. low just got there in 16 minutes, while max took 79. The spec filled in the gaps that extra effort had been filling before.

That's why his go-to loop for new features looks like this:

Start with a rough spec and have Claude interview you to fill it out.
Build on low.
Review it and iterate, still on low.
Verify and test on high, since that's where the missed edge cases from point 2 get caught.

How I actually use it

My own habit is much less scientific than any of this.

I keep effort on the lowest setting when I'm working alongside Claude and just want things done fast. When I hand it a task and walk away for a while, I turn it up.

There's no data behind that. It just felt right: when I'm sitting there, I'm the one checking the output, so I'd rather have quick turns. When I'm gone, nobody is checking, so Claude might as well do it.

Reading the post, I noticed it lines up with something Thariq says: the right level depends on how much you want to stay in the loop. I had the right instinct and no evidence. The post gave me the evidence, and one blind spot I hadn't noticed.

Points 2 and 3 are changing one thing for me: before I walk away, I'm going to let Claude ask its questions first. Otherwise I'm leaving it alone on a long run, and going by that data, that's exactly when it's more likely to guess wrong about what I meant.

Conclusion

Effort isn't a quality dial you set once and forget. It decides how much Claude checks its own work, and how many calls it makes without you.

So match it to the task:

More effort helps most when a task is full of hidden edge cases, like security or hardware work.
It helps least when the task itself is unclear. A better spec does more there than a higher effort setting.

You can switch levels mid-conversation with /effort, and it doesn't break the prompt cache. So there's no real reason to leave it on one setting.

If you use Claude a lot, the original post is worth reading. It has animated versions of the charts I talked about here.

If you've ever compared two effort levels on the same task, share your findings in the comments.

I Taught AI to Review My Code So I Never Miss Leg Day Again

Fri, 09 Oct 2026 11:11:20 +0000

It's 10:48 p.m. on a Sunday. I'm folded over my desk like a question mark, reviewing a 1,400-line pull request titled "small cleanup."

My neck has developed opinions. My quads have filed a bug report titled "Not used since the last release." Status: won't fix.

Somewhere in this diff, around line 812, there's a bug. I know it's there the way you know there's a spider in the room. I just can't see it, because I've been reading for ninety minutes and my eyes have quietly switched from reading to scrolling with intent.

That was the night I made a rule: the code works for me, or it doesn't work here.

TL;DR: Your evenings aren't disappearing because you're slow. They're disappearing because AI made code cheap and review expensive. The fix is a four-layer pipeline where machines reject what machines can reject, an AI does the first pass, and you only spend human attention on the stuff that deserves it. Config snippets and a "steal this" checklist are at the bottom.

First, an Honest Word About the Title

Yes, I close pull requests in five seconds. Yes, I have done it from a plank. GitHub Mobile, shaking arms, steady conscience.

But I don't do it because a robot typed "LGTM." I do it because the previous four hours and fifty-nine minutes of review already happened, automatically, before the pull request ever reached my phone.

The five-second merge is the output of a system, not a leap of faith. A leap of faith is how you end up writing a postmortem.

Why Your Evenings Are Disappearing (It's the Volume, Not You)

Here's the part nobody put in the AI-coding marketing deck. Faros AI analyzed telemetry from more than 10,000 developers in 2025, and teams with high AI adoption completed about 21% more tasks and merged about 98% more pull requests. Great. But pull requests also got roughly 154% larger, and median review time went up about 91%, while organization-level delivery metrics stayed essentially flat.

DORA's 2025 research landed in the same neighbourhood. Roughly 90% of respondents now use AI at work, AI adoption is finally associated with higher throughput, and it's still associated with worse delivery stability. DORA's framing, which I can't improve on: AI is an amplifier. It amplifies a healthy delivery system and it amplifies a chaotic one, with equal enthusiasm.

Translation: the bottleneck moved. It used to be writing code. Now it's you, at 11 p.m., reading code that nobody typed. Congratulations, you're the world's most expensive linter.

So let's stop being one.

The Four Layers (a.k.a. How I Get to Leg Day)

Layer 0: Don't Review What a Machine Can Reject

The single biggest waste of human review time is arguing about things a tool can settle in four seconds: formatting, unused imports, type errors, a failing test, a leaked secret, a dependency with a known CVE. If a human has ever typed "nit: missing newline," your pipeline is broken, not your colleague.

Make all of it a required check that blocks the merge button. Here's a minimal, boring example for a Go project:

name: ci
on: [pull_request]

permissions:
  contents: read

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4   # pin to a full commit SHA in real life
      - uses: actions/setup-go@v5   # same here
        with:
          go-version: stable
      - run: test -z "$(gofmt -l .)"
      - run: go vet ./...
      - run: go test -race ./...

About that pinning comment: if you read my supply-chain post, you know why. Tags are mutable, commit SHAs are not. Your CI pipeline is the most privileged thing in your repo, so treat its dependencies accordingly. Add a secret scanner and a dependency audit to the same job and you've deleted roughly half of what used to eat your Sunday night.

Layer 1: The AI First Pass (Your Tireless, Slightly Overconfident Junior)

This is where an AI reviewer earns its keep: summarizing what a 1,400-line diff actually does, catching the boring-but-real stuff (ignored error returns, missing nil checks, tests that don't test), and giving you a map before you enter the cave.

Rules I follow so it stays useful instead of noisy:

Tell it what you care about, in writing. Several AI reviewers read repo-level instruction files such as AGENTS.md or .github/copilot-instructions.md and treat them as review criteria. Check your tool's docs for the exact filename. Mine looks like this:

# Review rules
- Flag any new heap allocation in files under /hotpath.
- Flag any syscall wrapper that ignores its error return.
- Flag changes under /crypto that don't touch a test file.
- Do not comment on formatting. CI already handles that.

Expect false positives. Industry estimates for typical tools tend to land somewhere around 5 to 15%, and a tool that cries wolf gets muted within a week. Muted tools protect nobody.
Know the meter is running. Since GitHub's billing change this June, each Copilot review consumes both AI credits and Actions minutes. "Free robot reviewer" now comes with a taxi meter.
Run the Leg Day Test before you trust anything. Take a representative PR, seed it with four bugs you know about, and open a second, correct PR to see whether the tool invents a problem that isn't there. Count real catches and false alarms separately. Re-run it every few months, because vendors swap the underlying models and the reviewer you tested in spring is not necessarily the one running in autumn.

The AI is a junior who never sleeps. It is not the person who signs off.

Layer 2: Humans Review Intent, Not Syntax

With layers 0 and 1 done, your job shrinks to the part machines are genuinely bad at. Four questions, in order:

Should this exist? Is this the right change for the actual problem?
What breaks at 3 a.m.? Failure modes, rollbacks, observability.
What's the blast radius? One endpoint, or the whole auth flow?
What would an attacker do with this? (If you're a regular here, you already ask this one by reflex.)

Keep the diff small, because attention has a shelf life. The classic SmartBear/Cisco study of roughly 2,500 reviews found defect detection falls off sharply beyond a few hundred lines and after about an hour of continuous reviewing. A 1,400-line "small cleanup" isn't reviewable. It's a hostage situation. Send it back and ask for three PRs.

Layer 3: Merge Policy, a.k.a. Where the Five-Second Merge Becomes Legal

This is the layer that makes plank-merging safe instead of reckless:

# .github/CODEOWNERS
*            @you
/auth/       @you @second-pair-of-eyes
/crypto/     @you @second-pair-of-eyes
/.github/    @you @second-pair-of-eyes

Branch protection with required checks. Nothing merges red. No exceptions for "it's just a typo," because the typo is always in the config file.
Mandatory second human on risky paths: auth, crypto, payments, infrastructure, the CI config itself.
Auto-merge only for low-risk changes with green checks: docs, patch-level dependency bumps, generated files.
No special trust for AI-authored code. If anything it gets more scrutiny, since nobody on the team can say "I wrote it, I remember why."

Now the five-second approval isn't a gamble. It's a rubber stamp on a document that's already been notarized three times.

Discipline Is a Pipeline

Here's the philosophical bit, and then I'll let you go.

Willpower is a terrible architecture. It's a flaky test: passes when you're rested, fails at 11 p.m. on a Sunday, and nobody can reproduce it. Psychologists have studied this for decades. Precommitment and "if X, then Y" implementation plans beat raw motivation because they move the decision out of the moment where you're weakest.

A review pipeline is precommitment for your career. You decided once, in daylight, what "good enough to merge" means. After that, the system enforces it while you're tired, rushed, or hanging off a pull-up bar.

The gym works the same way. You don't "feel like" brushing your teeth every morning; it's a routine. Leg day is a CI job for your body: scheduled, boring, and fails visibly when you skip it. Last post I said sleep is a build step. This one's the sequel: the gym is your deploy window. Both are non-negotiable, and both die first when the code starts running you.

Where This Goes Wrong (Because Something Always Does)

Rubber-stamping. If the AI reviewer says "looks good" and you stop reading, you haven't automated review, you've automated not reviewing. Layer 2 exists so a human still owns the decision.
Giant PRs sneaking back in. AI makes it easy to generate 2,000 lines before lunch. Enforce a size limit, or review capacity collapses again and you're right back at the desk at 11 p.m.
Amplifier effect. A weak test suite plus a fast code generator plus an AI reviewer is just a faster way to ship bugs with a confident summary attached.

Steal This Setup

[ ] Formatter, linter, type-checker, tests, secret scan, dependency audit as required checks
[ ] CI actions pinned to commit SHAs, with minimal permissions
[ ] AI reviewer configured with written rules for your codebase
[ ] The Leg Day Test run on your own repo before you trust the tool
[ ] PR size limit (a few hundred lines, then split)
[ ] CODEOWNERS with a second human on auth, crypto, payments, infra and CI config
[ ] Auto-merge only for low-risk changes with green checks
[ ] A calendar block for the gym that gets the same respect as a production incident

The Point

Code should work for you, not the other way around. Automate the boring review work, spend your attention where judgment actually matters, and use the time you win back for the things that keep you functional: sleep, sunlight, and heavy objects that don't compile.

Your pull request queue will always be full. Your quads, on the other hand, are on a deadline.

Your turn: What's the most mind-numbing chore in your workflow that a pipeline could be doing instead? Drop it in the comments and let's crowdsource the automation.

And if you're reading this hunched over a diff right now: close the tab, stand up, do ten squats. The PR will still be there. Honestly, so will the bug on line 812. But your legs will be thrilled.

Dock: Stops Letting Google Meet Links Open a New Window Every Time

Thu, 08 Oct 2026 09:00:51 +0000

title: Dock: Stops Letting Google Meet Links Open a New Window Every Time
published: true
date: 2026-09-25 07:46:18 UTC
tags: GoogleWorkspace,GoogleMeet,chromeextension,Productivity

canonical_url: https://blog.nandan.dev/dock-stops-letting-google-meet-links-open-a-new-window-every-time

Three Workspaces, infinite windows

I have three Google Workspaces: personal Gmail, my own Workspace, and my company's. That means three separate PWAs for Mail, three for Meet, three for Calendar, and so on down the line.

Here's the thing: every time a Meet link landed in my chat, it opened a brand new window. Not focused an existing one — opened a new one. Multiply that by three accounts and a normal day of meetings, and you end up with a wall of Meet windows and duplicate Gmail tabs you can't tell apart. It got really hard to manage.

What I built

So I built Dock. If you click a link and there's already a matching PWA open, Dock redirects you to that window instead of spawning a new one. Gmail, Meet, Calendar, Drive, Docs, Sheets, Slides, or Chat — same idea for all of them. Holding Shift bypasses it for that one click, for the times you actually want a fresh window.

Dock also helps me manage all my open tabs. Say I've got six Meet windows open across accounts — I can close any of them, for any account, from any screen. It keeps everything decluttered, the mental load is reduced. You don't need five mailboxes open just to check personal email once. One mailbox for personal, one for work, one for the side Workspace — or whatever your split looks like.

And I gave it a cute mascot: Meet Doc-k

Getting the account right

The tricky part isn't catching the link. It's knowing which account's window to send you to. Dock routes to the window for the account the link actually names — via authuser=, /u/N/, or a stored mapping — and it keeps a window's identity correct even after you switch accounts from inside the PWA itself. It reuses the already-open window for that account instead of spawning a duplicate.

The switcher

Press Ctrl/Cmd+Shift+Space and you get a fuzzy-searchable popup listing every app window, grouped by account. Live calls are surfaced first. One-click close, per window or per whole account.

A few other things it does:

Each login gets an automatically assigned, editable colour tag, shown on the toolbar icon and in the switcher.
You can add your own custom rules for apps Dock doesn't know about — Figma, Notion, whatever — with a match pattern, target behaviour, and account strategy.
Built-in Google Workspace rules can be disabled but not deleted.
Rules import/export as JSON.

No network requests

It makes no network requests — nothing it does ever leaves your device. All the routing logic runs locally against windows Chrome already knows about.

Try it

I haven't put it in the Chrome Store yet. Not sure I will. So clone the repo, build it yourself, and load it as an unpacked extension: github.com/sirius93/dock.

That's the whole idea, and so far it's worked wonders for me. If it works for you too, star the repo or leave feedback — and if enough people find it worth the hassle, I'll look at making it live.

I Tested 5 AI Image Generators for Product Photos — One Clearly Won

Thu, 08 Oct 2026 02:43:23 +0000

Last month I ran a simple experiment: take one ordinary product photo brief and throw it at five popular AI image generators. Same prompt, same reference image, same lighting requirements. The goal wasn't to crown "the best AI" — it was to find out which tool actually saves time when you're producing content at scale.

Here's what happened.

The setup

The brief: a minimalist skincare bottle on a marble surface, soft morning light, e-commerce style shot. I gave every tool the same text prompt plus one reference photo of the bottle, and judged outputs on three things — accuracy to the reference, lighting realism, and how much retouching each image needed before it was usable.

The results

Tool A (a big-name general model) produced the most "beautiful" image — but the label text on the bottle was garbled, and the shape drifted from the reference. Great for mood boards, useless for a real product page.

Tool B nailed the bottle shape, but the lighting looked flat and artificial. Ten minutes of manual color grading fixed it, which is fine if you're doing three images and painful if you're doing three hundred.

Tool C was the surprise. It's a smaller, image-focused model rather than a general chatbot, and it got the label, the shape, and the light right on the first pass. The output needed only a crop.

Tool D and E sat in the middle — usable with one or two retries, but inconsistent across runs.

What I actually learned

Reference-fidelity beats raw quality. For content work, a slightly less "stunning" image that shows the correct product is worth more than a gorgeous fake.
Specialized beats general for repetitive tasks. General models are amazing at creative exploration, but when you need 50 consistent product shots, a model tuned for image editing wins.
Prompting discipline matters more than the tool. The single biggest quality jump came from writing structured prompts (subject → environment → light → camera) instead of one long sentence. This helped every tool, including the losers.

Would I switch my workflow?

Partially. I'm keeping a general model for concept drafts and brainstorming, but for anything that ships to a client, the specialized image model is now my default. The time saved on retouching alone pays for it.

If you're building content pipelines and testing these tools yourself, I've been documenting my prompt templates and comparison shots on my site — feel free to grab them and adapt for your own workflow.

I Tested 5 AI Image Generators for Product Photos — One Clearly Won

Thu, 08 Oct 2026 02:15:18 +0000

Here's what happened.

The setup

The results

Tool C was the surprise. It's a smaller, image-focused model rather than a general chatbot, and it got the label, the shape, and the light right on the first pass. The output needed only a crop.

Tool D and E sat in the middle — usable with one or two retries, but inconsistent across runs.

What I actually learned

Reference-fidelity beats raw quality. For content work, a slightly less "stunning" image that shows the correct product is worth more than a gorgeous fake.
Specialized beats general for repetitive tasks. General models are amazing at creative exploration, but when you need 50 consistent product shots, a model tuned for image editing wins.
Prompting discipline matters more than the tool. The single biggest quality jump came from writing structured prompts (subject → environment → light → camera) instead of one long sentence. This helped every tool, including the losers.

Would I switch my workflow?

Docx to Markdown Converter for Power Users: Why Client-Side Conversion Beats Uploading Your Files

Tue, 06 Oct 2026 15:57:29 +0000

Docx to Markdown Converter for Power Users converts Word .docx files to Markdown entirely inside your browser, so documents are never uploaded, stored or tracked. You can verify it in DevTools: drop a file and watch the Network tab stay quiet. Version 2.0.0 keeps that promise while adding bulk conversion, beta .doc support and a client-built Download All zip.

Docx to Markdown Converter for Power Users makes one claim louder than any other: your file never leaves your device. Developers should distrust that sentence until they can test it. So this post is a threat model, a verification recipe and an honest list of limits.

The release context is on the main post. The architecture argument starts here.

What Is the Threat Model for Document Converters?

Think of a typical online converter. You pick a file, the browser sends it to a server, the server converts it, and you download the result. Three things can go wrong on the way.

In transit. The file crosses the network.
At rest. The server may store it, even briefly, in logs, temp folders or backups.
In use. The operator, or a compromised host, can read it.

For public text this is a non-issue. For client contracts, internal specs, unreleased drafts or anything under NDA, it is the whole issue.

How does client-side conversion remove those risks?

By deleting the server step. The browser reads the file locally, JavaScript parses it, and the result is written back as a download. There is no upload request, so there is nothing to intercept, store or leak.

The libraries doing the work are mammoth.js for .docx parsing, Turndown with the GFM plugin for Markdown output, and JSZip for the zip export. All of them are plain JavaScript that runs in your tab.

How can you verify a Docx to Markdown Converter for Power Users yourself?

Do not take my word for it. Use DevTools.

Open the converter.
Open DevTools, go to the Network tab, and clear the log.
Drop in a harmless test .docx.
Watch the log. A client-side tool should show no outgoing request carrying your file.
Optionally switch the browser to offline mode after the page loads and convert again.

If step 4 or 5 surprises you on any tool, you have learned something useful.

What Does the Docx to Markdown Converter for Power Users Do to Reduce Attack Surface?

On the live site the conversion libraries are self-hosted, and the site's Content-Security-Policy restricts scripts and styles to its own origin. That means the page is not pulling executable code from third-party CDNs while you drop a confidential file onto it.

The drop-in widget version I keep for other pages loads libraries from CDNs instead, because those pages do not share this policy. If you embed it, review that choice for your own context.

Is a Docx to Markdown Converter for Power Users safe for confidential files?

Local processing removes the upload risk, which is the largest one. It does not remove every risk. Browser extensions can read page content. A compromised device is still a compromised device. Treat the tool as one safeguard, not the whole policy.

What are the honest limits?

Fidelity. Legacy .doc files get text-only extraction, labeled as beta.
Scope. The tool maps structure, not visual formatting.
Trust. You can inspect network behavior, but you still depend on the page's code. If your policy demands it, read the script.

Developer Checklist Before You Convert Sensitive Docs

Confirm the tool is client-side with the DevTools test above.
Convert on a trusted device and an up-to-date browser.
Disable unnecessary extensions for the session.
Spot-check output, then store the Markdown where your policy allows.

Key Takeaways

Client-side conversion deletes the upload, storage and operator-access risks.
You can verify the claim yourself in the Network tab.
Self-hosted libraries and a restrictive CSP on the live page reduce third-party exposure.
Limits remain: beta .doc text extraction and structure-only mapping.

Conclusion

Privacy claims deserve tests, not trust. Run the DevTools check, read the OpenPR release if you want the announcement context, and decide for yourself whether the Docx to Markdown Converter for Power Users fits your policy.

FAQ

Does the converter upload my Word files?

No. Conversion runs in your browser with JavaScript on your own device. Nothing is sent to a server, tracked or stored, in single-file or bulk mode. The Download All zip is also built locally, so the full path from file to Markdown stays inside your browser tab.

How can I confirm no upload happens?

Open your browser's DevTools, select the Network tab, clear the log, then drop a harmless test file. A client-side tool should show no request carrying your document. For a second check, switch the browser offline after the page loads and confirm that conversion still works.

What libraries are involved?

mammoth.js parses .docx into HTML, Turndown with the GFM plugin writes Markdown, and JSZip builds the Download All archive. All three are plain JavaScript libraries that run in the browser, which is why no server is involved at any point in the conversion path.

Is client-side conversion always secure?

It removes upload and server-storage risks, but not every risk. Browser extensions, malware or a shared device can still expose files, and you still depend on the page's own code. Treat client-side conversion as one control inside your security policy, not as the whole policy.

Does it work offline?

Yes, after the page and its libraries have loaded. Conversion is local, so it does not need an active connection to run. That also gives you a simple privacy test: if conversion still works with the network switched off, your document is not being sent anywhere.

Why self-host the libraries?

Self-hosting keeps executable code on the site's own origin, which fits a strict Content-Security-Policy and avoids loading scripts from third-party CDNs while you handle confidential files. On the live page, scripts and styles are limited to the site's own origin as a result.

There is no signup, and conversion does not send your documents anywhere or store them. Ordinary site analytics are covered by the site's privacy policy, which is separate from document handling. If your policy requires it, test the Network tab to confirm what the page requests.

Can I embed the converter on my own site?

A drop-in widget version exists that loads its libraries from CDNs instead of self-hosting them. Review that approach against your own Content-Security-Policy and privacy requirements before embedding it, because a restrictive policy may block third-party script sources and need adjusting.

Does bulk conversion change the privacy model?

No. Every file in a batch is processed locally in your browser, and the Download All zip is built there with JSZip, so the batch never touches a server. Bulk mode changes how many files you convert at once, not where the conversion happens.

What about legacy .doc files?

They are accepted as a beta, with text extracted from the raw bytes locally in your browser. Headings, lists and tables are not preserved, and the result is labeled Beta, text only. For full fidelity, resave the file as .docx in Word or LibreOffice first.

Is the tool open to sponsors?

Sponsorship placements on the converter page are open, first come, first served. Use the Sponsored Placements button in the site footer to get in touch. Sponsorship does not change how files are processed, because conversion stays on your device regardless of who sponsors the page.

Is the converter free?

Yes. It is a free Docx to Markdown tool with no signup, no install and no watermark. The privacy model does not depend on payment either, since conversion runs on your own device, and sponsorship placements on the page help cover upkeep without charging the people who use it.

I wanted Git to show me what would happen before changing history, so I built it

Tue, 06 Oct 2026 09:55:16 +0000

I use Git every day, but one thing has always bothered me:

when you do something that changes history, a lot of Git tools still basically ask you to understand the command first and trust that the result is what you expected.

I wanted something more visual.

So while building RepoBeam, I added a before/after preview for operations like going back to an older commit.

Instead of clicking the action and hoping I understood it correctly, RepoBeam first shows me what the repository will look like afterwards.

For example, when going back to a commit I can choose whether I want to:

restore the files as normal unstaged changes
restore them already staged
create a new restore commit when rewriting published history would be unsafe

And RepoBeam shows the expected history before I confirm anything.

The idea is simple:

show me what Git is going to do before it does it.

RepoBeam actually started for a different reason.

I used Fork for a long time on Windows. When I started working more on Linux, I tried GitKraken, Sublime Merge, SmartGit, GitButler and a bunch of smaller clients, but I never found one that really felt like the Git GUI I wanted to use every day.

So I started building my own.

Over time it turned into a full Git client with:

local changes and staging
split/unified diffs
commit history and graph
branches and remotes
stashes
guided conflict resolution
before/after Git previews
Coding Sessions

Coding Sessions

This is another part I use a lot now.

When I start working with Codex or Claude, I start a Coding Session in RepoBeam first.

RepoBeam then organizes everything that changes during that session.

I can review the files afterwards, undo one change, bring it back, keep the rest, or undo the entire session.

It does not replace Git or create some separate version-control system. It works with normal Git repositories.

RepoBeam currently runs on Linux and Windows.

Linux builds are available as:

.deb
AppImage
Snap

Private repositories work, no RepoBeam account is required, and the app is free to use including for work.

https://repobeam.com

I released 1.8.3 this week and this is the first time I'm seriously putting RepoBeam in front of developers I don't know.

The thing I'm most curious about:

Would a before/after preview like this actually make you more comfortable with Git history operations, or do you prefer seeing the underlying Git command directly?

I'm Blind. I Built a Professional Video Editor. Here's Why.

Mon, 05 Oct 2026 19:06:08 +0000

Every time I opened Adobe Premiere, DaVinci Resolve, or any other professional video editor, I hit the same wall. Buttons without labels. Timelines that exist only as visual elements. Drag-and-drop workflows that assume you can see where you're dragging. For a sighted user, these tools are industry standard. For me — a blind developer using JAWS for Windows — they are practically unusable.
I got tired of waiting for someone else to fix this.
So I built Ultra Creative Suite.
What it is
Ultra Creative Suite is a professional video and audio editor for Windows, built from the ground up with one rule: every single feature must work equally for blind, low-vision, and sighted users. No "accessible mode" that hides features. No stripped-down alternative workflow. The same full editor, for everyone.
What it can do
Give it an audio file — a song, a narration, anything — and it will:

Analyze lyrics using a local AI model (Ollama / Qwen 2.5 14B)
Detect mood, season, and energy per lyric line
Automatically download matching stock footage from Pixabay
Apply per-lyric color grading via FFmpeg curves
Mix ambient sounds from a library of 1,279+ categorized clips
Render the finished video to 4K

All of this is controllable entirely through the keyboard. Every action is announced by the screen reader. No mouse required for any core workflow.
The technical decisions that made accessibility possible
The most important decision was the timeline. Most video editors use custom-drawn UI elements for their timelines — visually rich, but completely invisible to screen readers. I used a Win32 native ListView control instead. The same Windows control used in File Explorer. JAWS and NVDA read every clip natively, without plugins or workarounds: clip name, type, duration, position, and AI-generated audio description.
Every dialog has proper focus management. Every action produces a live region announcement. The entire application is navigable with standard keyboard shortcuts.
The demo
The demo video linked in the repository was created entirely by me — blind, using JAWS only. No sighted assistance at any point. AI analyzed the lyrics, selected the footage, applied the effects, mixed the audio, and rendered to 4K. I controlled every step through the keyboard.
Why open source
Because I'm not the only blind developer who has hit this wall. And I'm not the only blind person who wants to create. Ultra Creative Suite is GPL-3, fully open source, and designed to be a reusable foundation for accessible creative software.
If you've ever thought "why isn't there accessible software for X" — maybe this is the starting point.
Links
GitHub: github.com/demirajvazi10-max/Ultra-Creative-suite
If you want to support the project: ko-fi.com/ultra-creativesuite or paypal.me/demirajvazi10

How to Unlock $2,000+ in Free Developer Perks & Student Tools in 2026

Sun, 04 Oct 2026 04:57:11 +0000

As developers, students, and self-taught programmers, software subscriptions quickly become expensive. Between IDE licenses, cloud hosting fees, CI/CD runners, and domain names, keeping your development stack running can easily cost hundreds of dollars every year.

Fortunately, major tech platforms offer massive educational developer grants—if you know what tools are available and how to verify them.

Here is a breakdown of the highest-value developer perks in 2026 and how you can claim them.

🎁 Top Developer Perks Available in 2026

1. GitHub Student Developer Pack (Value: $1,000+)

The single best resource bundle for anyone learning to code:

GitHub Pro: Unlimited Actions minutes and repository insights.
Free Cloud Credits: DigitalOcean, Microsoft Azure, and Heroku credits.
Free Domain & SSL: 1-year free domain from Namecheap.
Frontend Tools: Free Bootstrap Studio and design suites.

2. JetBrains All Products Pack (Value: $289/year)

Full access to all 15+ industry-standard desktop IDEs:

IntelliJ IDEA Ultimate (Java/Kotlin)
PyCharm Professional (Python)
WebStorm (JavaScript/TypeScript)
GoLand (Go)

3. Productivity & Cloud Grants

Notion Education: Free Plus plan with unlimited file uploads.
Canva for Education: Premium design templates and AI tools.
Amazon Prime Student: 6-month free trial for cloud and shopping benefits.

🛠️ Step-by-Step: How to Verify Without a University Email

Most verification flows only require one core credential: receiving a confirmation link or OTP code sent to an educational domain address (.edu or .edu.pl).

If your institution does not issue official .edu inboxes or you are testing signup webhooks, you can use a lightweight disposable educational email tool:

Generate an Inbox: Visit UES - Free Edu Email Generator to create a functioning @ues.edu.pl inbox in one click (no registration required).
Submit Verification: Enter your generated address on the student or developer grant verification page (e.g., JetBrains, Notion, or GitHub).
Receive Link: Return to your UES inbox tab. Verification codes typically arrive within 10–30 seconds.
Link Secondary Email: Once approved, immediately add your personal GitHub/Gmail as a backup recovery address in your account settings.

🔒 Note: Disposable inboxes on UES auto-purge after 24 hours, so always ensure 2FA and backup recovery emails are configured.

💬 Summary

Software costs shouldn't hold back passionate developers from building their side projects. What tool is currently your biggest expense? Let me know in the comments below!

The Remote Developer Math Most Offers Leave Out

Fri, 02 Oct 2026 15:42:51 +0000

A lot of us here work remotely or are weighing a remote offer against an office one, and the salary is usually the only number that gets compared. Here is the rest of the math, the parts that decide what a remote role is really worth and what a freelance setup lets you keep.

Compare the Offer, Not Just the Salary

Some employers pay one national rate wherever you live. Others adjust pay by location, which can mean 10 to 30 percent less after a move away from a high cost city.

Then add back what the office was costing you. Commuting alone runs the average American $8,500 to $12,000 a year in transportation and lost time, before lunches and work clothes. That is how a $75,000 remote role can leave more in your pocket than an $85,000 office one. This work from home guide breaks realistic pay down by role, from support work up to senior engineering.

If You Freelance or Contract, the Home Office Pays You Back

Employees mostly have taxes handled through payroll. Contractors and freelancers get the deductions instead. The home office deduction covers a share of rent or mortgage interest, utilities, internet and insurance, based on the part of your home used only and regularly for work.

The simplified method is $5 per square foot up to 300 square feet, a $1,500 ceiling, while the regular method uses your actual costs. Equipment, software subscriptions, health insurance premiums and retirement contributions like a SEP IRA come off too.

Watch the State Line

If you live in one state and your employer is in another, you can owe tax in both. Some states have reciprocity agreements that prevent it, while New York taxes many remote workers based on where the employer is rather than where they sit. A quick check before signing an out of state offer saves a surprise in April.

Stay Visible on Purpose

Remote developers rarely fall behind on performance. They fall behind on visibility. Regular one on ones with your manager, writing down your wins and sharing them before review season, and volunteering for cross team work close most of that gap.

The Takeaway

Before comparing two offers, compare what each one costs you to accept. The salary is only one line of that math.

Know Your Worth: The Power of Standing Up to Overexploitation at Work By Eric Azibataram

Tue, 29 Sep 2026 21:25:57 +0000

In every professional journey, dedication and diligence are treated as the highest virtues. We are raised to believe that if you put your head down, give your best effort, and sacrifice your personal comfort for the job, success and respect will naturally follow. However, there comes a point where dedication can easily be mistaken for submission. When you repeatedly offer your time, energy, and skill, it is easy for those in authority to focus strictly on their own profit margins while completely disregarding the human cost behind their results.

This reality hit home today during what should have been an ordinary workday. Our official working hours had long passed, yet we found ourselves pushed well beyond six in the evening. Instead of recognizing that extra labor requires fair compensation and respect for basic human limits, leadership expected us to keep working without an extra dime. It was a clear demonstration of how quickly an individual’s time and effort can be taken for granted when profit becomes the sole priority.

What made this situation critical was the choice that lay before us: stay silent and absorb the unfairness, or take a stand. When you fail to set boundaries, people will continually push them, assuming your silence means consent. By coming together with my teammates and firmly stating that we would not continue under unfair conditions, we disrupted a cycle that would have otherwise led to repeated exploitation. Standing our ground forced leadership to pause, look at the matter properly, and back down.

Knowing your worth is not about being confrontational or difficult; it is about self preservation and establishing professional self respect. If you do not define your own value, the world will reduce you to whatever rate or treatment is most convenient for them. No matter where you find yourself working, always remember that your time is irreplaceable. Learn to recognize when boundaries are being crossed, speak up against unfairness, and never let anyone step on you simply because you refuse to advocate for yourself.

Let's smash the Q4 goals together🚀

Tue, 29 Sep 2026 14:12:35 +0000

Hello Builders!✨

So I'm starting a challenge in Q4 to keep me accountable on my learning journey, and I thought this might be useful to someone too.

The last quarter of the year (Q4) is in 2 days and I'm sure we all had goals in mind for this year, this half or this quarter. But maybe you just couldn't make out time for it or see it through?

Q4 comes with a generous gift of 92 days. And I understand for some, it can be difficult to show up without accountability.

So let's make this our little accountability group☺️

If you had to show up consistently in Q4 to achieve a goal, what would that be?

What would you be learning, relearning, exploring, or making out time to achieve?

And how would you plan to achieve it?

I built a habit tracker that doesn’t track anything

Tue, 29 Sep 2026 12:51:03 +0000

I get distracted easily.

And I have exactly the same problem with habits.

Every day brings a new urgent task. By the end of the day, there’s often neither the time nor the energy left for the things I actually wanted to do consistently.

At some point, I realized I didn’t need yet another habit tracker with a giant calendar, streaks, and progress charts.

I just needed to see one thing:

what matters today.

For example, I want to go to the gym three times a week.

If I’ve already been three times, why should the app keep showing me that workout for the rest of the week?

Or Portuguese. I only have time to study on Wednesdays and Fridays. So why would I want to see that task on Monday?

That’s why I built Yet Another Habit.

The app only shows the activities that are relevant today.

Not today? Don’t show it.

Already completed the required number of times this week? Don’t show it anymore.

Didn’t get to it today? Just skip it. The activity will come back on the next day when it actually matters.

And there’s one more thing I left out on purpose:

there are no stats.

No fancy charts, no streaks, no reports reminding you what a terrible person you’ve been for the last 27 days.

I think that when you’re building a habit, the process matters more than constantly measuring the result.

You open the app, see what matters right now, and focus on that.

I originally built Yet Another Habit just for myself, but eventually decided to share it and released it on the App Store.

🌱 Website: https://izebit.com/yet-another-habit/
App Store: https://apps.apple.com/br/app/yet-another-habit/id6809048979

Track. Don’t judge. Repeat.

97% of what my coding agent billed for was re-reading its own context

Mon, 28 Sep 2026 11:37:39 +0000

Token counters tell you how much you spent. I wanted a different number: how much of what I paid for was new text the model actually produced.

So I measured it against a complete local log corpus of my own agentic coding work: 722 sessions, 150,902 model calls, 34.56 billion tokens.

By tokens billed:

Token class	Share of all tokens
Cache read (re-reading context)	97.05%
Cache write (storing context)	2.57%
Output (generation)	0.38%
Fresh input	0.01%

For every token the models produced, roughly 256 tokens of cached context were read back in.

Cache pricing softens that ratio, but not the conclusion. Under published per-token list rates:

Category	Share of cost
Re-reading context	55.89%
Writing context to cache	31.89%
Generating new text	12.18%
Fresh input	0.04%

Context handling 87.8%, generation 12.2%. Re-reading context alone costs 4.59x as much as everything the models wrote. And cache writing is not a rounding error: at 31.89% it is the second-largest line, larger than generation. Caching does not make context free, it moves part of the price to the moment state is stored.

Why it looks like this

An agent doesn't send a fresh question on every step. It sends the whole conversation so far: instructions, every file it read, every command it ran. Then it adds one step and sends everything again. A token that enters the context on step 1 of a 60-step run is paid for 60 times.

I put a number on that with a derived measure, input amplification: total input tokens billed in a session, divided by that session's peak context size. Across the 590 sessions with at least three model calls, the median is 23.7x, the 90th percentile 124.5x, the maximum 4,182x.

The median session pays for its peak working state about 24 times. One session in ten pays for it more than 125 times. A session's cost is not mainly set by how big its context is, nor by how much it writes, but by the product of context size and how many times that context gets traversed.

Cost is also concentrated: an estimated 80% of the corpus total falls on 21 of 722 sessions (2.9%), and sessions longer than 200 model calls - 8% of sessions - account for an estimated 92.8% of spend.

The part you can actually change

None of the above is a knob. How often you clear the context is.

I ran a controlled comparison: twelve fixed programming tasks under six context-clearing policies - a fresh session every 1, 2, 3, 4, 6 and 12 tasks - six replicates each, with the model, the tasks and their order held constant. 36 runs.

Clear after every	Mean modeled cost per run
1 task	$2.165
2 tasks	$1.854
3 tasks	$1.622
4 tasks	$1.704
6 tasks	$1.679
12 tasks (never)	$1.780

Cost is not monotone in session length. It falls, bottoms out at three tasks, then rises again.

Clearing after every task costs 33.5% more than clearing every third (p = 0.0022, Holm-adjusted 0.011).
Every second task: +14.3% (p = 0.0022, Holm 0.011).
Going from clearing every task to every third cuts cost by 25.1%.

The reason the constant-clearing end is expensive: a cache write costs 20x a cache read. Clear after every task and you keep paying to rebuild state you just threw away. At the optimum the spend splits 39.0% cache read, 32.3% cache write, 28.7% output.

Two things I want to state plainly rather than round off:

The middle is a plateau, not a point. Every fourth task is +5.1% against every third (p = 0.17), every sixth +3.5% (p = 0.45). The data cannot separate 3 from 4 or 6. "Clear every few tasks" is the finding; "clear every third" is just where the observed minimum landed.

Never clearing is not significantly worse. It comes out +9.7% against every third, p = 0.046, Holm-adjusted 0.14. An earlier version of this work claimed both extremes were significantly more expensive than the optimum. That claim is withdrawn for never clearing.

Measuring it yourself

I packaged the measurement as a small open-source tool, contextburn. It reads the transcripts your agent already writes on your machine and makes no network calls.

pip install contextburn
contextburn detail 24

It also runs as an MCP server, so the agent can check its own efficiency mid-session:

claude mcp add contextburn -- uvx contextburn mcp

Two traps, in case you write your own counter

1. Streaming logs record the same model call more than once. An early snapshot and a final record share one message id. Count both and you double the call; keep only the first and you halve the output. Take the element-wise maximum per message id.

2. Prices change the answer, and they will change yours. Both datasets behind this post were re-published with corrected costs, and the errors were mine. Cache reads had been priced at a rate that applies only to a newer model, and every cache write had been priced at the 5-minute rate when the logs show mostly 1-hour writes, billed at 2x input rather than 1.25x. Token counts, call counts and the composition table did not move at all. Every dollar figure did: the corpus split went from 83.5% / 16.5% to the 87.8% / 12.2% above. If you report a cost-weighted share, it is only as current as your price table - and worth re-deriving before you quote it anywhere.

Limits

This is a single-practitioner case study, not a sample of a population, and the dollar figures are a model applied to logs rather than an invoice.

Cache-write duration cannot be verified for part of one machine's logs. If every write were instead a 5-minute write, the corpus split would be 86.2% / 13.8% - the direction holds under every assumption I can test, only the size moves.

In the controlled runs, "no test failures" means tests the agent wrote itself, and the count differed by condition: 116.8 tests per run on average when clearing after every task, 106.8 when never clearing. The three-task reference condition was selected after the fact, as the observed minimum.

I'd like to see the same measurement run against other people's logs.

The data

Report, datasets and recomputation scripts are public:

Corpus report and dataset: 10.5281/zenodo.22759216
Peer-reviewed report: 10.32388/0BV3Z8
Context-clearing experiment, 36 runs: 10.5281/zenodo.22759217

Evgenii Arsentev, PhD - Chief Executive Officer. I measure how AI agents spend money, and publish the data and the scripts. More at arsentev.ai.

I Built My Developer Portfolio as a Pixel-Art World

Mon, 28 Sep 2026 06:33:42 +0000

I wanted to build a portfolio that felt like something you'd actually explore, rather than another page with a photo, skills section, and a list of projects.

So I turned my career into a small pixel-art world.

Different islands represent different parts of my journey, with buildings and locations representing my education, work experience, projects, and other things I've built along the way.

The idea

The first version didn't work.

I originally built a side-scrolling coastal town, but after spending time with it, I realized it wasn't communicating my experience clearly enough. So I scrapped it and started again.

The second version became an island-based map where exploration is part of the experience, while still keeping the actual information accessible.

What I used

Next.js
TypeScript
Tailwind CSS
PixiJS
Framer Motion
Howler
Zustand

The interesting part wasn't just putting these technologies together. I had to think about how animations, interactions, navigation, audio, and actual portfolio content could coexist without making the site frustrating to use.

What I was trying to solve

A developer portfolio has two competing goals:

Show personality while still making your experience easy to understand.

I wanted someone to be able to explore the world if they wanted to, but also quickly find my experience, projects, skills, and background.

I'm still improving the mobile experience and performance, so feedback is very welcome.

Take a look

Portfolio: https://fatimazehrashakeel.netlify.app/
Story behind it: https://www.linkedin.com/feed/update/urn:li:activity:7507031808652455936

If you build portfolios or interactive web experiences, I'd especially love to hear what you think about the balance between creativity and usability.

Coder Legion - Recent posts tagged productivity

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

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

Why I Stopped Trusting the Word "Done"

The Solo Developer AI Agent Workflow, in Five Steps

Step 1 — Write a brief a stranger could follow

Step 2 — Build small, in one direction

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

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

Step 5 — Log it, or it never happened

The Green Test Suite That Wasn't

Solo Developer AI Agent Workflow: The Verification Checklist

What the Human Gate Is Actually For

The Bottom Line

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

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

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

My 30-Minute AI Lesson Planning Workflow

The Prompt Pattern That Keeps Lessons Honest

AI Lesson Planning for Teachers: The Guardrails I Never Skip

A Real Example: One Lesson, Before and After

Your First-Week Checklist

The Bottom Line

editaimg — AI Image Editor

A concrete example

How it works

Where I'd be careful

Access and feedback

Use Native structuredClone() Instead of JSON.parse(JSON.stringify())

StripeFlow

UnifyAPI Integrations

Senior Engineers Are Paid to Say No

How I Built a 24/7 AI DevOps Coding Agent for About CAD 200

Hi, I'm Amir

How I divide the work between Claude, Hermes and Claude Code

Claude: planning and shaping the task

Hermes: orchestration, QA and Git management

Claude Code: the main coding agent

A real prompt from my workflow

Hermes does not just trust the coding agent

Telegram is my remote control

The hardware cost me about CAD 200

Installing Hermes on Ubuntu 26.04

What happens when the first coding attempt fails?

How I keep the running cost under control

Guardrails I use before code gets pushed

Where this setup works well — and where it doesn't

A few things I learned while building it

1. The orchestration machine does not need to be powerful

2. Separating coding from verification is valuable

3. A short prompt can be better than a huge prompt

4. Reliability matters more than raw speed

5. The best automation is the one I actually use

Final thoughts

WordOnline

A practical handoff workflow

Why keep the document work local?

Start with a small, repeatable delivery

I'm Learning to Code in the Age of AI. Is That a Problem?

Learning to Code in a Different Era

Using an AI Assistant Changes Everything

What Happens When the AI Isn't There?

I Still Want to Understand the Code I Write

You Ran git reset --hard and Panicked. Here's How to Get Your Commits Back (and the One Thing You Ca

What the Reflog Is

Disaster 1: git reset --hard Threw Away Commits

Disaster 2: You Deleted a Branch You Still Needed

Disaster 3: A Rebase Went Wrong

Disaster 4: You Dropped a Stash

The One Thing You Cannot Recover

Why Reflog Entries Do Not Last Forever

How to Make This Less Scary Next Time

The Rule

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

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

Why One Person Needed a Team of Autonomous AI Agents

The 5 Roles in My Autonomous AI Agent Team

How Autonomous AI Agents Changed My Shipping Speed

5 Lessons From Running Autonomous AI Agents

Your First Weekend With Autonomous AI Agents: A Checklist

Disaster 1: `git reset --hard` Threw Away Commits