Air Review: 51/100 after a 37-page crawl

Fact	Value
Domain	air.dev
Category	Agent-enabled software development platform
Pricing	Unknown in supplied inputs
Pages crawled	37
Crawl date	2026-10-11

Air has a clear product category and a recognizable JetBrains brand context. Its strongest public scores are first impressions and positioning (76/100) and audience and messaging (78/100): the site shows projects, environments, automations, and connected agents in a coherent workspace. The score is pulled down by performance (24/100), risk and stability (28/100), editorial QA of content (38/100), writing quality (42/100), design execution (58/100), and accessibility (52/100). The homepage recorded a 26.9-second lab LCP and a 9.1 MB transfer in PSI conditions. The evidence also identifies host and canonical confusion, a soft-404 redirect pattern, and a malformed robots.txt artifact as stability risks.

Air is legible as an agent-enabled software development environment, but the name is difficult to own in search. The hero says jetbrains air is one system for building software with agents and promises compatibility with existing agents and ACP connections. Demonstrations of projects, environments, automations, agent activity, and credits make the workflow tangible. The gap is distinctiveness: the evidence shows no named customer outcomes or comparison pages. Use JetBrains Air consistently with a descriptive category modifier, then add attributable proof with measurable engineering outcomes.

Air presents a connected system rather than a single assistant. Choose where you work spans IDE, Web, CLI, and Mobile, while the demonstration shows projects, environments, automations, agent runs, and credit usage. That breadth makes the product model concrete, but it asks visitors to choose among surfaces before establishing one first-use job. Keep the interoperability promise, then offer task-based paths for coding, review, automation, and governance.

Air passes the ten-second comprehension check, but mobile is undermined by extreme delay and competing starts. The homepage exposes both Try Air and Try in your IDE, so one Air-specific CTA should be dominant. PSI mobile records FCP 22.7 s, LCP 26.9 s, and time to interactive 35.6 s. Choose one primary start, make destinations explicit, and prioritize headline and CTA interactivity.

Air has foundational accessibility barriers in forms, controls, and structure. The rendered DOM reports 4 of 5 homepage inputs without a label or ARIA name; PSI flags unlabeled selects and buttons without accessible names. Sampled templates also report no skip link or main landmark, heading jumps on help and store, and generic read more links. Add explicit names, a skip link, a main landmark, logical headings, and descriptive link text.

Air has a recognizable responsive presentation: the 390px capture reports no page-level horizontal scroll, a valid viewport, and 16px body text. The execution weakens at component level. The crawl reports 135 undersized mobile tap targets, while extracted CSS contains 96 colors, 28 font sizes, 16 radii, 7 font families, and 64 spacing values. Fix semantic structure and 44px hit areas, then consolidate tokens and make the product demo genuinely mobile-composed.

Air has healthy real-user homepage data: p75 LCP 1.726 s, INP 177 ms, CLS 0.07, and TTFB 373 ms. The lab run exposes a large margin on slower devices: mobile FCP was 22.7 s and LCP 26.9 s, while PSI measured 9,148 KiB. The network summary recorded 16,948 KiB across 253 requests, including 12,968 KiB from www.jetbrains.com. Fix LCP discovery first, then split and defer non-critical work and add image dimensions.

Air’s strongest line names the category and interoperability clearly: Works with the agents you already use and any you can connect via ACP. That specificity does not carry through the sampled routes: 15 pages repeat the same title, meta description, and H1, while help contains 1,597 words in one paragraph with 49.9-word average sentences. Preserve the direct promise, but give each route a distinct opening, descriptive H2s, and short paragraphs.

The main stability risk is indexability, not a measured traffic decline. All 37 inventory rows canonicalize to https://www.jetbrains.com/air/, while 17 sampled legacy paths redirect there and several air.dev pages remain 200. The nonexistent probe also reaches the homepage with 200, creating a soft 404. The robots artifact is HTML rather than directives. Choose one primary host, apply consistent redirects, return a genuine 404 or 410 for unknown paths, and serve plain-text robots.txt.

The evidence supports an editorial QA failure at template level. Fifteen pages share the same title and meta description, and help places 1,597 words in one paragraph. Keep the hero promise as the control sample, then require route-specific metadata and H1s and answer-first sections before publication.

Air earns its clearest marks for positioning and audience messaging. The product category is understandable, and the public surface gives concrete views of projects, environments, automations, and connected agents. The main fixes are practical: reduce the homepage mobile load, address accessibility barriers such as unnamed controls, and resolve the stability and editorial QA findings identified in the evidence. Air is presented as a system for software development with agents. The public surface is available for evaluation; the supplied evidence identifies remediation work before publication-quality standards are met.

This review covers the scored dimensions available in the supplied inputs for air.dev. The crawl covered 37 pages on 2026-10-11. Pricing is marked unknown because no pricing page was captured. Google Search Console is not connected, so traffic magnitude and historical loss cannot be measured. The editorial QA assessment uses the supplied crawl and rendered evidence; source support for individual claims was not independently reverified in this gate. Read How SiteList scores for the review method.