DEV Community

Part 15: Workflow Patterns and Recipes - Data Transformation

Nick — Fri, 26 Jun 2026 08:03:00 +0000

As we conclude this 15-part series on Vyshyvanka, we want to leave you with practical tools. One of the most common challenges in workflow automation is not moving data, but transforming it. Today, we look at the patterns we use to map, clean, and reshape data as it flows through your pipelines.

The Transformation Challenge

In a real-world workflow, you rarely get the data exactly in the format you need. Service A might return a deeply nested JSON object, while Service B expects a flat structure with different field names. Vyshyvanka handles this through its expression engine and Code Node — giving you both declarative and programmatic transformation options.

Pattern 1: Path Projection with Expressions

When you have a large JSON response and only need specific values, use expressions in your node configuration to extract exactly what you need:

{{ nodes.api.data.items[0].user.id }}

This plucks a deeply nested ID from an API response and passes it as a clean input to your next node. You can use this directly in any node's configuration field.

For more complex extraction, combine with built-in functions:

{{ toUpper(nodes.api.data.items[0].user.name) }}
{{ concat(nodes.user.data.firstName, " ", nodes.user.data.lastName) }}
{{ coalesce(nodes.api.data.nickname, nodes.api.data.name, "Anonymous") }}

Pattern 2: Structural Remapping with Code Nodes

When you need to transform the entire shape of the data, the Code Node is your best tool. It supports two runtimes:

JavaScript (via Jint engine):

General-purpose JavaScript for complex transformations. You have access to:

input — the full input data from upstream nodes
executionId — current execution ID
workflowId — current workflow ID
log(message) — logging that appears in execution output
getItems() — returns input as an array (wraps single values)
toJson(value) — serializes a value to a JSON string

// Remap an API response to a different structure
log("Transforming user data: " + input.email);
return {
    email: input.email.toLowerCase(),
    fullName: input.firstName + " " + input.lastName,
    isVerified: input.status === "active",
    createdYear: new Date(input.createdAt).getFullYear()
};

JSONata:

A declarative query and transformation language, ideal for complex path selection and restructuring:

{
    "users": items.{
        "id": userId,
        "name": firstName & " " & lastName,
        "active": status = "active"
    },
    "total": $count(items)
}

JSONata shines when you need to reshape deeply nested structures without imperative loop code.

Pattern 3: Batch Processing with runForEachItem

Both JavaScript and JSONata support two execution modes:

runOnce: Executes your code against the full input object. Use this for single-item transformations or when you need access to the entire dataset.
runForEachItem: If your input is an array, the engine executes your logic for every item, collecting the results into a new array.

// Mode: runForEachItem
// 'input' here is a single item from the array
return {
    id: input.id,
    label: input.name.toUpperCase(),
    processed: true
};

This is the equivalent of a .map() operation, but managed by the engine with proper error handling and logging for each item.

Pattern 4: Conditional Routing with Logic Nodes

Not all transformation is about reshaping data — sometimes you need to route data differently based on its content. The Switch node evaluates a value and routes to different output ports:

Configure the switch value: {{ nodes.api.data.status }}
Define cases: "active" → port A, "suspended" → port B, default → port C

Each downstream branch can then apply its own transformation logic appropriate to that case.

The If node handles binary decisions:

Condition: {{ nodes.check.data.amount }} > threshold
True branch: process normally
False branch: send alert

Pattern 5: Aggregation with Loop + Merge

For workflows that need to process a collection and then aggregate the results:

Loop Node: Iterates over an array, executing a subgraph for each item.
Subgraph nodes: Transform/enrich each item (API calls, lookups, etc.).
Loop completion: The loop node collects all outputs from its "done" port.
Merge Node: Combines data from multiple branches into a single object.

The loop node exposes per-iteration context:

{{ nodes.loop.data.index }}        // Current iteration index
{{ nodes.loop.data.item }}         // Current item
{{ nodes.loop.data.isFirst }}      // Boolean
{{ nodes.loop.data.isLast }}       // Boolean
{{ nodes.loop.data.totalCount }}   // Total items

Pattern 6: Data Enrichment Pipeline

A common pattern is fetching additional data for each item in a collection:

HttpRequest → Get list of orders from API
Loop → For each order:
- HttpRequest → Fetch customer details by {{ nodes.loop.data.item.customerId }}
- Code Node → Merge order + customer into enriched object
DatabaseQuery → Store enriched results

Each step references the previous step's output through expressions, creating a data pipeline that transforms raw API responses into enriched, business-ready objects.

Best Practices

Keep transformations close to their consumer: Transform data in the node configuration or a Code Node immediately before the node that needs it.
Use expressions for simple extractions: {{ nodes.api.data.user.name }} is clearer than a Code Node for simple path access.
Use Code Nodes for complex logic: Multi-field remapping, conditional logic, and calculations belong in Code Nodes where they are testable and readable.
Prefer JSONata for pure data reshaping: When you are only restructuring JSON without side effects, JSONata expressions are more concise than JavaScript.
Use runForEachItem for array transformations: It handles iteration, error collection, and result aggregation automatically.

Wrapping Up the Series

We hope this series has shown you that Vyshyvanka is built for the real world — secure, extensible, and performant. We started with basic triggers and ended with complex data transformation patterns. The platform gives you the building blocks; how you combine them is up to your creativity.

The community is the final piece of the puzzle. Now it is your turn. Go build something, share your custom nodes, and let us know what you think.

Check out the project source code here: https://github.com/homolibere/Vyshyvanka

كيفية تقييم أدوات الذكاء الاصطناعي لتحقيق إنتاجية حقيقية — shipping

Med Stream — Fri, 26 Jun 2026 08:00:15 +0000

كيفية تقييم أدوات الذكاء الاصطناعي لتحقيق إنتاجية حقيقية — shipping

لم يعد تطوير البرمجيات المفتوحة المصدر مجرد كتابة أكواد ونشرها على منصات المشاركة، بل أصبح سير عمل متكاملاً يعتمد على التكرار السريع، والأتمتة الذكية، والمراجعة الدقيقة. وفي قلب هذه التحولات تقف مكتبات مثل huggingface_hub، التي أصبحت شرياناً حيوياً يربط بين باحثي الذكاء الاصطناعي ومطوري التطبيقات حول العالم. لكن السؤال الذي يطرح نفسه: كيف يمكن إصدار نسخ جديدة من مثل هذه المكتبات بوتيرة أسبوعية دون المساس باستقرارها أو أمانها؟ الإجابة تكمن في مزيج متوازن من ثلاثة عناصر: الذكاء الاصطناعي الذي يُسرّع الإنتاجية، الأدوات المفتوحة التي تبني البنية التحتية، والإنسان في الحلقة الذي يضمن أن تبقى القرارات الفنية والأخلاقية في أيدٍ أمينة.

الإصدار الأسبوعي: فلسفة التطوير المستمر وقليل التكلفة

عندما يُفكر الفرق التقنية في إطلاق إصدارات جديدة، غالباً ما تتبادر إلى الذهن صورة إصدارات ضخمة تأتي كل بضعة أشهر محملة بمئات التغييرات. لكن هذا النموذج أثبت عبر السنوات أنه يحمل في طياته مخاطر تراكمية؛ فكلما طال الفاصل بين إصدارين، زادت كمية الأكواد التي يجب دمجها واختبارها، وتعقدت عملية تتبع الأخطاء. هنا تبرز فلسفة الشحن الأسبوعي كبديل عملي ومستدام.

