Nuffing.com

The Spatie team has open-sourced their internal coding guidelines as reusable AI skills via spatie/guidelines-skills. Skills are reusable instruction sets for AI coding assistants that activate automatically based on context — think of them as project-aware prompts that keep an AI agent aligned with your team’s conventions without repeated manual guidance.

The package ships with four skills covering the areas Spatie cares most about:

• spatie-laravel-php — PSR-12 standards, typed properties, constructor promotion, early returns, Laravel controller naming, validation rules, and Blade template practices.
• spatie-javascript — Prettier configuration, const declarations, strict equality operators, named functions, and destructuring patterns.
• spatie-version-control — Repository naming, branch conventions, commit messaging, and squash merge strategies.
• spatie-security — SSL requirements, CSRF protection, password hashing, database permissions, and credential management.

The skills are distributed through skills.sh, which means they work across multiple AI stacks — Claude Code, Cursor, Codex, and GitHub Copilot.

For Laravel Boost users, installation is via Composer:

composer require spatie/guidelines-skills --dev
php artisan boost:install

Select the Spatie guidelines from the available options and they’ll be set up automatically. To keep them current as the guidelines evolve, run:

composer update spatie/guidelines-skills
php artisan boost:update

If you’re not using Laravel Boost, you can install via the skills.sh CLI instead:

npx skills add spatie/guidelines-skills

Previously, Spatie offered a similar package spatie/boost-spatie-guidelines exclusively for Laravel Boost users. The move to skills.sh opens this up to anyone regardless of their AI tooling setup.

If you want a head start aligning your AI coding assistant with battle-tested Laravel and PHP conventions, the source is available on GitHub.

Wall Street seems to think Anthropic’s new AI design tool could be a serious threat to Figma and other software.

On Friday, Anthropic announced Claude Design, a new tool that lets users create polished visuals like slide decks, app prototypes, and marketing one-pagers using simple text prompts. The tool is powered by Claude Opus 4.7 and is rolling out as a research preview to Claude Pro, Max, Team, and Enterprise subscribers gradually throughout today.

It works by letting users describe what they want in plain language prompts. They can also upload codebases and design files, allowing Claude to build a design system that automatically applies a team’s colors, typography, and other design components across projects.

Claude then generates an initial version of the design, which users can refine through conversation, inline comments, direct edits, or custom sliders built by Claude.

Projects can be exported as PDFs, PowerPoints, or into Canva. Once completed, designs can also be packaged for Claude Code to build into working projects.

Anthropic said the tool has already been used to create realistic prototypes, pitch decks, and marketing materials. The company is pitching it as a way for experienced designers to explore ideas more quickly, while also giving founders and product managers without a design background a way to bring their ideas to life.

“Claude Design gives designers room to explore widely and everyone else a way to produce visual work,” the company said in a press release.

Anthropic is also emphasizing that the tool could be used to complement other products rather than completely replace them.

“We’re excited to build on our collaboration with Claude, making it seamless for people to bring ideas and drafts from Claude Design into Canva, where they instantly become fully editable and collaborative designs ready to refine, share, and publish,” Canva’s CEO said in Anthropic’s press release.

It should be noted that LLMs have been incredibly unreliable when it comes to generating visual elements. Yes, image generators can be impressive on first glance, but when a user starts trying to edit individual elements, things can quickly fall apart. We will have to wait and see how well Claude Design pulls off its stated purpose.

Still, Wall Street appears to see it as competition for the design industry.

Figma’s stock fell about 7% on Friday following the announcement. The company is widely considered the dominant player in UI and UX design for websites and apps, with an estimated 80% to 90% marketshare.

The timing is notable. Just two months ago, Figma launched a feature called Code to Canvas, which lets users convert code generated by tools like Claude Code into editable designs inside Figma.

Adding to the tension, Anthropic Chief Product Officer Mike Krieger stepped down from Figma’s board just days ago amid speculation the company was gearing up to launch a design tool.

Figma did not immediately respond to a request for comment from Gizmodo.

Editor’s note: This post originally appeared on The New Stack and is republished with permission. The original version is available here.

Key Takeaways

• S3’s durability and global availability remove the need to co-locate data with compute.
• Decoupled storage enables ephemeral clusters, event-driven workflows, and automatic tiering.
• TiDB X uses S3 as its shared backend for independent scaling and faster recovery.
• Object storage-first architecture matches the elastic, on-demand needs of AI agents.

For decades, database designers have built distributed databases around the assumption that storage must live close to compute.

The farther data travels over the network, the reasoning goes, the greater the potential for delay. Local RAID (redundant array of independent disks) arrays, network-attached storage (NAS), and cluster file systems keep data close, making it quick and easy to access. 

But in a distributed system, keeping the entire data store close to compute makes scaling slow, cumbersome, and expensive. Each time you replicate a node or cluster, you must replicate its associated data as well.

It isn’t ideal, but until recently, there wasn’t any reasonable alternative. Databases had to scale. Teams had to meet service-level agreements (SLAs). Wide-area networks weren’t reliable enough to support high-performance databases at scale. Database designers accordingly spent a great deal of energy solving problems related to coordination, consistency, and replication logic.

But imagine things were different. What if they didn’t have to worry about the network, where their data lived, or how to get it from Point A to Point B? How would they design a database then?

That’s the intriguing question raised by the advent of cloud object storage services like AWS S3, Google Cloud Storage, and Microsoft Blob Storage.

What is Cloud Object Storage?

The structure of cloud object storage services couldn’t be simpler. They’re essentially giant heaps of data, accessed via an API, through key/value pairings.

