After months of extensive work on a new static code analyzer for Go, our team announces that it’s now ready for public testing. Join the Early Access Program to be among the first to test. Here’s how.

Analyzer for Go?

We’ve written extensively about our Go analyzer in previous posts:

• How to create your own Go static analyzer?
• Go vet can’t go: How PVS-Studio analyzes Go projects
• Does the operator ^ represent exponentiation or exclusion?

We show how to make your own Go analyzer and highlight what kind of errors PVS-Studio can already detect. Today, we’re glad to announce that beta testing registration is open.

Over the past six months, we’ve been actively developing the Go analyzer. Before official release, we’d like to test its stability, performance, and analysis quality on real-world projects. Starting April 6, we’ll run for 3–4 month Early Access Program.

The first version ships with two dozen diagnostic rules, a CLI version of the tool, and a GoLand plugin for seamless running from the IDE. Later, we plan to support Go project analysis in VS Code.

How to join?

To take part in beta testing, fill out the form on our website and provide your email to receive the necessary information. Then select the product you want to test. On April 6, you’ll receive an email with guidelines on how to run the Go analyzer.

If you encounter any issues (errors, crashes, false positives, anything), please let us know through the feedback form.

What about other languages?

Go isn’t the only one joining the party. At the same time, testing will begin for JavaScript, and a month later for TypeScript. More details can be found in a separate note.

And that’s not all! April will also bring the launch of a testing program for PVS-Studio Atlas, our built-in platform for managing analysis results.

Stay tuned for updates!

Subscribe to our newsletter to get the latest news on new analyzers, early access programs, and other PVS-Studio announcements. See you soon!

JetBrains IDEs already offer a variety of AI features to help you with everyday development tasks, from code completion as you type to code generation and explanation in response to prompts or commands. As we continue expanding their AI capabilities, including with more tools and the ability to use third-party agents, we’ve also been exploring something else: AI features that work proactively.

Two experiments in this direction are the recap and insights features. After testing them with a small group of users late last year and receiving encouraging feedback, we’re now making them available as a separate experimental plugin for anyone who wants to try them out.

The new features

Recap: Think of this like a “previously on…” for your codebase. It provides a compact, auto-updating summary of your most recent activities, tracking where you left off, what you were doing, and what changed. It lives in its own tool window and stays out of your way until you call it. If you’ve ever had to spend ten minutes piecing together what you were last working on when you came back from a meeting or long weekend, or even just switched projects, you’ll find the recap to be a valuable resource.

Insights: These are one-line explanations of non-obvious code that you either did not author or have not seen in a while. They highlight blocks that deserve a closer look and explain what they do. The feature is selective by design, focusing on code that’s actually tricky instead of annotating everything. They are currently available only for Python and JVM languages.

Why a separate plugin?

Most AI features in your IDE are reactive – you ask, they respond. The recap and insights features are different. Instead of waiting for prompts, they proactively surface context and add notes to the editor. That’s a fundamentally different interaction model, and the stakes are higher. An incorrect instance of code completion costs you a keystroke. An unwanted feature in your editor depletes your focus and trust – and we take that seriously.

Offering these features in a separate plugin gives you explicit opt-in control and gives us a tighter feedback loop. We believe this is how opinionated AI features should be developed. We should ship them to people who actively want to try them, and then we listen closely and iterate.

How to get started

You can try the new features in JetBrains IDEs starting from version 2026.1 EAP by installing the JetBrains AI Assistant Experimental Features plugin. 

An active JetBrains AI Pro or Ultimate subscription is required. Both features use your existing AI quota. We monitor consumption closely and keep it under 10% of your quota. For 99% of our test users, it stayed well within those limits. If you are ever concerned about quota usage, you can disable individual features or uninstall the plugin at any time. We’d appreciate hearing about any anomalies you notice.

Installing this plugin means joining an active feedback loop, so enabling detailed data collection is required. We collect usage data and review it to improve feature quality. We’re not collecting anything new compared to regular data sharing in the AI Assistant plugin.

The plugin currently generates text in English only, regardless of your IDE language settings. Localization is on our to-do list, but we want to polish the core experience first.

What’s next

The recap and insights features are the first two tools in this plugin, not the last. We’re already working on updates to both based on what early testers have told us. Many mentioned that the recap was most valuable for long breaks and cross-project switching, rather than short interruptions, and requested shorter, crisper summaries. The next release will deliver that. There was also a request to ground the recap in the branch history, which we are now exploring.

Next on our radar is the VCS tool window. There’s already a Group with AI feature in your local diff view, but we have a lot more in mind. Tell us which AI-powered VCS features you’d welcome and what sorts of things would be absolute deal-breakers, even as an experiment.

The best features from this plugin will eventually graduate into the main AI Assistant plugin, but that will only happen when you tell us they’re ready.

Tell us what you think

Install the plugin, try the features, and share your feedback. You can use the in-IDE feedback form in the AI chat, leave a plugin review, or drop us a note here in the comments or on social media.

Ten years ago, persuasive design was a relatively new frontier in the field of UX. In a 2015 Smashing article, I was among those who showed a way for practitioners to move from being primarily focused on improving usability and removing friction to also guide users toward a desired outcome. The premise was simple: by leveraging psychology, we could influence user behavior and drive outcomes like higher sign-ups, faster and richer onboarding, and stronger retention and engagement.

A decade later, that promise has proven true — but not in the same way many of us expected. Most product teams still face familiar problems: high bounce rates, weak activation, and users dropping off before experiencing core value. Usability improvements help, but they don’t always address the behavioral gap that sits underneath these patterns.

Persuasive design didn’t disappear — it matured.

Today, the more useful version of this work is often called behavioral design: a way to align product experiences with the real drivers of human behavior, with an ethical mindset. Done well, it can improve conversion, onboarding completion, engagement, and long-term use without slipping into manipulation.

Here’s what I’ll cover:

• What has held up from the last decade of persuasive design;
• What didn’t hold up, especially the limits of pattern-first gamification;
• What changed in how we model behavior, from triggers to context and systems;
• How to use modern behavioral frameworks to improve both discovery and ideation;
• A practical way to run this work as a team, using a five-exercise workshop sequence, you can adapt to your product.

The goal is not to add more tactics to your toolkit. It’s to help you build a repeatable, shared approach to diagnosing behavioral barriers and designing solutions that support both users’ goals and business outcomes.

Is Persuasion The Same As Deception?

Behavioral Design is not about slapping deceptive patterns or superficial “growth hacks” onto your UI. It’s about understanding what truly enables or hinders your users on their way to achieving their goal and then designing experiences that guide them to success.

Behavioral design is more about bridging the gap between what users want (achieving their goals, feeling value) and what businesses need (activation, retention, revenue), creating win-win outcomes where good UX and good business results align.

But like with all powerful tools, they can be used both for good and bad. The difference lies in the intention of the designer. Some designers argue for not promoting behavioral or persuasive design, while others argue that we need to understand the tools to learn how to use them well and how we can easily, and often mindlessly, fall into the trap of promoting an unethical lens.

If we are not enlightened, then how can we judge what represents good and bad practice? If we do not understand how psychology works, then we lack the awareness needed to spot our biases. If we don’t understand these tools, we can’t spot when they’re misused.

The difference between persuasion and deception is intention, plus accountability.

A Decade Later, What Have We learned?

In the early 2010s, many teams treated persuasive design as almost synonymous with gamification. If you added points, badges, and leaderboards, you were doing psychology. And to be fair, those surface mechanics did work in some cases, at least in the short term. They could nudge people through onboarding flows or encourage a few extra logins. But over the decade, their limits became clear. Once the novelty wore off, many of these systems felt shallow. Users learned to ignore streaks that did not connect to anything meaningful or dropped out when they realized the game layer was not helping them reach a real goal.