التكرار الأسبوعي لا يعني بالضرورة إضافة ميزات ثورية في كل مرة، بل يعني تقليص حجم التغييرات إلى وحدات صغيرة يمكن فحصها واختبارها بسهولة. فبدلاً من دمج عشرات الطلبات البرمجية دفعة واحدة، يتم دمج كل طلب على حدة بعد اجتيازه لجولات من الفحص والتقييم. هذه الطريقة تمنح الفريق القدرة على اكتشاف الانحدارات في الأداء بشكل مبكر، وتقلل من ضغط العمل المتراكم على المشرفين، وتمنح المستخدمين تجربة أكثر سلاسة في التحديث.

إن سرعة التكرار هذه تتطلب بنية تحتية مرنة. فالنظام الذي يعتمد على عمليات يدوية في بناء الحزم واختبارها ونشرها لا يمكنه الصمود أمام إيقاع أسبوعي. ومن هنا يأتي دور الأتمتة كشرط أساسي لنجاح هذه الفلسفة، حيث يجب أن تكون عمليات الاختبار والبناء والنشر مؤتمتة بالكامل تقريباً، مع ترك مساحة للتدخل البشري في النقاط الحرجة فقط.

الذكاء الاصطناعي: مسرّع الإنتاجية وليس بديلاً عن المبرمج

لطالما كان الحلم هو وجود آلة تكتب البرمجيات بديلة عن البشر، لكن الواقع العملي أثبت أن الذكاء الاصطناعي يتألق أكثر عندما يكون مساعداً وليس محلّاً. في سير عمل مثل سير عمل huggingface_hub، تُستخدم نماذج اللغة الكبيرة وأدوات الذكاء الاصطناعي لتحمل المهام المتكررة والاستهلاكية للوقت، مما يحرر المطورين للتركيز على التصميم المعماري وحل المشكلات المعقدة.

من أبرز الاستخدامات العملية للذكاء الاصطناعي في هذا السياق:

صياغة الوثائق والشروحات البرمجية: يمكن للنماذج اللغوية أن تقترح مسوّدات أولية للتوثيقات التقنية، أو أن تولد تعليقات توضيحية للدوال البرمجية بناءً على سياقها، مما يوفر ساعات من العمل اليدوي.
توليد حالات الاختبار: عند إضافة ميزة جديدة، يستطيع الذكاء الاصطناعي اقتراح حالات اختبار تغطي المسارات الرئيسية والحالات الحدّية، بناءً على تحليل الكود المُقدّم.
المراجعة الأولية للأكواد: أدوات الذكاء الاصطناعي يمكنها أن تفحص الطلبات البرمجية بحثاً عن أنماط شائعة من الأخطاء، أو مشكلات الأمان البسيطة، أو مخالفات دليل الأسلوب البرمجي، قبل أن تصل إلى عين المراجع البشري.

لكن رغم هذه القدرات، يبقى الذكاء الاصطناعي محدوداً في فهم السياق الاستراتيجي للمشروع. فهو لا يدرك دائماً تأثير تغيير ما على نظام بيئي واسع من المستخدمين، ولا يمكنه اتخاذ قرارات تتعلق بأولويات الميزات أو التوافقية مع الإصدارات السابقة. لذلك، تظل مرحلة المراجعة البشرية حاجزاً لا يمكن تجاوزه.

الأدوات المفتوحة: العمود الفقري لسير العمل الحديث

لا يمكن فصل النجاح في الإصدار المتكرر عن البنية التحتية المفتوحة التي تدعمه. فالاعتماد على أدوات احتكارية مغلقة المصدر يخلق تبعيات قد تعرقل سرعة التطوير أو تُضعف من شفافية العملية أمام المجتمع المطوّر. لهذا السبب، تُبنى سير العمل الحديثة على مجموعة من الأدوات المفتوحة التي يمكن لأي مطور أن يدرسها، ويُحسّنها، ويُكيّفها حسب حاجته.

في بيئة تطوير مثل بيئة huggingface_hub، يتكامل عدة أدوات لتشكيل سلسة إنتاج متكاملة:

أنظمة التكامل والنشر المستمر (CI/CD): تُستخدم منصات مثل GitHub Actions لبناء خطوط أنابيب برمجية تُفحص كل تغيير يُدفع إلى المستودع. فعندما يفتح مطور طلباً برمجياً، تُشغّل هذه الأنظمة تلقائياً مجموعة من الاختبارات على بيئات متعددة، تغطي إصدارات مختلفة من لغة البرمجة ونظام التشغيل، مما يضمن أن التغيير لا يكسر التوافقية على منصات متباينة.

أدوات تنسيق الكود والفحص الساكن: أدوات مثل Ruff وBlack وMyPy تلعب دوراً حيوياً في الحفاظ على جودة الكود ووحدته الشكلية. فقبل أن يُدمج أي طلب برمجي، يجب أن يجتاز فحوصات تنسيق الكود للتأكد من اتباعه لمعايير المشروع، وفحوصات الكتابة للتأكد من مطابقة الأنواع البرمجية المتوقعة. هذه الفحوصات لا تضمن الأمان المنطقي فحسب، بل تُسهّل على أي مساهم جديد فهم الكود والانضمام إلى المشروع.

**أدوات إد

طريقة تطبيق إضافية

لتحويل الفكرة إلى ممارسة يومية، يمكن البدء بتجربة محدودة لمدة أسبوع. اختر مهمة واحدة فقط، مثل تلخيص بحث، إعداد مسودة، أو مقارنة أدوات. سجّل الوقت المستغرق، الأخطاء التي ظهرت، وما إذا كانت النتيجة أسهل في المراجعة من العمل اليدوي الكامل. بعد ذلك يمكن توسيع الاستخدام تدريجياً إذا كانت الفائدة واضحة.

من المفيد أيضاً إنشاء قائمة تحقق قصيرة قبل الاعتماد على أي نتيجة: هل المصدر معروف؟ هل توجد أرقام تحتاج إلى تحقق؟ هل توجد معلومات حساسة؟ وهل يمكن شرح النتيجة لشخص آخر بثقة؟ هذه الأسئلة البسيطة تقلل مخاطر الاعتماد الزائد على الأتمتة.

Originally published at https://nexus-ai-blog.com

Building a Solana Trading Bot: Architecture, Sniping Logic, and Low-Latency Execution

Anttoni Viitala — Fri, 26 Jun 2026 07:52:48 +0000

The Solana ecosystem moves faster than almost any other blockchain network.

New liquidity pools appear every minute. Meme coins launch, pump, and collapse within hours. Arbitrage windows close in seconds. And for anyone trading manually, the harsh reality is simple:

You are too slow.

That’s exactly why I built my own Solana Trading Bot — a production-ready, open-source sniper bot designed for:

Automated token sniping
Liquidity-based filtering
Mint authority verification
Take-profit / stop-loss execution
Low-latency transaction propagation

GitHub Repository:

https://github.com/legendaryangelist/solana-trading-bot-v3

