Amin Mallol

How I work

Four decisions, not four adjectives

Every one of these comes with the incident that taught it. If you want to probe one in an interview, the code is still there and I can walk you through it.

1. 01

   Fail closed, unless closing fails worse

   A default is a security decision. Picking one means knowing which way the failure hurts, and writing that down next to the code so the next person does not quietly reverse it.

   Evidence

   The investor portal returns 404 for any host not in its tenant map, after a fallback let a misconfigured alias impersonate a real fund and receive its cookies. The admin app in the same product deliberately does not, because its default host is the public marketing site.

   Cynad→
2. 02

   Put the invariant where it cannot be bypassed

   If a rule matters, it does not belong in the layer that is easiest to write it in. It belongs in the lowest layer that can still enforce it, because that is the only version of the rule that survives a refactor, a second client, or a script someone runs at midnight.

   Evidence

   devSpec's specification gate is a Postgres trigger, so no API route can route around it. Cynad's publish-once prices are enforced in the model and re-checked cross-row in the bulk import path, because the valuation code depends on the invariant rather than re-deriving it.

   devSpec · Cynad→
3. 03

   Know the bug class, not just the bug

   Fixing the reported case is half the work. The question worth asking is what category it belongs to, because that is what tells you where else the same mistake is already sitting.

   Evidence

   Rate limiting keyed on the request path meant two spellings of the same route disabled every throttle in the file, not just one. The fix resolves through the router and matches on the action. The related shape, found by asking what else leaks through an alternate path, was a password oracle in two-factor sign-in.

   Cynad→
4. 04

   Let the machine type; keep the deciding

   Generated code is cheap and confidently wrong output is cheaper still, so the leverage is not in producing more of it. It is in specifying precisely what is wanted beforehand, and in putting the rules somewhere nothing can route around afterwards.

   Evidence

   Work is specified in versioned work orders that name the API contract and what is out of scope before anything is written. devSpec enforces the same idea as a product: its gate is a Postgres trigger, so no client, no stray API call and no agent can get past an unanswered question.

   devSpec→
5. 05

   Constraints are a design input

   A 512MB budget or a 30-second request cap is not an obstacle to route around; it is information about which designs are available. Taking it seriously early is cheaper than discovering it in production.

   Evidence

   FlexiForm's job system runs as threads in one process rather than four forked ones, Selenium is lazily loaded because it costs 11MB resident, and spreadsheet exports are streamed to disk instead of buffered, where the buffer would cost three times the file size inside a web thread.

   FlexiForm→

AI-augmented engineering

Where the speed comes from

• 2,391

  lines of versioned work orders

  Specification before code

  Work is specified before any of it is written. Versioned, dated work orders that supersede each other when a constraint changes, each naming the repository, the stack, the exact API contract and what is explicitly out of scope. One of them hands work across two repositories with a role-by-action permission matrix, so the implementer never has to infer who is allowed to do what. This is the same discipline I productised in devSpec, where the gate sits in a Postgres trigger precisely so that no client, no stray call and no agent can route around it.

• 4 of 27

  claims killed before publication

  Controls against confabulation

  Research that will be published gets a control. Every extraction request carries one fabricated statistic alongside the real ones, so a model that is willing to invent a number has to reveal it. On the last set, every planted control was correctly rejected, 23 claims were confirmed verbatim against their primary source, and 4 were corrected or killed outright. Without the controls, those 4 would have shipped.

• 86 files

  judged per run, framework v2.6

  Measurement, not impressions

  I built a versioned code-health framework that scores a codebase on evidence rather than on how it feels to read. It fuses an LLM judge, at a pinned model and effort level, with real static analysis: cyclomatic and cognitive complexity, duplication detection, coverage, dependency audit and secret scanning. Scores are weighted (security 0.30, quality 0.25, coverage 0.20, robustness 0.15, efficiency 0.10), windowed over 90 days of churn, carried forward between runs and pinned to a commit, so two runs are comparable. It also runs in a due-diligence mode I have used to assess software before an acquisition.

None of this is a substitute for knowing the stack. It is how I avoid spending a senior engineer's day on work that does not need one.

Tech stack

What I have actually used, and where

No logo wall and no skill bars. Each entry says how long and on which product, because that is the only version of this list you can interview against.