AI-enabled jobs in the Philippines: an in-depth report

The 15-20% and 65-71% ranges in the intro don't come from a single survey: we put them together from several, each one measuring workers exposed to AI. The sources: Adaptavist (late 2025, n = 4,000 knowledge workers across the US, UK, Germany and Canada: 20% report stress or anxiety from fear of AI replacement, 35% report hoarding their skills, and it rises to 40% among Gen Z respondents); the Stack Overflow Developer Survey (2025: roughly 15% of developers view AI as a threat to their job, with a further 21% unsure); Reuters/Ipsos (2025, US adults: 71% worried AI will put too many people out of work permanently); and EY (65% of surveyed workers anxious about AI replacing their own job).

Three things to bear in mind before you use those ranges. First, the surveys measure different things: "stress or anxiety" (Adaptavist), "perceived threat" (Stack Overflow) and "worry about displacement in general" (Reuters/Ipsos, EY) are not the same thing, which is why we give you a range rather than a single number. Second, the people surveyed differ, and none of them is the Philippine workforce: the ranges describe similar digital-economy workers elsewhere. Third, self-reported anxiety moves with question wording and news cycles. Nobody has measured this for the Philippines specifically, and that gap is part of why this report exists.

Collection. We collected on 2026-07-27, from two sources: JobStreet Philippines (public search API, with the full listing text retrieved per listing) and Kalibrr (public job-board API, filtered to Philippine listings). We ran ten query terms: artificial intelligence, machine learning, generative AI, AI engineer, AI automation, AI agent, LLM, prompt engineering, chatgpt, AI. We deduplicated across queries by listing ID. The yield: 3,489 unique listings (3,023 JobStreet, 466 Kalibrr). Every listing carries first-seen and last-seen timestamps, so repeat scans can measure persistence and reposting.

Structuring. A language model (Claude Haiku 4.5, batched) read each listing's full text and converted it to a fixed schema: does the role genuinely involve AI (the noise gate), how central AI is (core: the job is building AI systems; applied: a job done with AI tools daily; peripheral: AI as a nice-to-have), one of eleven role categories, seniority (entry, mid, senior, lead, or unspecified), employer industry, named tools, skill phrases, and salary. Of the 3,489 listings, 3,447 made it through (the rest had descriptions too short to classify, or failed extraction). The noise gate passed 1,107 listings (32.1%): 721 applied, 334 core, 52 peripheral.

Vocabulary normalization. Extraction produced 5,365 distinct skill phrases and 1,564 distinct tool names. We merged synonyms and spelling variants into canonical terms with a language-model pass over the full vocabulary ("AI prompting", "prompting" and "prompt engineering" all become prompt engineering). Every demand count in this report is a count of canonical terms.

Salary normalization. Where a listing posts a salary, we take the midpoint of the posted range, converted to monthly PHP when the posting states another period or currency. Roughly 30% of AI-role listings post salaries. One known error class (per-year figures mislabelled as per-month, which convert to absurd monthly values) is excluded by capping at ₱600,000/month. Every pay figure in this report is a median over these midpoints: annex D explains why.

The 24 archetypes. The 1,107 AI roles carry 983 unique titles, so titles can't tell us what the job really is. So we represented each listing by its canonical skill set instead, and clustered within role category (a hard rule: an engineer and a marketer never merge), using bisecting 2-means on unit-normalized skill vectors with cosine similarity and deterministic seeding. Cluster budgets are proportional to category size, 25 in total; clusters smaller than 8 listings fold into 'other'. The result: 24 clusters covering 1,106 listings (one listing had no usable skills). Why roughly 25: each archetype needs enough members posting salaries for an honest median. A language model proposed the archetype names from each cluster's skill profile and sample titles, and we reviewed them; the hover descriptions are put together from up to 25 member listings per archetype. The taxonomy is frozen as version 1: future scans classify new listings into it by nearest centroid rather than re-clustering, so the trend lines can be compared from scan to scan. If 'other' ever exceeds roughly 10% of new listings, we re-cluster to version 2.