In this article, I’ll break down the architecture, the technical decisions behind it, and what I learned building automated trading infrastructure for Solana.

Why Build a Solana Trading Bot?

Search “Solana trading bot” and you’ll find dozens of closed-source bots promising profitability.

The problem?

Most of them hide:

Execution logic
Risk management systems
Transaction routing methods
Token filtering mechanisms

For developers, that’s a black box.

I wanted something transparent.

Something customizable.

Something optimized specifically for Solana’s performance model.

Unlike EVM chains, Solana introduces:

Parallel transaction execution
Priority fee markets
Account-based locking
WebSocket-heavy event systems

This makes bot development fundamentally different.

Building on Solana is less about writing simple buy/sell logic and more about building infrastructure for speed.

Core Architecture Overview

This bot follows an event-driven architecture.

Instead of polling for opportunities, it listens to market creation events in real time.

The system can be broken into five main layers:

1. Market Discovery Layer

The bot monitors newly created liquidity pools as they go live.

Key responsibilities:

Detect new pools instantly
Cache market states
Avoid duplicate processing

This is critical because most profitable entries happen within the first few blocks.

To optimize this:

Existing markets can preload into memory
New markets are cached dynamically
WebSocket subscriptions reduce latency significantly

This removes expensive repeated RPC queries.

2. RPC Infrastructure Layer

A Solana bot lives or dies by its RPC provider.

I built support for:

HTTPS RPC endpoints
WebSocket RPC endpoints
Commitment-level tuning

Recommended providers:

Helius
QuickNode

Why?

Because public RPC nodes fail under high load.

Private RPC infrastructure improves:

Faster account fetches
Better slot synchronization
Reduced dropped transactions
Lower latency under congestion

This directly affects profitability.

Execution Pipeline

Execution speed is everything.

Here’s the internal buy pipeline:

New Pool Detected ↓ Filter Validation ↓ Liquidity Check ↓ Mint Authority Check ↓ Social Verification ↓ Buy Trigger ↓ Transaction Build ↓ Priority Fee Injection ↓ Submission

Every stage is optimized to reduce unnecessary delay.

Advanced Token Filtering System

This is where most bots fail.

Speed without filtering is just fast gambling.

I designed multiple defensive filters.

Mint Renounced Check

One of the most important anti-rug checks.

If mint authority exists:

Supply can be increased
Tokenomics can be destroyed instantly

The bot verifies whether mint authority is revoked before buying.

Freeze Authority Detection

A token can freeze holders.

That means:

You buy.

You can’t sell.

The bot detects freeze authority and rejects those tokens.

Metadata Mutability Check

If metadata is mutable:

Token name can change
Symbol can change
Metadata can be manipulated

Immutable metadata increases trust.

Burned Liquidity Validation

Liquidity burn verification helps detect rug-pull vectors.

If LP tokens remain under owner control:

Exit risk is high.

This bot checks for burned pools before entry.

Social Presence Validation

Not a security check — but a strong signal.

The bot can validate:

Twitter/X
Telegram
Website links

In memecoin markets, social presence often correlates with initial community strength.

Configuration System

One of my main goals was flexibility.

Everything is configurable via environment variables.

Example:

QUOTE_AMOUNT=0.5
BUY_SLIPPAGE=5
AUTO_SELL=true
TAKE_PROFIT=30
STOP_LOSS=15
CHECK_IF_MINT_IS_RENOUNCED=true
CHECK_IF_BURNED=true
MIN_POOL_SIZE=10
MAX_POOL_SIZE=200

This makes strategy iteration extremely fast.

No code changes required.

Just configuration.

Transaction Optimization: Warp and Jito

Solana’s competitive trading environment often makes normal RPC submission too slow.

That’s why I added support for:

Warp Execution

Warp routes transactions through hosted infrastructure optimized for faster inclusion.

Benefits:

Better propagation speed
Lower failure rates
Improved validator routing

Jito Bundles

Jito Labs provides transaction bundle infrastructure.

This allows:

Priority ordering
Better landing probability
MEV-aware execution

For launch sniping, this is a major edge.

Auto Sell Logic

Buying is easy.

Selling well is difficult.

The bot includes:

Take Profit

Example:

30%
50%
100%

The bot continuously checks quote value against entry.

If target is reached:

Sell triggers automatically.

Stop Loss

Protects downside.

Example:

-10%
-20%

This prevents catastrophic drawdowns.

Especially useful in volatile low-cap launches.

Timed Exit

Not every token pumps.

Some die.

The timed exit ensures capital rotation:

Example:

Sell after 15 minutes regardless of performance.

This improves opportunity efficiency.

Real Performance Bottlenecks I Faced

While building this bot, I encountered several bottlenecks:

WebSocket Flooding

Too many market events caused memory pressure.

Fix:

Event deduplication
Listener cleanup
Smart cache eviction

RPC Rate Limits

Public endpoints failed frequently.

Fix:

Dedicated premium RPC providers.

Failed Transactions

Congestion caused dropped buys.

Fix:

Retry logic
Priority fee tuning
Warp/Jito execution

Token Account Issues

Many users forgot to initialize WSOL/USDC token accounts.

Fix:

Pre-check wallet balances before execution.

Security Model

Security was non-negotiable.

Private keys:

Stay local
Never leave the machine
Never sent to Warp

Even fee signing happens locally.

Best practices:

Use burner wallets
Limit active balances
Use isolated infrastructure
Rotate credentials

Who Is This Bot For?

This project is useful for:

Traders

Who want:

Fast sniping
Automated exits
Risk filters

Developers

Who want:

Extend execution logic
Add AI scoring systems
Build arbitrage modules
Add analytics pipelines

Researchers

Who want:

Study token launch patterns
Analyze rug probabilities
Model memecoin volatility

Open Source Repository

The full source code is available here:

https://github.com/legendaryangelist/solana-trading-bot-v3

Features:

✔ Real-time market monitoring
✔ Multi-layer rug filters
✔ Auto buy/sell
✔ Warp execution
✔ Jito support
✔ Snipe list support
✔ Configurable risk engine
✔ Production-ready architecture

Final Thoughts

Building a Solana trading bot taught me something important:

Winning in on-chain markets isn’t just about speed.

It’s about:

Information quality
Risk filtering
Execution reliability
Capital discipline

Automation gives you speed.

Infrastructure gives you consistency.

Strategy gives you longevity.

If you’re a developer exploring Solana bot development, automated trading systems, or on-chain sniper infrastructure, I hope this repository gives you a strong foundation.

The market moves fast.

Your code should move faster.

"Read-Only Reviewer Agents Catch What Your Main Agent Waves Through"

greymoth — Fri, 26 Jun 2026 07:51:19 +0000

The main agent writes the code. The reviewer agent reads it. The reviewer can't edit anything.

That constraint — no edit permission — is the whole point. It's not a safety measure. It's what makes the reviewer trustworthy.

What "waving through" looks like

I noticed a pattern in my own agentic work. The main agent finishes a feature, the tests pass, I mark it done. Later I find something wrong — a null case not handled, an error message that doesn't match the spec, a behavior that passes the test but fails in a slightly different context. Things that were visible in the code. Things I should have caught.

