Ask before building
The stated requirement is rarely the real one. I spend the first stretch with the operators — watching the workaround, the spreadsheet, the thing everyone stopped mentioning because it's just how it's done.
Mohammed J. Amer II
Forward Deployed Engineer · Technical Lead & Architect · Applied AI
New Jersey · NYC metro · open to hybrid · mjamer.com · linkedin.com/in/mohammedjamilamer · github.com/mjamilamer
I embed with enterprise customers, sit with the people actually doing the work, find what's really failing, then ship the system that fixes it — and stay the person they call once it's live.
The stated requirement is rarely the real one. I spend the first stretch with the operators — watching the workaround, the spreadsheet, the thing everyone stopped mentioning because it's just how it's done.
When a stakeholder wants everything at once, I'll say so. I'd rather ship something small that gets used on Monday than something complete that sits unopened for a quarter.
Architecture, code, release — then production support, the edge case nobody predicted, and the question three months later. Being the one who knows the system end to end is what makes the next build faster.
A large fiber-infrastructure customer needed to catch double-claimed footage in engineering design data. Each design line claims a stretch of a construction route — feet 100 to 250, say. When two lines claim the same stretch, that footage gets counted twice, and every cost and quantity rollup downstream is wrong. The check existed only as a Power BI process that had stopped completing, so it fell back to people reconciling by hand, four to eight hours at a time, every import.
Failing report. Manual reconciliation. No reliable path to a clean dataset.
Native pipeline, validated in minutes, running inside platform limits on every import.
I rebuilt it as a native pipeline: indexed lookups instead of full-table scans, and a chunker that reads the remaining query budget and sizes itself to fit inside it. When a stretch of route comes back dense enough to threaten the row cap, it halves its own chunk width and picks up from the last row it saw. A separate guard watches heap against a soft ceiling set below the platform's hard limit. When that trips, the affected chunk fails with a message telling the operator what to narrow — instead of taking the whole job down at the hard limit.
Four batch phases folded into one configurable job, and tuning moved into metadata, so admins change thresholds and modes without a deployment.
An entire contractor payment operation lived in Excel — engineering drawings, GIS data, and field work logs, cross-checked by hand before anyone could be paid. Roughly two terabytes of it. Every error was a payment error, and every audit was an archaeology project.
Hand reconciliation across three data sources. Errors surfaced downstream, in billing.
Completed work validated against engineered specs, posted to the ERP with a full audit trail.
I architected the platform that replaced it and led the two-engineer core build: ingest the engineering records alongside contractor-submitted logs, validate the work actually done against what was specified, and post reconciled records straight through to finance. The audit trail stopped being something reconstructed after the fact.
Across the engineering org, AI assistance had gone from novelty to daily habit without anyone agreeing on how. Output quality tracked whoever happened to write the prompt. The gap wasn't enthusiasm — it was that the models had no reliable access to how we actually build.
Ad-hoc prompting. Inconsistent output. Conventions living in people's heads.
Shared MCP server and agent rule set — codebase conventions available to the tools themselves.
I built an internal Model Context Protocol server and an agent rule set encoding our conventions. Turning that into something the whole org actually used was a team effort — engineers across teams stress-tested the rules, pushed back on what didn't hold up in real work, and shaped what the tooling should enforce. The interesting part was never the wiring. It was the collective judgment about what models should not be trusted with, and where a human review gate genuinely earns its cost.
Sole technical architect and primary engineering point of contact for two enterprise fiber-infrastructure implementations — discovery through production support. Cross-team escalation point; sets technical direction and mentors through design and code review.
Sole technical architect and primary engineering point of contact for two enterprise fiber-infrastructure implementations, owning delivery from discovery through production support. The validation domain I own runs about 12,000 lines of production Apex, carried by roughly 11,500 lines of tests. Cross-team subject-matter expert and escalation point: running standups, mentoring engineers through design and code review, and setting technical direction on major projects.
Led QA automation for a life-insurance technology platform — designing the end-to-end and browser-automation framework across web UI, REST APIs, and backend services, with behavior-driven specs both engineers and product could read.
Designed and built end to end: a Python / FastAPI backend runs Monte Carlo simulations to produce probabilistic return ranges rather than single-point forecasts, enforces a 25% position-concentration limit, and benchmarks every strategy against a market index. Results persist in SQLite and surface through a React / Recharts dashboard.
Graduate AI research at Northeastern (CS5100), co-authored. A multi-layer LSTM in TensorFlow / Keras forecasts ten years of daily Apple closing prices. I built the LSTM; my co-author led the ARIMA side.
The paper reports RMSE under 1 for the LSTM and about 7 for ARIMA. Those two numbers aren't directly comparable, and I'd rather say so first: the LSTM error is on MinMax-normalized data, the ARIMA error is in dollars. The paper also notes the ARIMA series was likely over-differenced, which makes it a weak baseline. The model worked. The comparison needed a shared scale.
Mohammed J. Amer II · New Jersey · NYC metro · mjamer.com · linkedin.com/in/mohammedjamilamer · github.com/mjamilamer