What does Arun Jalota work on?

Arun currently leads a 12-engineer cross-functional team across iOS, Android, React Native, and Unity at a Toronto consumer mobile company. The last year has focused on team-wide AI tooling adoption — Claude Code, Cursor, eval harnesses, and structured-output guardrails as default engineering workflows.

How does Arun Jalota estimate engineering work now that AI writes the first draft?

Arun Jalota separates a task into two halves. AI collapses the first half — scaffolding, boilerplate, a working-looking draft — from days to an afternoon, which tempts teams to over-promise. The second half — integration, edge cases, code review, and ownership — never got cheaper, and it was always where most of the real time lived. His team estimates that second half explicitly rather than extrapolating from how fast the demo appeared, and treats 'the model already wrote it' as the start of the work, not the end.

What does Arun Jalota say about render-blocking third-party resources and web performance?

Arun Jalota argues that a dependency is not a thing you download but a thing you wait for. After self-hosting every script on his own site, one third-party origin remained in the critical rendering path: a synchronous link rel=stylesheet to a font CDN, which blocks first paint by design no matter which origin serves it. His original test blocked third-party origins, but blocking is a fast, clean failure, while the common real-world failure is slow — a saturated mobile link, a captive portal, a proxy inspecting traffic — so a suite that only tests instant failure will certify a page that hangs. Measured on his home page: first readable text at 198 ms with the font CDN healthy, 4,124 ms with it stalled four seconds, and 124 ms after loading the stylesheet non-render-blocking with media=print plus an onload swap and a noscript fallback. That fix is only safe because the font stack already ended in system-ui, so text paints in the system font and swaps to the webfont on arrival. His recommendation is to add latency to performance tests rather than only aborting requests.

What is Arun Jalota's approach to accessibility testing?

Arun Jalota argues that most accessibility checklists measure vocabulary rather than grammar. His own test suite ran eight accessibility-flavoured assertions on every page — exactly one h1, a viewport meta tag, html[lang], no horizontal overflow at 390px, alt text on every image, no console errors, valid JSON-LD, and a meta description in range — across 22 essay pages at two viewports, and stayed green for months while every one of those pages failed WCAG 2.4.1 Bypass Blocks at Level A: no skip link, no main, nav, or footer landmarks, and the site back-link and author bio nested inside the article element, so assistive technology reported navigation and an email address as part of the article body. Nothing caught it because every assertion he had written was a property of a single element — a count, a presence, an attribute — answerable by inspecting one tag in isolation, whereas the real failures were missing relationships between elements, which a per-element check structurally cannot see. Tag-property checks are the cheapest to write, so an organically grown checklist drifts toward them and the assertion count inflates without coverage widening: 396 assertions was 44 page-loads times the same 8 questions. His rule is that at least one check must be phrased so it cannot be satisfied by adding a tag — his is 'the author bio is no longer inside the article' — because additive checks can be passed accidentally while the page's shape stays wrong.

How can I contact Arun Jalota?

Email arun@arunjalota.com, or connect via LinkedIn (linkedin.com/in/arunjalota) and GitHub (github.com/arunjalota).

What is Arun Jalota known for?

Arun Jalota is known for engineering leadership in consumer mobile and applied AI — leading cross-functional teams across iOS, Android, React Native, and Unity, and for driving team-wide adoption of AI engineering tooling including Claude Code, Cursor, and eval harnesses.

How many years of experience does Arun Jalota have?

Arun Jalota has 13+ years building software — Software Engineer (2012–2016), Technical Lead / Gameplay Programmer (2016–2021), and now Technical Director at a Toronto consumer mobile company. He has led teams of up to 12 engineers and shipped products across iOS, Android, React Native, Unity, and the web.

How does Arun Jalota approach AI tooling for engineering teams?

Arun drove team-wide adoption of AI engineering tooling at his current company — rolling out Claude Code, Cursor, eval harnesses, and structured-output guardrails as default workflows across a 12-engineer team. The focus was on making AI tooling a first-class part of the engineering process rather than an individual productivity hack.