The main agent wrote the code and verified the code. By the time it's reading its own output, it has already mentally modeled the feature as complete. It reads with the assumption that things are correct and looks for confirmation. It finds confirmation, because it wrote the code to pass the test it also wrote.

This is a verification problem, not an intelligence problem. The same issue shows up in human code review — the author is the worst person to catch their own oversights, not because they're careless but because they're too close to it.

Why tool scope is the right lever

You could try to solve this with prompting. Tell the main agent to "review critically before finishing." I've tried it. It helps a little. The agent will surface some issues it would have let slide. But it's working against its own completion-bias, and that's a weak force.

Scoping tools differently is a structural fix, not a nudge.

A reviewer agent that literally cannot call any write or edit tool has a different relationship to the code. It's not trying to finish. There's nothing to finish. It reads the diff, reads the spec, reads the test results, and that's all it can do. Its job is to notice things, not to fix them.

When you remove the option to fix, the noticing gets sharper.

What the reviewer actually catches

In practice the reviewer finds a few categories of things:

Spec drift. The main agent made a small judgment call somewhere that deviated from the spec. Not wrong exactly — a reasonable decision — but not what the spec says. The reviewer has the spec open and no stake in the implementation, so it flags it. The main agent might not have even noticed the deviation because the implementation "feels right."

Missing cases. The main agent handled the happy path and the obvious error case. The reviewer asks: what happens if this input is empty? What if this call fails? These are findable by reading; they just require a different mode of attention than writing.

Test-implementation coupling. Sometimes the test passes because the implementation and the test were written together, with the same blind spot. The reviewer reads both and asks whether the test actually covers the behavior, or just covers the code. These are different things.

Terminology mismatch. Error messages, variable names, API response fields that don't match the spec or the existing codebase conventions. Small. Easy to miss when you're focused on logic. Easy to catch when you're only reading.

How to set this up

The mechanics are simple. You're running two agent calls sequentially, not in parallel. The main agent does its work. When it's done, you pass the diff and the spec to a second agent with a system prompt that says it's a reviewer — and you configure it with read-only file access.

In Claude Code specifically, you can scope tool permissions at the agent level. The reviewer gets Read, Grep, Glob. No Edit, no Write, no Bash. It literally can't change anything even if it wanted to.

The reviewer's output is a list of findings. The main agent then gets those findings and addresses them. One more pass, one more reviewer check if needed.

When it's not worth it

Short scripts, throwaway code, things you'll rewrite anyway — the overhead isn't worth it. The reviewer adds latency and cost. For anything going to production, or anything that needs to match a spec, or anything you'll hand off: worth it.

The other case where it adds real value is when the spec is load-bearing. If you've written precise acceptance criteria and you want to know whether the implementation actually meets them — not just "tests pass" but "the criteria are satisfied" — the reviewer is good at that comparison.

The deeper point

The problem isn't that the main agent makes mistakes. It's that agent and reviewer are the same entity if they share context, state, and stake in the outcome.

Separate the concerns. Give each agent exactly the tools its role requires, no more. The reviewer doesn't need to write because its job is to read. When it can only read, it reads better.

Why Your Developer Productivity Metrics Are Measuring the Wrong Thing

Ak Thoha — Fri, 26 Jun 2026 07:46:20 +0000

Your DORA metrics are elite. Your velocity is up. Releases still slip.

You're measuring the pipeline, not what's blocking it.

DORA Sees the End, Not the Wait

DORA metrics are real. Google's research validates them. But they only see one moment: when code ships.

They don't see:

The 6 days a feature sat waiting for security review
The two teams building the same dependency, unaware of each other
The Slack thread where the real blocking decision lives

DORA sees elite teams ship fast. It doesn't see why those same elite teams still slip releases while mediocre teams ship on time.

The answer: visibility. One team can see its dependencies. The other can't.

Story Points Are a Confidence Game

Ron Jeffries invented story points and now regrets it—not because estimation is bad, but because points became a proxy for productivity when they measure neither.

Watch this pattern:

Q1: 45 → 45. Aligned.
Q2: 52 → 50. Velocity up.
Q3: 58 → 54. Charts green.
Reality: Same shipping speed all three quarters.

Teams learned to estimate generously without changing output. It works great until you cross team boundaries and suddenly Team A's 5 points has nothing to do with Team B's 5 points.

SPACE Found the Problem—Then Stopped

GitHub and Microsoft's SPACE framework added communication as a dimension of productivity. Good instinct.

Then it suggested measuring communication with surveys: "Do you feel informed?"

That's a feeling, not a signal.

The real signals hide in Slack threads nobody linked to tickets. PRs waiting on async reviews. Code shipped that silently broke another team's API contract.

SPACE named the problem. It didn't solve the visibility problem.

Three Signals That Show You're Blind

If you want to see what's actually slowing you down, measure this:

Phantom Dependencies How many pieces of work touch code across multiple repos without a formal dependency ticket? Most teams discover these only after merge. Panic mode activated.
Async Resolution Time Slack threads: 5-7 days to resolve blockers. Jira: a few hours. Same information, different container. This tells you something about where knowledge actually lives.
Context-Switching Interrupts UC Irvine research: 23 minutes to regain focus after one interrupt. Count the "who owns this?" moments in one engineer's week. Multiply that across your team. That's real velocity drag.

What Actually Works

Layer 1: Flow Metrics (Keep DORA) Use cycle time, not velocity. Velocity is a number teams learn to adjust. Cycle time is measured time.

Layer 2: Coordination Signals (The Missing Layer) Measure:

Untracked dependencies discovered post-merge per release
How long cross-team blockers sit in async channels
Pre-merge vs. post-merge dependency discovery rate
Unplanned context switches per engineer per week

Connect your tools and ask: "What's actually blocking work across all these systems?"

Layer 3: Outcome Confidence (Forward-Looking) Turn vague status updates into risk forecasts. "We're on track" becomes "72% confidence, main risk is untracked payment team dependency."

The Experiment

Try this on your last 3 releases:

Blind spots: How many cross-team dependencies did you discover only after code shipped?
Async channels: Which Slack threads contain blocking conversations? How long open?
One team, one week: Count "who owns this?" moments.

Most teams find the numbers shocking.

The Real Question

If releases slip despite strong metrics, you're measuring the wrong things.

Not "are developers fast?" but "can we see what's blocking them?"

Teams that surface dependency risk early ship 30-40% faster. Not because they code faster—because they can see.

Start measuring handoffs.

Mythreyi Chandoor builds execution intelligence tooling. 15+ years as a technical program director watching smart teams ship slower than they should—usually because visibility stopped at team boundaries.

Discussion

What's the biggest coordination blocker you see in your engineering org? Where do you lose the most time in handoffs nobody tracks?

Drop your experience in the comments—genuinely curious how others are solving this.

Loop Engineering: Why Prompt Engineering Is Becoming Obsolete

luka — Fri, 26 Jun 2026 07:45:56 +0000

For the last two years, "Prompt Engineering" has been one of the hottest skills in AI.

People spent countless hours optimizing prompts:

Add more context.
Use chain of thought.
Ask the model to think step by step.
Create reusable prompt templates.

Entire courses, books, and careers emerged around writing the perfect prompt.

But something fundamental has changed.

The future isn't about writing better prompts.

