Vassilis Poursalidis, TalentLMS Engineering Director
Vassilis has nearly 20 years of experience working in diverse projects in the technology industry, with a strong record of leadership and technical expertise. He is currently an Engineering Director …

Feature flags sound simple: check a boolean, branch on it. But the moment you adopt them at any real scale, your production environment depends on an external service for something that sits on nearly every request path. The API is trivial, isEnabled('some-flag'), but the operational reality behind that single call is not. The provider is a network dependency. It can be slow. It can be unreachable. It can go down entirely. And when it does, your feature flag check, a piece of infrastructure meant to make your releases safer, can become the thing that takes the entire service down.

This effort started with a decision that had nothing to do with flags: we are moving to trunk-based development. Merging to main continuously, without long-lived feature branches, only works if you have a way to ship unfinished or risky code dark; and be able turn it on, separately from the deployment. That’s what feature flags are for, but “we need feature flags” doesn’t tell you which flag system to build on, and we didn’t want to build one ourselves or lock ourselves into a single vendor’s SDK. Both of those turn out to hinge on who owns a flag, which is a section of its own below. (That move to trunk-based development is its own story, and one we’ll get into in a follow-up post.)

That’s what led us to OpenFeature : a vendor neutral, open standard for flag evaluation, backed by the CNCF rather than any one provider. It solves the part we didn’t want to solve ourselves: a common interface regardless of which flag backend sits behind it. But adopting the standard didn’t answer the questions that came right after: do we inject it instead of reaching for a global? What happens to our checkout flow if the flag provider is slow? And, most importantly, how do we test the failure case?

Flipster is our answer to those three questions, written at the start of adopting OpenFeature and trunk-based development together, not after years of running either.

There’s a second thing worth naming: Flipster is a product of Spec-Driven Development , a practice we have been running internally for over a year now. This wasn’t us trying it out for the first time; it was the discipline showing up in a public artifact. We wrote the specification (the behavior table shown below, the guarantees around defaults, the failure semantics) before implementation, and let the spec drive what got built. The .aidlc directory in the repo is a visible trace of that process. It’s part of why the README reads the way it does: the behavior was decided on paper first, which made it possible to be precise about things like “an evaluation never throws because a provider is unwell” instead of discovering that guarantee informally over time.

Two owners, one switch

A feature flag has two lifecycles: Ownership of the flag and ownership of its exposure. Each of them belong to different people.

Engineering owns the flag. We introduce it when the work starts; we are responsible for the code on both sides of it, and more importantly we are responsible for removing it. A flag that outlives its purpose is a permanent branch in the code: a small compounding tax on every change that touches it.

Product owns the exposure. When the feature gets activated, for which accounts, in what order, whether it widens or gets pulled back. None of those are engineering calls, and none of them should consume engineering capacity. We used to be involved because the deployment was controlling the flags and the deployment was ours.

Separating those two concerns is what removes this unnecessary link. Engineering decides whether the switch exists and when it stops existing. Product decides in which state it is and for whom. Neither has to negotiate with the other’s calendar to do its own job.

Both owners have to be in the room for the build-versus-buy question. A flag system that satisfies only engineering is a weekend’s work and useless the first time product wants to widen a rollout without filing a ticket. One that satisfies only product gets picked on the demo, and nobody asks whether it speaks OpenFeature until its SDK is already at every call site. Both halves have to be answered by the same decision, which is most of why we neither wrote our own nor shopped on features alone.

The same pair is the reason the switch has to survive a change of provider. Whatever backend we run today, those two lifecycles outlive it: engineering will still introduce and remove flags, product will still decide exposure and timing. Neither of those should have to be renegotiated because we moved to a different vendor. That is the practical argument for a neutral API rather than a vendor’s SDK; a provider swap stays a swap, instead of turning into a conversation about who owns what.

Three problems, one library

Once flags are owned this way, the surrounding tooling has to earn that trust.

Problem one: the SDK wants to be a singleton

OpenFeature’s idiomatic entry point is a process global. That’s a reasonable default for the SDK itself, but it’s an awkward fit for any codebase that takes dependency injection seriously. Global state resists testing, resists swapping implementations per environment, and quietly couples your domain code to a specific initialization order.

Flipster’s fix here is almost boring: it wraps the SDK behind a narrow interface you inject like anything else. Domain code depends on a FlagEvaluator, not on a global. That’s it. It’s not a clever abstraction, it’s the absence of one.

Problem two: a flag check is a network call on your hot path

This is the one that actually hurts in production. A flag provider is, almost always, a service you talk to over the network. Every isEnabled() call is a request that can be slow or can fail, and if that call sits in a hot path (say, checkout, or auth), a degraded flag provider can degrade everything downstream of it. Even though the flag itself was never the point of the request.