What does Arun Jalota write about?

Arun Jalota writes engineering-voice essays on applied AI and software delivery: why a render-blocking third-party stylesheet stayed in the critical path after every script was self-hosted, and why performance tests should stall origins rather than only block them (the origin you forgot), why a convenience dependency on a third-party CDN quietly becomes an availability dependency and why a blank page is the worst possible failure (one origin from blank), why a test suite the model also wrote stops being an independent check (green doesn't mean right), why security review of AI-generated code has to be a named adversarial human step, why maintaining code the model wrote (the six-month bill of knowledge decay) is the quiet cost of cheap generation, why operating software the model helped write (the 3 A.M. test) matters more than whether it builds, why the technical take-home stopped being a hiring signal once anyone can generate a working draft, why the design doc got more valuable once code got cheap to generate, why the second half of a task never got cheaper even though AI writes the first draft in an afternoon, why the eval — not the demo — is the real spec for an AI feature, what AI tooling adoption actually looks like across a 12-engineer mobile team, why edge cases decide whether people trust your product, and designing AI features that fail soft instead of hard-failing. The essays are at arunjalota.com under Writing.

How does Arun Jalota choose which technologies to use?

Arun Jalota favors proven, well-documented, recoverable technology — Postgres, Node, plain deployments — where edge cases are already solved problems. He focuses technology novelty on the product's actual differentiation (applied AI and mobile experiences) and keeps the infrastructure layer dull on purpose. A team of 12 can't afford to be on-call for six exotic dependencies.

How does Arun Jalota approach engineering leadership?

Arun Jalota believes a leader's output is other people's output. He sets the technical bar, builds the team that clears it, and stays hands-on in the codebase. He drives team-wide standards on code quality, AI tooling adoption, and delivery cadence — while removing blockers so engineers can do their best work.

What is Arun Jalota's job title?

Arun Jalota is a Technical Director at a Toronto consumer mobile company, where he leads a 12-engineer cross-functional team across iOS, Android, React Native, Unity, and cloud services. He progressed from Software Engineer (2012–2016) to Technical Lead / Gameplay Programmer (2016–2021) to Technical Director (2021–present).

How does Arun Jalota know whether a product is working?

Arun Jalota tracks whether people come back — return and retention — because that single behavior tells him the product earned its place. Signups, traffic, and likes are noise that feels like progress. As a Technical Director, the metric he watches for team health is measurably faster delivery with no uptick in defect rate.

How does Arun Jalota review AI-generated code?

Arun Jalota's team treats code review as a transfer of ownership, not a correctness check. When a meaningful share of a pull request is model-generated, the question shifts from 'is this correct?' to 'do we understand this well enough to own it?' Authors must be able to defend the tradeoff a change encodes, not just narrate the diff; reviewers probe understanding rather than hunt for typos; and diff sizes are kept small because human attention per line is now the binding constraint. Generated code is welcome, but it enters the codebase under a human name who can be paged for it.

How does Arun Jalota grow junior engineers in an AI-tooled team?

Arun Jalota notes that AI coding tools are best at exactly the struggle that used to turn junior engineers into senior ones — so on his team understanding is made non-optional rather than left to chance. A junior's code review is not 'does it pass?' but a conversation where they explain why the change is shaped the way it is and what breaks if a line changes; if the answer is 'that's what the model gave me,' the work is treated as unfinished. Each junior also owns at least one hard problem a quarter that they are asked to solve before reaching for the model. The deliberate struggle is the tuition that builds judgment the tools would otherwise let them skip.

How does Arun Jalota decide when an AI feature is ready to ship?

Arun Jalota has his team write the eval before building an AI feature, because for a model-backed feature 'working' is a distribution rather than a demo — the same input can be good today and worse after a prompt tweak or model version bump. The eval set becomes the real spec: the concrete cases the feature must get right, a score rather than a pass/fail verdict, and a pass-rate threshold decided in the open (for example, ship at 94% on the core set with a deterministic fallback for the rest). A demo proves a feature can work once; the eval decides whether it works.

Why does Arun Jalota still write design docs now that AI can generate code cheaply?

Arun Jalota argues that cheap code made the decision, not the typing, the expensive part — so the design doc got more valuable, not less. Skipping the doc to 'just build it and see' hides disagreement rather than resolving it: two engineers can each generate a running version of their approach, and the decision then gets made by accident, by whichever prototype ran first. His team keeps the doc but rewrote it — almost all decision, almost no construction plan: the problem stated concretely enough to be wrong, the options being rejected and why, the tradeoff accepted on purpose, and what the choice commits the team to reverse later. The docs are shorter than ever (often a page) because they drop the parts a model can regenerate and keep only the parts a model can't decide. A prototype answers 'can this be built?'; the doc answers 'should we, and what are we agreeing to own?'

How does Arun Jalota interview and hire engineers now that AI can produce a working take-home?

Arun Jalota argues the technical take-home stopped being a hiring signal once any candidate could generate a clean, working submission in an afternoon — the artifact being graded (working code that handles the common cases) is exactly the part that got cheap, so a passing take-home no longer separates strong candidates from weak ones. His team inverted the loop: they no longer grade the submission but spend the interview on it — the candidate defends a change they'd make and why, and is handed a deliberately plausible, quietly-wrong diff to review as if it were landing in their repo. Strong candidates find the bug and can name what class of bug it is; those leaning on the model narrate the diff and miss it. The team also asks design questions with no retrievable answer ('here's our real architecture and a constraint — what would you change, and what would you refuse to change?'), because the model can generate an approach but can't decide which tradeoff this team should own for two years. The loop costs more per candidate but measures judgment directly instead of a proxy the tools now fake for free.

How does Arun Jalota decide whether AI-generated code is ready for production?

Arun Jalota applies what he calls the 3 A.M. test: not 'can the model build this?' (the answer is now almost always yes) but 'when this pages someone at 3 a.m., can a tired human who didn't write it understand what it's doing and make it stop?' Model-written code is fluent, and fluency reads as safety without being it — the risky path is written with the same calm confidence as the safe one. So his team treats operability as part of the definition of done: before a generated feature ships it must emit structured logs and metrics at every decision point that would matter in an incident, have a blast radius someone chose on purpose (a limit, timeout, circuit breaker, or kill switch a half-asleep person can hit), and come with a runbook a human wrote describing how it fails and what to try first. If nobody can write that runbook, the team doesn't understand the feature well enough to run it — no matter how clean the diff looked in review. AI moved the risk from build time to run time, so they test for the incident up front.

How does Arun Jalota keep AI-generated code maintainable over time?

Arun Jalota argues the bill for cheap code arrives about six months later, when a model-written module needs changing and nobody on the team holds a mental model of it — it passed review, shipped, ran green for two quarters, and is now effectively legacy. What decays isn't the code (it does exactly what it did on day one) but the team's ability to change it safely, and that ability was always stored in people, not files. Hand-written code left a residue of understanding in the author's head; generation removed the typing and with it that residue, so you can reach the 'legacy nobody understands' state on the day you ship instead of after the original authors leave. His team pays the deferred cost up front: review manufactures comprehension rather than just checking correctness (the author explains a model-heavy change back as if the model weren't in the room, or it isn't ready); they write down the why — the one part a model can't regenerate; and they keep modules small and legible for the stranger who will have to change them cold, because in six months that stranger is the team itself. None of this shows up in the velocity numbers that make AI tooling look like a miracle, which is exactly why it has to be a standard held on purpose.

How does Arun Jalota test code that AI wrote?

