WINSKEL / THE PEOPLE
We started Winskel because working with more AI coding systems was making development more fragmented, not less. We're building one place that can understand the work, decide when different models should work alone or together, and show the developer what actually happened.
Ahmed started building Winskel after constantly moving between AI coding systems while making his own software. He works across the product, its orchestration system, and the company, and spends a lot of time using Winskel himself and talking with developers about their work.
Mohammed works across Winskel and stays especially close to the people using it. He spends time onboarding developers, running demos, seeing what works and what does not, and turning those lessons into changes across the company.
Rakan works across Winskel and spends a lot of time in the developer communities where we expect the product to grow. He works with early users, university clubs, hackathons, events, and other builders, bringing what he learns back into how we build and distribute Winskel.
02 / WORKING NOTE / 001
Take one coding objective: add an onboarding checklist. A stores progress, B builds its card, and C connects both in setup. A and B are independent; C depends on both. The diagrams compare schedules for that same dependency graph.
A, then B, then C. The owner keeps all context, but B starts after A even though it does not need A’s output.
Tserial = dA + dB + dC
A and B start together. C starts after the slower branch finishes. Planning, handoff, and integration add overhead h.
Tparallel = max(dA, dB) + dC + h
Let dA, dB, and dC be the elapsed durations of the three parts. Let h be extra planning, handoff, and integration time. With these simplifying assumptions, the parallel schedule wins only if:
h < min(dA, dB)
The saved time is the shorter independent branch. If overhead reaches that duration, splitting stops helping. A task with no independent branch has no such saving.
Schematic linear model · axes are symbolic, not measured results.
Part durations · Coordination overhead · Successful checks and review findings
See the workflowFIELD NOTES / HOW WE WORK
We build close to the work. A routing decision that looks elegant on paper still has to survive a real repository, an interrupted session, a failed check, and a developer who needs to understand what happened.
We move quickly, then verify. We talk to users, inspect what the product actually did, and revise our assumptions. We use AI throughout the work, while staying skeptical of confident output without evidence.
We want the team to have room for technical curiosity and ownership. The details matter: the handoff a developer can follow, the error that tells the truth, the workflow that stays simple when simple works.
PRINCIPLES / WORKING RULES
We care about the result, not which provider produced it. Model choice is a decision to test, not a team to join.
A system saying it succeeded is not proof. Make routes, changes, checks, and remaining uncertainty inspectable.
One model should own the work when that is enough. Split only when the objective actually benefits.
Different models and tools can bring different strengths. Coordinate them around one objective, with clear handoffs and dependencies.
Study outcomes, repairs, review findings, and user feedback. Change routing deliberately when the evidence warrants it.
A human question or approval can be the right step. Make it clear when the system needs one.
A useful system should be understandable, dependable, and precise in the small details people meet every day.
The question behind all of this is bigger than coding.
Read the manifesto