Software job postings are recovering. What should AI engineers build?
Read October's US software-posting rebound against its older baseline, then turn a real role requirement into a project with checkable results and task costs.
Published · Updated

Growth and the old baseline answer different questions
Moses Sternstein's October 30 a16z report shows software-development postings up 25.7% from October 1, 2025 in its Indeed chart. Separately, Indeed's US software-development series on FRED records an index of 80.78795 on October 23, with February 1, 2020 set to 100. That observation is about 19.2% below the pre-pandemic baseline. A large rebound can coexist with a depressed level.[1][2]
Keep the categories separate. The report's 29.5% engineering increase concerns traditional engineering fields, rather than software development. These are US posting measures. They establish neither completed hires nor improved opportunities for Canadian juniors, AI engineers or forward-deployed engineers specifically. The aggregate series also cannot identify which framework or technical skill employers now want.[1][2]
The report suggests AI may explain growing technical demand, while acknowledging other possible causes. Its charts do not isolate that effect. Likewise, fewer AI-job-loss news stories and explicitly AI-related layoff announcements measure attention and announcements. They cannot establish total displacement. Treat the recovery as a change in advertised demand within the measured market, with its cause unresolved.[1][2]
Choose a project from a requirement you can inspect
Here is an editorial preparation exercise, not a tested hiring intervention. Open one current employer posting for a role you actually want. Find a stated task you could demonstrate with public or synthetic inputs. If that requirement involves extracting document fields, define one document type and a small output schema. The posting supplies the relevance; the national index supplies no evidence that this particular skill is in demand.[1][2]
Write acceptance rules before choosing a model. For the hypothetical extraction project, a returned record needs every required field, a supporting source span for each value and an explicit unknown when the document lacks the answer. Completeness and correctness need separate checks: a populated field can still contain an invented value. Decide how a reviewer resolves ambiguous cases before comparing configurations.[1]
Retain the inputs, inspected outputs, rejected cases and the reasons for each verdict. Use material you can share lawfully, without customer records. Another engineer should be able to check whether your claimed successes satisfy your own rules. This is a proposed way to demonstrate your work; neither source tests its effect on interviews or offers.[1][2]
Predict the cheaper accepted result
The report's token-economics discussion adds a useful measurement warning. GPU rental rates and blended token prices lack a matched input-to-output conversion. The comparison alone cannot establish model-provider margins. For your project, a lower token price likewise cannot establish a lower cost of acceptable work. Include failed attempts, retries and review when calculating that cost.[1]
Consider this fictional static exercise. No model was run, and every input number is invented. Two configurations each attempt the same 100 tasks under identical acceptance rules. Configuration A costs USD 24, including retries and human review, and produces 60 accepted tasks. Configuration B costs USD 18 on the same basis and produces 30 accepted tasks. Predict which has the lower cost per accepted task before reading the answer.[1]
A costs USD 0.40 per accepted task; B costs USD 0.60. B has the smaller bill and half as many accepted results. Record review minutes and their assumed monetary rate separately so the comparison remains inspectable. Apply the same acceptance rules to both configurations. Otherwise a higher accepted count could reflect a looser standard rather than better performance.[1]
Keep a project record with explicit limits
Your reusable artifact is a short project record: the employer task, input set, acceptance rules, inspected successes and failures, total costs and cost per accepted task. State what you did not test. A small document sample cannot establish reliability across every document type. Present only results you actually obtained, and distinguish proposed improvements from completed work.[1][2]
The October rebound can inform your view of the US market without deciding your whole career plan. Use actual role requirements to choose the work and your own checked results to describe it. The a16z chart figures remain report-attributed; the FRED observation was separately checked, with its visible October 28 update date. Neither source establishes AI's causal employment effect or a hiring benefit from this exercise.[1][2]
Sources
- Charts of the Week: Job FUD FadesMoses Sternstein / a16z,
- Software Development Job Postings on Indeed in the United States (IHLIDXUSTPSOFTDEVE), updated October 28, 2026Indeed / FRED, Federal Reserve Bank of St. Louis,