Created
July 23, 2026 01:14
-
-
Save mattmakai/7afbc90497f0850a93b801eb93643949 to your computer and use it in GitHub Desktop.
Plushcap guidance for evaluating developer trends
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # A Practical Framework for Evaluating Developer Trends | |
| Use this document as a personal playbook or give it to an AI assistant as the instructions for evaluating a developer trend. Replace every value in `<angle brackets>` before beginning. | |
| The goal is not to predict which idea will become popular. The goal is to decide whether **you** should spend scarce career time on it, based on evidence that becomes available over three horizons: | |
| | Horizon | Time | Primary question | Best evidence | | |
| | --- | --- | --- | --- | | |
| | Short term | First 1–2 weeks | Is it real and useful now? | Hands-on experience and technical taste | | |
| | Medium term | Weeks 3–8 | Is there independent depth behind the excitement? | Repeated use, developer reactions, technical content, and product activity | | |
| | Long term | Week 8 onward | Is investment continuing and broadening? | Multi-month data, company breadth, products, competitors, startups, jobs, and infrastructure | | |
| Do not collapse these horizons into one popularity score. A viral launch can pass the short-term attention test while failing the hands-on test. A valuable technology can also look quiet before its growth curve inflects. | |
| --- | |
| ## Evaluation brief | |
| Start with this information: | |
| - **Trend:** `<name the concept, not only one product>` | |
| - **Implementations:** `<products, projects, libraries, protocols, or vendors>` | |
| - **Why it may matter:** `<one-sentence hypothesis>` | |
| - **Career goal:** `<what you want more of during the next 12–24 months>` | |
| - **Relevant domain:** `<your role, industry, or technical specialty>` | |
| - **Available time:** `<hours per week>` | |
| - **Evaluation start date:** `<YYYY-MM-DD>` | |
| - **Next checkpoint:** `<YYYY-MM-DD>` | |
| Separate a **concept** from its **implementations**. “Container orchestration” is a trend; Kubernetes is one implementation. “Local AI” is a trend; MLX, llama.cpp, Ollama, and LM Studio are implementations. A product can fade while the underlying concept grows. | |
| Write an initial falsifiable hypothesis: | |
| > I believe `<trend>` will become more important to `<people or organizations>` because `<mechanism>`. I would change my mind if `<observable evidence>` occurs by `<date>`. | |
| Also write the opportunity cost: what will you *not* learn, build, or ship if you choose this trend? | |
| --- | |
| ## Evidence rules | |
| Apply these rules throughout the evaluation: | |
| 1. **Date every observation.** Trend claims decay quickly. | |
| 2. **Distinguish observation from interpretation.** “Twenty companies published about it” is an observation. “It has durable demand” is an interpretation. | |
| 3. **Prefer repeated behavior to stated enthusiasm.** Shipped features, maintained projects, hiring, integrations, and technical postmortems are stronger than announcements. | |
| 4. **Measure breadth as well as volume.** One prolific company can manufacture many mentions. Independent activity across many companies is a stronger signal. | |
| 5. **Compare multiple windows.** Week-over-week data is noisy. Use it to find questions, then inspect 4-, 8-, 12-, and 52-week trajectories where available. | |
| 6. **Treat projections and partial periods explicitly.** Never compare an incomplete week or month with a complete one without labeling the projection. | |
| 7. **Look for mechanism, not just correlation.** Explain what is causing adoption: lower cost, a new capability, regulation, hardware improvements, platform distribution, or another driver. | |
| 8. **Actively seek disconfirming evidence.** Record failure modes, stalled projects, critical technical writing, declining breadth, and reasons teams stop using the technology. | |
| 9. **Do not mistake content for adoption.** Content is evidence of attention and investment. Validate usage with product releases, repositories, jobs, case studies, or your own experience. | |
| 10. **Let personal fit affect the bet, not the facts.** A durable trend can still be the wrong investment for your interests and goals. | |
| Maintain an evidence ledger: | |
| | Date | Horizon | Claim | Observation/source | Supports or challenges? | Confidence | | |
| | --- | --- | --- | --- | --- | --- | | |
| | `<date>` | Short/medium/long | `<claim>` | `<what you observed and where>` | Support/challenge | Low/medium/high | | |
| --- | |
| ## Use Plushcap as the trend-data layer | |
| [Plushcap](https://www.plushcap.com/) tracks developer-focused companies, engineering content, industry topics, Hacker News activity, and YouTube metrics. Its MCP server lets an MCP-compatible AI client query that data while it performs the evaluation. | |
| Plushcap is a supporting evidence source, not an oracle. Its content data is especially useful for measuring attention, persistence, company breadth, vocabulary, product activity, and competitive movement. Combine it with hands-on work and direct adoption evidence. | |
| ### Connect without an account | |
| The anonymous preview is read-only and intentionally limited. It provides six tools, including topic discovery, an eight-week trend snapshot, recent posts, and recent company activity. | |
| Codex: | |
| ```bash | |
| codex mcp add plushcap-demo --url https://mcp.plushcap.com/try/mcp | |
| ``` | |
| Claude Code: | |
| ```bash | |
| claude mcp add --transport http --scope user plushcap-demo https://mcp.plushcap.com/try/mcp | |
| ``` | |
| The preview currently exposes `list_trend_topics`, `get_trend_snapshot`, `search_recent_posts`, `get_recent_company_activity`, `list_companies`, and `get_company`. Its windows and result counts are fixed, so describe those limits in any conclusion. | |
| ### Connect for full analysis | |
| The authenticated streamable HTTP endpoint is: | |
| ```text | |
| https://mcp.plushcap.com/mcp | |
| ``` | |
| Codex: | |
| ```bash | |
| codex mcp add plushcap --url https://mcp.plushcap.com/mcp | |
| codex mcp login plushcap | |
| codex mcp list | |
| ``` | |
| Claude Code: | |
| ```bash | |
| claude mcp add --transport http --scope user plushcap https://mcp.plushcap.com/mcp | |
| ``` | |
| Then use `/mcp` in Claude Code to authenticate. Other compatible clients can use OAuth or send a Plushcap API key as a bearer token. See the current [Plushcap MCP documentation](https://www.plushcap.com/docs/mcp) for ChatGPT setup, API-key configuration, and client-specific details. | |
| ### Query sequence | |
| Ask the AI assistant to use Plushcap in this order. Let the client select the applicable tool names; the authenticated catalog may be broader than the anonymous preview. | |
| 1. **Resolve the topic.** List tracked trend topics. Find the closest topic and inspect its keywords. If no exact topic exists, identify adjacent topics and state the coverage gap. | |
| 2. **Establish a baseline.** Retrieve the longest relevant history available, plus 4-, 8-, and 12-week views. Capture mentions, posts, unique companies, and changes over time. | |
| 3. **Measure breadth.** Determine whether activity is spreading across independent companies or concentrated in a few publishers. Name the leading companies and their share when available. | |
| 4. **Inspect the underlying content.** Retrieve recent and representative posts. Classify them as announcements, tutorials, comparisons, integrations, benchmarks, case studies, operational lessons, security discussions, or criticism. | |
| 5. **Find product behavior.** Look for shipped features, integrations, production stories, maintenance work, and follow-on releases—not just introductory explainers. | |
| 6. **Map adjacent movement.** Query related trends, enabling technologies, substitutes, and implementations. The concept may be growing even when a particular product is declining. | |
| 7. **Find counterevidence.** Search for declining periods, shrinking company breadth, repetitive SEO content, abandoned implementations, or a failure to progress from introductory to operational material. | |
| 8. **Record freshness and limits.** State the data-through date, query window, partial periods, projections, missing sources, and preview limitations. | |
| Useful questions to ask through the MCP-connected assistant: | |
| - “Which tracked topic and keywords best represent `<trend>`? What important vocabulary is missing?” | |
| - “Show its weekly and monthly trajectory over the longest available window. Separate complete periods from projections.” | |
| - “Is growth coming from more unique companies, more posts per company, or more mentions per post?” | |
| - “Which independent companies have sustained activity for at least four weeks?” | |
| - “Classify recent posts by evidence depth. How much is introductory content versus product releases, benchmarks, case studies, or operational lessons?” | |
| - “Which adjacent trends are rising or falling at the same time, and what mechanism could connect them?” | |
| - “Find the strongest evidence against the claim that this trend is durable.” | |
| - “What observation during the next four weeks would most update this evaluation?” | |
| --- | |
| ## Horizon 1: short-term evidence (first 1–2 weeks) | |
| Get hands-on as soon as possible. At the beginning of a trend, direct experience is unusually valuable because most commentary comes from people who have not built with it. | |
| ### Required experiment | |
| Build the smallest real artifact that exercises the trend’s core claim. Do not settle for watching a demo. Use realistic inputs and attempt at least one task that matters to you. | |
| Record: | |
| - Time to first useful result | |
| - Setup, access, cost, and dependency friction | |
| - What became possible, faster, cheaper, or easier | |
| - Where the abstraction leaked or the “magic” broke | |
| - Reliability under a second and third attempt | |
| - Whether the implementation solved a real problem or merely moved complexity | |
| - Safety, security, privacy, and lock-in concerns | |
| - Whether you wanted to continue after the novelty wore off | |
| If the trend cannot be tried because it is waitlisted, enterprise-only, unaffordable, or demo-only, count that as negative short-term evidence unless restricted access is inherent to the domain. | |
| ### Short-term gate | |
| Choose one: | |
| - **Pass:** A real capability or meaningful improvement is visible, the mechanism makes sense, and you can name a useful next experiment. | |
| - **Watch:** The core idea is plausible, but access, reliability, cost, or relevance prevents a fair test. | |
| - **Fail:** The demo does not survive real use, recreates an existing solution with more complexity, or has no fit with your goals. | |
| Do not make a year-long commitment here. The maximum decision is a four-to-six-week exploration. | |
| --- | |
| ## Horizon 2: medium-term evidence (weeks 3–8) | |
| Now calibrate your experience against independent activity. The question is whether the trend develops depth after launch excitement. | |
| Repeat or expand your experiment and examine: | |
| - Does it still solve the original problem after several weeks? | |
| - Is sentiment becoming more technically specific? | |
| - Are independent developers reporting similar benefits and limitations? | |
| - Are companies shipping integrations and follow-on features? | |
| - Is content progressing from “what is it?” to architecture, benchmarks, security, operations, and tradeoffs? | |
| - Are multiple companies participating, or is one vendor driving the narrative? | |
| - Are adjacent tools, standards, or services forming around it? | |
| - Have credible critics identified a fatal flaw, a temporary limitation, or a useful boundary? | |
| Use Plushcap to compare the current week with multi-week and monthly trends. A large weekly percentage off a tiny base is a lead to investigate, not a conclusion. | |
| ### Medium-term gate | |
| Choose one: | |
| - **Pass:** Your repeated use remains valuable; activity persists across several weeks; company breadth or implementation depth is growing; and the conversation is becoming more operational. | |
| - **Watch:** Evidence is mixed, concentrated, or too young. Set one specific next observation and a review date. | |
| - **Fail:** Breadth collapses, content remains repetitive, products stop shipping, or repeated use does not justify the friction. | |
| --- | |
| ## Horizon 3: long-term evidence (week 8 onward) | |
| At this stage, favor sustained behavior and multi-month data over social-media mood. Once a trend becomes familiar, it may become fashionable to declare it dead even while investment continues. | |
| Assess: | |
| - **Trajectory:** Is the 12- or 52-week baseline rising, stable, cyclical, or decaying? | |
| - **Breadth:** Are more independent companies, projects, and domains participating? | |
| - **Depth:** Are teams publishing production details, benchmarks, migrations, security practices, and failure reports? | |
| - **Economic investment:** Are startups forming, incumbents launching features, customers paying, and employers hiring? | |
| - **Ecosystem formation:** Are complementary tools, standards, training materials, and infrastructure appearing? | |
| - **Durability mechanism:** What external force keeps improving the trend—hardware, cost curves, regulation, distribution, or a platform shift? | |
| - **Substitution risk:** Could the capability become a hidden feature, be absorbed by a platform, or be replaced by a simpler approach? | |
| - **Career transferability:** Will the skills remain useful if today’s leading implementation loses? | |
| ### Long-term gate | |
| Choose one: | |
| - **Invest:** Hands-on value, persistent breadth, product depth, and career fit reinforce one another. | |
| - **Maintain a small option:** The trend is plausible but uncertain; continue a low-cost project and review monthly. | |
| - **Stop:** The original mechanism is invalid, activity is decaying or artificial, or another trend offers much better personal leverage. | |
| --- | |
| ## Score only after writing the evidence | |
| Scores are a forcing function, not a substitute for judgment. Assign each dimension `0` (negative), `1` (mixed/unknown), or `2` (strong): | |
| | Dimension | Score | Evidence | | |
| | --- | ---: | --- | | |
| | Hands-on capability and usefulness | `/2` | `<evidence>` | | |
| | Repeated usefulness and reliability | `/2` | `<evidence>` | | |
| | Personal interest and career leverage | `/2` | `<evidence>` | | |
| | Persistence across multiple windows | `/2` | `<evidence>` | | |
| | Independent company/project breadth | `/2` | `<evidence>` | | |
| | Progression from hype to operational depth | `/2` | `<evidence>` | | |
| | Product, startup, customer, or hiring investment | `/2` | `<evidence>` | | |
| | Ecosystem and complementary infrastructure | `/2` | `<evidence>` | | |
| | Durable underlying mechanism | `/2` | `<evidence>` | | |
| | Resistance to counterevidence and substitution | `/2` | `<evidence>` | | |
| | **Total** | **`/20`** | | | |
| Interpret the score together with the horizon gates: | |
| - **0–7 — Do not invest:** Save your time unless the evidence changes materially. | |
| - **8–12 — Watch:** Review monthly; spend no more than one hour per week. | |
| - **13–16 — Explore:** Run a bounded four-to-six-week project at two to four hours per week. | |
| - **17–20 — Invest:** Make a meaningful three-month bet, typically five to ten hours per week or an equivalent work project. | |
| Do not choose “Invest” if the short-term hands-on test failed. Do not let a high mention count compensate for zero personal or career fit. Adjust the suggested hours to your real capacity; the relative commitment matters more than the number. | |
| --- | |
| ## Produce the final trend memo | |
| Use this exact structure so evaluations remain comparable over time: | |
| ```markdown | |
| # <Trend> evaluation — <date> | |
| ## Decision | |
| Invest / Explore / Watch / Do not invest | |
| Time allocation: <hours per week> through <review date> | |
| Confidence: Low / Medium / High | |
| ## One-sentence thesis | |
| <Who benefits, what changes, and why now?> | |
| ## Concept and implementations | |
| <Separate the durable concept from current products or projects.> | |
| ## Evidence by horizon | |
| ### Short term | |
| <What I built, what worked, what broke, and the gate result.> | |
| ### Medium term | |
| <Repeated-use results, reactions, product/content depth, Plushcap trend and breadth data, and the gate result.> | |
| ### Long term | |
| <Multi-month trajectory, investment, ecosystem, durability mechanism, substitution risk, and the gate result.> | |
| ## Plushcap findings | |
| - Data through: <date> | |
| - Windows examined: <windows> | |
| - Topic and tracked keywords: <topic/keywords> | |
| - Mentions/posts/company breadth: <key observations> | |
| - Representative companies and content: <observations> | |
| - Adjacent trends: <observations> | |
| - Limits, partial periods, and projections: <caveats> | |
| ## Strongest counterevidence | |
| <The best case that this trend is temporary, overstated, or irrelevant to me.> | |
| ## Score | |
| <Total>/20, with one sentence explaining the most uncertain dimensions. | |
| ## Next action | |
| <A concrete project, learning objective, or stop decision.> | |
| ## What would change my mind | |
| <Observable signal, threshold, and date.> | |
| ## Next review | |
| <YYYY-MM-DD> | |
| ``` | |
| --- | |
| ## Reusable prompt for an MCP-connected AI assistant | |
| Copy the following prompt into a client connected to Plushcap: | |
| ```text | |
| Evaluate the developer trend below using the short-, medium-, and long-term evidence framework in this document. | |
| Trend: <trend> | |
| Implementations: <products/projects, if known> | |
| My career goal: <goal> | |
| My relevant experience: <experience> | |
| My available time: <hours per week> | |
| Evaluation start date: <date> | |
| Use the Plushcap MCP server for current trend, company, and content evidence. First resolve the closest tracked topic and inspect its keywords. Then examine multiple time windows, separating mentions, posts, and unique-company breadth. Inspect representative underlying content, distinguish announcements and introductory posts from shipped features, benchmarks, case studies, and operational lessons, and find the strongest counterevidence. Query adjacent concepts and implementations so a product's trajectory is not confused with the broader trend. | |
| Do not invent unavailable data. State the data-through date, query windows, partial periods, projections, topic-coverage gaps, and any limits of the anonymous preview. Treat Plushcap content activity as evidence of attention and investment, not proof of adoption. | |
| Ask me for the results of a hands-on experiment if I have not supplied them. Until then, mark hands-on claims unknown and give me the smallest useful experiment to run. Do not make a final Invest decision without direct experience. | |
| Return the final trend memo in the specified structure. Make the recommendation personal to my stated goal, give a bounded time allocation and review date, and name the observable evidence that would change the decision. | |
| ``` | |
| --- | |
| ## Cadence | |
| - **During weeks 1–2:** Keep a short daily experiment log. | |
| - **During weeks 3–8:** Update the evidence ledger weekly and rerun Plushcap comparisons on the same day of the week. | |
| - **After week 8:** Review monthly or when a predefined disconfirming signal fires. | |
| - **Every three months:** Compare this trend with at least two alternative uses of the same time. | |
| The process is successful when it helps you commit earlier to a durable trend, stop sooner when evidence weakens, and explain both decisions without relying on vibes alone. | |
| --- | |
| *Adapted from Matt Makai’s “Developer Trends to Bet the Next Year of Your Career On” framework. Trend research can be performed with [Plushcap](https://www.plushcap.com/) and its [MCP server](https://www.plushcap.com/docs/mcp).* |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment