AES Just Wrote the Cleanest AI-Native JD on HN. Your Boolean String Is Wrong.
An AES intern post on HN's June 2026 thread admits the bar is not coding. Here is how to rewrite intake and sourcing strings for diff-readers.
The June 17, 2026 "Who is hiring?" thread on Hacker News (item 48357725) contains a summer-intern post from AES, an environmental-test-chamber manufacturer, that says the quiet part loud. The bar, in their own words, "is NOT raw coding ability. We use Claude Code for all code generation." Every recruiter intake doc and Boolean string I've reviewed this month is still pointed at the old signal, and it shows in the shortlists.
If you're sourcing for any team that has standardized on Claude Code or Codex, the AES post is the cleanest public template you'll get this year. It names the actual rubric: schema literacy, diff-reading, end-to-end ownership. None of those are in the keyword field of LinkedIn Recruiter.
What the AES post actually says
The listing is small enough to read in one sitting. Summer Software Engineering Intern, remote US with occasional Boston-area days, $30 to $40 an hour, June 15 through August 22, 2026. The team is a senior lead, a part-time backend specialist, and the intern, building a pre-production field-service-management platform with active user feedback.
The stack is named: Next.js 14 (App Router, RSC, Server Actions), TypeScript strict, Prisma plus Postgres, Tailwind and shadcn/ui, NextAuth, Twilio, Anthropic SDK. That stack is what every recruiter will paste into a Boolean string. It is also, per the JD itself, downstream of the actual hire decision.
The money line:
The bar is the ability to direct an AI at production engineering and catch it when it's wrong: schema literacy, diff-reading, end-to-end ownership.
AES is not an outlier in the same thread. Opaxa, in the SF section, screens for candidates who have "shipped agentic systems to production, plan-and-act, not chatbots or wrappers" and use Claude Code or Cursor as default. They then add a line that should make every sourcer reread their candidate outreach templates: "Please write it yourself; if it's clearly AI-generated, I'll pass." Neurotone, in the same thread, defines a CSM role where "Claude is how you'll triage tickets, investigate our codebase, write docs, and automate the repetitive parts of the job."
This isn't just a tiny-team intern phenomenon either. Augment Code published a hiring rubric in March 2026 that arrived at the same answer: "Coding still matters, but it's no longer the primary differentiator of engineering talent. As code becomes cheaper to produce, the most expensive mistake is building the wrong thing."
The Boolean string is the tell
Look at the last ten Boolean strings your team ran. I'll bet most of them OR together languages and frameworks. ("Next.js" OR "React") AND "TypeScript" AND ("Prisma" OR "Drizzle") AND ("3 years" OR "4 years"). That string matches the stack section of the AES JD. It does not match the rubric section at all.
What you actually want to surface are signals the keyword fields don't index. Public PR review history on busy open-source repos. RFC or design-doc authorship. Postgres or Prisma migration commits, especially the ones that touch foreign keys, cascading deletes, or partial indexes. Linear or Notion specs the candidate has shared publicly. A track record of bug reports that read like incident postmortems rather than "doesn't work."
You can construct some of that on GitHub if you're patient. Filter by is:pr reviewed-by:<handle>, scan for migration filenames in monorepos, eyeball comment density. It's slow, and it's why we built Refolk: you describe the person in plain English ("engineer who reviews a lot of Prisma migration PRs on busy Next.js repos and has shipped something with the Anthropic SDK") and get a ranked shortlist across GitHub, LinkedIn, and the open web. The point of sourcing AI-native engineers is to stop matching on the stack noun and start matching on the verb.
Why diff-reading is the actual bar
Anthropic shipped Code Review for Claude Code on March 9, 2026, a multi-agent automated PR review system built directly into the agentic coding tool. The product never auto-approves. The human always makes the merge decision. That product decision is the structural reason AES's rubric exists.
IBM Research's 2026 AAAI paper put numbers on it: LLM-as-judge alone catches roughly 45% of code errors. Combined with deterministic analysis, detection rises to 94%. The remaining 6% is the hire's job, and the 6% is where the latent production bugs live.
Throughput evidence underscores why the review bottleneck matters now. A fintech reported cutting average bug-fix time by 50% after a team-wide Claude Code rollout. A SaaS team moved from bi-weekly to weekly releases inside two months. An e-commerce team raised PR merge rate by 40% while holding quality. PR description overhead dropped from about two hours per engineer per week to near zero. Code is cheaper. Review is the new constraint. The hires that move the needle are the ones who can read a diff at the speed the agent ships them.
Rewrite the intake meeting first
Sourcing strings won't fix themselves until the intake meeting changes. Here's the swap-list I've been handing engineering managers.
Drop these questions
- Years of Next.js, years of TypeScript, years of Postgres.
- "Walk me through a system design for a URL shortener."
- "Which languages are you most proficient in?"
- "Are you a senior engineer?" as a binary.
Add these questions
- Describe the worst bug Claude Code or Cursor shipped on your watch. How did you catch it? How long had it been in the codebase?
- Here's a 400-line Prisma migration diff. Read it out loud. Tell me what's about to break in production.
- Walk me through a feature you owned from spec to deploy where the model wrote most of the code. What did you reject and why?
- Show me a PR you reviewed where you blocked a merge that the author thought was ready.
The "years of Next.js" question is a proxy from an era when ramp-up time on a framework was a real cost. With agentic tooling, ramp-up on a framework is mostly free. Ramp-up on a domain (environmental-test chambers, field-service workflows, customer hardware), and on a codebase's invariants, is not. That's what schema literacy diff reading hiring is actually measuring.
The seniority filter is misleading
AES is hiring an intern under this rubric. That is the single most important detail in the post. Diff-reading and schema literacy don't correlate cleanly with seniority. They correlate with how many ambiguous AI outputs the candidate has personally had to reject.
A new grad who's spent twelve months as a heavy Claude Code user, shipping in someone's pre-production codebase, has rejected more agent suggestions than an eight-year senior IC who only adopted the tool in Q1. The senior IC has other things going for them (production instincts, on-call scars), but the specific muscle the JD names is a reps question, not a tenure question.
If your intake doc still says "senior" as a hard filter, you're going to miss the AES profile entirely. The better filter is "ships under AI assistance and has the receipts." Refolk handles that kind of compound query without forcing you back into Boolean syntax, which is the point: the rubric is now too multidimensional for an AND-OR tree.
The "did they write it themselves?" paradox
Opaxa's line in the same June thread is worth sitting with: hiring managers want candidates who can wield AI, but reject candidates who use AI to apply. On the surface it reads inconsistent. It isn't. Both tests are the same test: judgment under AI assistance.
A candidate who lets the model write their cover letter without catching the giveaway phrasing has failed the diff-reading screen before the interview. A candidate who uses the model to draft, then rewrites until the result sounds like a human who has actually shipped, has passed. The application is a work sample for the job.
You can mirror this on the sourcing side. If your outreach is obviously model-generated, the candidates you most want (the ones with the diff-reading instinct) will notice and ignore you. The first message should sound like a human read their PR history. Because a human (or a tool that surfaces the right detail to a human) should have.
A practical rewrite of the AES search
Walk it through concretely. The old string for the AES role probably looked like:
("Next.js" OR "React") AND "TypeScript" AND ("Prisma" OR "ORM") AND ("intern" OR "junior" OR "new grad")
That string returns thousands of profiles and ranks none of them on the rubric.
The rewrite, in plain English, is closer to: "People who have reviewed Prisma or Drizzle migration PRs on active Next.js App Router repos in the last year, have at least one merged PR touching Server Actions or RSC, have written at least one public spec or RFC, and have shipped something with the Anthropic SDK or OpenAI agents." Then sort by review density, not by stars.
That is a query, not a Boolean string. It's the kind of intake-meeting-questions-engineering-leads-actually-care-about query that a JD rewrite for AI tools should produce. Refolk runs it as-is. If you're not on Refolk, your job is to translate that sentence into three or four separate searches and then manually intersect them, which is what eats Tuesday.
What to change this week
- Pull last week's three open reqs. Find the rubric line that's actually doing the hiring work. If you can't find it, the intake meeting failed.
- Rewrite the Boolean strings against the rubric, not the stack. Keep the stack as a tiebreaker, not a gate.
- Replace one whiteboard round with a diff-reading round. Use a real diff from your repo, ideally one Claude Code wrote and you rejected.
- Audit your outreach for AI tells. If you wouldn't merge it, don't send it.
- Stop using "senior" as a hard filter on roles where the AES rubric applies. Use review density and shipped-with-agent evidence instead.
The AES post will scroll off the front page. The signal won't. Claude Code hiring patterns are showing up in CSM listings, GTM-engineer listings, and intern listings in the same thread. The teams that rewrite their intake docs in June will be staffed by August. The teams running 2024 Boolean strings will still be sourcing in September.
FAQ
Is the AES post a one-off, or is the rubric actually shifting?
It's not a one-off. Opaxa and Neurotone in the same June 2026 HN thread describe the same pattern for engineering and CSM roles respectively. Augment Code published an explicit "raw coding ability is not on our rubric" hiring framework in March 2026. GTM-engineer postings mentioning Claude Code grew 340% between Q1 2025 and Q1 2026 per TheirStack. The AES JD is the cleanest articulation, not the only one.
How do I screen for diff-reading without inventing a new interview loop?
Use a real diff from your repo, ideally one your team generated with Claude Code and then rewrote. Ask the candidate to read it out loud and flag what's going to break in production. You're looking for them to notice schema invariants, cascading effects, and edge cases the model missed. The IBM Research number says automated review catches about 94% of errors. The 6% your candidate finds (or doesn't) is the signal.
Should I stop sourcing on framework keywords entirely?
No, but demote them. Frameworks are tiebreakers, not gates, because ramp-up under agentic tooling is fast. Lead with review density, migration history, and evidence of shipping with an AI agent. Then use the stack as a sort key. The AES JD literally names Next.js 14, Prisma, and the Anthropic SDK, and still tells you the framework isn't the bar.
What if my intake meeting still won't change?
Bring the AES post and the Augment Code rubric to the meeting. Ask the hiring manager which 6% of bugs they want the hire to catch. If they can't answer, the rubric isn't ready and the req shouldn't open. That's a harder conversation than rewriting a Boolean string, and it's the only one that actually fixes the pipeline.