Skip to content
View achirothmane's full-sized avatar
🤗
🤗

Block or report achirothmane

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Content in all repositories owned by your account will be closed.
Maximum 250 characters. Please don’t include any personal information such as legal names or email addresses. Markdown is supported. This note will only be visible to you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
achirothmane/README.md

◈ Build trajectory

Software Engineering
        │
        ▼
Backend · APIs · Data · Reliability
        │
        ▼
AI-Native Systems · Agents · Automation
        │
        ▼
Product Engineering
        │
        ▼
Useful Digital Products
        │
        ▼
Measure → Learn → Improve → Ship again

I use GitHub as a working engineering portfolio: real systems, real experiments, real failures, and progressively stronger products.

Portfolio system map: SYSTEM-MAP.md — canonical map of projects, shared capabilities, real dependencies, gates, and the future operating surface for long-running agents/Dots.

My direction is deliberately broader than one niche:

software engineering + AI-native systems + developer tools + technical product building


◈ Current learning stack

⚙️ Software Engineering

Python Go Rust TypeScript SQL

APIs · PostgreSQL · Testing · Git · CI/CD · Backend architecture

Goal: build maintainable systems with clear contracts and production-oriented behavior.

✦ AI-Native Systems

LLM APIs Tool Calling Agents

RAG · evaluation · observability · agentic workflows · automation

Goal: treat AI as part of a real software system, not as an isolated prompt.

◉ Product Engineering

UX Onboarding Measurement

Distribution · retention · pricing · packaging · product economics

Goal: turn engineering capability into products people can understand and use.

◇ Formal methods & systems reasoning

TLA+ · state machines · invariants · concurrency · failure modeling

I use formal methods as an engineering discipline for understanding complex systems, especially distributed state, concurrency, and failure behavior — not as the identity of the portfolio.


◈ Selected builds

CI / Developer Tools

Experiments around failure analysis, retry behavior, CI reliability, and practical engineering automation.

CI → diagnose → decide → improve

Databases / Reliability

Measures regressions around PostgreSQL changes and tests stronger ways to explain what actually changed.

change → observe → compare → isolate

Product / Analytics

Explores whether reported conversion reflects the real customer journey and whether measurement can support product decisions.

journey → signal → verify → decision

AI + Software Engineering

Uses AI in code modernization while keeping testing and engineering verification inside the implementation loop.

legacy → analyze → change → verify

Cloud / Reliability

Detects failures in authentication-email delivery flows.

auth event → delivery path → signal

AI / Deployment

Experiments around shipping and operating AI-enabled software.

AI capability → deploy → operate → learn


◈ Technical constellation




◈ Live GitHub signal



◈ Working philosophy

Build real things. Learn from the implementation. Measure what happens. Improve the product. Ship again.

I prefer projects that force useful learning: APIs that must work, workflows that must survive failure, databases that must preserve state, AI features that must operate inside software, and products that must produce understandable outcomes.

BUILD → TEST → MEASURE → LEARN → IMPROVE → SHIP

Independent software and product work, documented through real repositories.

Pinned Loading

  1. workflow-failure-lab workflow-failure-lab Public

    GitHub Actions retry safety + flaky test intelligence: safe reruns, JUnit evidence, quarantine lifecycle, CODEOWNERS routing, and deduplicated issue tracking.

    Python 3