This is where self-determination theory has quietly reshaped how serious teams think about motivation. It distinguishes between extrinsic motivators, such as rewards, points, and status, and intrinsic drivers like autonomy, competence, and relatedness. Put simply, if your “gamification” fights against what people actually care about, it will eventually fail. The interventions that have survived are the ones that support intrinsic needs. A language learning streak that makes you feel more capable and shows progress can work because it makes the core activity feel more meaningful and manageable. A badge that only exists to move a dashboard number, on the other hand, quickly becomes noise.

Lesson 1: From Quick Fixes To Behavioral Strategy

One key lesson from the past decade is that behavioral design creates the most value when it moves beyond isolated fixes and becomes a deliberate strategy. Many product teams start with a narrow goal: improve a sign-up rate, reduce drop-off, or boost early retention. When standard UX optimizations plateau, they turn to psychology for a quick lift, often with success.

The biggest opportunity is not one more uplift on a stubborn metric, but having a systematic way to understand and shape behavior across the product.

Behavioral design isn’t about hacks.
It’s about helping people succeed.

Common signals are easy to recognize: people sign up but never finish onboarding; they click around once and never return; key features sit unused. A behavioral strategy doesn’t just ask “What can we change on this screen?” It asks what is happening in the user’s mind and context at those moments.

That might lead you to design an onboarding experience that uses curiosity and the goal-gradient effect to guide people to a clear first win, instead of hoping they read a help doc. Or it might lead you to design for exploration and commitment over time: social proof where it actually matters, appropriate challenges that stretch but don’t overwhelm, progressive disclosure so advanced features show up when people are ready, and the right triggers at the most opportune moment instead of random nags.

Great products aren’t just easy to use.
They’re easier to commit to.

Product psychology has shifted from scattered hypotheses to a growing library of repeatable patterns. Those patterns only shine when they sit inside a coherent behavioral model: what users are trying to achieve, what blocks them, and which levers the team will pull at each stage.

Simple nudges, inspired by Thaler and Sunstein, have helped popularize behavioral thinking in design. But we’ve also learned that nudges alone rarely solve deeper behavioral challenges. A behavioral strategy goes further: it blends tactics, grounds them in real motivations, and ties experiments to a clear theory of change. The goal is not a one-off win on today’s dashboard, but a way of working that compounds over time.

Lesson 2: Game Mechanics Alone Are Not Enough

Game mechanics alone are no longer a credible behavioral strategy. Ten years ago, adding points, badges, and leaderboards was almost shorthand for “we’re doing psychology.” Today, most teams have learned the hard way that this is decoration unless it serves a real need.

A behavioral approach starts with a blunt question: What is the game layer in service of, and for whom? Does it help people make progress that matters to them, or does it just keep a dashboard happy? If it ignores intrinsic motivation, it will look clever in a slide deck and brittle in production.

In practice, that means points and streaks are not treated as automatic upgrades anymore. Teams ask whether a mechanic helps users feel more competent, more in control, or more connected to others. A streak only makes sense if it reflects real progress in a skill the user cares about. A leaderboard only adds value if people actually want to compare themselves and if the ranking helps them decide what to do next. If it does not pass those tests, it is clutter, not a motivational engine.

Streaks and badges only work when they support something users truly value.

The most effective products now start with the intrinsic side. They are clear about what the product helps users become or achieve, and only then ask whether a game mechanic can amplify that journey. When game elements are added, they live in the core loop rather than on top of it. They show mastery, mark meaningful milestones, and reinforce self-driven goals. That is the difference between treating gamification as a paint job and using it to support users on a path they already care about.

Lesson 3: From Cause And Effect To Holistic Systems Thinking

Early persuasive design often assumed a simple logic: find the broken step, add the right lever, and users move forward. Nice on a slide, rarely true in reality.

People don’t act for a single reason. They have context, history, competing goals, mood, time pressure, trust issues, and different definitions of success. Two users can take the same step for completely different reasons. The same user can behave differently on a different day.

That’s why systems thinking matters. Behavior is shaped by feedback loops and delays, not just one trigger. Outcomes we care about, trust, competence, and habit, are built over time. A change that boosts this week’s conversion can still weaken next month’s retention.

If you have ever shipped a “conversion win” and then watched support tickets, refunds, or churn go up, you have felt this. The local metric improved. The system got worse.

Your design structures either enable people or box them in. Defaults, navigation, feedback, pacing, rewards — each of these decisions reshapes the system and therefore the journeys people take through it.

So the job is not to perfect a single funnel. It is to build an environment where multiple valid paths can succeed, and where the system supports long-term goals, not just short-term clicks.

The job isn’t to perfect one funnel, but to support multiple valid paths.

A mature behavioral strategy is explicit about that. It is designed for several paths instead of one “happy flow,” supports autonomy instead of forcing compliance, and looks at downstream effects instead of only first-step conversion.

Lesson 4: From Triggers To Context

The same shift has happened in the frameworks we use. A decade ago, the Fogg Behavior Model (FBM) was everywhere. It gave teams a simple trio: motivation, ability, trigger — and a clear message: shouting louder with prompts does not fix low motivation or poor ability. That alone was a useful upgrade.

Fogg’s own work has moved on, too. With Tiny Habits, the focus leans more on identity, emotion, and making behaviors feel easy and personally meaningful. That mirrors a broader shift in the field: away from “fire more prompts” and toward designing environments where the right behavior feels natural.

Teams eventually ran into the same wall: prompts do not fix low capability or missing opportunity. You cannot nag people into skills they do not have or into contexts that do not exist. That is where many teams that work deeply with behavior change have gravitated toward COM-B as a more complete foundation.

COM-B breaks behavior into capability, opportunity, and motivation. It starts with a blunt check: can people actually do this, and does their environment let them? That maps well to modern products, where behavior happens across devices, channels, and moments, not on a single screen. It also plugs into broader behavior change work in health and public policy, so we do not have to reinvent everything inside UX.

Thinking this way nudges teams away from simple cause-and-effect stories. A drop in completion rate is no longer “the button is bad” or “we need more reminders,” but a question about how skills, context, and motivation interact. A capability issue might need a better interface and better education. An opportunity issue might be about device access, timing, or social surroundings, not layout. Motivation might be shaped as much by pricing and brand trust as by any in-product message.

Modern behavioral design is less about activating clicks and more about shaping conditions where action feels easy and meaningful.

This broader lens also makes cross-functional work simpler. Product, design, marketing, and data can share one behavior model and still see their own responsibilities in it. Designers shape perceived capability and opportunity in the interface, marketing shapes motivational framing and triggers, and operations shape the structural opportunity in the service. Instead of everyone pushing their own levers in isolation, COM-B helps teams see that they are working on different parts of the same system.

Lesson 5: Psychology Can Also Be Used To Design And Decode Discovery

COM-B is often used as a bridge between discovery and ideation. On the discovery side, it gives structure to research. You can use it to design interview guides, read analytics, and make sense of observational studies. It was built to diagnose what needs to change for a behavior to shift, which maps neatly onto early product discovery.

Good discovery doesn’t just ask what users say, but examines what their behavior reveals.

Instead of asking “Why did you stop using the product?” and writing down the first answer, you deliberately walk through capability, opportunity, and motivation. You ask things like:

• Can users actually do this, given their skills and knowledge?
• Does their context help or hinder them in practice?
• How strong is their motivation compared with other demands on their time and money?