Their unlimited storage capacity and their “everywhere” availability make them revolutionary. They can hold billions of records — images, logs, training data, whatever you need — and crucially, they can make every one of those records available to compute anywhere in the world, at any level of workload.

S3 is extremely reliable. AWS designed S3 for 11 nines of durability (that’s 99.999999999%) and 99.99% availability, and it replicates data automatically across Amazon’s regional facilities. This means data on S3 is extremely safe and highly available without the need to manage physical disks or replication.

In addition, S3 scales seamlessly. There are no fixed volumes. No need for capacity planning. You can store practically unlimited data, and performance scales with parallel access rather than a single-server bottleneck. These guarantees free architects from worrying about low-level storage failures, capacity, and edge cases involving consistency. 

In short, cloud object storage provides a highly durable, always-on, strongly-consistent single source of truth. It’s not as fast as local storage, but it doesn’t have to be. What services like S3 lack in sheer speed, they more than make up for in reliability and ease of maintenance. Instead of worrying about shards, segmentation, and software-defined networks, a database can simply retrieve data with confidence that it will be delivered in a reasonable amount of time. 

What this means is that for the next generation of distributed databases, cloud object storage will, for all intents and purposes, be the network. 

Architectural Patterns Emerging Around Object Storage

Building on cloud object storage enables several architectural patterns that were previously impractical.

• Ephemeral compute clusters: Keeping object storage separate from compute makes it easier to spin up clusters temporarily for a specific job and tear them down afterward. This is especially useful for AI agents, which often construct temporary databases to accomplish tasks. Compute can be spun up at will without the overhead of data replication.
• Event-driven workflows: The arrival of a new object in S3 can trigger a Lambda function, start a training job, or notify downstream consumers. This sort of workflow would be impractical in a system with highly replicated data, but it’s trivial when data is centralized in a single store.
• AI and ML pipelines: Many distributed machine learning workflows benefit from a centralized object storage data store. Training datasets, feature stores, model checkpoints, and experiment logs all commonly live in object stores. Frameworks like TensorFlow, PyTorch, and SageMaker are designed to stream data directly from object storage.
• Tiering storage at large scale: Databases often classify data as either in-demand (“hot”) or rarely accessed (“cold”). Hot data is stored on high-speed flash storage, while cold data is stored on a more cost-efficient spinning disk. Provisioning hot and cold storage normally requires manual intervention and careful capacity planning. But with cloud object storage, the database can automatically handle tiering, shuffling data between the object store and the high-speed cache based on demand. The availability and infinite capacity of the object store make planning unnecessary.

Example: TiDB X

Now let’s see how these capabilities translate into a real-world design. PingCAP uses cloud object storage as the foundation for TiDB X, the latest version of our popular open source distributed SQL database, TiDB.

Figure 1. TiDB X’s architecture with built-in object storage.

As shown in the diagram above, TiDB X fully separates compute and storage, using S3 for the shared backend. Compute nodes scale independently up and down. Fast local caches and Raft ensure consistency and low-latency access for hot data. Instead of keeping the entire data store close by, TiDB X keeps only the most active data near compute. TiDB X monitors query patterns, latency targets, and data characteristics, then reshapes itself in response to demand. 

Its object storage-based architecture streamlines recovery and backup processes. By using S3 for primary data persistence, TiDB X reduces the overhead of traditional backup maintenance, enabling significantly faster completion times. This design also mitigates the impact of node failures: since local state functions primarily serve as a cache for durable, replicated storage, a failed instance can be replaced by retrieving its required state directly from object storage to resume operations.

From an operational perspective, cloud object storage makes TiDB X both highly adaptable and extremely cost-efficient. Its autoscaler responds not just to preset infrastructure thresholds, but to contextual signals like query patterns, latency targets, and data types. This enables it to reshape its resources in real time to address different tasks.

In sum, by building atop AWS’s high-performance object data store, TiDB X demonstrates how a cloud database can achieve elasticity, performance, and simplicity without sacrificing consistency or scale.

S3 as the Communication Fabric

Keeping large relational data stores close to compute resources has always been a compromise. It was an expensive solution to a problem created by the limitations of traditional networking. 

With architectures like TiDB, we see that the sheer power and scale of services like S3 have made the old workarounds unnecessary. They’ve rendered traditional architectures increasingly obsolete. More than that, they’ve enabled practices, such as ephemeral compute, suited to a world where users are more likely to be AI agents than humans.

As AI reshapes business organizations and best practices, the database itself is changing form. In large part, it’s services like S3 that are making that shift possible. By making data placeless, ubiquitous, and effortlessly accessible, cloud object storage is overturning the assumptions that once guided database design. The result will be databases that are more flexible and resilient  — ones that are simpler to manage and scale almost effortlessly.

TiDB X is built from the ground up on cloud object storage. Explore the architecture behind it or try TiDB Cloud for free to see it in action.

Steve and Timpani moved from California to Texas in the hit series Californians Move To Texas. There were a few cultural differences they weren’t prepared for in going from California wokeness to Texas freedom. Now their story continues…

In the all-new season, Steve and Timpani’s continued adjustment to all things Texas hits a speed bump when Timpani’s sister, Brittuni, arrives to talk some "California sense" into her gun-loving sister. Can Steve and Timpani’s love survive the wedge slowly being driven between them? And who knows what other surprises may be in store.

Catch the trailer here and get hype:

Episode 1: The Rodeo will premiere on YouTube on April 7 at 7PM PT: