The everyday tools. Typed where it matters, plain where typing would only be ceremony.
- TypeScript
- JavaScript
- Python
- SQL
- Liquid
- HTML5
- CSS3
I am an AI engineer and full stack developer in Cairo. Four years of Next.js, TypeScript, Supabase and Shopify, plus the multi model pipelines that keep four to five client projects moving every month without the quality slipping.
I started in the front end, moved through full stack, and now spend most of my time on the layer above both: how work gets routed, reviewed and shipped when a large part of the typing is done by a model.
The practical version of that is unglamorous. Every project runs across development, staging and production. Stakeholders sign off on staging, not in a meeting. Releases are monitored and the rollback path has actually been tested, because a rollback you have never run is a hope, not a plan.
The interesting version is that a knowledge graph of the codebase lets an agent ask a question instead of reading forty files to find the answer. That one change is most of the reason four or five client projects can run in the same month without the review queue collapsing.
The everyday tools. Typed where it matters, plain where typing would only be ceremony.
Interfaces that stay fast on a mid range phone on a bad connection, because that is where most people actually are.
Postgres with row level security doing the access control, so the rules live next to the data instead of scattered through the app.
Sessions, roles and money. The three places where a shortcut costs the most later.
Routing work across models by complexity and cost, with knowledge graphs so agents query structure instead of re-reading source.
Development, staging and production on every project, with stakeholder sign off on staging and a rollback path that has been tested.
Model choice is a cost and quality decision made per task, not a default set once and forgotten. Cheap models do the cheap work. Expensive ones are saved for the problems that actually need them.
Requirements come out of a call with the stakeholder, not a ticket. Business goal in, technical spec out.
Work is routed by complexity and cost. Light models review and make small edits, frontier models pair as advisor and worker on standard builds, and a solo frontier model takes the hard logic.
The codebase is indexed into a knowledge graph so agents query structure instead of re-reading files. On large repositories that cuts repeated context cost by roughly 70 percent.
Live library docs through MCP keep APIs real rather than hallucinated, and a per project DESIGN.md keeps generated interfaces consistent across sessions and contributors.
Automated code review and security passes gate every release. This is what holds defect rates down while four to five projects run at once.
Preview deploy, sign off on staging, then a monitored production release with a rollback path that has actually been tested.
Most repositories are private because the work is client owned. Code walkthroughs and architecture notes are available on request.
The short version. Open a role for the detail, or take the CV and read it somewhere more comfortable.
Tell me what you are building and where it is stuck. If it is a good fit I will say so quickly, and if it is not I will usually know someone who suits it better.