You walk through recent experiences in detail: which device they used, what time of day it was, who else was around, and what else they were juggling. You talk about how important this behavior is compared with everything else in their life and what trade-offs they make. To participants, these questions feel natural. Under the hood, you are systematically covering all three parts of COM-B, in line with how behavior change practitioners use the model in qualitative work.

You can look at behavioral data in the same way. Funnel drop-offs, time on task, and click patterns are clues: are people stuck because they cannot progress, because the environment gets in the way, or because they do not care enough to continue? Modern analytics tools make it easier to watch what people actually do rather than only what they report, and combining quantitative and qualitative data gives you a fuller picture than either alone.

When there is a gap between what people say and what they do, you treat it as a signal rather than an irritation. Someone might say that saving for retirement is very important, but never set up a recurring transfer. A user might claim that onboarding was simple, while their session shows repeated back and forth between steps. Those mismatches are often where biases, habits, and emotional barriers live. By labelling them in terms of capability, opportunity, and motivation, and linking them to specific barriers like risk aversion, analysis paralysis, status quo bias or present bias, you move from vague “insights” to a structured map of what is actually in the way.

The gap between what people say and what they do is not noise — it’s the map.

The output of this kind of discovery is not just personas and journeys. You also get a clear statement of the current behavior, the target behavior, and the behavioral barriers and enablers that sit between them.

Lesson 6: Use Behavioral Discovery In Your Ideation

The bridge from discovery to ideation can be a single sentence template:

From current behavior to target behavior, by doing X, because of barrier Y.

This “from–to–by–why” framing forces teams to say what they actually believe. You are not just saying “add a checklist.” You are saying: “We believe a checklist will help new users feel more capable, which will increase the chance they complete setup in their first session.” Now it is a behavioral hypothesis you can test with experiments, not just a design idea you hope for.

From there, you can generate several variants that express the same principle in different ways and design experiments around them. You might try a few messages that all lean on loss aversion, or several ways of simplifying a high-friction step, or different forms of social proof that vary in tone and proximity.

The important shift is that you are no longer throwing ideas at the wall. You are deliberately targeting the capability, opportunity, or motivation issues that discovery surfaced, and testing which levers actually work in your context.

Every idea should answer one question: which barrier are we trying to change?

Over time, this loop between behavioral discovery and ideation turns into a local playbook. You learn that in your product, some principles reliably help your users and others fall flat. You also learn that patterns from glowing case studies do not automatically transfer. Even gamification and behavior change research often emphasize context-specific, user-centred implementations rather than generic recipes.

This dual use of psychology in discovery and ideation is one of the bigger shifts of the past decade. A product trio can look at a stubborn drop-off point and ask, together, “Is this a capability, opportunity, or motivation issue?” Then they generate ideas that target that part of the system instead of guessing. That shared language makes behavioral design less of a specialist add-on and more of a normal way for cross-functional teams to reason about their work.

A Decade Later: What Has Proven To Work In Practice

If the first decade of persuasive design taught us anything, it is that behavioral insight is cheap until a team can act on it together.

Methods matter.

Over time, a small set of workshop formats has consistently helped product teams uncover behavioral barriers, align on opportunities, and generate solutions grounded in real psychology instead of surface patterns. As behavioral design has grown from tactical nudges into a strategic discipline, an obvious question keeps coming up: How do teams actually do this work together in practice?

How do product managers, designers, researchers, and engineers move from scattered observations (“people seem confused here”) to a shared behavioral diagnosis, and then to targeted ideas that reflect the real drivers of capability, opportunity, and motivation?

One effective way to make this concrete is through a workshop format. The aim is to help teams:

• Interpret research through a behavioral lens,
• Surface capability, opportunity, and motivation gaps,
• Prioritize high-potential opportunities, and
• Generate ideas that are both psychologically sound and ethically considered.

Real product work is messy and full of feedback loops; nobody follows a perfect step-by-step checklist. But for learning, and especially for introducing behavioral design into a team for the first time, a structured sequence of exercises gives people a mental model. It shows the journey from early discovery to behavioral clarity, from opportunities to ideas, and finally to interventions that have been stress-tested through an ethical lens.

The exercises below are one such recipe. The order is intentional: each step builds on the previous one to move from empathy and insight to prioritized opportunities, concrete concepts, and responsible solutions. No team will follow it letter-perfect every time, but it reflects how behavioral design work tends to unfold when it goes well.

Before diving into the details, here is the full recipe and how each exercise contributes to the bigger behavioral design process:

1. Behavioral Empathy Mapping
   Builds a shared understanding of the user’s psychological landscape: emotions, habits, misconceptions, and sources of friction.
2. Behavioral Journey Mapping
   Maps the user’s flow over time, and overlays behavioral enablers and obstacles.
3. Behavior Scoring
   Prioritizes which behavioral opportunities to tackle first based on impact, feasibility, and evidence.
4. Ideas First, Patterns Later
   Encourages context-first ideation, then uses persuasive patterns to refine and strengthen promising concepts.
5. Dark Reality
   Evaluates ethical risks, unintended consequences, and potential misuse.

A note on timing: In practice, this sequence can be run in different formats depending on constraints. For a compact format, teams often run Exercises 1–3 in a half-day workshop, and Exercises 4–5 in a second half-day session. With more time, the work can be spread across a full week: discovery synthesis early in the week, prioritization mid-week, and ideation plus ethical review toward the end. The structure matters more than the schedule; the goal is to preserve the progression from understanding → prioritization → ideation → reflection.

Below is a brief walkthrough of each exercise as I typically facilitate them in workshops in tandem with a library of persuasive patterns.

Exercise 1: Behavioral Empathy Mapping

The first step is building a shared, psychologically informed understanding of users. Behavioral Empathy Mapping extends traditional empathy mapping by paying attention to what users attempt, avoid, postpone, misunderstand, or feel uncertain about. These subtle behavioral signals often reveal more than stated needs or pain points.

Goal: Understand what drives or blocks the target behavior by capturing what users think, feel, say, and do — and spotting behavioral barriers and enablers.

Steps:

1. On a whiteboard or large paper, draw an empathy map: Thinking & Feeling, Seeing, Saying & Doing, and Hearing.



2. Add research insights by letting everyone silently add sticky notes from interviews, data, support logs, or observations into the quadrants. One insight per note.
3. Identify barriers and enablers.
   Cluster notes that make the behavior harder (barriers) or easier (enablers).

Output: A focused map of the psychological and contextual forces shaping the target behavior, ready to feed into Behavioral Journey Mapping.

Exercise 2: Behavioral Journey Mapping

Once you understand the user’s mindset and context, the next step is to map how those forces play out across time. Behavioral Journey Mapping overlays the user’s goals, actions, emotions, and environment onto the product journey, highlighting the specific moments where behavior tends to stall or shift.

Unlike traditional journey maps, the behavioral version focuses on where capability breaks down, where the environment works against the user, and where motivation fades or conflicts arise. These become early signals of where change is both needed and possible.

The output shows the team precisely where the product is asking too much, where users lack support, or where additional motivation or clarity might be required.

Goal: Map the steps from the user’s starting point to the target behavior, and capture the key enablers and barriers along the way.

Steps:

1. Draw a horizontal line from A (starting point) to B (target behavior).



2. Have everyone write the steps a user takes from A to B on sticky notes (one per note). Include actions inside and outside the product.
3. Place the notes in order along the line. Merge duplicates and align on a shared sequence.
4. Extend the vertical axis with two rows:
   • Enablers (what could help users move forward),
   • Barriers (what could slow or stop users).



5. Look for steps with many barriers or few enablers. These are behavioral hot spots.
6. Highlight the steps where a good nudge could meaningfully help users complete the journey.

Output: A clear, behavior-focused journey showing where users struggle, why, and which moments offer the most leverage for change.

Exercise 3: Behavior Scoring

With a clearer picture of the user journey and what moments could benefit from a behaviorally helpful hand, you are now ready to identify the behavior it makes most sense to focus on trying to influence.

Goal: Decide which potential target behaviors are worth focusing on first, based on impact, ease of change, and ease of measurement.

Steps:

1. List potential target behaviors. Based on the output of the Behavioral Journey Mapping, list behaviors that could potentially be targeted. One behavior per sticky note. Be as concrete as possible (what users do, where, and when).
2. Create a table with the following columns:
   • Impact of behavior change (how much it could move the goal),
   • Ease of change (how realistic it is to influence),
   • Ease of measurement (how straightforward it is to track).

Potential target behaviors	Impact of behavior change	Ease of change	Ease of measurement	Total
…
…
…

3. Enter each listed behavior into the table and score them from 0 to 10 in each column.
4. Sort behaviors by total score and discuss the highest-scoring ones:
   • Do they make sense given what you know about users and constraints?
5. Select the primary target behaviors you want to carry into the next exercises.
   Optionally, note “bonus behaviors” that might follow as a side effect.

Output: A small set of prioritized target behaviors with a clear rationale for why they matter now, and a list of lower-priority behaviors you may revisit later.

A filled-out Behavior Scoring table could look like this:

In this case, the checklist completion emerges as the strongest initial focus: it has high impact, is realistically influenceable through design changes, and can be measured reliably. Inviting a teammate may be strategically important, but it may require broader changes beyond interface design, making it a secondary focus.

Exercise 4: Ideas First, Patterns Later

Once the team has agreed on which behavior matters most, the next risk is jumping too quickly to familiar psychological tricks. One of the clearest lessons has been that starting with “the pattern” often leads to generic solutions that feel clever but fail in context.

This exercise deliberately separates idea generation from psychological framing.

Goal: Generate solutions grounded in user context first, then use psychological principles to sharpen and strengthen them.

Steps:

1. Start by restating the prioritized target behavior and the key barrier identified during journey mapping. Keep this visible throughout the exercise.
2. Then give the team a short, focused ideation window (10–15 minutes).
   The rule here is simple: no references to behavioral models, cognitive biases, or persuasive patterns yet. Ideas should come directly from the user context, constraints, and moments uncovered earlier.
3. Collect ideas on a shared surface and group similar concepts. Look for multiple ways of solving the same underlying problem (cluster them together).

4. Only now do you introduce a library of psychological principles and techniques. I developed the persuasive patterns for this exact purpose. The goal of this step is not to replace ideas, but to refine them:

   • Which ideas could be strengthened by reducing friction?
   • Which might benefit from clearer feedback, social signals, or better timing?

   • Are there alternative ways to achieve the same effect more respectfully or more clearly?

     Patterns are used as lenses, not prescriptions. If a pattern does not improve clarity, agency, or usefulness in this context, it is simply ignored.

Output: A refined set of solution concepts that are grounded in real user context and supported, where appropriate, by behavioral principles rather than driven by them.

This sequencing helps teams avoid “pattern-first design,” where ideas are reverse-engineered to fit a theory instead of addressing real human situations.

Exercise 5: Dark Reality

Before ideas turn into experiments or shipped features, they need one final test. Not for feasibility or metrics, but for ethics.

Over the years, this step has proven critical. Many persuasive solutions only reveal their downside when you imagine them working too well, or being applied in the wrong hands, or used on the wrong day by the wrong person.

Goal: Surface ethical risks, unintended consequences, and potential misuse before implementation.

Steps:

1. Take one or two of the strongest ideas from the previous exercise.
2. Imagine worst-case scenarios by asking the team to deliberately shift perspective:
   • What if a competitor used this against us?
   • What if this nudges users when they’re stressed, tired, or vulnerable?
   • What happens if this works repeatedly over months, not once?
   • Could this create pressure, guilt, or dependence?
3. Capture concerns around autonomy, trust, fairness, inclusivity, or long-term well-being.
4. For each risk, explore ways to soften or counterbalance the effect:
   • Clearer intent or transparency,
   • Lower frequency or gentler timing,
   • Explicit opt-outs,
   • Alternative paths forward.
5. Some ideas are reshaped. Some are paused.
   Some survive intact, but now with greater confidence.

Output: Solutions that have been stress-tested ethically, with known risks acknowledged and mitigated rather than ignored.

Building A Shared Vocabulary For Product Psychology

The teams that get the most out of behavioral design rarely have a single “psychology expert.” Instead, their team shares a vocabulary around product psychology and knows how to communicate around customer problem behaviorally.

A shared vocabulary turns psychology into cross-functional work.

When patterns and principles are shared:

• Product, design, engineering, and marketing can talk about behavior without talking past each other.
• Discovery insights are easier to interpret because common barriers and drivers have names.
• Ideas can be framed as behavioral hypotheses (“we believe this will increase early competence…”) instead of vague guesses.

The Persuasive Patterns collection grew from this need: giving teams a common language and a concrete set of examples to point at. Whether used as a printed deck in a workshop or as long-form references during everyday work, the goal is the same: make product psychology something the whole team can see and discuss.

Persuasive design was often framed as a bag of tricks. Today, the work looks different:

• Game mechanics are used to support intrinsic motivation, not drive vanity engagement.
• Frameworks like COM-B and systems thinking help teams see behavior in context, not as a single trigger.
• Behavioral insight is used to shape discovery and ideation, not just last-minute copy changes.
• Ethics is part of the design brief, not an afterthought.

The next step is not more sophisticated nudges. It is a more systematic practice: simple methods, shared language, and a habit of asking “What is really going on in our users’ lives here?”

If you start by focusing on one behavioral problem, use a couple of the exercises in this article, and give your team a shared set of patterns to reference, you are already practicing persuasive design in the way it has evolved over the last ten years: grounded in evidence, respectful of users, and aimed at outcomes that matter on both sides of the screen.

If you are building a multilingual application with Laravel and Inertia.js, you need a way to share your backend PHP translations with your JavaScript frontend.

For years, developers have defaulted to the “industry standard” packages. But as Inertia.js has evolved, these legacy giants are starting to show their age. They are often bloated, framework-locked, or require frustrating build-step configurations.

Let’s put the most popular localization packages head-to-head against a powerful newcomer—Laravel Lang Sync Inertia—and see why it’s the ultimate choice for your next project.

🏗️ The Heavyweights: vue-i18n & react-i18next

These are the default, massive JavaScript internationalization libraries.

• How they work: You have to manually export your Laravel translations to JSON, import them into your JS bundle, and set up a complex configuration file in your frontend.
• The Problem: The Disconnect. They don’t know Laravel exists. You are forced to write custom Artisan commands or build scripts just to keep your backend .php files and frontend .json files in sync. Plus, importing massive JSON dictionaries directly into your JS bundle drastically increases your frontend load time.

👑 The Popular Go-To: laravel-vue-i18n

This is currently one of the most popular packages for Laravel + Vue developers.

• How it works: It uses a Vite plugin to automatically parse your Laravel translation files and inject them into your Vue app.
• The Problem:
• Framework Locked: As the name implies, it’s for Vue. If you are using React with Inertia, you are out of luck.
• Global Loading: It typically loads your entire language directory into the frontend. If your app has thousands of translation keys, your user is downloading megabytes of text they don’t even need for the current page.
• Vite Plugin Complexity: Relying on Vite plugins can sometimes cause caching issues during development or complex CI/CD pipeline setups.