The 1,106 skill fingerprints projected from 343 skill dimensions down to two (PCA, mean-centered unit vectors, power iteration). Each dot is one listing, coloured by centrality. The projection is computed rather than drawn: the grouping you can see (content top-left, automation upper-right, building-with-AI lower-right) is what the clustering formalizes. The overlap between the colours is real too, which is why we cluster within role category rather than globally.

The map's edges. Three edge types, three derivations. Stated edges (skill to job): the top skills in an archetype's fingerprint with a share of at least 0.12, capped at 3 per archetype; the edge weight is the share of the archetype's listings naming the skill. Implied edges (baseline to job): discipline tokens in the archetype's member titles (developer, engineer, programmer), emitted when at least 35% of titles carry the token and no stated edge already covers the pair (this captures the prerequisites job ads assume rather than state). Prerequisite edges (skill to skill): for every skill pair with at least 8 co-occurring listings, we compare conditional probabilities, and draw an edge from A to B when P(A present | B present) is at least 0.30 and beats the reverse conditional by a factor of at least 1.4. The asymmetry gives us the direction: specialist listings ask for their foundations, however not the other way around. We insert edges strongest-first with a cycle guard, then transitively reduce, so a job connects to the skills closest to it, and the rest of the path comes through the chain.

The hours. The learning hours behind the skill slider are estimates, not measurements: the extra hours each skill takes to reach an employable level, assuming the skill's prerequisites in the map are already met, for a digitally literate learner with no coding background. A job's total is the sum over its full upstream path. These are the only numbers in the report that aren't measured, and they're labelled as such wherever they appear.

Coverage. Two job boards. We don't yet scan company career pages, LinkedIn, or specialist boards, so enterprise employers that hire only through their own systems are under-represented. The keyword net misses things too: a role that is AI-heavy in practice but never says so in its ad is invisible to us.

Selection bias in pay figures. Only about 30% of AI-role listings post salaries, and the employers who post may differ from the ones who don't. Every pay comparison in this report carries this bias, including the bucket gap in annex D.

Extraction error. Every structured field is a language model's reading of free text. We haven't yet run a human-validated error-rate sample, so until we do: treat individual listings as approximately right, and aggregate counts as reliable to within a few percent, not down to the last listing.

Stated-skill bias. Job ads name whatever filters candidates, and leave out what they take for granted. We measured this directly: developer, engineer or programmer appear in 62-93% of member titles across the building tier's engineering archetypes, whilst software engineering rarely appears as a stated skill; spreadsheet skills appear in over half of all AI-role listing bodies whilst almost never showing up as a stated requirement. The implied-edge layer in the map exists to correct for this, however the correction is partial.

Clustering impurity. Hard clustering misfiles some listings. A known example: a group of full-stack developer listings sits inside the QA automation archetype, because both name test automation. We estimate archetype impurity at roughly 10-15%, and archetype medians pick up small distortions from it.

A snapshot, not a trend. Every figure describes listings live during the July 2026 collection window. Nothing here measures growth, decline or turnover: that requires the repeat scans the pipeline is built for.

Demand floor. Job postings measure external hiring demand only. Companies that upskill existing staff never post, so every corporate-demand reading here is a floor, not a total.

The buckets section claims that jobs building with AI pay more than jobs using it. Here is the test behind that claim.

The samples. Of the 1,107 AI roles, salaries are posted on 232 using-AI listings and 84 building-AI listings. Each listing's salary is the midpoint of its posted range, in monthly PHP, with the same mislabelled per-year outliers capped out as everywhere else in this report. The medians: ₱56,000 (using) vs. ₱120,000 (building).