The standard answer to “a dependency might be slow or down” is a circuit breaker, and that’s what Flipster puts in front of the provider. Flipster doesn’t implement its own breaker logic, it defines a small port and ships an adapter over the existing Ganesha library, so you get a proven implementation rather than a bespoke one.

But the breaker alone isn’t the interesting part. The interesting part is what happens before the breaker even trips, because a single failed request and a fully open circuit are different situations, and conflating them is where a lot of flag handling code goes wrong.

In fact, they need different responses. One failed evaluation should be absorbed on the spot: you serve something sensible and carry on, because a provider that hiccups once is still a provider. An open circuit is a different claim entirely, that this provider is known to be unwell, and the right response is to stop calling it at all. Flipster does both and in that order. The declared default answers each individual failure the moment it happens, and the breaker, once tripped, stops the wasted network attempts. Watch a real provider get killed underneath it and you see the defaults start appearing several requests before the circuit actually opens.

Problem three: defaults that disagree, and failure paths nobody can test

Here’s the pattern we wanted to avoid before it ever had the chance to happen: a feature flag call with a fallback value passed at the call site (getBooleanValue('new-checkout', false)), repeated at a few more call sites, each with its own guess at the right default. A few months later, nobody remembers which fallback is the ‘official’ one, and nobody has a reliable way to force the provider into a degraded state to check what actually happens. We hadn’t lived through that yet, we just didn’t want to build it that way in the first place.

Flipster addresses this with a single idea: declare defaults once, separately from call sites. withDefaults() is the one place in your codebase a flag’s fallback value lives. Call sites don’t carry a default; they can’t disagree with each other, because there’s nothing to disagree about.

That makes withDefaults() more than a fallback map. It is the list of flags your code is allowed to ask about at all: a flag missing from it throws even when the provider is perfectly healthy and would have answered. Adopting Flipster means accepting that every flag gets declared, not just the ones you expect to fail.

This produces a small but deliberate behavior table:

The middle two rows are the distinction from the previous section, written down. An error while the circuit is still closed costs a full round trip and then falls back; an open circuit skips the call altogether. Same value served, different amount of your request budget spent getting there.

That last row is the one people notice first, and argue about. Flipster intentionally does not let an undeclared flag silently evaluate to false. A typo’d flag key that quietly reads as “feature disabled” is indistinguishable from a feature someone deliberately turned off, and nobody investigates a flag that looks correctly configured. So it throws, with a message that suggests the key you probably meant. Declarations are also validated when the stack is built, not at first use, so a malformed defaults map fails during deployment instead of surprising someone during an incident.

And because failure behavior is now fully deterministic (a declared default, injected doubles, a controllable breaker), the failure paths become ordinarily testable, instead of the kind of thing you only find out about in production. That determinism is easier to see than to describe. The diagram below traces a single isEnabled() call through both checks: whether the flag is declared, and whether the circuit is open; and shows exactly which of the four rows in the table above it lands on.

That determinism only helps if you can actually exercise it in a test, so Flipster ships its own test doubles in the runtime package, no extra dependency to pull in. An InMemoryProvider stands in for a real backend, a RecordingProvider wraps any provider and tracks how many times it was actually called, a ThrowingProvider simulates a hard failure, and a ControllableCircuitBreaker lets a test pin the circuit open directly instead of trying to manufacture enough failing requests to trip a real threshold. That last one matters more than it sounds: without it, “test what happens when the circuit is open” means fighting your breaker’s timing and thresholds just to get into the state you actually wanted to assert on.

Put together, all three fixes are one builder call at the edge of the application and an injected dependency everywhere else:

use Epignosis\Flipster\Flipster;

$flags = Flipster::for($provider)          // any OpenFeature provider
    ->withDefaults([
        'new-checkout'     => false,
        'checkout-variant' => 'control',
        'rate-limit-rpm'   => 100,
    ])
    ->withBreaker($breaker, 'flags')
    ->evaluator();

// Domain code depends on FlagEvaluator, and on nothing else.
if ($flags->isEnabled('new-checkout')) {
    // ...
}

Note what the call site does not contain: a default value, a try/catch, or any hint that a network is involved.

What we deliberately left out

Flipster does not cache. That was a conscious decision, not an oversight: the provider you choose already owns the flag data’s lifecycle and its invalidation signals, and a cache bolted on from the outside can only guess at correctness with a TTL. Caching is a job for the layer that actually knows when the data changed.

We also didn’t build another flag evaluation API. Flipster composes with OpenFeature; it doesn’t compete with it. If you want per-call defaults instead of the declared-once model, the underlying OpenFeature client is still right there.