🚀 The Smart Alternative: laravel-lang-sync-inertia

If you are using Inertia.js, you don’t need heavy Vite plugins or manual JSON sync scripts. You need a package that uses Inertia’s native data-sharing capabilities intelligently.

Here is why Laravel Lang Sync Inertia is the superior package for this stack:

1. Granular, Page-by-Page Loading (Zero Bloat)

Instead of forcing the frontend to download your entire translation dictionary, you load only what is necessary for the current page right from your Laravel Controller.

public function checkout()
{
    // Only sends the checkout and payment translations to the frontend!
    syncLangFiles(['checkout', 'payment']);

    return Inertia::render('Checkout');
}

The Result: Lightning-fast page loads. Your Inertia payload stays incredibly small.

2. Built for Both Vue AND React

Why lock yourself into one framework? Whether your Inertia app uses Vue 3 or React, this package provides native-feeling companion hooks (vueLang() and reactLang()) that give you the exact trans() and __() helpers you are used to in Laravel Blade.

3. Pure Runtime Magic (No Vite Plugins Required)

Because it passes data securely through Inertia’s native props, you don’t have to mess with your vite.config.js. It works out of the box. No background watchers, no complex build steps.

4. Need Static JSON? It Does That Too.

If you ever decide you want to use a heavy library like vue-i18n, this package includes a blazing-fast Artisan command (php artisan erag:generate-lang) that flawlessly compiles your PHP arrays into perfectly mapped JSON files.

📊 The Head-to-Head Comparison

🎯 Final Verdict

If you are building a pure SPA and want to manage translations entirely in JavaScript, the standard vue-i18n is fine.

If you want your translations injected via Vite and only use Vue, laravel-vue-i18n is a solid choice.

But if you want the absolute best performance, zero build-step configuration, multi-framework support, and the ability to load translations granularly on a per-page basis, Laravel Lang Sync Inertia is the undisputed winner.

Stop sending massive translation files to your frontend. Upgrade to smart syncing today.

👉 Get it on Packagist: composer require erag/laravel-lang-sync-inertia

👉 NPM Companion: npm install @erag/lang-sync-inertia

⭐ Star the Repo: GitHub – eramitgupta/laravel-lang-sync-inertia

The Spark

It started with a code review.

I was scrolling through a colleague’s pull request — about 40 commits spanning two weeks of work — and I found myself genuinely impressed. Not just by the code, but by the narrative arc hiding inside those commit messages. There was a clear beginning (scaffolding, initial setup), a middle (the struggle with edge cases, the refactors, the “fix typo” commits at 2 AM), and an ending (tests passing, cleanup, the final polish).

I thought: what if there was a tool that could take these raw commit logs and turn them into an actual story?

Not a changelog. Not release notes. A story.

That idea became GitStory.

What GitStory Does

GitStory is a web app that reads the commit history of any GitHub repository and uses AI to generate a narrative in one of six distinct writing styles:

• Dev Blog — A technical blog post with code insights
• Engineer’s Diary — A personal development journal
• Novel — Creative fiction where the developer is the protagonist
• Epic Tale — A grand saga of a coding quest
• Business Book — Leadership lessons extracted from the repo
• Mystery — A whodunit starring your code

You paste a GitHub repo URL, pick a style, choose a date range, and the AI writes the story in real-time with streaming output. You can then copy, share, or just enjoy reading about your work from a perspective you’ve never seen before.

Why I Built This

I’m a developer who has always been interested in the intersection of code and storytelling. Commit histories are, fundamentally, logs of human decisions. Each commit represents a moment where someone said “this is worth saving.” But we almost never look at them that way.

Most commit logs look like this:

fix: resolve null pointer in user service
feat: add pagination to dashboard
chore: update dependencies
fix: typo in README
wip
wip
wip

But behind those messages is a story of problem-solving, creativity, and persistence. I wanted a tool that could surface that story — and make it fun to read.

There was also a selfish motivation: I wanted to use it for my own portfolio. Imagine being able to share not just “I built X” but a narrative of how you built X, automatically generated from your actual work.

Tech Stack Decisions

Next.js 14 with App Router

I went with Next.js 14 (App Router) because I needed:

• Server-side rendering for OGP meta tags (so shared stories look good on Twitter/Slack)
• API Routes to proxy GitHub API calls and Gemini API calls
• Edge Runtime for the OGP image generation endpoint
• Streaming responses for real-time story generation

The App Router’s generateMetadata function was particularly useful. Each shared story gets its own URL (/story/[id]), and the metadata is dynamically generated from the story content:

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const story = await getStory(params.id);
  const preview = story.story.slice(0, 150).replace(/n/g, ' ') + '...';

  return {
    title: `${styleLabel} Story | GitStory`,
    openGraph: {
      images: [`/api/og?style=${encodeURIComponent(styleLabel)}&id=${params.id}`],
    },
  };
}

Google Gemini AI

I chose Google Gemini (specifically gemini-2.0-flash) for several reasons:

1. Speed — Flash models are optimized for fast inference, which matters when you’re streaming a story to the user in real-time
2. Cost — The free tier is generous enough for a freemium product
3. Quality — The output quality for creative writing tasks is surprisingly good
4. Streaming — The generateContentStream API works perfectly with web streams

The integration is straightforward:

const model = genAI.getGenerativeModel({ model: 'gemini-2.0-flash' });
const result = await model.generateContentStream(prompt);

const readable = new ReadableStream({
  async start(controller) {
    for await (const chunk of result.stream) {
      const text = chunk.text();
      if (text) {
        controller.enqueue(encoder.encode(text));
      }
    }
    controller.close();
  },
});

The streaming approach means users see the story appear word by word, which creates a much better experience than waiting for the entire response.

GitHub OAuth via NextAuth.js

Authentication serves two purposes:

1. Private repo access — Users can generate stories from their private repositories
2. Rate limiting by user — Pro users get higher limits

I used NextAuth.js with the GitHub provider. The key insight was passing the accessToken through to the GitHub API call so authenticated users can access their private repos:

const response = await fetch('/api/story', {
  method: 'POST',
  body: JSON.stringify({
    repoUrl,
    style,
    days,
    accessToken: session?.accessToken,
  }),
});

Upstash Redis for Story Storage

Shared stories need to be persisted somewhere. I chose Upstash Redis because:

• Serverless — No connection management headaches on Vercel
• TTL support — Stories can automatically expire
• Fast reads — Story pages need to load quickly for OGP crawlers

Stripe for Subscriptions

The Pro plan uses Stripe for subscription billing. I implemented webhooks to handle subscription lifecycle events and store plan data alongside user records.

The Hardest Parts

Prompt Engineering for Six Styles

Getting the AI to produce consistently good output across six different writing styles was harder than I expected. The initial prompts were too vague:

// Too vague - produces generic output
"Write a story based on these commits"

The final prompts are more specific about tone, structure, and audience:

const systemPrompts = {
  'epic-tale':
    "Write an epic tale or saga about a heroic developer's journey, " +
    "with these commits as milestones in the adventure.",
  'novel':
    "Write a novel excerpt where the main character is a developer, " +
    "incorporating these commits as key events in the story. " +
    "Make it narrative and engaging.",
  // ...
};

I also found that providing the commits in a structured format (date, message, author) gave better results than dumping raw JSON.

Rate Limiting Without a Database

For the free tier, I needed rate limiting but didn’t want to spin up a database just for that. I implemented an in-memory rate limiter for development and Upstash Redis for production:

const rateLimit = checkRateLimit(clientIp, {
  maxRequests: plan.maxRequests,
  windowSeconds: plan.windowSeconds,
});

Pro users get higher limits, which is handled by checking their subscription status before applying the rate limit.

OGP Image Generation

When someone shares a GitStory link on Twitter or Slack, I wanted it to look good. Next.js has built-in OGP image generation using ImageResponse with the Edge Runtime:

export const runtime = 'edge';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const styleName = searchParams.get('style');

  return new ImageResponse(
    <div style={{
      background: 'linear-gradient(135deg, #667eea 0%, #764ba2 100%)',
      // ... JSX layout
    }}>
      <div style={{ fontSize: '72px', color: 'white' }}>GitStory</div>
      <div>A {styleName} created with GitStory</div>
    </div>,
    { width: 1200, height: 630 }
  );
}

This runs on the edge, so it’s fast and doesn’t add load to the main server.

Streaming on the Client

Consuming a streamed response in React requires manual handling with ReadableStream:

const reader = response.body?.getReader();
const decoder = new TextDecoder();
let accumulatedStory = '';

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  const chunk = decoder.decode(value, { stream: true });
  accumulatedStory += chunk;
  setStory(accumulatedStory);
}

This gives the user a “typewriter” effect as the story streams in. It’s a small detail, but it makes the experience feel alive.

Try It With Famous OSS Repos

One of the features I’m most proud of is the one-click demo with famous open-source repositories. On the generate page, you can instantly try GitStory with:

• React (facebook/react)
• Next.js (vercel/next.js)
• Vue (vuejs/core)
• TypeScript (microsoft/TypeScript)
• Rust (rust-lang/rust)
• Linux (torvalds/linux)

Try generating an Epic Tale from the Linux kernel’s recent commits. You’ll get something like Linus Torvalds embarking on a mythical quest to tame the beast of memory management. Or generate a Mystery from React’s commits and read about the detective investigating the case of the missing reconciler optimization.

These demos are a great way to see what GitStory can do before you point it at your own repositories.

Head over to git-story.dev and give it a try. The “Try with a popular repo” buttons are right there on the generate page.

Architecture Overview

Here’s a simplified view of how it all fits together:

Browser
  |
  |-- POST /api/story { repoUrl, style, days, accessToken }
  |
  v
Next.js API Route
  |
  |-- 1. Check rate limit (Redis / in-memory)
  |-- 2. Fetch commits from GitHub API
  |-- 3. Format commits into structured text
  |-- 4. Send to Gemini with style-specific prompt
  |-- 5. Stream response back to client
  |
  v
Browser renders story in real-time
  |
  |-- User clicks "Share"
  |-- POST /api/story/save { story, repoUrl, style }
  |-- Story saved to Redis with unique ID
  |-- Share URL: /story/[id]
  |
  v
Shared story page
  |-- Server-side rendered with OGP metadata
  |-- Dynamic OGP image via /api/og (Edge Runtime)

The entire app runs on Vercel’s free tier (with the exception of Upstash Redis and Stripe for Pro features). The architecture is intentionally simple — there’s no traditional database, no complex state management, no build pipeline beyond what Next.js provides.

Lessons Learned

1. Streaming Changes Everything

The difference between “wait 10 seconds for a response” and “watch text appear in real-time” is enormous in terms of perceived performance. Streaming should be the default for any AI-powered feature.

2. Prompt Quality > Model Quality

I spent more time iterating on prompts than I did on any other part of the app. A well-crafted prompt with a mediocre model beats a vague prompt with a state-of-the-art model every time.

3. The “Try It Now” Button Is Everything

Adding one-click demos with famous OSS repos increased engagement dramatically. People want to see what the tool does before they trust it with their own data. Lower the barrier to “aha” as much as possible.

4. OGP Is Worth the Effort

Stories that look good when shared get shared more. The dynamic OGP image generation was a relatively small investment that had an outsized impact on organic distribution.

5. Keep the Stack Simple

Next.js App Router + Vercel + a single external API (Gemini) + Redis. That’s it. No state management library, no ORM, no complex deployment pipeline. For a side project, simplicity is a feature.

What’s Next

I’m currently working on:

• More writing styles — Screenplay, poetry, and academic paper styles
• Team stories — Aggregate stories across multiple repos for team retrospectives
• Commit filtering — Let users focus on specific authors or file paths
• Multi-language support — Generate stories in languages other than English

Try It

If you’ve read this far, I’d love for you to try GitStory. Sign in with GitHub, paste a repo URL (or click one of the popular repo buttons), pick a style, and see your commits transformed.

It’s free to use. No credit card required. And if you generate a story you like, share it — each story gets its own URL with a nice OGP preview.

I’d also love feedback. What styles would you want to see? What features would make this useful for your workflow? Drop a comment below or open an issue on the GitHub repo.

Happy storytelling.

GitStory is open source and built with Next.js, Google Gemini AI, and Tailwind CSS. Try it at git-story.dev.

Quick Answer: The best alternatives to Perplexity Sonar for developers are Valyu (for specialised data access + web search + benchmark-leading accuracy), Linkup (for simple web search with predictable pricing), and Tavily (for LangChain/LlamaIndex-integrated RAG).

For Sonar Deep Research specifically, Valyu’s DeepResearch API is the only alternative that matches multi-step research with citations while also accessing full-text SEC filings, PubMed, and academic sources that Sonar cannot reach.

I’ve been building search-grounded AI apps long enough to have a mental list of the API switches that felt obvious in hindsight. Switching off Perplexity Sonar is near the top.

The Sonar API is a capable product. I’m not here to trash it. But if you’ve been running a production app on Sonar and you’ve hit the reliability ceiling, the throttling wall, or the “this thing only knows about public web pages” limit, you’re not alone, and there are real alternatives now.

This article covers what Perplexity Sonar actually is (the full product family, not just the consumer chatbot), the documented reasons developers switch, and the concrete alternatives for each use case, including a dedicated section on Sonar Deep Research specifically.

What Perplexity Sonar Actually Is

First: Sonar is Perplexity’s API product, not the consumer app.

“Perplexity” and “Sonar” are distinct things. Searching for Perplexity alternatives usually returns lists of consumer chatbots (ChatGPT, Claude, etc.). That’s the wrong category if you’re building as a developer.

The Sonar API family has five models:

sonar-deep-research runs autonomous multi-step research, searches the web multiple times, reasons over what it finds, produces a comprehensive report. Available via Perplexity API and OpenRouter.

The pricing for Deep Research compounds fast. A request that triggers 30 searches costs $0.15 in search fees alone, before tokens.

Why Developers Are Switching

These are documented complaints from /r/perplexity_ai, /r/AI_Agents, and developer comparisons, not personal opinions.

Reliability. One developer documented 20+ daily API outages with the Perplexity status page showing green the entire time. For a production app, that’s not workable. The common workaround is building fallback logic, which defeats the point of paying for a managed API.

Intentional throttling. Linkup documented this in their own comparison: Sonar’s API accuracy appears deliberately capped to avoid creating a competitive consumer product. Perplexity’s primary business is a consumer chatbot. The API is secondary. The engineering priorities show.

The architecture problem. Sonar uses a /chat/completions endpoint, the same pattern as LLM chat APIs. Every API call forces a full text generation. If you only want source URLs for a RAG pipeline, you still pay for a generated answer. For developers who want to control the generation step themselves (use Claude or GPT-4 for generation, use search just for retrieval), this creates a wasteful and expensive architecture.

Linkup measured this…The unpredictability in output token length (ranging from 4 to 340,000 tokens) makes cost-per-query essentially impossible to forecast.