It's about building better loops.

Prompt Engineering Assumes One Conversation

Traditional prompt engineering treats every interaction as an isolated event.

Human
↓
Prompt
↓
LLM
↓
Answer

If the answer isn't good enough, you rewrite the prompt.

The prompt becomes the product.

This made sense when LLMs were essentially advanced autocomplete systems.

Modern AI Doesn't Stop After One Response

Today's AI agents don't simply answer.

They observe.

They execute.

They evaluate.

They retry.

A coding agent might:

read your repository
generate code
run tests
discover failures
modify the implementation
rerun tests
repeat until success

The original prompt quickly becomes irrelevant.

What matters is the feedback loop.

The Prompt Is Now Just Initialization

Think about developers using Claude Code, Codex, Gemini CLI, or OpenHands.

The initial instruction might be:

"Implement dark mode."

Everything afterward happens inside an iterative process.

The agent continuously gathers new information.

It edits files.

Reads compiler errors.

Checks logs.

Runs commands.

Refines its plan.

Eventually, the original prompt becomes a tiny fraction of the total reasoning process.

Enter Loop Engineering

Instead of asking:

How do I write the perfect prompt?

We should ask:

How do I design the perfect iteration loop?

A good AI loop includes:

memory
verification
tool execution
feedback
retry strategy
stopping conditions
evaluation

The intelligence increasingly comes from the loop—not the prompt.

An Example

Bad approach:

Write the perfect prompt.
Hope it works.

Loop Engineering:

Generate solution
↓
Execute
↓
Measure
↓
Identify failure
↓
Improve
↓
Repeat

Notice what's happening.

The model no longer depends on humans to refine the prompt.

The system refines itself.

This Is How Human Experts Work

Software engineers don't write perfect code on the first try.

Scientists don't publish their first hypothesis.

Designers don't ship their first sketch.

Experts iterate.

AI is moving toward the same workflow.

Iteration is replacing instruction.

The Real Competitive Advantage

Many people still ask:

"What's the best prompt?"

Increasingly, that's the wrong question.

The better questions are:

How does the agent detect failure?
How does it recover?
What information should persist between iterations?
When should it stop?
Which tools should it call next?

These are Loop Engineering problems.

Prompt Engineers May Become Loop Engineers

Prompt engineering isn't disappearing overnight.

A good initial prompt still matters.

But its importance is shrinking.

As AI gains longer context windows, persistent memory, tool use, and autonomous execution, the prompt becomes merely the starting state of a much larger system.

The real engineering challenge shifts from language to process.

From wording to workflows.

From prompts to loops.

And perhaps, in a few years, we'll look back at "Prompt Engineer" the same way we look back at "Flash Developer" or "SEO Meta Keywords Specialist"—an important role for its era, but one eventually absorbed into a broader discipline.

Maybe the next generation won't call themselves Prompt Engineers.

Maybe they'll simply be Loop Engineers.

🚀 I Built PDFEditDesk – A Free Online PDF Toolkit 📄

Rajkumar V — Fri, 26 Jun 2026 07:45:32 +0000

👋 Hi Dev Community!

I'm excited to share PDFEditDesk, a side project I've been building to make working with PDFs faster and easier.

🌐 Try it here: https://pdfeditdesk.com

✨ With PDFEditDesk, you can:

📄 Edit PDFs
🔗 Merge PDFs
✂️ Split PDFs
🗜️ Compress PDFs
🔄 Convert PDFs
📑 Organize PDF pages

🎯 My goal was to create a clean, fast, and user-friendly experience without unnecessary complexity.

I'd love your feedback on:

🎨 UI/UX
⚡ Performance
🐞 Bugs
💡 Features you'd like to see

Every suggestion helps improve the product. Thanks for checking it out! ❤️🚀

"Your Repo Is the Memory. Your Model Is the Worker."

greymoth — Fri, 26 Jun 2026 07:42:52 +0000

There's a framing I keep coming back to. The model doesn't hold state — the repo does. The model is the worker. The repo is the memory. Once that clicks, a bunch of decisions about how to structure agentic work become obvious.

I've been running Claude Code nearly every day. My token breakdown: cacheRead 72%, input 0.3%, output the rest. That 72% number isn't an accident. It's what happens when you treat the repo as the ground truth and stop asking the model to reconstruct context from scratch.

The basic principle

The model forgets. Not sometimes — always, between sessions, and often within them when context gets long. If your workflow relies on the model remembering what it decided two hours ago, you're building on sand.

The repo doesn't forget. A spec file, a requirements doc, a TODO list with completed items marked — these are durable. The model can read them fresh every time and pick up exactly where things are.

So the workflow becomes: write everything down in the repo, have the model read before it acts, have the model write its decisions back.

What "frozen spec" means in practice

The spec file is the source of truth. It's not a suggestion. When I start a work session I don't say "continue where we left off." I say "read the spec, read the current state of the repo, tell me what's left."

The model reads. The model acts on what it reads. The model marks items done only after I've verified they work — not when it thinks it's done, not when it says it's done. After I've confirmed.

This sounds slow. It's the opposite. I've burned hours debugging half-finished features because a previous session "completed" something that wasn't complete. The [●] only goes in after verification. Every time I've skipped that, I've paid for it.

Why cacheRead 72% matters

When the model reads the same files repeatedly across a session — the spec, the main source files, the test results — those reads get served from cache. The cost difference between input tokens and cached reads is significant. More importantly, the latency drops. Reads that would have taken seconds are near-instant.

The implication: structure your repo so the model reads the same files often. One clean spec file is better than scattered notes. One consolidated state file is better than comments spread across six modules. Predictable read patterns = high cache hit rate = faster, cheaper sessions.

My 0.3% input figure is low because I'm not pasting long context into prompts. The repo provides the context. The prompt is just the directive.

What breaks this pattern

Two things reliably break it.

First: specs that change without the model knowing. If I update the requirements doc mid-session without telling the model to re-read it, the model is now operating on stale information it thinks is current. The fix is trivial — tell it to read the spec again — but easy to forget.

Second: verification that isn't real verification. "Does this look right?" is not verification. Running the tests and reading the output is verification. Clicking through the UI and confirming behavior is verification. The [●] gate only holds if the criterion is external and objective.

The reviewer pattern

One extension of this I've been using: a second model pass that's read-only. After the main agent makes changes, a reviewer agent reads the diff and the spec together, with no ability to edit files. It's surprising how often the reviewer catches things the main agent waved through — not because the main agent is bad, but because the same agent that wrote the code has already mentally "completed" the task and reads its own output charitably.

The reviewer has no such prior. It reads what's there.

What this changes about how I write specs

Short and precise beats long and thorough. A 200-line spec that's been carefully maintained is more useful than a 2,000-line doc that's 70% stale. The model will read the whole thing every time; every line of noise is a tax.

I also stopped writing "what" specs and started writing "what + acceptance criterion" specs. Not "implement pagination" but "implement pagination — verified when /api/posts?page=2 returns the correct slice and the total count header is accurate." The acceptance criterion is what tells me when to mark [●].

The limit

This framing doesn't fix bad judgment. If the spec is wrong, the model faithfully executes the wrong thing. If the acceptance criterion is too easy to satisfy, you get implementations that pass the test and miss the intent.