Every salaried AI-role listing is one dot, jittered within its lane; the vertical bars mark the lane medians. Look at the shape as well as the medians: the applied lane is dense at the low end with a long right tail (the highest-paid applied listings are the AI-assisted developers), whilst the core lane sits shifted right with a wide spread. The two overlap substantially, which is why our claim is about medians and likelihoods rather than a wall between the buckets.

Why medians and not averages. Salary data is skewed: a few very high postings drag an average upward, and one mislabelled listing can move it by thousands. The median (the middle listing) barely moves when an outlier lands. That's why every pay figure in this report is a median.

The test. For skewed data like this, the standard tool is the Mann-Whitney U test. Instead of comparing averages, it asks: if you repeatedly drew one listing from each bucket at random, how often would the building one pay more? If the two buckets really paid the same, that would hover near 50/50.

The result. U = 14,329, z = 6.39 (normal approximation with tie correction), two-sided p ≈ 1.7 × 10⁻¹⁰, i.e if using-AI and building-AI jobs truly paid the same, a gap this consistent would show up by chance far less than one time in a billion. The effect size (rank-biserial r = 0.47) is the practical way to read it: draw one listing from each bucket at random, and the building one pays more roughly 3 times out of 4.

The seniority check. The 'Building with AI' bucket is more prone to wanting seniors: 61% of the salaried ones want seniors or leads, vs. 32% of the 'using AI' ones, and experience commands pay on its own. So we re-ran the same test within each seniority level:

• Mid-level: ₱58,250 (using, 100 listings) vs. ₱75,264 (building, 19), U = 1,386, z = 3.16, p ≈ 0.002, rank-biserial r = 0.46.
• Senior: ₱105,600 (65) vs. ₱135,000 (41), U = 1,736, z = 2.62, p ≈ 0.009, r = 0.30.
• Entry and lead point the same way, however each holds only 10 salaried building listings, too few to test honestly.

A reweighting check gives the split: if the 'Building with AI' bucket had the 'using AI' bucket's experience mix, its median would sit near ₱91,000 rather than ₱120,000. So comparing like with like, the building premium shrinks from more than double to roughly 30% extra, and the rest of the pay gap is experience mix. Both parts are real, and the body's rule of thumb claims only the first.

What this does and does not establish. It establishes that the pay difference between the buckets is real, and that it survives holding experience level fixed. It does not pin the medians down to the peso (they move by a few thousand with the sample), and it carries the one bias both buckets share: only listings that post salaries are counted, and the employers who post salaries may differ from the ones who don't. Neither problem changes the direction or the rough size of the gap.

Dataset. One SQLite database holding every stage: raw listings (full text, source, timestamps: 3,489 rows), structured extractions (3,447 rows), the canonical vocabulary mapping (6,929 term rows), the frozen taxonomy (24 archetypes and 1,106 listing assignments), and per-run scan records. Collection window: 2026-07-27.

Models used. Structuring and vocabulary normalization: Claude Haiku 4.5. Archetype naming and description writing: Claude Sonnet 5. Clustering, edge derivation and all statistics are deterministic code, not model output, and re-run identically from the database.

Pipeline. Four stages, each re-runnable and incremental: scan (pull and deduplicate listings, refresh last-seen timestamps), extract (structure new listings), canonicalize (merge new vocabulary), classify (assign new listings to the frozen taxonomy). A single export step regenerates the graph data (all three edge types, with the thresholds from annex B) from the database. Every figure in this article is derived from these tables, with no hand-entered numbers except the learning-hour estimates, which live in one reviewed file.

Cadence. The July 2026 run is the baseline. We plan to re-scan weekly: because the taxonomy is frozen and classification is deterministic, week-over-week changes in demand, pay and archetype mix can be compared directly. If we ever need corrections or a re-cluster, we'll publish them as versioned updates, so nothing in this report changes silently.

Access. The dataset contains only public job-listing content. If you want to verify a figure or run your own analysis, contact us through the site and we'll share the relevant extract.