Web-only. This is the hard ceiling. Sonar searches the public web. That’s it. No SEC filings, no PubMed, no academic journals, no ChEMBL compound databases, no FRED economic data. If you’re building financial analysis tools, biomedical research assistants, or anything that requires authoritative data that lives behind institutional barriers, Sonar hits a wall.

The $5 Pro plan trap. Many developers sign up for Perplexity Pro at $20/month expecting meaningful API access. The Pro plan includes $5/month in API credits. That’s roughly 1,000 standard queries at low search depth. A heavy testing session can burn through it in hours.

Alternatives for Standard Sonar Use Cases

Valyu DeepSearch API

The most differentiated option in this category, specifically because it goes beyond web search.

Valyu’s DeepSearch API gives you a single endpoint that searches the public web AND 36+ specialised data sources; SEC 10-K, 10-Q, 13F, 13D, 13G filings with full-text search, PubMed and bioRxiv research papers, ChEMBL bioactive compounds, academic journals, FRED and BLS economic data, clinical trials, patent databases.

For developers building anything that needs financial data, biomedical research, academic content, or economic indicators, this is the alternative that actually solves the problem. Sonar doesn’t provide reliable data in many of these areas.

On raw web search accuracy, Valyu benchmarks at 79% on FreshQA (600 time-sensitive queries) versus Sonar’s architecture which relies on Perplexity’s indexed web.

On finance-specific questions, Valyu scores 73% vs Google’s 55%.

from valyu import Valyu

client = Valyu(api_key="your-api-key")

# Search web + SEC filings + economic data in one call
response = client.search(
    query="What risk factors did Apple disclose in their most recent 10-K?",
    search_type="all", # web + proprietary
    max_num_results=10
)

print(response)

The MCP server integration means it drops into Claude Desktop, Cursor, and other MCP-compatible tools with zero additional code. Native Vercel AI SDK and LangChain integrations exist.

Platform: platform.valyu.ai | Docs: docs.valyu.ai | Free $10 credit on signup.

Best for: Developers who need specialised data (financial, biomedical, academic, economic) or who want benchmark-leading accuracy on time-sensitive and domain-specific queries.

Linkup

Linkup’s pitch is architectural clarity. They expose a dedicated /search endpoint with an outputType parameter, you specify whether you want search_results (clean JSON of sources), answer (generated text), or structured (custom JSON schema). This is fundamentally different from Sonar’s chat completion approach.

Pricing is transparent and flat: standard search at €5/1,000 queries, deep search at €50/1,000 queries. No token variability. On SimpleQA benchmarks, Linkup hit 91% vs Sonar’s 77.3%.

The one limitation: Linkup is web-only. No specialised data access.

Best for: Developers who want predictable pricing and architectural control over the search/generation split.

Tavily

They are one of the most commonly used search APIs in the LangChain/LlamaIndex ecosystem. Tavily’s biggest advantage is installation friction: if you’re building a LangChain agent, Tavily is a one-liner. The free tier (1,000 credits/month) is generous enough for development.

Performance is solid. Pricing: $0.008/credit pay-as-you-go, Monthly plans start around $30/month for ~4,000 credits.

Best for: RAG pipelines built on LangChain or LlamaIndex where developer experience and quick integration matter more than maximum accuracy.

Alternatives for Sonar Deep Research Specifically

sonar-deep-research occupies a specific niche: multi-step autonomous research that produces comprehensive reports, not just answers. The use case is different from standard search. You’re asking it to do what a human researcher would do over an hour, not just answer a question.

The key question is what you actually need from a deep research API:

1. Multi-step search execution (runs multiple queries, synthesizes results)
2. Citations and source references in the output
3. Access to authoritative data sources, not just indexed web pages
4. Structured output or webhook support for long-running tasks

On criteria 1, 2, and 3, Valyu’s DeepResearch API is the only alternative that matches sonar-deep-research functionally while expanding what it can do.

# Valyu DeepResearch - multi-step autonomous research
# with access to SEC filings, PubMed, academic journals

from valyu import Valyu

client = Valyu(api_key="YOUR_API_KEY")

# Create an async DeepResearch task
task = client.deepresearch.create(
    query="Analyze the financial health of Tesla based on recent SEC filings and analyst sentiment",
    mode="standard",  # also supports: "fast", "heavy", "max"
    output_formats=["markdown"],
    search={
        "search_type": "proprietary",
        "included_sources": ["finance", "academic"]
    }
)

if task.success:
    print(f"Task created: {task.deepresearch_id}")

    # Wait for completion with progress updates
    result = client.deepresearch.wait(
        task.deepresearch_id,
        on_progress=lambda s: print(f"Status: {s.status}")
    )

    if result.status == "completed":
        print(result.output) # markdown report
        print(result.sources)  # cited sources with URLs
        print(result.cost) # fixed task cost

The difference that matters for serious use cases: when Sonar Deep Research researches “clinical trial outcomes for GLP-1 receptor agonists,” it’s searching whatever’s publicly indexed on the web. When Valyu DeepResearch does the same query, it’s searching PubMed, ClinicalTrials.gov, FDA drug labels, ChEMBL, and Open Target where the actual source databases where this research lives.

For financial research: Valyu reads the actual 10-K filings, earnings transcripts, and insider trading data. Sonar reads articles about those filings.

Pricing comparison for deep research:

Valyu also supports webhooks (for async long-running tasks), file analysis, and follow-up instructions, features the Sonar Deep Research endpoint doesn’t offer.

Head-to-Head Comparison Table

Which Alternative for Which Use Case

Building a RAG pipeline on LangChain/LlamaIndex?
Start with Tavily. It’s the path of least resistance and performs well. If you hit accuracy issues or need data beyond the public web, move to Valyu.

Building anything that touches financial data?
Valyu. SEC filings, earnings data, stock prices, FRED economic data, balance sheets, insider trading, all in one API call. No other search API comes close for this use case.

Building biomedical or clinical research tools?
Valyu. PubMed, bioRxiv, ClinicalTrials.gov, ChEMBL, DrugBank, Open Targets, FDA drug labels. The Bio app (310 GitHub stars) is a live demo of what’s possible.

Need multi-step autonomous research (replacing sonar-deep-research)?
Valyu DeepResearch API. It’s the only deep research API that combines multi-step synthesis with access to authoritative specialised databases, plus structured output formats and webhook support.

Pure web search with transparent pricing, no specialised data needed?
Linkup for pricing predictability.

A Note on What Sonar Does Well

Sonar has strong developer documentation, an OpenAI-compatible API format that makes migration easy, and solid performance for general web Q&A tasks. The sonar-reasoning-pro model is genuinely useful for chain-of-thought web-grounded reasoning.

The limitations documented here are real, but they’re architectural constraints that come from being a secondary product of a consumer AI company, most likely not signs of bad engineering. If your use case is pure web Q&A at scale and you’re happy with the public web as your data universe, Sonar is a viable choice.

The alternatives above exist for when those constraints become blockers.

FAQ

What is the best alternative to Perplexity Sonar API?
Valyu DeepSearch for developers who need specialised data access (finance, biomedical, academic) or benchmark-leading accuracy. Linkup for predictable pricing and architectural control. Tavily for the fastest LangChain/LlamaIndex integration.

What is the best alternative to Perplexity Sonar Deep Research?
Valyu’s DeepResearch API is the only alternative that matches sonar-deep-research on multi-step research synthesis while also accessing SEC filings, PubMed, academic journals, and clinical trial data that Sonar cannot reach.