The shape of the fix

None of these three problems are novel, and none of the fixes are exotic: DI over globals, a circuit breaker over a flaky dependency, single sourced defaults over scattered ones. That’s sort of the point. This is early. Flipster is new, born directly out of adopting trunk-based development and OpenFeature together, and built the way we build everything now, spec first. We’d rather get this resilience layer right once, in the open, before we’ve written “make the flag provider safe to depend on” glue code in five different places and had to reconcile it later.

The quick facts:

• 344 tests, 654 assertions, 99+% coverage: the failure paths are covered, not just the happy one
• MIT licensed, and public because none of the problems it solves are specific to us
• Batteries included: a containerized toolchain where Docker is the only prerequisite, CI across PHP 8.1 through 8.5, runnable examples, and documentation that covers the traps rather than just the API

Flipster is on GitHub at epignosis/flipster , MIT licensed, and installable via Composer:

composer require epignosis/flipster

If you’re already on OpenFeature and just want the resilience layer without adopting anything else, docs/migrating.md in the repo walks through adopting it incrementally in a codebase that’s already using the SDK directly.

Vassilis Poursalidis, TalentLMS Engineering Director
Vassilis has nearly 20 years of experience working in diverse projects in the technology industry, with a strong record of leadership and technical expertise. He is currently an Engineering Director …

Engineering organizations usually notice scaling problems in obvious places first: infrastructure, delivery, communication, coordination. Hiring processes rarely make that list. At least not initially.

For a long time, our hiring process seemed to work reasonably well. Candidates received a take-home assignment, submitted their solution, and we reviewed it internally before moving to follow-up discussions. It was a familiar setup, widely used across the industry, and it produced decent hiring outcomes: hires we felt good about, at a pace that felt manageable.

But over time, we realized we had been too focused on running the process instead of stopping to question it. The problem was the operational cost and fragility of the process itself; the reviewer fatigue, the inconsistency that crept in when people were stretched thin, and the brittleness of a process that depended on too few hands.

What started as a discussion about replacing take-home assignments with live coding eventually became something much bigger:

How do you redesign a process so ownership can scale beyond a small number of people?

This article is not really about live coding versus take-home assignments. It is about simplifying an important engineering process so it becomes teachable, repeatable, scalable, and collectively owned by the team.

What Running the Process Taught Us

We did not sit down one day and decide to redesign our hiring process. The realization came gradually, built up through the friction of running it: patterns we kept noticing, problems we kept deferring, and questions we kept asking ourselves after every hiring cycle. Eventually we had accumulated enough signal that the direction was clear.

The Process We Inherited

When new people became involved in hiring, the onboarding material was essentially the assignment PDF itself. The mechanics were undocumented. The decision-making even more so. The real evaluation criteria lived in the heads of the people already running the interviews, built up through shadowing discussions, reviewing past submissions, and years of accumulated intuition.

That worked while only a few people were deeply involved. But it created a fragile dependency. Understanding what trade-offs mattered, which shortcuts were acceptable, what architectural decisions were red flags, and how to distinguish strong engineering from polished presentation - none of that was captured in any scalable way. What started as an onboarding inconvenience eventually became a structural bottleneck.

The Hidden Cost of the Process

The workflow looked simple on paper: send the assignment, wait for the submission, review the solution, schedule a follow-up, decide. In practice it was significantly more complicated. Solutions required lengthy internal discussions. Different reviewers focused on different aspects. Calibration took time. The process generated substantial asynchronous overhead, and because it depended on a small number of experienced people, progress bottlenecked around availability. We even began using AI to help review submissions, but it reduced the load without changing the underlying problem.

The result was a hiring cycle that could easily stretch close to a month. Internally, it consumed considerable senior engineering bandwidth. Externally, it created a poor candidate experience. Candidates frequently told us the assignment was too large, and many requested extensions just to complete it. Also strong candidates rarely pause their search while waiting for us to finish our internal discussions, and in a competitive hiring environment, long feedback loops mean losing good people before the process is even over.

AI Started Shifting the Ground

Around the same time, another shift was becoming harder to ignore. AI-assisted coding changed the nature of take-home assignments. Not because candidates were doing something wrong, and not because we discourage AI. We actively promote its use. The problem was that the format increasingly optimized for polished output rather than observable thinking. We found ourselves spending more time validating depth of understanding than discussing engineering decisions.

Some submissions looked exceptionally strong, but follow-up conversations revealed significant gaps. In one case, a candidate declined to share their screen while walking us through their solution, making it difficult to assess how familiar they actually were with the code they had submitted. The assignment no longer evaluated engineering capability alone. It now required us to separately evaluate authorship confidence and depth, and the process became heavier precisely when we needed it to become lighter.

