Six Months In, She Generated a Better String Than I Did
AI is commoditizing Boolean search. What replaced it? How top sourcers are adapting from syntax mastery to problem definition and intake mastery.
A friend of mine, six months into her first recruiting role, was showing me how she’d been sourcing. We were sitting at coffee bar on a Saturday, she had a laptop open, I had coffee going cold next to me.
She typed two sentences into a chat interface and got back a Boolean string for a senior data engineer role. Twenty-eight terms. Proper nested logic. Site operators I’d used myself. It would have taken me, at a confident pace, somewhere between fifteen and twenty minutes to build and test something comparable if I were doing that manually a few years ago. Maybe longer if the hiring manager brief was vague, which they usually are.
She ran it. Results were solid. She moved on to showing me something else.
She didn’t even know what made it good. She didn’t look proud. She didn’t look like she’d accomplished something. She looked like she’d copy-pasted a template.
I’ve been writing Boolean search strings for years. Not casual strings. I mean the deep stuff: nested parentheses, creative operator stacking, X-ray searches across GitHub and Stack Overflow and niche developer forums that most recruiters have never heard of. Google dork queries that surfaced PDFs with speaker bios attached.
Strings I tested across three search engines because Bing and Google handle operators differently and sometimes Bing returns something Google buries. I was proud of that. It was a craft. It took time to build and it separated real sourcers from people who typed “software engineer Prague” into LinkedIn and called it sourcing.
That afternoon I thought: well. That’s that.
How LinkedIn Broke Us and We Went Deeper Anyway
Boolean search for recruiting peaked somewhere around 2018 to 2020 (my guess). I know that sounds like a strange thing to date precisely, but I’ve been watching the curve.
Before LinkedIn became the platform that ate everything, sourcers lived in Google. We built complex X-ray searches to find candidates across the open web. We knew the quirks of different search engines. We knew how intitle: and inurl: and filetype: worked, and how to use them to surface conference attendee lists and public GitHub repositories and those weirdly useful PDFs that companies would accidentally post to their career pages with full employee directories attached.
LinkedIn absorbed most of that traffic over time. Its own search got better, but it also got more restrictive. Results got capped. Profiles got hidden behind paywalls. The algorithm changed every few months, silently breaking shortcuts that sourcers had spent weeks refining and sharing in private Slack groups.
So we went deeper. More complex strings. More creative combinations. More obscure operators shared in recruiter forums at midnight by people who treated sourcing like a competitive sport. The arms race between sourcers and platforms drove the skill to a genuinely impressive level. I remember a specific search I built in 2021 for a machine learning engineer fluent in Czech. It was twenty-seven operators long. It used nested logic that looked like code. It took me most of an afternoon to build and test. It found exactly the right people.
I also remember thinking, while I was building it: this is fragile. If LinkedIn changes one thing, this breaks.
It did. Three weeks later.
The fragility was always there, but for a long time the skill still mattered enough to justify the investment. If you could write better strings than the recruiter at the next desk, you found candidates they missed. You filled reqs faster. Hiring managers noticed. That visibility translated into career capital in a way that was real and not imaginary.
And then it stopped mattering, almost all at once.
What I found when I ran the experiment myself
A week after I watched the junior sourcer, I ran a test I probably should have run months earlier.
I pulled five old sourcing briefs from my own history. Real searches I’d done over the past few years, across different role types and locations. I gave each one to an AI model with a single instruction: generate a Boolean search string to find candidates matching this profile.
Every result was functionally equivalent to what I’d built manually. In two cases the AI included operators I hadn’t thought to use. In one case it suggested a niche developer community I’d been using as a source for about a year but hadn’t shared publicly, which was either reassuring or slightly unsettling depending on how you look at it.
The quality wasn’t the surprising part. I’d been testing AI for sourcing tasks for over three years. I knew it could do this. What surprised me was the gap in time. My original searches had taken between twenty minutes and two hours each. The AI completed all five in under three minutes total.
That’s not a marginal improvement. A 10x speed improvement in a task is a big deal. A 50x improvement is a different kind of thing entirely. At some point the math stops being about efficiency and starts being about whether the skill itself still carries value.
There’s research on automation and skill atrophy, mostly in aviation contexts, showing that when pilots hand off tasks to autopilot systems for extended periods, their manual proficiency degrades faster than anyone expected. The researchers expected gradual erosion. What they found looked more like a step-change.
The finding has been replicated in surgical robotics and process control contexts since then. The pattern is consistent enough that I take it seriously: when a tool does something reliably, the human stops practicing that thing, and the proficiency drops faster than the person realizes.
I’m not sure that applies cleanly here. Boolean mastery isn’t like landing a plane manually. The stakes are lower. But the question of what happens to a skill once it’s automated isn’t just about performance, it’s about whether it’s worth maintaining at all. And I’ve spent some time sitting with that question uncomfortably.
Let’s Talk About the Elephant in the Room
For years, Boolean expertise wasn’t just a skill. It was an identity. It was the credential that separated “real sourcers” from people who just posted jobs and waited. It was what you pointed to when someone questioned your value. It was the craft you defended when vendors claimed their tool could replace you.
The sourcing community built culture around this. Conference talks. Certification tracks. Blog posts deconstructing advanced operators. A whole world of knowledge that assumed search syntax mastery was the foundation of the profession.
That world is now selling a skill that has been commoditized. And the people who built their professional identity around it are facing something harder than learning a new tool. They’re facing the loss of a professional identity they spent years building.
I’ve watched this play out in conversations over the past twelve months or so. Some experienced sourcers are in denial: AI can’t handle complex multi-source searches, the strings aren’t really that good, you need expertise to evaluate the output. The first two are false. The third is true but not in the way they mean it.
Some are doubling down. Going deeper into syntax. Learning more obscure operators. Betting that if they get advanced enough, the AI won’t catch up. It’s a bet I wouldn’t take. These models don’t get tired. They don’t forget operators. They update every few months and the updates almost always improve performance on exactly this kind of structured task.
Boolean string construction is the first recruitment skill to be genuinely automated by AI, but it won’t be the last. What’s happening now to search syntax will happen to other technical recruiting skills over the next few years. The question isn’t whether you can hold on to the old skill. The question is whether you can build the new one before the old one stops mattering.
I don’t know which skill comes next, for the record. I have guesses, but I’m not confident enough to make a prediction I’d stand behind. Anyone who tells you they know the exact order in which recruiting tasks will be automated is selling you something.
Problem definition is harder than it sounds
So what do you build instead?
Not prompt engineering. Anyone can write a prompt. The skill that actually replaces Boolean mastery is problem definition, and it’s harder to learn because there’s no syntax to memorize.
A junior sourcer can ask an AI: find me senior Python developers in Berlin. The AI returns a string. The string works. The results are generic, because the prompt was generic. The AI doesn’t know that “senior Python developer” means something completely different at a startup rebuilding its data infrastructure versus a bank modernizing legacy systems.
It doesn’t know that this specific hiring manager considers open-source contributions more meaningful than years of experience. It doesn’t know that the last two engineers hired into this role came from gaming companies and both thrived, or that the three who didn’t came from consulting and none of them lasted. The AI only knows what you tell it.
The sourcer who defined the problem well before writing a single prompt gets dramatically better results.
Defining the problem means translating a vague hiring manager brief into specific, searchable attributes. It means identifying which criteria are real requirements versus wishlist items, which happens through conversation, not documentation. It means knowing which signals in a candidate profile actually predict success for this role and which are noise. And it means having the kind of relationship with a hiring manager where they’ll tell you the real requirements, not just the ones on the job description.
That last part is the actual skill gap I see in most sourcing teams, and it existed before AI. Boolean mastery was, in some ways, a convenient substitute. If you could find candidates through technical precision, you didn’t have to be as good at the intake conversation. Now the technical precision is automated, and the intake conversation matters more than it ever did.
I’ve been trying to get better at intake conversations for years, and I’m still not on the top level I want to be. But it turns out that getting a hiring manager to articulate the hidden criteria for a role requires a kind of structured curiosity that doesn’t come naturally to people who got into sourcing because they were good at research. I’m including myself in that.
The second piece, result evaluation, is related. When you wrote Boolean yourself, you understood why each component was there. You could look at a set of mediocre results and know which term was introducing noise. You could iterate with intention. When an AI generates the string, you lose that transparency unless you deliberately maintain it. You have to look at results against a clear picture of what good looks like, then translate your assessment back into a better prompt. It’s a different skill. It’s closer to managing a junior team member than to writing code.
Neither of these is as learnable from a blog post as Boolean was. They compound over time in a way that syntax never quite did, because the contextual knowledge you build about specific roles, specific talent markets, specific hiring managers becomes more valuable the longer you stay in those domains. A sourcer who’s been hiring data engineers in Prague for four years understands something about that talent pool that an AI genuinely doesn’t have.
Whether that knowledge can translate into better sourcing output when working with AI tools is what I’m trying to figure out. The answer is yes in my experience, but I don’t have clean data on it, and I’d be skeptical of anyone who does.
Why this might actually be fine
I’ve been doing this long enough to know how these articles land. Some of you reading this feel validated. Some feel attacked. Some are already using AI for sourcing and wondering what took so long.
Let me make a case that’s easy to miss: Boolean mastery was a gatekeeping skill. It kept people out of the profession who could have been excellent sourcers but didn’t have the patience for operator syntax. It created a hierarchy where time spent memorizing search logic mattered more than understanding talent markets. It rewarded a narrow kind of technical precision over the judgment calls that actually determine whether a hire works out.
The skill set that replaces it is harder to develop but more durable. Problem definition doesn’t become obsolete when a platform changes its search algorithm. Result evaluation doesn’t get automated by the next model release. The contextual knowledge of a talent market doesn’t expire overnight.
There’s a question I keep not answering here, which is whether sourcing as a distinct function survives at all. Not sourcing skills, the actual job category. If AI can generate the search, run the search, and screen the first round of results, what does the sourcer do? I’ve thought about this a lot and I don’t have a clean answer. I think the job changes shape more than it disappears, but I’ve been wrong about technology timelines before and I’m not going to pretend I know how this plays out.
If you need somewhere to start this week: take one open role and write down what you actually know about what makes a candidate succeed in that specific context. Not the job description requirements. The real ones. The things you learned from previous hires that worked and previous hires that didn’t. Then write a prompt using that context, not just the job title and location. See what happens to the results.
The Boolean is still there, under the hood. The AI generates it now. The craft is deciding what to ask for.
The Prompts I Actually Use (And Where They Break)
Below is the system I’ve landed on after some time of testing. Not a complete guide and super advanced prompts. But these three templates I use repeatedly, an iteration checklist I run when results disappoint, and an honest note about which model does what as of this writing.