DEV Community: Wahib EL KHADIRI

Coding with an AI agent: what actually changed (and what didnt)

Wahib EL KHADIRI — Wed, 05 Aug 2026 07:49:51 +0000

Every job post now says "we expect you to use AI in your daily workflow." Good — because used well, an AI coding agent is a real multiplier. Used badly, it's a confident intern that ships bugs. After months of building and shipping merged open-source PRs with an agent in the loop, here's what actually changed — and what didn't.

What genuinely got faster

Navigating unfamiliar codebases. Dropping into a repo I've never seen and asking "where is X handled and why" collapses hours into minutes. This is the single biggest win — not writing code, but understanding it.

Boilerplate and tests. Regression tests, argument parsing, config plumbing — the stuff you know how to write but don't want to. The agent drafts, I review.

Refactors with a spec. "Replace this nested loop with a vectorized construction, preserve ordering and the guards" → a clean patch I then verify.

What did NOT change (and never should)

You still own correctness. I don't merge anything I can't explain and haven't tested. On one fix I had the agent generate a change, then I ran the old and new code side-by-side across every input and asserted identical output before opening the PR. The agent wrote the diff; I signed off on it.

Judgment is still yours. Which issue to pick, whether the scope is sane, whether a bounty is a dead race — the agent will happily execute a bad plan. Deciding what to do is the human's job.

The workflow that works for me

Human: pick a small, concrete problem.
Agent: explore the codebase, propose a minimal change.
Human: sanity-check the plan (reject vague or oversized ones).
Agent: implement + draft a test.
Human: run the full suite, verify, read every line.
Human: write the PR, disclose AI assistance, ship.

Notice the human is at both ends. The agent compresses the middle.

The honest failure mode

The trap is trusting output you didn't verify. An agent will produce plausible, well-formatted, wrong code — and it looks exactly like the right code. The discipline that matters in 2026 isn't prompting; it's verification. Reviewing AI output is now a core engineering skill, not an optional one.

Delegation, not abdication. Let the agent do the typing. Keep the thinking.

How a self-taught dev gets merged PRs into real open-source projects

Wahib EL KHADIRI — Wed, 05 Aug 2026 07:49:50 +0000

I'm self-taught, 22, and I have merged pull requests in real open-source projects — a quantum-computing library, an AI coding-agent toolkit, security tooling, data stacks. No CS degree, no referral. Just a repeatable process. Here it is, no fluff.