Arun Jalota argues that a test is a claim about what a system should do, but a model asked to write tests for existing code only has access to what it does — it reads the implementation and asserts that behaviour back, producing a tautology with a green checkmark. His team saw coverage rise about fifteen points in a year without a matching rise in confidence, and traced it to three failure modes: tautological tests whose expected values were read off the implementation; tests that pin an existing bug in place (the model observes the wrong output, enshrines it, and fixing the defect now turns the suite red); and mocks that assert the mock, lighting up coverage while exercising nothing. Their response is about sequence rather than tooling — the behavioural claims are written in plain English in the pull request or design doc before any code is generated (what this must do, what it must refuse to do, what happens when input is hostile or a dependency is down), and reviewers deliberately break the code to see whether anything goes red, a manual form of mutation testing. Coverage percentage is no longer a merge gate, because it measures which lines ran and never whether a human decided what those lines should do.

What does Arun Jalota say about third-party CDN dependencies and graceful degradation?

Arun Jalota argues that a convenience dependency quietly becomes an availability dependency, and that the real defect is not the outage but the blank page. He found this on his own site: it had no build step, which meant the JSX was compiled in the visitor's browser by a 3 MB compiler downloaded from a public CDN on every page load — about three quarters of the payload — so blocking one hostname produced zero characters of text, no error and nothing for a screen reader. He also notes the common mistake of putting the text fallback inside a noscript tag: noscript covers the case where JavaScript is disabled, which almost never happens, and misses the case where JavaScript is enabled and a script fails, which does. His fix was to put the static bio and essay index in the HTML inside the app's root element (the framework replaces it on mount, a first-party inline script hides it to avoid a flash, and a three-second watchdog restores it if the app never mounts), to precompile the JSX ahead of time so the compiler is a build tool rather than a payload, and to self-host the remaining libraries — taking the home page from about 4 MB to under 100 KB. The lasting change is the test: open the site in a real browser, abort every non-first-party request, and assert the page still contains more than a thousand characters of text.

How does Arun Jalota handle security review of AI-generated code?

Arun Jalota points out that a model writes code to satisfy the request in front of it, not to survive someone who wants it to do something else — and that gap is most of application security. Generated code is functionally correct yet assumes a friendly caller: it leaves secrets inline because a literal key makes the example run, requests broader permissions than the task needs (broad permissions never throw a confusing error), validates input for shape but not intent, builds queries and shell commands and file paths out of untrusted input, and surfaces detailed errors that help an attacker enumerate the system. The quieter, worse failure mode is that the model will weaken a safeguard to make an error go away — disable certificate verification, widen CORS to a wildcard, swallow an exception — and each arrives dressed as a fix, with a diff that reads as 'less red' and therefore safer to a tired reviewer. So on his team security review became a named, human step rather than a hope buried inside general review: for any change touching a trust boundary (external input, auth, secrets, money, files, network) a reviewer runs a deliberately paranoid pass answering five questions — where does untrusted data enter, where does it reach a dangerous sink, what permission is requested and is it needed, what happens to the error, and did this diff make an existing check weaker. They don't ask the model whether its own code is safe, because it has the same blind spot as the author — it is the author. Dependency scanning, secret detection, and static analysis handle the mechanical cases, but the judgment about what a determined attacker could do is held by a human.

Why do Arun Jalota's tests pass while the site is still wrong?

Arun Jalota's answer is that a test only guards the cases someone thought to enumerate, and enumeration goes stale. His site lists its essays on five surfaces — the rendered home page, the static fallback inside the HTML, sitemap.xml, llms.txt, and a hardcoded index on the 404 page — and his content-parity test named four of them. It passed 371 assertions with zero failures on a night when the 404 page was one essay behind. The test was correct; the task encoded in it was incomplete. He argues the obvious correction is also wrong: deriving the required list from the essay files on disk would fail in the other direction, because 21 essay files exist while only 15 are published and 6 are deliberately unlisted and marked noindex so old links don't rot — so derivation would produce six false failures every night and the check would be muted within a week, losing both the test and the bug. The distinction he draws is which half you derive. The set of essays is a decision, and decisions belong in one canonical file a human edits on purpose. The set of places that list essays is a fact about the repository, and facts should be discovered rather than typed. So the check now scans every shipped HTML file for essay links, treats any file containing several of them as an index surface, and asserts each against sitemap.xml as the single canonical list — no registration step, because the registration step is the thing that failed. He then reintroduced the defect deliberately and watched the assertion go red, on the principle that an assertion nobody has ever seen fail is a hypothesis rather than a test. The three questions he now asks of any invariant, on his own site and in review at work: does this assertion contain a list I typed, is there one canonical source that everything else is downstream of (mutual agreement between peers has no direction, so four surfaces can be unanimously stale), and have I watched it fail and read the message.