The model is a good worker. It does what it's told, reads what you give it, marks things done when you say so. Whether the work was the right work — that part is still yours.

"I Found ~30 Mergeable OSS Bugs in a Day. They Were All the Same Shape."

greymoth — Fri, 26 Jun 2026 07:42:48 +0000

Yesterday I shipped around 28 pull requests across real repos — zod, NestJS, Fastify, Scrapy, Pygments, others. Not spam. Not docs typos. Actual behavioral fixes that got merged or are pending review.

The method has a name now. I'm calling it sibling-leftover.

What sibling-leftover actually is

When a maintainer merges a PR that fixes something in one area, they're implicitly approving the intent. But if the fix touched only one of two symmetric branches in the code — and left the sibling untouched — there's a window. The maintainer already agreed the behavior was wrong. The fix pattern is already in-tree. You're not arguing a new position; you're completing a sentence they started.

The leftover sibling is almost always a bug. Not always a serious one. But it's real.

Two concrete examples

zod #5945 → #6141

zod #5945 fixed cidrv4 validation. The PR landed. Closed. Merged. I looked at the diff and noticed cidrv6 sat right next to it in the same file, same logic shape, no corresponding fix. Opened #6141 targeting ipv6. The maintainer already understood the problem domain; the test pattern was already established. Merge friction: near zero.

NestJS #17188 → #17207

NestJS #17188 fixed a behavior in the WebSockets transport. Adjacent in the codebase: the microservices transport, same underlying issue. #17207. Same shape, different branch. I didn't have to explain why something was wrong — the merged PR did that for me.

This is the pattern. One fix → locate its symmetric counterpart → ship the mirror.

Why merge rates are high

Three reasons stack:

Domain approval is already in. The maintainer accepted that this class of bug exists. They didn't reject the premise, they fixed it. You're not asking them to believe something new.
Test infrastructure exists. The first PR almost always adds or modifies tests. Your fix can follow the same structure, in the same file, targeting the sibling case. Reviewers don't have to imagine what passing looks like.
The diff is small and symmetric. A small, obviously correct diff in a familiar area is much easier to approve than a large refactor. Cognitive load for the reviewer is low.

How to run this yourself

Step one: find recently merged PRs in repos you care about. GitHub search — is:pr is:merged sort:updated — works. Filter by the last 30-60 days.

Step two: read the diff. Look for constants, enum branches, transport names, protocol variants, format handlers — anything where the code obviously has siblings. cidrv4/cidrv6. websockets/microservices. rgb/rgba. http/https. These pairs are everywhere.

Step three: grep the repo for the sibling. Confirm it has the same bug pattern. Write the fix following the same style as the merged PR — same variable naming, same test shape.

Step four: open the PR. Reference the original merged fix explicitly. "This mirrors #XXXX which fixed the same issue in [sibling]. Applying the same approach here." That sentence alone cuts review time.

What this is not

It's not cherry-picking trivially obvious things to pad a contribution count. Some of the fixes I found were non-trivial — the sibling had slightly different logic that required careful adaptation. A few I dropped because the behavior divergence was intentional and I wasn't sure.

The method is a search strategy, not a guarantee. You still have to read the code. You still have to understand why the original fix was correct. The frame just tells you where to look.

One thing I'll keep doing

Before I look for new bug categories, I now scan the merged PRs from the last week in repos I'm watching. It's maybe 20 minutes. The hit rate — "this fix has an unaddressed sibling" — is surprisingly high. My rough estimate from yesterday: about 40% of format/transport/protocol-related fixes leave something behind.

The bugs are there. They're findable. The method is repeatable.

Automating Student Onboarding via WhatsApp in SugarCRM

Northbeam Technologies — Fri, 26 Jun 2026 07:41:34 +0000

A multi-step conversation engine that captures leads and creates CRM records automatically — no staff required.

The Problem

When prospective students first contact the school via WhatsApp, staff had to manually collect their details and create a record in SugarCRM by hand. Leads that arrived outside business hours were simply missed or delayed — there was no way to capture them without a person in the loop.

The school was already using Twilio for outbound WhatsApp messages from SugarCRM, but replies from unknown numbers went nowhere.

What We Built

A multi-step conversation engine built directly into SugarCRM. When an unknown number sends a WhatsApp message, the system:

Intercepts the message via a Twilio webhook
Checks whether the phone number already exists as a student record
If yes → routes to the existing follow-up flow (no change)
If no → starts a guided intake questionnaire, validates each answer, and creates the student record automatically

Zero admin involvement for new contacts.

How It Works

Key Technical Decisions

State machine, not a script.

Each conversation is a session with a current_step pointer. Questions can be reordered, toggled, or mapped to any CRM field without changing code. Admins manage the question bank directly from SugarCRM's UI.

Phone number normalization.

The system normalizes Israeli, US, and Vietnamese number formats before matching — preventing duplicate records from format variations like +1-555... vs 001555....

Media guard.

If a student sends a photo or voice note, the system replies politely that only text is supported and automatically resends the current question.

Partial completion handling.

If a student stops mid-flow, automated reminders go out at 2h and 24h. If minimum data (name + phone) is collected and the student still doesn't respond, a partial record is saved so the lead isn't lost.

Multi-number support.

Multiple Twilio sender numbers can be registered in SugarCRM. Each conversation session locks to the number the student originally contacted.

What Changed After Launch

✅ Student record creation from WhatsApp is fully automated for new contacts
✅ Leads outside business hours are captured without any staff intervention
✅ Admins can view full chat history, manually resume sessions, or override any step from inside SugarCRM
✅ The existing outbound messaging workflow for known students is completely unchanged

Stack

PHP — core logic and SugarCRM custom modules
SugarCRM — custom modules for session management, question bank, and student records
Twilio WhatsApp API — inbound webhook + outbound messaging
MySQL — session state persistence

The main lesson here: WhatsApp bots don't need a separate platform. If your CRM already has a webhook endpoint and an API, you can build the conversation engine right inside it — and keep everything in one place for your team.

Originally published on northbeam-tech.com

Understanding Filament themes in v4/v5: from Colors to custom CSS

yebor974 — Fri, 26 Jun 2026 07:41:24 +0000

Filament provides a flexible theming system that lets you customize the look and feel of your admin panel. This guide covers how to create and apply custom themes for Filament v4/v5 with Tailwind CSS v4.

This is an updated version of an earlier guide written for Filament v3 and Tailwind v3. The overall approach is similar, but what the theme command generates and the CSS syntax have changed with Tailwind v4's CSS-first configuration. If you're still on Filament v3, the original guide is available here.

Setting primary colors for panels

Before touching the theme files, the simplest customization is setting your panel's color palette. This part hasn't changed: Filament still uses the Filament\Support\Colors\Color class.

Option 1: define colors per panel

In your panel provider:

use Filament\Support\Colors\Color;

public function panel(Panel $panel): Panel
{
    return $panel
        ->colors([
            'danger' => Color::Rose,
            'gray' => Color::Gray,
            'info' => Color::Blue,
            'primary' => Color::Indigo,
            'success' => Color::Emerald,
            'warning' => Color::Orange,
        ]);
}

Option 2: define colors globally

In AppServiceProvider, applied across all panels:

