Mustafa Tawfiq

Forward Deployed Engineer · Cairo, Egypt (UTC+2) · remote

I sit with the client, find the real problem, and ship the AI system that solves it.

This page was built in Fredrin. One ticket per section, each in its own worktree, reviewed and merged on the board.

About me

I am an AI Solutions Architect at an AI solutions company in Dubai, fully remote since October 2025. Every AI project there starts with me: I meet the client, design the solution, build the core parts, and plan and review the work of our AI engineers.

What I do best is solve problems I have not seen before. I break the problem down, learn what I need fast, and find a clear path. I studied computer engineering at Cairo University, and I have delivered for clients in 10 different industries, from telecom and banking to healthcare and legal.

What I have shipped

How I work with coding agents

I direct AI coding agents every day, Claude Code and Codex, like an engineering team. I plan the work, split it into small tasks, and write the context the agents need: what the project is, the rules, how to test. Then I review every change before it ships.

I run many projects in parallel. On a normal day I have 10 to 30 agent sessions open at once. Each project has one orchestrator session that plans the work and checks it, and worker sessions that each own one part. I built this setup myself, with my own reusable skills and review checklists. It is how I ship fast without dropping quality: nothing merges without a review.

When an agent gets something wrong, I first ask what it did not know. Most of the time the fix is better context, not a better prompt.

How I would land Fredrin at a customer

Week 1: first merged ticket.

  1. Install the app with their team, connect GitHub, and pick 3 small real tickets from their backlog.
  2. Write their Project Context from what is already there: the README, the CI config, the code conventions, how they test.
  3. Run the 3 tickets, watch where the Workers guess, fix the context, and run again. The goal is one merged ticket in the first week.

Weeks 2 to 4: make it stick.

  1. Wire CI status back to the board, so the team trusts what an agent ships.
  2. Set up remote machines and automations for the work they repeat.
  3. Move the team from me running tickets to them running tickets.

All the time: feed it back.

  1. Every point of friction becomes a product ticket. If I can fix it in Fredrin, I ship the fix myself, so the next customer does not hit it.

What I noticed building this page

What worked well. The six section tickets ran at the same time, each in its own worktree, and all six were ready for review in about two minutes. They merged with no conflicts. The merge check before each merge made every review fast.

What slowed me down. One Worker started a slow screenshot check, ended its run while it waited, and the ticket went to Blocked. I did not patch the code. I added one line to the project context: Workers run their checks and finish, and the reviewer checks the look. The next run finished in under a minute.

What I would change in Fredrin.

  1. "Reset build" also deletes the ticket's chat history. I wanted to run a ticket again and keep the record of what went wrong.
  2. Marking a check as "human" took three tries. The board's message said to name the check and the reason, but it only worked once the plan line also had the check's ID. One clear example in that message would save the tries.
  3. One Worker finished before it closed its build step. The work was done and checked, but the ticket shows "Step failed".

Contact

mustafa_tawfiq@outlook.com · linkedin.com/in/mustafatawfiq · github.com/mustafatawfiq