We Were Evaluating the Wrong Things

As we re-examined the process, another realization we had been slow to confront emerged. The assignment required substantial boilerplate and project setup work just to bootstrap a solution. Those are genuine engineering skills. But we had to ask ourselves: how representative was this of the work engineers actually do in our organization?

We are a product-oriented company. Our engineers spend most of their time evolving existing systems, reasoning about trade-offs, debugging production issues, and iterating on long-lived codebases. They rarely bootstrap entirely new projects from scratch. Over time we recognized that our interview process had been rewarding greenfield setup efficiency rather than collaborative product engineering.

The Real Bottleneck Was Ownership

At this point, the conversation stopped being about interview formats. The real issue was organizational scalability. Only a small number of people could confidently evaluate submissions. The process depended on context and reviewer experience that were difficult to transfer. Scaling hiring meant scaling dependency on the same individuals.

That led us to a broader realization: complexity naturally concentrates ownership. We were not simply trying to improve interviews. We were trying to distribute decision-making across the engineering organization. But delegation becomes extremely difficult when a process is ambiguous, context-heavy, cognitively expensive, and dependent on intuition that is hard to teach. We could not scale ownership of a process that only a few people knew how to execute consistently. That became the real problem to solve.

From Problem to Process

Once we framed the problem correctly, our goals became much clearer: reduce the hiring cycle from close to a month to a few days or a week, reduce coordination overhead, make interviewer onboarding easier, improve evaluation consistency, and create a process that reflected our actual engineering reality. These were not small adjustments. They pointed toward a fundamentally different kind of process. That is where live coding entered the discussion.

We chose live coding not because it is universally superior or because take-home assignments are inherently flawed, but because it aligned better with the constraints we were trying to solve. The biggest advantage was not speed. It was shared context. Instead of reviewing a polished artifact asynchronously, interviewers and candidates collaborate in real time. We observe problem decomposition, communication, trade-off reasoning, and adaptability. The signal is more immediate and easier to calibrate across interviewers.

Switching to live coding was only part of the work. The other part was building a process rigorous enough to be distributed. We developed a full playbook covering both technical and communication dimensions of evaluation. Assignments come with boilerplate already in place, and we maintain a pool of exercises calibrated to each seniority level. Interviewers work from a structured scorecard, a feedback form helps us measure how the process is performing over time, and guidance is available for anyone running interviews for the first time. The process is aligned with HR so handoffs are clean. What used to live in the heads of a few people is now embedded in the process itself.

The deeper lesson from this experience had very little to do with hiring specifically. Delegation is rarely blocked by willingness. More often it is blocked by ambiguity. Organizations frequently try to distribute ownership without first simplifying the underlying process, then wonder why only a small number of people can operate it effectively. A process becomes scalable when expectations are explicit, onboarding is teachable, and cognitive overhead is reduced. Simplification is not about removing rigor. It is about removing unnecessary operational friction.

The most obvious improvement was speed, but the more important improvement was organizational. Hiring is no longer the responsibility of a small group. It is a capability owned by the team. Eight additional engineers are now actively involved in the process, and that number continues to grow. Even the steering of the process itself has been handed to the team. That is the real outcome we were aiming for.

Trade-offs Still Exist

None of this means live coding is without limitations. Some candidates perform better in asynchronous environments, interview stress is real, and calibration and interviewer training still matter. To ease some of that pressure, we recently started sharing the repository a day in advance. Not the assignment itself, which remains a surprise, but enough context for candidates to familiarize themselves with the codebase before the session begins. We also encounter practical friction that is harder to control. Candidates occasionally ghost scheduled sessions, which introduces its own scheduling overhead. We are still learning and adjusting as we go.

Final Thoughts

This journey started as a discussion about replacing take-home assignments. It ended as a lesson about scalability, delegation, and organizational design. As engineering organizations grow, the challenge is not only building better systems. It is building processes that can be collectively owned. That often requires simplifying things that previously depended on experience, intuition, and hidden context. Because sustainable organizations are not built around a few people carrying critical processes indefinitely. They are built when important work becomes teachable, repeatable, and distributed across the team.

Vassilis Poursalidis, TalentLMS Engineering Director
Vassilis has nearly 20 years of experience working in diverse projects in the technology industry, with a strong record of leadership and technical expertise. He is currently an Engineering Director …

Almost everyone has experienced it: the relentless stream of LinkedIn connection requests, the “just following up” emails, the messages that start with “Hey Vassilis!” as if you’re old friends. Some are merely persistent. Others cross into territory that feels manipulative, even offensive.

For years, I sat on the receiving end of these approaches, treating them as little more than background noise. My strategy was simple: ignore and move on. I viewed these messages as a byproduct of having an online presence; annoying, but harmless. However, lately, the tactics have shifted. I began seeing patterns that moved beyond mere persistence and into calculated manipulation. The uncomfortable truth? They work. And they work often enough to justify their continued use.

This crossing of the threshold (from annoying, to deceptive) is what finally prompted me to speak up. It is one thing to be sold to; it is another to be engineered. Let’s dissect the mechanics of these modern B2B playbooks, why they persist despite the friction they cause, and what this evolution reveals about the current and future state of sales.

The Standard Playbooks

The Multi-Touch Sequence

This is sales 101: contact a prospect across multiple channels over 2-3 weeks. The pattern is based on the widely-cited statistic that it takes 7-8 “touches” to get a response from a cold prospect. The persistence isn’t personal, it’s systematic.

The Value-First Approach

Rather than leading with a pitch, they offer something first: a relevant article, an invitation to a webinar, a whitepaper, or benchmark report. By “providing value” upfront, they create a subtle obligation and establish themselves as a helpful resource rather than just another vendor. The ask comes later, after you’ve presumably been warmed up by their generosity.

The Problem-Aware Template

These messages reference specific pain points supposedly common to software engineering departments at companies like yours:

I noticed companies like [company name] often struggle with scaling engineering teams / managing technical debt / attracting senior talent…

Here’s the thing: they’re using industry generalizations rather than researching your actual situation.

The Social Proof Play

We work with [competitor or similar product], and they’ve seen a 40% improvement in deployment velocity.

This simultaneously creates legitimacy (if our competitors use them, maybe we should) and Fear Of Missing Out - FOMO (are we falling behind?). Sometimes the social proof is genuine. But most of the time they’re cherry-picked, exaggerated, or strategically vague.

The Trigger Event Approach

These reps are monitoring your company for signals: funding announcements, job postings for senior engineers, product launches, conference appearances. They time their outreach for moments when you might actually need their solution. You may think this is actually one of the more legitimate approaches (at least they’re doing their homework!), but it still means your company’s activities and your own personal activities are being fed into sales automation systems across dozens of vendors.

Other Common Approaches

Beyond these core playbooks, you’ll encounter several other variations:

• The “Breakup” Email: After no response, they send a final message - “I’ll assume this isn’t a priority and remove you from my list” - designed to trigger guilt.
• The “Quick Question” Hook: Messages with sentences suggesting a brief ask when it’s actually a full sales pitch waiting on the other side.
• The Survey/Research Request: “We’re conducting research on engineering leadership”, but the research mysteriously reveals you need their offering.
• The Comparison/Audit Offer: “Free assessment” of your current infrastructure, that’s really just sales qualification disguised as service.
• The Latest Hype Integration Play: “Your customers are demanding AI features”, the latest hype cycle where every vendor suddenly has an AI solution that will help you add intelligence to your product.

And of course countless other baiting techniques are waiting for you out there.

When Playbooks Turn Manipulative

The tactics above are standard, perhaps even acceptable. But there’s a darker set of approaches that cross ethical lines.

The Escalation Ladder: From Polite to Aggressive

Watch as the tone shifts across this sequence:

• Touches 1-2: Friendly, helpful tone. “I’d love to show you how we’re helping companies like yours…”
• Touches 3-4: Mild pressure. “Just circling back on my previous message…”
• Touches 5-6: Guilt or challenge. “I haven’t heard back - is this not a priority for you right now?”
• Touches 7+: Aggressive ultimatum. “Should I assume you’re not the right person?” or “Can I close your file?”

The psychology is deliberate: create urgency or trigger a response through discomfort. Some Sales Development Reps (SDRs) are explicitly taught that a “no” is better than silence, because it’s a response they can log and report to their manager.

The Gatekeeper Bypass

You respond to a cold outreach stating that you are not the right person, or perhaps you choose not to respond at all. Instead of accepting this boundary, they counter: “I understand - who should I speak with instead?” or “Would you mind introducing me to the person who handles this?”

Think about the audacity here. You have clearly indicated a lack of interest or relevance, yet their response is to dismiss your boundary and deputize you into their sales force. By asking for a direct introduction or a colleague’s contact details, they are asking you to compromise your internal network for their commercial gain.

In any other context, providing internal contact paths to an unverified external actor would be flagged as a security risk. In sales, it’s framed as “helpfulness.” You should not, under any circumstances, provide the details of your colleagues to a cold caller. If you genuinely believe an offering has merit, you may choose to discuss this internally with your company and then decide how to proceed.

Manufactured Intimacy

Messages that open with “Hey [First Name]!” and casual language as if you’re already acquainted. Or worse: “We’re delighted to have met you at [conference name]!” when you’ve never communicated at all.

They’re trained to write as if they’re continuing an existing relationship rather than initiating a cold contact. It’s deliberately deceptive, designed to bypass your mental filters for unsolicited sales approaches.

Identity-Based Manipulation: Where It Gets Personal

This is where sales tactics cross from annoying into genuinely offensive territory.

You receive a message that opens with:

• “As a fellow Greek…” (or even worse, written in Greek)
• “I noticed we’re both from [your hometown]…”
• “My family is also from [your region of origin]…”
• Comments about your name’s etymology or ancestral background

This isn’t accidental. This is weaponizing your identity and heritage as a sales tool.

Why is this particularly egregious: It exploits cultural norms around helping “one of your own.” It creates artificial obligation based on shared background. It takes something deeply personal (your heritage, your roots, your identity) and commodifies it for commercial gain.

Some sales trainers actually teach this as “finding common ground” or “building rapport.” But there’s nothing genuine about it. It’s manufacturing false kinship for the explicit purpose of making a sale.

For those of us from smaller ethnic communities or regions, this manipulation is especially invasive. The bonds within these communities are real and meaningful. Using them as a sales tactic is a calculated exploitation of something that is morally wrong.

The Uncomfortable Economics

Here’s the part that’s hard to accept: these tactics work.

Not on you, perhaps. You may be immune or have developed pattern recognition to understand and avoid these approaches. But they work often enough across the broader target audience to justify their continued use.

Those few opportunities can generate enough potential revenue to make the entire campaign “successful.” The remaining 99+% who were spammed or offended simply don’t matter in this calculation, because as it turns out the ends justify the means. Let that sink in for a bit.

Who Responds to These Tactics?

They’re effective with:

• Less experienced engineers who haven’t yet developed pattern recognition for sales approaches
• People-pleasers who feel guilty not responding or uncomfortable refusing to help
• Those from cultures with strong in-group obligations (the ethnicity/ancestry play specifically targets this)
• Those who think that responding will just make it stop (personally, if I have not subscribed to a newsletter, I will not even hit unsubscribe as this is a signal for them that someone is listening)
• People who haven’t learned to set firm boundaries with cold outreach

The Race to the Bottom

The companies that use manipulative tactics have optimized for conversion rate, not reputation. They’ve calculated that:

• Burning bridges with 99% of prospects is acceptable collateral damage
• Offending people doesn’t hurt them (those people weren’t going to buy anyway, goes the logic)
• The people who respond don’t seem to care about the tactics used

It’s the same economic model as spam email or robocalls. A tiny success rate justifies a massive negative impression on everyone else.

And here’s the meta problem: this creates a race to the bottom. Companies see competitors using aggressive tactics and getting results, so they adopt them too. Sales leaders promote SDRs who hit quota using these methods, reinforcing them as “best practices.” The system perpetuates itself.

The Opportunity Cost: What You’re Not Getting

Here’s something that makes these tactics even more frustrating: in theory, sales conversations could be valuable learning opportunities. A good salesperson understands their market deeply. They talk to dozens of engineers every week. They see patterns across companies, industries, and use cases. They could offer genuine insights about what your peers are struggling with, what solutions are actually working, and what emerging challenges you should be thinking about.

But that’s not what happens with these playbook-driven approaches. The conversation is extractive, not collaborative. They’re mining you for information (budget size, decision timeline, pain points they can exploit) while offering nothing substantive in return. The entire interaction is optimized for moving you through their sales funnel, not for mutual value exchange. Also be vigilant with what information you are allowed to share about your company.

This is the real tragedy of modern sales playbooks: they’ve eliminated the possibility of unexpected learning. You might engage with a cold outreach hoping to discover something new about your market, a technology, or an approach you hadn’t considered. Almost universally, you come away with nothing but time wasted.

Now imagine an interaction where someone reaches out with genuine domain expertise and offers real insights before asking for anything. Not vague numbers, but the actual facts of what the value proposition is. Would you remember them years later?

What This Means for You

First, recognize that you’re the target of an industrial process. Sales development is now heavily automated, data-driven, and optimized. The personalization you see is often manufactured at scale. The commonalities they mention are frequently mined from your LinkedIn profile by automation tools.

Second, understand that your response (or lack thereof) is a data point in their system. They’re iterating on what works. Every A/B test, every message variation, every new manipulation tactic exists because somewhere, at some point, it outperformed the alternative.