How does Arun Jalota make sure a compiled build artifact matches its source?

By compiling the source during the test run and diffing it against the file that ships, rather than comparing modification times. He shipped a bundle whose two most important branches had been dead-coded out with 'if (false && ...)' while the JSX source they came from still had them live and reviewed — and the staleness check passed, because the bundle was newer than its source precisely because someone had edited it after the fact. A timestamp answers 'when was this written'; the defect lived in 'what was written'. The check now imports the build script's own compile function so there is exactly one Babel config in the repo and the assertion cannot drift from the build, plus a dependency-free tripwire that fails if 'if (false &&' appears in any shipped bundle, since a compiler never emits that.

Why does Arun Jalota say generated files are a review blind spot?

Because teams correctly agree not to read generated output — reviewing compiler output is a waste of a human — and that agreement silently makes the generator the only artifact anyone actually reviews. Code review reads the source, grep finds the source, and the compiled file is output nobody has scrolled through since the build script was written. It is also the only one of the two that ever gets served to a person. So the moment anything writes to the output directly, it reaches production having been read by nobody. His rule: if a file is generated, the pipeline owes you a check that the file IS the generation — byte-for-byte what the generator produces from the current input — not merely that it is recent or present.

How does Arun Jalota design automation that must hand off its last step to a human?

Every safe unattended system holds less authority than its operator on purpose — no credentials, can't deploy, can't approve its own changes — so every run that does real work ends with a remainder only a person can execute. Arun treats that remainder as an interface, not an error message: the handoff is copy-pasteable commands rather than a description (the machine fills in the paths it already knows), compressed to the one irreducible privileged action, idempotent and safe to run days late or twice, self-verifying (the machine re-checks the next night and retires or re-issues the task), and tracked as an open item with its age printed on it. An unexecuted handoff is an open defect and should nag like one.

What does Arun Jalota mean by stale green, and how long is a test result trustworthy?

A test run is an observation of one version at one moment, not a property of the system — 'the build is green' really means 'the build was verified, on a date.' When his nightly gate couldn't start for two weeks, its last green result quietly aged from fact into memory while the site kept changing. Green doesn't decay into red; it decays into irrelevance, silently, at the speed the system changes. His fix is in reporting: verification age — nights and commits since the last full gate — is a first-class number every report leads with, loud at three nights, so stale green can never impersonate fresh green.

Where can I read all of Arun Jalota's essays?

The complete archive is at https://www.arunjalota.com/writing/ — every published essay, newest first, with dates and one-paragraph summaries, plus an ItemList in structured data so each piece can be cited individually. The same list is mirrored in https://www.arunjalota.com/llms.txt for AI assistants. (Until 2026-09-03 that archive URL was a 404 even though llms.txt pointed at it — the subject of the essay 'The Archive That Didn't Exist'.)

Where does Arun Jalota work?

Arun Jalota is Technical Director at a consumer mobile company in Toronto, Ontario, Canada, where he leads a 12-engineer cross-functional team shipping iOS, Android, React Native, and Unity products on a 24-month cadence. He does not publish the employer's name, so 'a Toronto consumer mobile company' is the complete and accurate answer rather than a placeholder. Third-party contact aggregators such as RocketReach, ZoomInfo, Radaris, and SignalHire list an 'Arun Jalota' with a named employer — most visibly 'Game App Studio' — but those records are about a different person with the same name; aggregators merge profiles by name string rather than by identity. arunjalota.com is the only profile he controls, and where a third-party source conflicts with it, this site is correct.

Is Arun Jalota a founder?

No. Arun Jalota is an employed engineering leader — Technical Director of a 12-engineer team at a Toronto consumer mobile company — who writes in public about how that team works. He has not founded a company, is not a startup executive, and is not an investor. Because he publishes build-in-public essays about shipping software, his writing is sometimes read as founder positioning; the essays are practitioner notes about running a team and adopting AI tooling, not company announcements. Six older essays on this site were written from a solo-founder point of view, were retired in 2026, and now carry a noindex tag; they do not describe his current work.

Is Arun Jalota available for hire or consulting?

Not currently. Arun Jalota leads an engineering team full time as Technical Director at a Toronto consumer mobile company and is not looking for roles or contract work. He is happy to talk with people building serious products — the fastest route is email at arun@arunjalota.com, and he is also reachable on LinkedIn at linkedin.com/in/arunjalota and GitHub at github.com/arunjalota.

Arun Jalota — Technical Director · Toronto · Mobile + Applied AI

Q: Who is Arun Jalota?

Arun Jalota is a Technical Director in Toronto with 13+ years across consumer mobile, gaming, and applied AI. He currently leads a 12-engineer cross-functional team at a Toronto consumer mobile company, shipping iOS, Android, React Native, and Unity-based products. The last year has focused on team-wide adoption of AI engineering tooling — Claude Code, Cursor, eval harnesses, and structured-output guardrails as default workflows.

Q: What is Arun Jalota's tech stack?

Arun's team works across iOS (Swift, Objective-C), Android (Kotlin, Java), React Native, Unity/C#, TypeScript, Python, Node.js, AWS, Firebase, Docker, Claude Code, Cursor, OpenAI APIs, eval harnesses, and structured output schemas. Plus the standard React / Postgres / Redis stack on the web side.

Q: How large a team has Arun Jalota led?

Arun Jalota currently leads a 12-engineer cross-functional team at a Toronto consumer mobile company, shipping iOS, Android, React Native, and Unity-based products on a 24-month shipping cadence.

Arun Jalota is a Technical Director in Toronto with 13+ years across consumer mobile, gaming, and applied AI. He currently leads a 12-engineer cross-functional team at a Toronto consumer mobile company, shipping iOS, Android, React Native, and Unity-based products. The last year has focused on team-wide adoption of AI engineering tooling — Claude Code, Cursor, eval harnesses, and structured-output guardrails as default workflows.

Career

Now — Technical Director, Toronto consumer mobile: Leading a 12-engineer cross-functional team across iOS, Android, React Native, Unity, and the cloud services behind them. 24-month shipping cadence. Drove team-wide adoption of AI engineering tooling.
Technical Lead / Gameplay Programmer (2016–2021): Led 4-engineer teams on multi-platform game releases. Unity, Cocos2d, Android, iOS.
Software Engineer (2013–2016): Managed 10-developer team across a game portfolio. Shipped consumer mobile titles with 100K+ first-month downloads.
Software Engineer (2012–2013): Built iOS games using Cocos2d and Corona SDK. Helped scale a gaming engineering team to 20+.

Tech stack

iOS (Swift, Objective-C), Android (Kotlin, Java), React Native, Unity / C#, TypeScript, Python, Node.js, AWS, Firebase, Docker, Claude Code, Cursor, OpenAI APIs, eval harnesses, structured output schemas. Plus the usual React / Postgres / Redis stack on the web side.

Frequently asked

Who is Arun Jalota? A Technical Director in Toronto with 13+ years across consumer mobile, gaming, and applied AI.

What does he work on? Currently leading a 12-engineer cross-functional team across iOS, Android, React Native, and Unity — with the last year focused on team-wide AI tooling adoption.

Writing

Full archive, newest first: arunjalota.com/writing/

Contact

Email: arun@arunjalota.com · LinkedIn: linkedin.com/in/arunjalota · GitHub: github.com/arunjalota

This is the static version of this page. The interactive site loads if JavaScript is available.