Is Perplexity Sonar web-only?
Yes. All Sonar models (Sonar, Sonar Pro, Sonar Reasoning, Sonar Reasoning Pro, Sonar Deep Research) search only the public web and Perplexity’s index. They have no access to SEC filings, academic databases, clinical trials, or other specialised data sources.

Why is Sonar API unreliable?
Perplexity’s primary product is a consumer chatbot. The API is a secondary product. Developer forums document 20+ daily outages with no reflection on the official status page. The API capacity and reliability engineering reflects these priorities.

Does Perplexity Sonar have an MCP integration?
Yes. Sonar offers a Model Context Protocol server. Valyu also does. It can be added to Claude Desktop, Cursor, and other MCP-compatible environments with one command: npx skills add valyuAI/skills.

How does sonar-deep-research pricing work?
Sonar Deep Research charges $2/million input tokens, $8/million output tokens, $5 per 1,000 searches (a single request might trigger 30 searches = $0.15 in search fees alone), and $3/million reasoning tokens. The total cost per request is hard to predict and can range significantly based on query complexity.

AI Agent Database Blast-Radius Prevention Kit: Stop Your Agent From Torching Production Data

If you’ve spent any time wiring AI agents to databases, you’ve probably had that stomach-drop moment. The agent misinterprets an ambiguous instruction, constructs a plausible-looking DELETE statement, and suddenly you’re explaining to your team why 40,000 user records are gone. I’ve been there. The worst part isn’t the incident itself — it’s realizing the guardrails you thought were in place were more like suggestions the model cheerfully ignored when it got confident enough.

The problem compounds fast when you’re building autonomous agents that chain multiple database operations. A single misread context window mid-task can cascade: an UPDATE without a WHERE clause, a truncation that looked like a targeted cleanup, a schema migration running against the wrong environment because the connection string came from an env var that got shadowed. These aren’t hypothetical edge cases. They’re the normal failure modes of giving an LLM direct database access without a structured containment layer.

What Most Developers Try First

The usual responses are README warnings (“always review before executing”), basic read-only roles, or wrapping everything in a transaction with a manual rollback step. These help, but they break down in practice. Read-only roles block your agent’s legitimate write tasks. Manual review defeats the autonomy you’re building toward. Transactions give you rollback capability but don’t prevent the agent from generating destructive SQL in the first place, and they don’t give you visibility into why a particular query got constructed. You end up with either an over-restricted agent or one with enough rope to hang your schema.

A Structured Containment Approach

A more durable approach centers on three layers working together: pre-execution query analysis, scoped execution environments, and an audit trail tied to agent reasoning. The query analysis step catches structural red flags before anything touches the database — unqualified mass updates, DDL statements outside designated migration contexts, operations on tables flagged as protected. This isn’t just regex pattern matching; it involves parsing the query AST to understand scope and surface area, then comparing against a defined risk threshold for the current agent task.

The scoped execution layer handles the environment problem. Each agent session gets a permission profile derived from its declared task intent, not just its role. An agent summarizing quarterly data gets SELECT on reporting views. An agent running a backfill job gets time-boxed write access to specific tables with row-count caps enforced at the middleware level. If the agent tries to exceed that scope — even with valid credentials — the request is blocked and logged with context.

# Simplified blast-radius check before execution
def check_query_risk(query: str, task_context: TaskContext) -> RiskAssessment:
    parsed = parse_sql_ast(query)
    affected_tables = extract_affected_tables(parsed)
    operation_type = classify_operation(parsed)  # SELECT/DML/DDL

    if operation_type in ("DROP", "TRUNCATE") and not task_context.allows_ddl:
        return RiskAssessment(blocked=True, reason="DDL not permitted in this task scope")

    estimated_rows = estimate_affected_rows(parsed, task_context.db_connection)
    if estimated_rows > task_context.row_limit:
        return RiskAssessment(blocked=True, reason=f"Estimated {estimated_rows} rows exceeds limit")

    return RiskAssessment(blocked=False, estimated_rows=estimated_rows)

The audit trail piece is what actually helps you debug and improve. Each blocked or flagged operation gets stored with the agent’s chain-of-thought excerpt, the raw query, the parsed risk factors, and the task context at that moment. This gives you a feedback loop — you can see whether your limits are miscalibrated, whether certain prompt patterns consistently produce risky queries, and where legitimate agent tasks are getting incorrectly blocked.

Quick Start

• Define your protected tables in a manifest file — schemas, tables, and the operations that require elevated justification
• Instrument your database call layer to route all agent-generated queries through the AST parser before execution
• Create task profiles that map declared agent intents to specific permission sets and row-count thresholds
• Set up shadow mode first — run the risk checks in logging-only mode for a week before enforcing blocks, so you can tune thresholds without disrupting current workflows
• Wire the audit log to your existing observability stack (

Get ready! Javiera Electra lit up KEXP Live in Bilbao, performing “La llorona / Espadámbar” from the awesome Iglesia de la Encarnación. Electra Hernández totally nailed it on acoustic guitar and vocals, backed by a tight crew including Oscar Hernández, Frauke Steinhofel, and Franco Ibacache.

This sweet gig was a team effort by KEXP and BIME, captured on October 29, 2025 (yep, a trip to the future!) and supported by Sounds from Spain and more. It’s a whole vibe!

Watch on YouTube

UI freezes are among the most frustrating issues plugin developers encounter. Investigating them can be particularly challenging due to the complexity of concurrent programming. What makes things even trickier is that UI freezes in JetBrains IDEs are not always caused by heavy work on the event dispatch thread.

On Thursday, March 19, at 03:00 PM UTC, join us for a live session with Yuriy Artamonov, Product Manager for the IntelliJ Platform at JetBrains, hosted by Patrick Scheibe, IntelliJ Platform Developer Advocate. Together, they’ll explore common causes of UI freezes in JetBrains IDE plugins and share practical strategies to prevent them.

During the livestream, we’ll dig into several surprisingly common problems that affect many plugins, including:

• Long-running non-cancellable read actions
• Network calls made while holding a read lock
• Misuse of external processes

You’ll also learn:

• Why APIs like ReadAction.compute and runReadAction can block write actions and freeze the UI even when your code doesn’t run on the event dispatch thread
• Which patterns to avoid when working with read actions and background tasks
• How to write cancellable, freeze-safe plugin code that keeps JetBrains IDEs fast and responsive

Whether you’re new to plugin development or have already published plugins on JetBrains Marketplace, this session will help you better understand common causes of UI freezes and how to avoid them in your own code.

At the end of the session, stay for a live Q&A where you’ll have the chance to ask questions and discuss real-world scenarios with our experts.

Speaking to you:

Yuriy Artamonov is a Software Developer in IntelliJ Platform at JetBrains. Yuriy has been developing libraries, frameworks, and tools for developers for the past 15 years. As a member of the JetBrains IntelliJ Platform team, Yuriy loves introducing useful new tools to the daily routines of millions of developers around the world. His professional aspiration is to raise the bar of the software industry by helping developers improve their craft.

Exciting news! The Computer Science and Artificial Intelligence bachelor’s program at Neapolis University Pafos is hosting an Open Day on March 29.

This event is a great opportunity to meet the professors and current students, learn how the program works, and see the campus in person.

The CSAI program is supported by the JetBrains Foundation, which provides full scholarships for talented students. These scholarships cover all essential costs:

• Tuition
• Accommodation
• Medical insurance
• Visa fees
• A monthly allowance of €300

Up to 40 scholarships are available this year.

Open Day

Date: Sunday, March 29, 2026

Time: 11:30 – 15:00 

Location: Neapolis University Pafos (Kyrenia and Ammochostos auditoriums)