Third, accept that the vast majority of these interactions will offer you nothing of value. You’re not missing out by ignoring them. The chance that you’ll learn something genuinely useful is vanishingly small; not because the products are necessarily bad, but because the sales process is designed for extraction, not education.

Fourth, and most importantly: you owe these cold outreach attempts nothing. No response, no explanation, no referral to a colleague. The manufactured intimacy is not real. The shared heritage angle is exploitation, not community. The aggressive follow-ups after you’ve said no are not deserving of guilt.

Your attention and your network are valuable. Protect them accordingly and follow up only if you are genuinely interested in their offering.

A Better Way Forward?

For sales professionals reading this: I understand you have quotas. I understand the pressure you’re under. But consider what you’re optimizing for. Your help is needed to fix this broken system.

The manipulative tactics I’ve described may generate short-term results, but they’re burning long-term trust not just to your company but for all B2B outreach. They’re training an entire generation of software engineers to automatically dismiss and block sales outreach. They’re making it harder for every company out there to get through the noise.

There is a better approach: do real research, reach out with genuine specificity, respect boundaries when set, and build actual relationships rather than manufactured ones. It’s slower. It doesn’t scale as well. But it works with the prospects who matter most, the true potential buyers with real budgets and real problems.

For engineering fellows: share your experiences. When a vendor uses manipulative tactics, tell your network. When someone reaches out with genuine value and respect for your time, remember them and speak about their company. We can collectively shape what “best practices” look like by rewarding the behavior we want to see. And remember, those tactics are mostly executed by companies with products and services that do not speak for themselves.

The current system works because we allow it to. We can choose differently.

Vassilis Poursalidis, TalentLMS Engineering Director
Vassilis has nearly 20 years of experience working in diverse projects in the technology industry, with a strong record of leadership and technical expertise. He is currently an Engineering Director …

Long gone are the days when a developer will walk across the entire stack. For years, software development has been moving toward specialization. We’ve carved ourselves into distinct tribes: infrastructure engineers who live in YAML and Terraform, architects who sketch systems in boxes and make decisions in ADRs, backend developers who speak in APIs and databases, frontend developers who breathe JavaScript and CSS, and QA engineers who guard the gates of production.

This specialization brought expertise. But it also brought something else: gaps.

The Gaps Between the Silos

These gaps are where projects slow down. They’re in the handoffs, the assumptions, the translation layers between team members and teams. They’re in the backend developer who builds an API without considering how the frontend will consume it. The infrastructure engineer who provisions resources without understanding the application’s actual needs. The QA engineer who writes tests disconnected from how the code actually behaves.

Each handoff is a game of broken telephone. Each specialized role is a potential bottleneck.

Enter Agentic Coding

This is where agentic coding becomes transformative, not as a way to create the mythical 10x developer, but as a way to bridge these gaps. AI-assisted development tools enable a different kind of developer: the full-stack generalist who can move fluidly across the entire stack.

Not because they’re superhuman, but because they have assistance.

The Bridge Builder, Not the Specialist

With agentic coding tools, a single developer can:

• Provision the infrastructure layer: spinning up containers, configuring cloud resources, setting up CI/CD pipelines; not as an infrastructure specialist, but as someone who understands enough to make informed decisions with AI assistance filling the knowledge gaps.
• Design coherent architecture: mapping out system boundaries, considering scalability and maintainability, with AI helping validate approaches and spot potential issues.
• Build backend services: implementing business logic, designing database schemas, creating APIs; with AI suggesting patterns, catching edge cases, and writing boilerplate.
• Craft frontend experiences: building interfaces that actually work with the backend they just created, because there’s no translation layer, no assumptions, just continuity.
• Think like QA: writing tests at every layer, shifting testing left (earlier in the development cycle) as much as possible, because they understand the full context of what could break and why.

Importantly, these bridge builders don’t vibe code and don’t work in isolation. They carefully review what AI suggests and always improve how they use those tools. They’re also supported by a network of evangelists, senior staff members, and domain experts who provide guidance, review architectural decisions, and help navigate complex technical challenges. The difference is that with AI assistance, these senior voices can focus on high-level guidance and strategic direction rather than being pulled into every implementation detail. The generalist can execute across the stack with AI handling the tactical work, while leaning on experienced colleagues for wisdom about patterns, pitfalls, and best practices that only years of experience can provide.

The Power of Context

The real advantage isn’t speed, it’s context. When the same person (with AI assistance) works across the stack, knowledge doesn’t get lost in translation. The API is designed with the frontend in mind because the same person is considering both. The infrastructure is provisioned based on actual application needs, not assumptions. Tests are written by someone who intimately knows the failure modes and has incorporated the appropriate logic in the development process.