use Filament\Facades\Filament;
use Filament\Support\Colors\Color;

public function boot(): void
{
    Filament::defaultColors([
        'danger' => Color::Rose,
        'gray' => Color::Gray,
        'info' => Color::Blue,
        'primary' => Color::Indigo,
        'success' => Color::Emerald,
        'warning' => Color::Orange,
    ]);
}

When to stop here: if your goal is only to change branding colors, ->colors() is all you need. Create a custom theme only when you need structural UI changes, like repositioning elements, changing spacing, or styling parts of the interface that color tokens don't reach.

Generating the theme

The command itself hasn't changed:

php artisan make:filament-theme

You'll be prompted for a panel name (default: admin). What changed is what this command generates and does for you.

On a Tailwind v4 setup, running it for a member panel generates a theme.css scoped to that panel:

@import '../../../../vendor/filament/filament/resources/css/theme.css';

@source '../../../../app/Filament/Member/**/*';
@source '../../../../resources/views/filament/member/**/*';

Notice the @source paths point specifically to Member, not a generic Filament/**/*. Each panel gets its own scoped theme out of the box.

That's it: the generated file is intentionally minimal. If you want a dedicated place for CSS variables or light/dark overrides, you can add your own @layer base block:

@layer base {

    :root {

    }

    :root[class~="dark"] {

    }

}

The other change worth noting: in Filament v3, you had to manually add the theme to vite.config.js and register it with ->viteTheme() in your panel provider. In v4/v5, the command does both for you automatically. No manual wiring required.

A few things changed compared to Tailwind v3:

No more tailwind.config.js. Tailwind v4 no longer requires a tailwind.config.js file for basic theme customization. It moved to CSS-first configuration. There's nothing left to generate or maintain in a separate JS config file for the theme.

@source directives replace the old content array. Tailwind v4 scans these paths directly from CSS to know which files to look at for class usage, instead of declaring them in a JS config.

The generated file is intentionally minimal. Just the import and the @source paths for that panel. No boilerplate @layer base block is added automatically; that's something you add yourself if and when you need it, as shown above.

Adding your own directories to @source

The generated @source directives only cover Filament's own files. Your resources, components, or anything outside app/Filament won't be scanned by default. If you use Tailwind classes in Blade components, Livewire components, or custom views, you need to add those directories yourself:

@source '../../../../app/Filament/**/*';
@source '../../../../resources/views/filament/**/*';
@source '../../../../resources/views/components/**/*';
@source '../../../../resources/views/livewire/**/*';
@source '../../../../app/Livewire/**/*';

Forget to add a directory here, and Tailwind will purge classes it never saw being used, even if they're correctly written in your code. Rebuild with npm run build after adding new paths.

What gets registered automatically

Since the command handles registration for you, vite.config.js already includes the new theme after running make:filament-theme:

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/css/app.css',
                'resources/css/filament/admin/theme.css',
                'resources/js/app.js',
            ],
            refresh: true,
        }),
        tailwindcss(),
    ],
});

And your panel provider already has the theme registered too:

->viteTheme('resources/css/filament/admin/theme.css')

Nothing left to wire up manually. Just run the command, and both files are updated for you.

Multiple panels, multiple themes

If your application has more than one panel, an admin panel and a member panel for example, each one gets its own theme file and is registered independently.

Run make:filament-theme once per panel:

php artisan make:filament-theme backend
php artisan make:filament-theme member

Each run automatically adds its theme to vite.config.js and registers it in the matching panel provider. You'll end up with both entries already in place:

laravel({
    input: [
        'resources/css/app.css',
        'resources/css/filament/backend/theme.css',
        'resources/css/filament/member/theme.css',
        'resources/js/app.js',
    ],
    refresh: true,
}),


// BackendPanelProvider
->id('backend')
->viteTheme('resources/css/filament/backend/theme.css')

// MemberPanelProvider
->id('member')
->viteTheme('resources/css/filament/member/theme.css')

Each theme.css is scoped to its own panel by default. The @source directives only point to that panel's files, and customizing one theme doesn't affect the other. This is how the Multipanel and Multi-Tenant starters are set up: two themes, generated empty and scoped, ready for each panel to be styled differently if needed.

Sharing one theme across panels: you don't have to generate a separate file per panel. If two panels should look identical, you can point both panel providers at the same theme file:

// BackendPanelProvider
->viteTheme('resources/css/filament/shared/theme.css')

// MemberPanelProvider
->viteTheme('resources/css/filament/shared/theme.css')

Just make sure the @source paths in that shared file cover both panels directories, since a single generated theme only scopes to the panel it was created for.

Reading Filament's hook classes

Once you start customizing beyond colors, you'll be targeting Filament's own CSS classes, the ones used in the sidebar example below and throughout the interface. They follow a consistent naming convention worth knowing:

fi is short for "Filament"
fi-ac is used for classes from the Actions package
fi-fo is used for classes from the Forms package
fi-in is used for classes from the Infolists package
fi-no is used for classes from the Notifications package
fi-sc is used for classes from the Schema package
fi-ta is used for classes from the Tables package
fi-wi is used for classes from the Widgets package
btn is short for "button"
col is short for "column"
ctn is short for "container"
wrp is short for "wrapper"

Once you know this pattern, hook class names become much easier to read without digging through Filament's source every time.

Finding hook classes in practice: the naming convention tells you what a class means once you've found it, but you'll still need to find it first. The fastest way:

Open your browser's dev tools on the panel you want to customize
Inspect the element you want to target
Look for classes starting with fi- in the inspector
Use that class in your theme's CSS

This is the most reliable way to target the exact element you're looking at, rather than guessing from the naming convention alone.

Customizing your theme

With the theme registered, you can now add your own styles directly in theme.css. Filament's hook classes, documented in the Filament docs, let you target specific parts of the interface.

Here's an example customizing the sidebar, the same idea as in the original v3 guide, adapted to the new file structure:

@import '../../../../vendor/filament/filament/resources/css/theme.css';

@source '../../../../app/Filament/**/*';
@source '../../../../resources/views/filament/**/*';

.fi-sidebar {
    @apply !bg-gray-500;

    .fi-sidebar-header {
        .fi-icon-btn-icon {
            @apply text-primary-500;
        }
    }

    .fi-sidebar-group-label, .fi-icon-btn-icon, .fi-sidebar-group-icon, .fi-sidebar-item-icon, .fi-sidebar-item-button, .fi-sidebar-item-label {
        @apply text-white;
    }

    .fi-sidebar-item-active {
        .fi-sidebar-item-button {
            @apply bg-primary-500;
        }
    }

    .fi-sidebar-item, .fi-sidebar-item-button {
        :hover {
            @apply hover:bg-primary-500;
        }
    }

    .fi-icon-btn {
        :hover {
            @apply hover:text-primary-500;
        }
    }

    .fi-sidebar-nav-groups {
        @apply gap-y-0;
    }
}

The @apply syntax and the hook classes themselves haven't changed. What changed is everything around them: how the theme is generated, how Tailwind scans your files, and how the build is configured.

Using CSS variables for reusable values

If you find yourself repeating the same color or value across multiple rules, defining a CSS variable in @layer base keeps things consistent and easier to update later:

