Zaid Hijazi
Switch language: عربي
Contact
AI Engineering

AI is an engineering problem. Not a demo.

I treat AI as an engineering problem: measure it, control its cost, and design for when it’s wrong.

  • Measure it

    Every AI feature ships with a test set and a number that says how good it is.

  • Control its cost

    Cost and speed per run are budgeted before launch, not discovered after.

  • Design for when it’s wrong

    Low confidence, silence or bad input lead to a safe, clear next step.

AI projects

Two systems, one approach

CV Scoring Engine

A public tool that scores a CV out of 100, the way hiring systems read it. I audited how it scored, fixed the rules that took points unfairly, and made every score explainable — a flawless CV can now reach 100.

A score is only useful if you can explain it.

Score on the same sample CV

Before and after the fixes · score out of 100

  • Sample CV score +5 points
    Before: 85
    After: 90

How it’s built

Approach
Clear, weighted rules decide the score — no model in the scoring step. I fixed four problems: checks that don’t apply to a CV no longer cost points, the target role is read from the CV itself, Word and text files are read correctly, and the same issue is never counted twice.
Evaluation
I started with a written audit of how the scorer worked, then checked every fix against the same sample CV. Because the rules are fixed, the same CV always gets the same score.
Cost & speed
No model is called to compute the score, so each scan costs almost nothing and the result comes back right away.
When it fails
Every check shows its result and the reason behind it, so the candidate knows exactly what to fix. If a Word or text file is hard to read, the scanner recovers the text instead of failing.
Arabic support
The tool works in Arabic and English. Reading Arabic PDF CVs is the next step.

Spec-driven engineering with AI agents

How I build software with AI coding agents. I write the spec first: the data model, the business rules and how each feature is accepted. The agent writes code against that spec, tests check it, and I review every change before it ships. This is how I built a multi-tenant ERP with 18 modules on my own, alongside my other production work.

The agent writes the code. I own the design, the rules and the decision to ship.

  1. Spec Written contract
  2. Agent Writes the code
  3. Tests Check the spec
  4. Review Human approves

When the spec is unclear, the agent stops and asks a human instead of guessing.

How it’s built

Approach
Before any code, I write a spec in Markdown: the data model, the business rules, the screens and the acceptance checks for each feature. Each project also has its own agent skills — written rules for its stack, naming, folder layout and bilingual text. The agent works in small tasks, one feature at a time. Small tasks are easier to check, and easier to undo.
Evaluation
A change is done only when three checks pass: the acceptance checks in the spec, the automated tests, and my own review of the code. I read every change before it is merged. If I cannot explain a line, it does not ship.
Cost & speed
Speed comes from dividing the work, not from skipping review. The agent handles the repeated work — screens, forms, migrations, translations — while I focus on design, business rules and edge cases. That split is what lets one engineer build and run a full multi-tenant ERP.
When it fails
When the spec is unclear, the agent stops and asks instead of guessing. When a change fails a check, it goes back with the failing test, not a vague note. Risky areas — money, permissions, tax invoicing and personal data — always get a full line-by-line review.
Arabic support
Every spec is written for both languages from the start. Interface text, right-to-left layout, and Arabic numbers and dates are part of the acceptance checks — not something fixed at the end.

Need AI that’s measured before it ships?

Tell me the decision it should make. I’ll tell you how we’ll know it works.

Talk about your AI feature