Agentic coding tools make this possible by:

• Keeping you in focus: Instead of spending hours researching unfamiliar territory or waiting for a specialist to become available, developers can move forward immediately with AI assistance that understands the context of what they’re building.
• Providing on-demand expertise: need to write a complex SQL query with proper indexing strategies? Configure a load balancer with health checks and failover logic? Set up CORS policies that balance security and functionality? The developer doesn’t need years of specialization in databases, infrastructure, or security protocols. They need to understand the problem well enough to evaluate the solution, and AI bridges the gap between understanding and implementation.
• Maintaining consistency: when infrastructure configuration, backend logic, frontend implementation, and test suites all flow from the same contextual understanding, the result is a more coherent approach.

What makes this even more powerful is that AI can leverage context from across the entire development process. When building the frontend, the AI can reference the backend implementation you just created (understanding the exact shape of API responses, the error states that might occur, and the validation rules already in place). When writing tests, it knows the actual business logic from the backend and the user interactions from the frontend. When configuring infrastructure, it understands the actual resource needs based on the application code. This contextual awareness means each layer informs and improves the rest, creating solutions that are more coherent and robust than what emerges from siloed development.

Greenfield and Legacy: Two Sides of the Same Coin

For greenfield projects, agentic coding is remarkably effective. AI tools come equipped with knowledge of current best practices across the entire stack: modern framework patterns, security considerations, scalability approaches, testing strategies, and more. Starting from scratch, a developer with AI assistance can bootstrap a properly structured project in hours: infrastructure as code following current standards, a backend with sensible architecture, a frontend using modern patterns, and comprehensive test coverage. The AI doesn’t just generate code; it applies the collective wisdom of thousands of well-architected projects.

But here’s what makes agentic coding truly powerful: it works just as well with existing codebases. AI tools can analyze and understand the patterns, conventions, and architectural decisions already present in a project. They can be tuned to mimic the existing codebase style: the naming conventions, the error handling patterns, the testing approaches, and the architectural boundaries. When you’re adding a new feature to a five-year-old application, the AI doesn’t impose some idealized pattern from its training. It stays aligned with your project’s conventions, making contributions that feel native to the codebase.

This adaptability means the full-stack generalist can be effective whether they’re building something new or extending something that’s been running in production for years.

Not Replacing Specialists

As mentioned earlier, experts who provide guidance remain important. Deep expertise still matters. But it’s about recognizing that many projects don’t need ten specialists (they need many well-rounded developers who can bridge the gaps with AI assistance).

For startups, small teams, and rapid prototyping, this is transformative. For larger organizations, it’s about creating developers who can work across team boundaries, who can understand and contribute to multiple layers, who can see the whole system rather than just their piece.

Don’t get me wrong, I do not advocate that we need less specialists or less developers. On the contrary, I advocate to allow specialists to do more meaningful work and to give developers new powers.

The Skills That Matter

The full-stack generalist in the age of agentic coding needs different skills than before:

• Breadth over depth: understanding enough about each layer to ask the right questions, validate AI suggestions, and knowing when to call in specialists.
• Systems thinking: seeing how pieces fit together, understanding trade-offs across the stack.
• Critical evaluation: knowing when AI suggestions make sense and when they don’t.
• Communication: being able to speak the language of different domains, even if not fluent.

In a sense, the most important skills are problem-solving and the ability to communicate with fellow engineers.

The Future Is Bridge Builders

Software development is at an inflection point. Agentic coding tools aren’t creating 10x developers who work faster. They’re creating bridge builders who eliminate the gaps between specialized domains.

This new breed of developers won’t replace specialists. But they’ll change how teams are structured, how quickly products can be built, and how much overhead is lost to handoffs and translation.

The future isn’t about being the best backend developer or the best frontend developer. It’s about being effective across the entire stack; not through years of specialization in each domain, but through intelligent use of AI assistance that makes generalist competence not just possible, but powerful.

The gaps are closing. The bridges are being built. And the developers building them might just change how we think about software development itself.

When you combine all of the above (the elimination of silos, the contextual awareness across layers, the ability to work on both greenfield and legacy projects, the support from senior expertise), with the significant speedup that agentic coding offers, you get compound results.

It’s not just about doing more things; it’s about doing them faster, with better integration, and with higher quality. This convergence is giving rise to what we might call v2.0 of the Full-Stack Developer: someone who leverages AI to move seamlessly across the entire development lifecycle, producing cohesive solutions at a pace that would have seemed impossible just a few years ago. These developers aren’t superhuman, but they are transformative, and they represent the future of how software gets built.