Why bother (if you're job-hunting)

A merged PR is public, verifiable proof you can read a real codebase, follow its conventions, and ship. It beats a wall of tutorial projects on a resume, because a stranger with commit rights already said yes to your code.

The playbook

1. Find a genuinely small, unclaimed issue

Search GitHub for label:"good first issue" state:open in a language you know. Then filter hard:

0 comments and no assignee → nobody's racing you.
The issue names the file and the fix → scope is bounded.

Skip anything vague ("improve testing", "add feature X"). Vague = subjective review = rejection.

# GitHub search that surfaces fresh, unclaimed issues
is:issue is:open label:"good first issue" no:assignee sort:created-desc

2. Check for competing PRs before you start

Fast-moving repos get duplicate PRs. If someone opened one an hour ago, move on — I've lost that race twice and learned.

3. Reproduce, fix, and add a test

Clone, reproduce the bug, make the minimal change, then write a regression test. The test is what turns "trust me" into "here's proof." Run the full suite and note any failures that are pre-existing (verify with git stash).

4. Match the house style

Read CONTRIBUTING.md. Some repos require you to comment "I'll take this" first. Some enforce DCO (git commit -s). Some use Conventional Commits. Follow their rules exactly — reviewers notice.

5. Write the PR like a reviewer is busy

One sentence: what was broken.
The fix, and why this one.
Proof it works (test output).
Disclose AI assistance if you used it — honesty builds trust.

What I stopped doing

Chasing bounties. Most are dead (archived repos) or 200-person races. Terrible expected value.
Padding volume. Two clean PRs to reputable repos beat ten to 3-star toy projects. Quality is the signal.

The mindset

You're not "contributing to open source." You're solving one small, concrete problem for someone, cleanly, with a test. Do that ten times and you have a track record no bootcamp certificate can match.

Start today: find one 0-comment good first issue, and ship the smallest correct fix you can.

A GitHub Actions tag is a promise, not a fact: pinning by SHA the right way

Wahib EL KHADIRI — Sun, 02 Aug 2026 22:58:53 +0000

When you write uses: actions/checkout@v4 in a GitHub Actions workflow, you are not pinning anything. You are trusting a promise.

A tag is a movable pointer. Whoever owns that repository can repoint v4 at a different commit tomorrow, after you reviewed it, and every run of your pipeline will silently pull the new code. In a job that holds a registry login, a PyPI token, or a signing key, that is exactly the place you do not want a mutable reference.

I recently went through a project's workflows and pinned the remaining actions to commit SHAs. Here is what I actually learned doing it — beyond "just use the SHA".

A tag is a promise; a SHA is a fact

Compare these two lines:

# a promise: "v4 will keep meaning what you reviewed"
- uses: docker/login-action@v4

# a fact: this exact tree, forever
- uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4

The second form is content-addressed. dbcb813… can only ever refer to one tree of code. If upstream is compromised and someone force-pushes v4 to a malicious commit, your pinned SHA keeps running the code you actually audited. That is the whole security argument for pinning, and it is a real one — tag-repointing has been used in real supply-chain incidents.

Re-resolve the SHAs yourself

The interesting part is how you get the SHA. It is tempting to copy it from a table someone handed you. Don't. The point of pinning is to pin to code you verified, so resolve each ref yourself against the source of truth:

gh api repos/docker/login-action/commits/v4 --jq .sha

This dereferences the ref to the commit it currently points at. Do it for every action, and you have both verified the value and produced the exact string to paste. When I did this across seven uses: lines, they matched the values I'd been given — but the trust now comes from having checked, not from having copied.

Keep the version comment, or you break Dependabot

Here is the subtlety that turns a security win into a maintenance problem. Once you pin to a SHA, the human readability is gone — nobody knows dbcb813 is v4 at a glance, and neither does your update tooling unless you tell it:

- uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4

Dependabot parses that trailing # v4 comment. Keep it, and Dependabot keeps offering version bumps as PRs — you get the security of a pin and a maintained update path. Drop the comment, and Dependabot goes quiet: your pin quietly rots, and a stale pin nobody notices is its own risk. The comment is not decoration; it is the contract with your update bot.

The one pin you have to think about

Not every ref is a version tag. Some actions publish from a moving branch on purpose:

- uses: pypa/gh-action-pypi-publish@release/v1

release/v1 is a branch the maintainers push fixes to. Pinning it to a SHA is still correct — but now you own the decision of when to move it forward, and this one holds the PyPI publish. That is a real trade: you have removed the silent-update risk, but you have taken on the duty to bump it deliberately when upstream ships a fix. Pin it, keep the # release/v1 comment so Dependabot still nudges you, and write down that you understand the trade. The judgement is the point, not the edit.

The takeaway

Pinning actions by SHA is a one-line-per-uses: change, and the diff looks trivial. The value isn't in the edit — it's in three habits:

Resolve every SHA yourself against the upstream repo.
Keep the # vX comment so Dependabot can still bump it.
Name the moving-branch pins and accept that you now own their updates.

A tag says "trust me." A SHA says "here is exactly what runs." In the job that holds your credentials, prefer the fact.

This came out of a real contribution — pinning the remaining actions across a project's workflows in thingctx#127. If you maintain workflows with credentialed jobs, it's an afternoon's audit worth doing.

AgentOS: a Rust runtime for AI agents with deterministic time-travel replay

Wahib EL KHADIRI — Sun, 26 Jul 2026 18:22:50 +0000

Most agent frameworks help you build a workflow. The harder part starts after that: the workflow has to run as a long-lived process, fail clearly, restart carefully, and be inspectable after the fact.

That's the gap I'm building AgentOS for — an open-source, Rust-first runtime layer that sits underneath frameworks like LangGraph, AutoGen or CrewAI instead of replacing them.

What one process gives you

cargo run -p agentos-cli -- run --agent examples/simple_agent.toml

That single command brings up a supervised agent, a health endpoint, a gRPC message bus, a live SSE event stream, and a recorded trace you can replay later. No API key is needed just to bring the runtime up.

Time-travel debugging

Your agent does something weird on step 7. Reproducing it costs real API calls, and it never behaves the same way twice.

AgentOS journals every LLM exchange and tool result at the provider boundary, so any run can be replayed deterministically — and forked into alternate timelines:

agentOS run --agent my_agent.toml    # every step journaled automatically
agentOS replay --session agent_123   # offline re-run, no API cost, drift-checked
agentOS fork --from ckpt_4 --prompt "try the other path"

The dashboard's Recordings view turns those journals into a scrubbable timeline: step through the prompt, each exchange, tool calls and their results, with per-exchange checkpoints as fork anchors.

What's inside

crates/kernel — lifecycle, agent handles, supervisor
crates/bus — in-memory, gRPC, SSE and WebSocket messaging
crates/trace — recording, replay, diff, checkpoint model
crates/vault — secret isolation, encryption, scopes, audit
crates/memory, crates/registry, crates/llm, crates/cli, crates/sdk
dashboard/ — React debugging surface

Where it honestly stands

Stable enough for local use: the run / ps / logs / trace / replay CLI flows, local state inspection, export and import, and the core crates with workspace checks and tests.

Still experimental: the dashboard, the WASM plugin runtime, Docker Compose packaging, LLM provider integrations, and Python/TypeScript SDK packaging. Stronger restart and recovery guarantees with explicit tests are next. It is an alpha, and I would rather say that than claim production hardening it has not earned yet.

Try it

git clone https://github.com/WAHIB-EL-KHADIRI/AgentOS
cd AgentOS
cargo build --workspace
cargo run -p agentos-cli -- run --agent examples/simple_agent.toml

Repo: https://github.com/WAHIB-EL-KHADIRI/AgentOS

Feedback on the runtime boundaries is what I want most: if you run agents today, what breaks first for you — supervision, observability, or reproducing failures?

I Taught an Open-Source SEO Tool to Check Whether Your Site Is Readable by AI Agents

Wahib EL KHADIRI — Tue, 21 Jul 2026 23:08:35 +0000

Most SEO audit tools still ask the questions search engines cared about ten years ago: is your title tag the right length, do your images have alt text, is your sitemap valid. Those still matter. But a growing chunk of how people find content now goes through an AI assistant instead of a search results page, and almost no audit tool checks whether your site is even reachable by one.

I picked up an open issue on open-seo (an open-source Semrush/Ahrefs alternative) to close that gap, and it turned into a good lesson in scoping a feature for someone else's codebase instead of your own.

The actual question

"Is this site AI-readable?" breaks down into concrete, checkable things:

Does robots.txt block the crawlers that build AI search indexes and answer live user requests?
Does the site have an llms.txt — the emerging convention that gives an AI assistant a clean map of your important pages?
Does the site advertise a Markdown alternate for its pages, so an assistant can read clean content instead of parsing full HTML?

Straightforward to state. The interesting part was not flagging noise.

Lesson 1: not every robots.txt block is a signal

A site with Disallow: / for every crawler made a deliberate, site-wide choice. Reporting "GPTBot is blocked!" on a site that blocks everything isn't useful information — it's noise dressed up as an insight. So the check only flags an AI agent when it's treated worse than the generic rules:

const rootUrl = `${origin}/`;
if ((robots.isAllowed(rootUrl, GENERIC_PROBE_AGENT) ?? true) === false) {
  return []; // whole site is closed — not an AI-specific signal
}

I also grouped agents by why they visit instead of firing one issue per bot. GPTBot and ClaudeBot are training crawlers; blocking them is often an intentional content policy and barely worth a heads-up. ChatGPT-User and Claude-User fetch a page live because an actual human asked an assistant about it right now — blocking those is a much bigger deal, because you're breaking a request in progress, not opting out of a training set. Same signal, completely different severity, so they're separate issue types with separate default severities instead of one generic "AI crawler blocked" bucket.

Lesson 2: absence isn't always an error

llms.txt and Markdown alternates are both new enough that almost nobody has them yet. If the check flagged every single audited site for "missing Markdown alternates," it would train users to ignore the audit tool's warnings entirely — the boy-who-cried-wolf failure mode of any linter. Both checks are info severity with copy that says, explicitly, "this is common, not an error." The one genuinely broken state — a site that serves llms.txt but violates its one hard structural requirement (starts with an H1) — is the only case that gets bumped to warning.

Lesson 3: match the codebase's own constraints, not your own instincts

My first instinct for "does this page have a Markdown alternate" was to persist a new boolean column on the crawled-pages table. Then I actually looked at how the project's crawl pipeline works: full page data lives in a database table, but only a slim summary (title, status code, a few other fields) survives between crawl phases as durable workflow state — link lists and everything else deliberately get dropped to keep memory bounded on 10,000-page crawls.

Adding a persisted column meant a schema migration, which meant touching both the SQLite and Postgres schema paths this project supports side by side — a much bigger, riskier diff for a feature that doesn't actually need to survive past the audit run. So instead the flag rides through the same transient summary object the pipeline already carries between phases, and the finding — not the raw per-page flag — is the only thing that gets persisted, as a single site-level issue row. Same pattern the project already used for the file-based llms.txt check; I just extended it instead of inventing a new one.

Lesson 4: extend the open PR, don't fragment the review

I'd already opened a PR for the robots.txt and llms.txt checks. Before anyone had reviewed it, I built the Markdown-alternates check too — and instead of opening a third PR, I pushed a second commit onto the same branch. The maintainer hasn't looked at any of it yet, so there was no in-flight review to disrupt, and one PR that closes three-quarters of the original issue is easier to review than three PRs that each close a quarter of it and reference each other.

Result

19 unit tests, no schema changes, no new external API calls beyond one extra fetch for llms.txt. The PR's open here if you want to see the actual diff: every-app/open-seo#122.

every-app / open-seo

Open source alternative to Semrush and Ahrefs

OpenSEO

Open source alternative to Semrush and Ahrefs

OpenSEO is an SEO tool for the people. If tools like Semrush or Ahrefs are too expensive or bloated, OpenSEO is a pay-as-you-go alternative that you actually control.

All-in-one SEO tool for you and your AI agent.

Connect with any agent like Claude Code, OpenClaw or Hermes. We have pre-built skills, but you can build your own to tailor OpenSEO to your needs.

Hosted Version

Try OpenSEO for free on our website. If you want to support the project, a hosted subscription is $10/month.

openseo.so

Why use OpenSEO?

Best in class MCP and AI Skills.
Modern, simple UI.
- Focused workflows instead of a bloated, complex SEO suite.
No subscriptions.
- Bring your own DataForSEO API key and pay only for what you use.
Fork and vibe code your own custom tool.

Main SEO Workflows

Keyword research
Rank tracking
Competitor Insights
Backlinks
Site…

View on GitHub

The code itself was the easy part. The actual work was reading how someone else already solved similar problems in their codebase before writing a single line — the "how do I avoid noise" and "how do I fit this project's existing shape" questions mattered more than the crawler-detection logic itself.

I Shipped My First Rust Release, and CI Turned Red Twice in 20 Minutes

Wahib EL KHADIRI — Tue, 21 Jul 2026 22:43:39 +0000

I shipped the first public release of my Rust project last night. Within about twenty minutes, CI turned red twice. Here's what broke, how I found it, and the two calls I made under a bit of time pressure.

The project

AgentOS is a runtime layer for AI agents — the infrastructure around an agent, not the agent logic itself: supervised lifecycle, a gRPC message bus, a health endpoint, an SSE event stream, a secrets vault, and deterministic time-travel replay (every LLM/tool exchange gets journaled, so a run can be replayed offline with no API cost, and forked into alternate timelines from any checkpoint).

It's a 10-crate Rust workspace, MIT/Apache-2.0. I'd been building it privately for a while. Last night I flipped the repo to public and tagged the first alpha release. That's when things got interesting.

Failure #1: a clippy lint that didn't exist last month

The repo had been private, so CI hadn't run against a fresh clippy in a while. The moment I pushed a commit after going public, this showed up:

error: you seem to want to iterate on a map's values
   --> crates/bus/src/grpc.rs:631:37
    |
631 |         for (_agent_id, senders) in subs.iter() {
    |                                     ^^^^^^^^^^^
    |
    = help: use the corresponding method
631 -         for (_agent_id, senders) in subs.iter() {
631 +         for senders in subs.values() {

clippy::for_kv_map, denied by -D warnings in CI. Fair catch — the code was iterating a HashMap and discarding the key on every iteration, which is exactly what .values() is for. One-line fix:

// before
for (_agent_id, senders) in subs.iter() {

// after
for senders in subs.values() {

Pushed, CI green again. This one was boring, which is the best kind of bug to have.

Failure #2: the release matrix, at 12:33am

The bigger one showed up when I tagged v0.1.0-alpha. The release workflow builds five targets in parallel — Linux x64, Linux arm64, macOS Intel, macOS Apple Silicon, Windows — and packages each into a binary release with checksums.

Four went green. Linux arm64 died with:

error: failed to run custom build command for `openssl-sys v0.9.116`
...
Could not find directory of OpenSSL installation
$HOST = x86_64-unknown-linux-gnu
$TARGET = aarch64-unknown-linux-gnu

openssl-sys needs a real OpenSSL installation (headers + libs) for the target architecture to link against, and cross-compiling from an x86_64 GitHub Actions runner to arm64 doesn't have that available without extra setup. Not a code bug — a missing piece of cross-compilation infrastructure.

I had three honest options at that point:

Block the whole release until arm64 cross-compiling was solved properly
Vendor OpenSSL and wire up a cross-linker for the arm64 target under time pressure, late at night, for a release I hadn't tested that way before
Ship the four targets that work, drop arm64 from this release, and track the real fix as its own issue

I went with option 3. Four platforms is still a real alpha release that covers the overwhelming majority of contributors trying it out. Blocking on a cross-compilation edge case for a Linux architecture almost nobody in the alpha audience runs felt like optimizing for the wrong thing at midnight. And silently vendoring a rushed fix into a security-relevant dependency (TLS) is exactly the kind of shortcut that comes back to bite you.

So: pulled the target from the matrix, re-tagged, watched the four remaining builds go green, and filed the real fix as its own issue with three candidate approaches laid out (the best one is probably migrating off openssl-sys to rustls entirely, which would remove the system OpenSSL dependency for every target, not just arm64 — cross-compilation problems like this are usually a sign the dependency choice needs revisiting, not just the CI config).

The one check I'm glad I ran before either of this

Before any of the above, I'd actually run the README's own quickstart end to end — cargo build --workspace, then run the example agent — specifically to catch the gap between "the README claims this works" and "this actually works." It did, and the real terminal output (supervisor spawning the agent, health server on :8080, gRPC bus on :50051, an SSE stream on :8081) is now in the README instead of a hypothetical example. I also downloaded the actual released Windows binary afterward and ran agentOS.exe --version against it — small thing, but it's the difference between "the release workflow exited 0" and "a stranger who downloads this file gets a working program."

Neither bug was catastrophic. Both were the kind of thing that's mildly stressful in the moment and completely mundane in hindsight — which is most of what real engineering work actually looks like, release-day war stories included.

If you want to poke at it, the repo's here: github.com/WAHIB-EL-KHADIRI/AgentOS. There are a handful of labeled good first issues if anyone wants to dig into a self-contained piece of it — I'm around to answer questions on any of them.

WAHIB-EL-KHADIRI / AgentOS

Runtime infrastructure for AI agents — lifecycle, supervision, secrets, and deterministic time-travel replay. Built in Rust.

AgentOS - Runtime Infrastructure for AI Agents

AgentOS is an open-source runtime layer for AI agents. It focuses on the infrastructure around agents: lifecycle, supervision, messaging, state, secrets observability, and trace replay.

Created by WAHIB EL KHADIRI — founder and architect.

Most agent frameworks help you build an agent workflow. AgentOS focuses on what happens after that workflow needs to run as a long-lived process, fail clearly restart carefully, and be inspected after the fact.

See it run

Real output from a fresh clone — no API key required to bring the runtime up:

$ cargo run -p agentos-cli -- run --agent examples/simple_agent.toml
INFO agentos_kernel::supervisor: agent spawned and running agent_id=agent_simple_agent state=Running name=simple-agent
INFO agentos_kernel::agent: agent loop started agent_id=agent_simple_agent
INFO agentos_kernel::events: system event emitted event=agent.spawned seq=0
INFO agentOS::run: AgentOS runtime started agent_id=agent_simple_agent host=127.0.0.1 http_port=8080 grpc_port=50051 sse_port=8081
INFO agentos_kernel::health: health server listening on 127.0.0.1:8080
INFO agentos_bus::grpc: gRPC bus server listening on 127.0.0.1:50051

…

View on GitHub