@layer base {
    :root {
        --sidebar-bg: #1f2937;
    }

    :root[class~="dark"] {
        --sidebar-bg: #111827;
    }
}

Then reference it directly in your styles:

.fi-sidebar {
    background: var(--sidebar-bg);
}

This is especially useful for values you'll reuse in several places, or want to swap between light and dark mode without duplicating rules.

Run npm run build once you're done, and your custom theme is live.

Common mistakes when customizing Filament themes

A few things come up repeatedly when developers start working with Filament themes for the first time.

Creating a theme when ->colors() is enough. If the only goal is changing the primary color, buttons, and sidebar accents, ->colors() in the panel provider covers that without generating any files. A custom theme is only necessary for structural changes, targeting specific interface elements via hook classes, or using CSS variables for fine-grained control. Generating a theme file when it isn't needed just adds a build step and a file to maintain.

Forgetting to add custom Blade directories to @source. The generated theme only scans Filament's own directories by default. Any Tailwind classes used in custom Blade components, Livewire components, or views outside app/Filament won't be detected unless you explicitly add those paths. Tailwind silently purges the undetected classes, and the issue only shows up at build time when styles randomly stop working in production.

Styling internal Filament classes instead of hook classes. Filament's hook classes, prefixed with fi-, are the intended surface for CSS customization. Styling classes without the fi- prefix means targeting internal implementation details that can change between releases without notice. Filament's own documentation explicitly warns against this: if a hook class you need doesn't exist yet, the recommended path is to open a pull request to add it, not to target internal classes and accept the maintenance risk.

Overriding too much. The more CSS overrides added to a theme, the harder upgrades become. When Filament ships a new version, any structural change to the interface can break rules that were written against the old markup. Prefer color tokens, CSS variables, and targeted hook class overrides before rewriting large sections of the interface. A theme should adapt Filament to a brand, not turn Filament into a completely different application.

And of course, editing vendor files directly. Any change made inside vendor/filament is overwritten the next time composer update runs. If something in Filament's default theme needs to be overridden, the right place is the custom theme.css file, using hook classes to target the element. The vendor directory is never the right place.

Don't want to build a theme from scratch?

If building a custom Filament theme isn't where you want to spend your time, Filafly offers premium themes and plugins ready to drop into your panel.

Use code MASTERY15 for 15% off your purchase.

Discover Filafly themes →

Originally published on Filament Mastery

The No-Panic Guide to JSON Schema Validation for REST APIs

Janardan Joshi — Fri, 26 Jun 2026 07:38:21 +0000

A few years ago, I shipped what looked like a textbook, harmless API update.

The endpoint returned valid JSON. Every single local test passed with flying colors. We hit deploy, dusted off our hands, and went to grab coffee.

Ten minutes later, Slack exploded. The frontend team was reporting errors across the entire app.

The culprit? A seemingly minor refactor: I had changed a property named name to fullName, and dropped another field entirely because "surely nothing is using this anymore." (Narrator: Everything was using it.)

The API wasn't throwing 500 errors. It was technically functioning perfectly—but every single client depending on that old data structure was completely broken. That’s exactly the kind of production nightmare JSON Schema is designed to kill.

What is JSON Schema (and Why Should You Care)?

At its core, JSON Schema is just a blueprint for your data.
If the data doesn't fit the dress code, it doesn't get in.

A quick look at a basic JSON-schema:
{
"type": "object",
"required": ["id", "name", "email"],
"properties": {
"id": { "type": "integer" },
"name": { "type": "string" },
"email": { "type": "string", "format": "email" }
}
}

The Drift Dilemma

Imagine your API spits out this clean response today:
JSON

{
"id": 1,
"name": "John Doe",
"email": "john@example.com"
}

A month from now, a well-meaning developer refactors the endpoint, and it morphs into this:
JSON

{
"userId": 1,
"fullName": "John Doe"
}

To a basic uptime monitor, the API looks healthy. It’s returning a 200 OK and a valid JSON object. But your frontend applications are screaming because id became userId, name became fullName, and email vanished into the void.

Without automated schema validation, you usually find out about this contract drift after your users start complaining.
The Basics: Types, Nesting, and Strictness

JSON Schema is incredibly flexible and easily maps to standard data types (string, integer, number, boolean, object, array, and null).

But it’s not just about playing hide-and-seek with missing keys. Where schema validation really saves your skin is handling data integrity when things get messy under the hood.

The "Accidental String" Trap

Type mismatches are incredibly easy to slip into a codebase during a quick refactor. For example, if someone inadvertently wraps an age in quotes—sending "25" as a string instead of a clean integer like 25—the frontend code might try to perform math on it or break entirely. A strict schema validator flags that data type shift instantly before it can wreck anything downstream.

Taming Nested Chaos

Let's be honest: real-world APIs are almost never neat and flat. They are complex webs of nested objects and arrays. JSON Schema lets you map out these deep relationships without breaking a sweat.

Take a look at how it handles a list of tags tucked inside a user profile:
JSON

{
"type": "object",
"properties": {
"user": {
"type": "object",
"properties": {
"tags": {
"type": "array",
"items": { "type": "string" }
}
}
}
}
}

If a bug in your database query suddenly returns a mixed array like ["developer", 123], the validator immediate halts the response. It knows exactly what a valid array should look like and refuses to let a rogue integer slip by.

Locking the Back Door with additionalProperties By default, JSON Schema allows extra fields it doesn't recognize. To stop unexpected data from quietly bleeding into your responses, you can pass a secret weapon: JSON

{
"additionalProperties": false
}

Now, if someone tries to slip unauthorized fields into the payload, the validator shuts it down. The Production Reality Check: Dynamic Data

If you try to implement raw schema validation in the real world, you will immediately run into the "Dynamic Data Problem." APIs love to return things like this:
JSON

{
"timestamp": "2026-06-26T10:21:15Z",
"request_id": "7dc2c5abc123",
"trace_id": "abf942xyz789"
}

These values change on literally every single request. Technically the data is different, but functionally, your API isn't broken. If your validation pipeline treats every changing timestamp as a breaking change, you’ll end up with alert fatigue and a team that hates you.In practice, the trick is to validate the structure of these fields (e.g., ensuring timestamp is always a valid ISO date string) while ignoring the actual shifting value. Moving Beyond Manual Testing

Manual inspection during code reviews is great, but humans are remarkably bad at noticing that a nested key changed from camelCase to snake_case at 4:30 PM on a Friday.Integrating schema validation directly into your CI/CD pipeline acts as a safety net:

[Developer Commit] ➔ [Run Unit Tests] ➔ [Validate Against JSON Schema] ➔ [Safe Deployment]

If a pull request accidentally breaks the data contract, the build fails before it ever touches a production server.What We Built to Solve This

Wrestling with writing, maintaining, and ignoring dynamic fields across dozens of schemas is exactly why we built Fixzi.ai.Instead of forcing you to manually map out massive JSON structures or guess which fields are going to throw false positives in production, Fixzi automates the heavy lifting. It continuously monitors your live APIs, automatically maps your contracts, highlights actual breaking differences, and smartly ignores the chaotic dynamic fields (like tokens and timestamps) that you shouldn't be wasting time worrying about.It turns API validation from a tedious chore into background peace of mind.