DEV Community: BLNCraft

3 Files Every AI-Assisted Project Needs Before You Write a Line of Code

BLNCraft — Fri, 29 May 2026 23:06:11 +0000

Most developers think of project setup as: install dependencies, configure TypeScript, set up linting.

That is the wrong order. The AI-native setup order is different, and skipping it means your AI assistant works against your project instead of with it.

Here are the three files that should exist before you write a line of application code.

File 1: CLAUDE.md (the instruction layer)

CLAUDE.md is a markdown file at your project root that Claude Code loads as a system prompt prefix on every session. Think of it as the briefing document your AI assistant reads before touching your codebase.

A minimal CLAUDE.md for a new project:

# Project: My SaaS App

## Stack
Next.js 15, TypeScript strict, Prisma + PostgreSQL, Tailwind CSS

## Rules
- No `any` types. No unvalidated JSON.parse().
- Auth via NextAuth.js. Never roll custom auth.
- DB access only in `src/services/` — never in route handlers directly.
- Run `npm run typecheck` before declaring a fix done.

## Deploy
Vercel. Main branch auto-deploys. Staging on `preview` branches.

Ten lines. That is enough to prevent 80% of the decisions where the AI would otherwise guess wrong.

Why write this before any code? Because when you write it after, you are describing what you accidentally built rather than what you intended. The instruction layer should drive the codebase, not document it retroactively.

File 2: .cursorrules (the tool layer)

If you use Cursor, @.cursorrules loads into Cursor's context. It is similar to CLAUDE.md but optimized for Cursor's behavior — shorter, more rule-focused, less narrative.

The key difference from CLAUDE.md: CLAUDE.md can afford to be contextual ("we use Prisma because our team knows it"). @.cursorrules should be purely prescriptive ("never write raw SQL; use Prisma query builders").

Keep them in sync. If you update the auth pattern in one, update the other. Two source-of-truth files with the same content that drift apart are worse than one.

A clean pattern: have CLAUDE.md be the canonical source. In .cursorrules, reference it and add only Cursor-specific formatting rules:

Project context: see CLAUDE.md at repo root.

Additional Cursor rules:
- Auto-import from absolute paths, not relative.
- Prefer named exports over default exports.
- Format with Prettier on save — do not manually align anything.

Four lines. Everything else lives in CLAUDE.md.

File 3: README.md (the onboarding layer)

This one surprises people. The README is not for human readers — it is for your AI assistant's cold-start.

When you open a new Cursor session or start a new Claude Code chat, the AI does not remember anything from yesterday. The README is the document it will read first if you paste it in, and it is what future agents (or you, in three months) will read to understand how the project works.

A README that serves as an AI onboarding document:

## Quick context
SaaS app for indie devs. Subscription billing via Stripe, auth via NextAuth.js,
database via Prisma + PostgreSQL on Neon.

## Local setup
npm install && cp .env.example .env.local && npx prisma migrate dev

## Project structure
src/
  app/          Next.js App Router pages
  services/     Business logic — no HTTP here
  components/   React components — no data fetching here
  lib/          Utilities and config

## Common tasks
Run dev: npm run dev
Run types: npm run typecheck
Run tests: npm test
Deploy: push to main

No fluff. No marketing copy. Just: what is this, how do I start it, what is where.

Why all three, before any code

These three files form a triangle:

CLAUDE.md tells the AI what matters (the stakes, the patterns, the non-negotiables)
.cursorrules tells the AI how to behave (the mechanical rules, the formatting, the import conventions)
README.md tells the AI what exists (the structure, the commands, the mental model)

When all three are in place before you write application code, you are building inside a defined context. The AI works with your decisions instead of making its own.

When none of them are in place, you are doing vibe coding in the wrong direction — the AI is building something, and you are figuring out what it is as you go.

The shortcut

Setting these three files up for a new project takes 20-30 minutes if you are doing it from scratch. Doing it for 12 different tech stacks (Next.js SaaS, Express + JWT, FastAPI, Discord Bot, Chrome Extension, and more) takes considerably longer.

The Vibe Coder Kit packages 12 production-configured starters where all three files are already in place and consistent with the actual codebase. You clone, run the setup command, and your AI assistant is already briefed.

The test

At the end of your next project setup, ask: "If a new developer (or a new AI session) opened this repo with no context, could they figure out what it is, how to run it, and how to work in it?"

If the answer is yes, you have done the setup right.

BLN Craft builds developer tools for AI-native workflows. Find us at blncraft.com.

5 .cursorrules Antipatterns Killing Your AI Productivity

BLNCraft — Fri, 29 May 2026 23:01:44 +0000

Your .cursorrules file is probably not working the way you think it is.

Not because Cursor is broken — but because most .cursorrules setups make the same five mistakes. Here is what they are and how to fix them.

Mistake 1: One file, everything in it

The most common .cursorrules antipattern is the monolith: one file at the project root, 300 lines long, covering TypeScript conventions AND API auth patterns AND deployment notes AND "always write clean code."

The problem: Cursor loads this file into every context, regardless of what you are editing. When you are fixing a CSS bug, your SQL query rules are burning token budget for nothing. When context gets long, older rules get compressed out — which means your most important constraints are the ones most likely to disappear.

Fix: Split into scoped rule files.

.cursorrules                  # 50 lines: project overview, stack, non-negotiables
src/api/.cursorrules          # Auth patterns, error format, rate limiting
src/components/.cursorrules   # Component conventions, state patterns  
scripts/.cursorrules          # Env handling, idempotency, logging

Each file loads only when files in that directory are open. Your total in-context rule budget stays tight.

Mistake 2: Vague constraints

"Write clean, readable code."
"Keep functions small."
"Follow best practices."

These are not rules. They are aspirations. The AI already knows what "best practices" means — and it will apply its own interpretation, not yours.

Rules need to be specific enough to fail. If you cannot imagine a concrete code sample that violates the rule, the rule is too vague to enforce.

Vague: "Handle errors properly."
Specific: "All async functions must have a try/catch. Errors must be logged via logger.error() before rethrowing. Never swallow errors silently."

Vague: "Use descriptive variable names."
Specific: "Boolean variables must start with is, has, should, or can. No single-letter names outside of loop indices."

The second versions are automatable. The first versions are vibes.

Mistake 3: No project structure context

The AI does not know your project layout unless you tell it. This leads to imports from wrong paths, new files dropped in wrong directories, and helper functions duplicated because the AI didn't know one already existed.

Add a compact directory map early in your .cursorrules:

Project structure:
src/
  api/          # Express routes + middleware
  services/     # Business logic (no HTTP)
  models/       # Prisma schema types
  utils/        # Pure functions, no side effects
  types/        # Shared TypeScript interfaces
tests/          # Mirrors src/ structure
scripts/        # One-off automation, not imported by app

Eight lines. Enough to save the AI from putting a database call in a route handler because it didn't know services/ exists.

Mistake 4: Rules that contradict the codebase

If your .cursorrules says "never use any types" but your codebase has 200 any type usages, the rule is fighting the existing code. The AI gets conflicting signals: the rule says one thing, the examples in the codebase say another. The examples usually win.

Your rules should describe what the code already does, not what you wish it did.

If there is a gap — you want to adopt a new pattern but your codebase isn't there yet — say so explicitly:

# Migration in progress: we are removing `any` types.
# New code must not use `any`. Existing `any` usages will be fixed incrementally.
# Do not add new `any` even when refactoring old code.

This gives the AI a clear mandate without creating a contradiction.

Mistake 5: Duplicating rules across tools without a source of truth

If you use Cursor + Claude Code, you end up with .cursorrules and CLAUDE.md saying the same things in slightly different ways. Then one gets updated and the other doesn't. Then they contradict each other. Then neither is trusted.

The fix is a single authoritative source with tool-specific adaptations:

Keep your core project rules in CLAUDE.md (it is the most structured format and is loaded by Claude Code as a system prompt prefix).
Have .cursorrules import or reference the same core rules, adding only Cursor-specific formatting/behavior.
When you update the rules, update the source — not each tool's file separately.

For greenfield projects, starting with a production-configured starter that already has both files wired up correctly saves this setup cost entirely. The Vibe Coder Kit includes 12 starters (Next.js SaaS, Express + JWT, FastAPI, Discord Bot, and more) where .cursorrules and CLAUDE.md are already synchronized and match the actual codebase structure.

The test for a good rules file

Read each rule and ask: "Could a developer violate this rule while genuinely trying to follow it?" If yes, the rule is too ambiguous. Make it specific enough that violations are unambiguous.

Then count your lines. If your .cursorrules is over 100 lines, split it. If it is under 20, you probably have not captured your real conventions yet.

Short. Specific. Scoped. Consistent with the codebase.

Those four constraints will make your AI coding setup work the way the demos promise.

BLN Craft builds developer tools for AI-native workflows. Find us at blncraft.com.

5 CLAUDE.md Patterns That Make AI Actually Follow Your Rules

BLNCraft — Fri, 29 May 2026 22:58:36 +0000

Have you ever set up a CLAUDE.md file, dropped in 200 lines of rules, and then watched the AI completely ignore half of them anyway?

You are not alone. The irony of writing instructions for AI coding assistants is that the same productivity trap applies to you: more rules ≠ better results.

Here are five patterns that actually work, learned from managing production CLAUDE.md setups across a dozen project starters.

1. The 800-token rule

The biggest CLAUDE.md mistake is treating it like documentation. It is not documentation. It is a system prompt prefix — and system prompts have a working memory budget.

A rough heuristic: keep your primary CLAUDE.md under 800 tokens (~600 words). Beyond that, context compression pushes older rules out when long files are open.

What to cut:

Rationale paragraphs ("we do this because...")
Historical context ("we used to use X but now...")
Anything that is obvious from the codebase itself

The rule goes in CLAUDE.md. The rationale goes in a comment in the relevant file, or nowhere.

2. Use glob-scoped rules, not one giant file

Claude Code supports scoped CLAUDE.md files — rules in src/api/CLAUDE.md apply only when files under src/api/ are open. Use this.

A frontend rule about "never use inline styles" has no business loading when the AI is working in your Express routes. A backend rule about "always use parameterized queries" does not need to be in context when fixing a CSS animation.

Practical layout:

CLAUDE.md              # project-wide: stack, deploy process, critical invariants
src/api/CLAUDE.md      # API-specific: auth patterns, error formats, rate limiting
src/web/CLAUDE.md      # Frontend-specific: component conventions, state patterns
scripts/CLAUDE.md      # Automation: env var handling, idempotency requirements

Each file stays under 300 tokens. Total loaded at any time: ~600 tokens. Still under budget.

3. One concern per rule

Compound rules fail silently. When you write:

"Functions should be small, pure, and well-named, with explicit return types and no side effects unless they are in service files."

...the AI picks the parts it agrees with and ignores the rest. This is not a model quality problem — it is a parsing problem. Compound sentences create ambiguity about which clause is the constraint and which is the suggestion.

Split every compound rule into atomic statements:

## Functions
- Max 30 lines. Extract helpers if exceeded.
- Explicit return types on all exported functions.
- No side effects except in `*Service.ts` and `*Repository.ts` files.

Three lines, three enforceable constraints, zero ambiguity.

4. Negative rules outperform positive rules

"Use Zod for all schema validation" is a positive rule. It tells the AI what to do, but not how strongly you mean it.

"Never use any types. Never use untyped JSON.parse() without a Zod schema." — these are negative rules. They draw a hard line.

In practice, AI assistants weight prohibitions more heavily than recommendations. This is because prohibitions reduce the valid solution space (easier to enforce) while recommendations just add a preference (easier to deprioritize under other pressures).

Reframe your positive rules as negative rules where you can:

Positive	Negative
Use environment variables for all config	Never hardcode URLs or credentials
Write tests for all public functions	Never ship a new exported function without a test file
Use the existing logger	Never call `console.log` directly in production code

The negative framing also makes violations easy to grep for.

5. Pair CLAUDE.md with a production-configured starter

The best CLAUDE.md is one that describes a codebase that already follows its own rules. When the starter project has ESLint configured, TypeScript strict mode on, and the folder structure already in place — the CLAUDE.md rules are reinforced by the code itself.

This is why project starters are worth spending time on. If your starter has any types everywhere and no linting, your CLAUDE.md rule against any is fighting the existing codebase instead of aligning with it.

We built the Vibe Coder Kit specifically for this: 12 production-configured starters (Next.js SaaS, Express + JWT, Node CLI, Chrome Extension, Discord Bot, FastAPI, and more) where the CLAUDE.md rules match what the code already does. Zero setup, immediate AI alignment.

The one-line takeaway

CLAUDE.md files fail the same way most documentation fails: they get long, stale, and comprehensive when they should be short, current, and opinionated.

Short. Scoped. Atomic. Negative where possible. Backed by a codebase that already follows the rules.

That is the setup that makes vibe coding actually work.

BLN Craft builds developer tools for AI-native workflows. Follow us at blncraft.com for more.

You Don't Need Microservices Yet: A Reality Check for Devs

BLNCraft — Wed, 27 May 2026 07:04:54 +0000

You spent three years building a distributed system. Kubernetes clusters, service meshes, inter-service gRPC calls, a dedicated message broker — and your user base is 200 people, 40 of whom are your coworkers testing it.

The Architecture Trap

There's a well-worn path in software engineering that goes something like this: you read about how Netflix decomposed their monolith, you watch a conference talk about event-driven architecture, and suddenly your SaaS for managing yoga class bookings has seventeen services, a Kafka cluster, and three on-call rotations.

This isn't a hot take. It's a recurring diagnosis. Developers — especially good ones — are pattern-matchers. We see sophisticated solutions to hard problems and we want to apply them. The trouble is, microservices aren't a better way to build software. They're a specific solution to a specific set of scaling and team-coordination problems that most applications will never have.

Netflix had thousands of engineers and hundreds of millions of users before they went full microservices. Your B2B dashboard tool does not have that problem. It has a different problem: it needs to ship features, fast, without a distributed tracing setup just to debug why a user can't log in.

What a Monolith Actually Looks Like in 2024

The word "monolith" has been so thoroughly dragged through the mud that developers treat it like a slur. But a well-structured monolith isn't a big ball of mud — it's a modular application with clear internal boundaries that happens to deploy as a single unit.

Here's a straightforward Node.js/Express monolith structure that scales comfortably to hundreds of thousands of users:

// src/app.ts — entry point, clean and boring
import express from 'express';
import { userRouter } from './modules/users/user.routes';
import { billingRouter } from './modules/billing/billing.routes';
import { notificationRouter } from './modules/notifications/notification.routes';
import { db } from './lib/db';

const app = express();

app.use(express.json());
app.use('/api/users', userRouter);
app.use('/api/billing', billingRouter);
app.use('/api/notifications', notificationRouter);

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

export default app;

// src/modules/users/user.service.ts — a self-contained module
import { db } from '../../lib/db';
import { NotificationService } from '../notifications/notification.service';
import { BillingService } from '../billing/billing.service';

export class UserService {
  private notificationService: NotificationService;
  private billingService: BillingService;

  constructor() {
    this.notificationService = new NotificationService();
    this.billingService = new BillingService();
  }

  async createUser(email: string, plan: string): Promise<{ id: string; email: string }> {
    // All of this happens in one process, one transaction, one deployment.
    // No network calls. No distributed transactions. No saga pattern.
    const user = await db.user.create({
      data: { email, plan, createdAt: new Date() },
    });

    await this.billingService.initializeBillingRecord(user.id, plan);
    await this.notificationService.sendWelcomeEmail(user.email);

    return { id: user.id, email: user.email };
  }

  async getUserById(id: string) {
    return db.user.findUnique({ where: { id } });
  }
}

Notice what's not here: no message queues to coordinate the billing and notification steps, no distributed tracing to figure out why the welcome email failed, no separate deployment pipelines per service. If something breaks, your stack trace tells you exactly where. Your rollback is one command.

The modules are still cleanly separated. If you ever genuinely need to extract NotificationService into its own service — because your notification volume is overwhelming the main app, or because a separate team owns it — you can. The internal boundaries are already there. You're paying none of the distributed systems tax until you actually need to.

The Real Costs Nobody Talks About

When someone pitches microservices, the conversation is usually about scalability and team autonomy. Fair points, eventually. But the costs are almost never foregrounded honestly:

Operational complexity compounds. Every service you add is a new thing that can fail in production, a new set of logs to aggregate, a new deployment pipeline to maintain. At five services you're fine. At twenty you need a platform engineering team whose entire job is keeping the infrastructure running for the product engineers.

Distributed transactions are genuinely hard. In the monolith example above, createUser runs billing and notification in sequence. If billing fails, you throw an error, nothing is committed, the user doesn't exist. In a microservices world, you've got eventual consistency, saga patterns, compensation transactions, and a whole new class of bugs where the user exists in one service but not another.

Local development gets painful fast. Running npm run dev is great. Running docker-compose up for twelve services, waiting for them all to be healthy, and then realizing service seven has a port conflict is a productivity graveyard. Junior devs especially get slowed down enormously.

Debugging requires infrastructure. In a monolith, you add a console.log and you're done. In microservices, you need distributed tracing (Jaeger, Zipkin, Datadog APM) just to follow a request through the system. That tooling is powerful, but it's also expensive and takes real time to set up correctly.

When Microservices Actually Make Sense

This isn't a microservices hit piece. There are legitimate reasons to decompose a system:

Independent scaling needs. Your video transcoding workload needs 10x the compute of your API layer and runs on completely different hardware profiles.
Team boundaries at scale. Once you have 50+ engineers, Conway's Law means your architecture should reflect your org structure. Separate teams genuinely benefit from deployment independence.
Wildly different tech requirements. Your ML inference pipeline wants Python and GPUs. Your API wants Node. They genuinely shouldn't be the same process.
Compliance isolation. Your payment processing code needs to live in a PCI-compliant environment that the rest of your app doesn't touch.

If none of these apply to you right now, you don't need microservices. You need a better-organized monolith and maybe a read replica on your database.

A Practical Migration Path That Isn't Premature

If you're starting fresh or refactoring, here's the approach that keeps your options open without paying distributed systems costs upfront:

Build a modular monolith. Strong internal module boundaries, dependency injection, no circular imports between modules. Treat each module as if it could become a service, but don't make it one.
Use a job queue early. Not Kafka — something like BullMQ backed by Redis. This handles async workloads (emails, webhooks, report generation) without splitting your codebase. One deployment, async processing.
Watch your metrics, not your ambitions. Set up basic APM. Only split a service when you have concrete evidence that a specific part of the system is causing problems — response time degradation, resource contention, deployment coupling that's actually slowing teams down.
Extract one service as an experiment before extracting many. The operational overhead of service number two is enormous relative to one. Service number five is marginal. Feel the actual cost before committing the architecture.

Ship the Thing

The best architecture is the one that lets you move fast now while not painting you into a corner for later. A well-structured monolith with clear module boundaries does exactly that. It's boring, it's pragmatic, and it ships.

At BLN Craft, we build dev tools for developers who want to move faster without setting their architecture on fire first. If you're tired of infrastructure getting in the way of building, come take a look.

Now go delete a Kubernetes cluster you didn't need.

How AI Image Generation Is Quietly Eating Developer Workflows in 2026

BLNCraft — Tue, 26 May 2026 14:02:22 +0000

You spent three years perfecting your pixel-art aesthetic. Congratulations — a neural network can now replicate it in 400 milliseconds.

That's not a threat. That's actually the most interesting development in developer tooling this year, and if you're not thinking about how AI image and video generation slots into your build pipeline, you're leaving both time and money on the table.

The Irony Is the Point

Here's the 2026 situation: we are living through peak retro-aesthetic obsession — lo-fi pixel art, CRT shaders, chunky 8-bit sprites — at the exact same moment that AI image generation has crossed the uncanny valley and landed squarely in "indistinguishable from real" territory. Midjourney v7, Stable Diffusion XL successors, and a wave of API-first generators have made photorealistic content generation a commodity.

For indie devs and small studio teams, this convergence is genuinely useful. You no longer need a motion designer on retainer to produce onboarding videos, asset variations, or marketing visuals. You need an API key, a prompt strategy, and about 45 minutes to wire it up.

The tools that have reached serious adoption — like the generation platforms hitting millions of users in 2026 — tend to share a few traits: advanced editing, session-scoped privacy (assets auto-deleted after use), and programmatic access. Those aren't luxury features anymore. They're table stakes.

Let's talk about how to actually use this in a dev context.

Wiring an AI Image Generation API Into Your Node Pipeline

Most generation APIs follow the same basic pattern: POST a prompt and config, poll or receive a webhook with the result URL, download and store the asset. Here's a clean TypeScript implementation that works with any OpenAI-compatible image endpoint (swap the base URL for your provider of choice):

import axios from 'axios';
import fs from 'fs/promises';
import path from 'path';

interface GenerationOptions {
  prompt: string;
  width?: number;
  height?: number;
  style?: string;
  outputDir?: string;
}

interface GenerationResult {
  url: string;
  localPath: string;
  generatedAt: string;
}

async function generateImage(options: GenerationOptions): Promise<GenerationResult> {
  const {
    prompt,
    width = 1024,
    height = 1024,
    style = 'photorealistic',
    outputDir = './generated',
  } = options;

  const response = await axios.post(
    'https://api.your-image-provider.com/v1/images/generate',
    {
      prompt: `${prompt}, ${style}`,
      width,
      height,
      response_format: 'url',
    },
    {
      headers: {
        Authorization: `Bearer ${process.env.IMAGE_API_KEY}`,
        'Content-Type': 'application/json',
      },
    }
  );

  const imageUrl: string = response.data.data[0].url;

  // Download and persist locally — don't rely on ephemeral provider URLs
  await fs.mkdir(outputDir, { recursive: true });
  const filename = `asset-${Date.now()}.png`;
  const localPath = path.join(outputDir, filename);

  const imageBuffer = await axios.get(imageUrl, { responseType: 'arraybuffer' });
  await fs.writeFile(localPath, imageBuffer.data);

  return {
    url: imageUrl,
    localPath,
    generatedAt: new Date().toISOString(),
  };
}

// Usage
(async () => {
  const result = await generateImage({
    prompt: 'A Berlin street at dusk, neon reflections on wet cobblestones',
    style: 'cinematic photography, 35mm',
    outputDir: './assets/generated',
  });

  console.log(`✓ Saved to ${result.localPath}`);
})();

Two things worth noting here. First, always download and store the asset yourself — provider URLs are frequently ephemeral, especially on platforms with session-scoped deletion. Second, appending style descriptors to the prompt programmatically means you can run the same base prompt through multiple style passes in a loop without touching your prompt logic.

Automating Asset Variant Generation With a Bash Script

If you're building a game, a marketing site, or anything that needs multiple visual variants of the same concept, doing this manually is exactly the kind of work you should automate. Here's a shell script that takes a base prompt and generates variants across a list of style modifiers:

#!/usr/bin/env bash

set -euo pipefail

API_KEY="${IMAGE_API_KEY}"
API_URL="https://api.your-image-provider.com/v1/images/generate"
BASE_PROMPT="${1:-'a developer working late in a Berlin apartment'}"
OUTPUT_DIR="./generated-variants"

STYLES=(
  "pixel art, 16-bit retro"
  "photorealistic, cinematic lighting"
  "watercolor illustration"
  "cyberpunk neon aesthetic"
  "minimalist flat design"
)

mkdir -p "$OUTPUT_DIR"

for STYLE in "${STYLES[@]}"; do
  FULL_PROMPT="${BASE_PROMPT}, ${STYLE}"
  SAFE_STYLE=$(echo "$STYLE" | tr ' ,' '__')
  OUTFILE="${OUTPUT_DIR}/variant_${SAFE_STYLE}_$(date +%s).png"

  echo "→ Generating: ${FULL_PROMPT}"

  RESPONSE=$(curl -s -X POST "$API_URL" \
    -H "Authorization: Bearer $API_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"prompt\": \"${FULL_PROMPT}\", \"width\": 1024, \"height\": 1024, \"response_format\": \"url\"}")

  IMAGE_URL=$(echo "$RESPONSE" | python3 -c "import sys, json; print(json.load(sys.stdin)['data'][0]['url'])")

  curl -s -L "$IMAGE_URL" -o "$OUTFILE"
  echo "✓ Saved: $OUTFILE"
done

echo "\nAll variants generated in ${OUTPUT_DIR}"

Run it as: bash generate-variants.sh "a developer working late in a Berlin apartment"

You'll get five variants in under two minutes. Now pipe that into your asset build step, your Figma import workflow, or your CI/CD pipeline if you're generating OG images dynamically.

Practical Takeaways for Dev Teams

1. Treat generation as a build step, not a manual task. If you're hand-prompting images for every release, you're doing it wrong. Codify your prompts, version them in your repo, and run generation as part of your asset pipeline.

2. Session-scoped privacy matters for client work. Platforms that auto-delete generated content after a session aren't just a marketing bullet point — they're genuinely relevant when you're generating assets for client projects under NDA. Know what your provider's data retention policy is before you use it professionally.

3. Style-as-parameter is a design system concept now. You can maintain a styles.json config that maps your brand's visual language to prompt modifiers. Swap the style config per project. This is essentially a visual design token system for AI generation.

4. The pixel-art irony is actually useful. Generating a photorealistic base image and then applying a pixel-art post-process shader in your game engine or CSS gives you the best of both worlds: AI-quality composition and layout, retro aesthetic on top. This is a real technique people are shipping.

5. Video is 6-12 months behind image in API maturity. Most video generation APIs are still in closed beta or have rate limits that make them impractical for automated pipelines. Build your image workflow now; the video equivalent will slot in with minimal refactoring when it's ready.

The Bigger Picture

We're at a strange inflection point. The tools for generating realistic visual content are mature enough to be boring infrastructure, but most development teams are still treating them as novelty. The teams that will move fastest in the next 18 months are the ones that have already automated their asset generation and are spending their creative energy on the 10% that automation can't touch.

Berlin-style honesty: the AI image generation hype cycle peaked about 18 months ago. What we have now is the boring, productive aftermath — commodity APIs, reasonable pricing, and enough stability to actually build on. That's the best time to start.

BLN Craft builds developer tools for people who'd rather be shipping than configuring. If that sounds like you, come find us at blncraft.com — we're always working on something that helps developers move faster without the usual nonsense.

Jira Is Turing-Complete (And You've Been Coding in It)

BLNCraft — Mon, 25 May 2026 07:06:21 +0000

You didn't realize it, but the last time you built a Jira workflow, you wrote a program. A bad one, probably — no version control, no tests, no linter — but a program nonetheless.

The Uncomfortable Truth About Jira

Jira started as a bug tracker. A humble list of things that were broken, assigned to people who would fix them. That was 2002. Fast-forward to today and Jira is a sprawling automation engine with conditional branching, state machines, persistent storage, and event-driven triggers. It has, without anyone really intending it to, crossed the threshold into Turing completeness.

This isn't a hot take for engagement. Nicolas Seriot actually explored this — demonstrating that Jira's workflow and automation system is expressive enough to simulate computation. And once you see it, you can't unsee it.

The implications are weird and worth unpacking.

What Turing Completeness Actually Means (Briefly)

A system is Turing complete if it can simulate any computation given enough time and memory. The classic examples are Rule 110, Conway's Game of Life, and — now, apparently — your company's sprint board.

The key ingredients: conditional logic, state that persists, and the ability to loop. Jira has all three:

Workflows are finite state machines. Statuses are states. Transitions are edges. Guards on transitions are conditionals.
Custom fields are persistent memory. You can read them, write them, and branch on their values.
Automations are event-driven triggers with branching logic, field updates, and the ability to create or modify issues — including triggering further automations.

That last point is the kicker. Automations can trigger automations. You have recursion. Or at least iteration. You're cooked.

You've Already Written Jira Programs

Here's a concrete example. Say you build a workflow where:

A ticket enters In Review
An automation checks a custom field review_pass_count (integer)
If it's less than 2, it increments the field and transitions the ticket back to In Progress with a comment
If it's 2 or more, it transitions to Done

That's a loop with a counter. That's a while loop. In Jira.

In pseudocode:

review_pass_count = 0

while review_pass_count < 2:
    status = "In Progress"
    review_pass_count += 1

status = "Done"

The Jira automation that implements this looks roughly like the following when exported as JSON (Jira Cloud lets you import/export automation rules as JSON):

{
  "trigger": {
    "type": "FIELD_VALUE_CHANGED",
    "configuration": {
      "fields": ["status"],
      "toStatus": "In Review"
    }
  },
  "conditions": [
    {
      "type": "ISSUE_FIELDS_CONDITION",
      "configuration": {
        "conditions": [
          {
            "field": "cf[10042]",
            "operator": "LESS_THAN",
            "value": "2"
          }
        ]
      }
    }
  ],
  "actions": [
    {
      "type": "EDIT_ISSUE",
      "configuration": {
        "fields": [
          {
            "fieldId": "cf[10042]",
            "value": "{{issue.cf[10042] + 1}}"
          }
        ]
      }
    },
    {
      "type": "TRANSITION_ISSUE",
      "configuration": {
        "transitionId": "11"
      }
    }
  ]
}

This is real. This works. You just programmed a loop in a project management tool.

The State Machine Is Already There

Workflows are the part of Jira most developers ignore because they're "an admin thing." They shouldn't be. A Jira workflow is literally a directed graph — statuses as nodes, transitions as edges. That's a state machine, which is the foundation of a huge portion of real software: parsers, network protocols, UI components, game logic.

Here's a simple TypeScript representation of what your Jira workflow actually is under the hood:

type Status = "Backlog" | "In Progress" | "In Review" | "Done" | "Blocked";

type Transition = {
  from: Status;
  to: Status;
  guard?: (fields: Record<string, unknown>) => boolean;
  action?: (fields: Record<string, unknown>) => Record<string, unknown>;
};

const workflowTransitions: Transition[] = [
  { from: "Backlog", to: "In Progress" },
  { from: "In Progress", to: "In Review" },
  {
    from: "In Review",
    to: "Done",
    guard: (fields) => Number(fields["review_pass_count"]) >= 2,
  },
  {
    from: "In Review",
    to: "In Progress",
    guard: (fields) => Number(fields["review_pass_count"]) < 2,
    action: (fields) => ({
      ...fields,
      review_pass_count: Number(fields["review_pass_count"]) + 1,
    }),
  },
  { from: "In Progress", to: "Blocked" },
  { from: "Blocked", to: "In Progress" },
];

function transition(
  current: Status,
  target: Status,
  fields: Record<string, unknown>
): { status: Status; fields: Record<string, unknown> } | null {
  const match = workflowTransitions.find(
    (t) =>
      t.from === current &&
      t.to === target &&
      (t.guard ? t.guard(fields) : true)
  );

  if (!match) return null;

  return {
    status: target,
    fields: match.action ? match.action(fields) : fields,
  };
}

This is exactly what Jira is doing internally. Your workflow configuration is this code. It's just stored in a database and executed by their engine instead of a JavaScript runtime.

So What Do We Do With This Information?

A few things, practically speaking:

1. Version control your Jira automations.
If you accept that automations are code, they deserve version control. Export automation JSON regularly and commit it to a repo. Yes, this is tedious. So is debugging a production automation that someone silently changed three months ago.

2. Document your workflow logic like you'd document code.
Workflow screens in Jira are visual but not readable. Screenshot them, export them, and write a README explaining the intent. Future-you (or a new teammate) will need it.

3. Resist the urge to build complex logic inside Jira.
Just because you can build a loop counter in Jira doesn't mean you should. If your automation JSON exceeds ~50 lines, consider whether a real webhook + a small serverless function is more maintainable. It almost certainly is. Use Jira for state, use code for logic.

4. Use the API to inspect what you've built.
Jira's REST API lets you pull workflow schemes and automation rules programmatically. If you're inheriting a Jira instance, this is how you audit it without clicking through 47 admin screens.

curl -u your@email.com:YOUR_API_TOKEN \
  -X GET \
  -H "Content-Type: application/json" \
  "https://your-domain.atlassian.net/rest/api/3/workflowscheme" \
  | jq '.[].name'

This returns the names of all workflow schemes in your instance. A starting point for understanding what kind of program you've accidentally inherited.

The Deeper Point

Jira being Turing complete isn't a party trick. It's a symptom of a broader pattern: the tools we use to manage software are becoming as complex as the software they manage. Notion has formulas. Airtable has scripts. GitHub Actions is clearly a programming language (a bad one). The line between "configuration" and "code" has dissolved.

This means two things. First, developers should stop delegating tool configuration entirely to project managers and admins — there is code in there, and it deserves engineering attention. Second, the next time someone asks why your sprint velocity is down, you can honestly say you've been debugging a distributed state machine with no observability tooling.

That's a real answer.

BLN Craft builds developer tools for people who want to ship faster and think more clearly about their systems. If that sounds like you, check out what we're working on at blncraft.com.

The AI Dev Stack That Actually Works in 2026

BLNCraft — Sat, 23 May 2026 09:42:33 +0000

The AI Dev Stack That Actually Works in 2026

It's 2026. Your team has been shipping with Claude for two years. You've watched Cursor go from "interesting VSCode fork" to table stakes. You've automated half your n8n workflows. And you've probably noticed something: the hype was real, but the execution gap is brutal.

Most devs are still treating AI like a search engine that types code. They're not. The actual shift in 2026 isn't "AI writes your code." It's "AI executes your intent when configured correctly." And that configuration—the rules, the prompts, the workflow definitions—is where the real work lives.

What Changed Since 2024

Two years ago, the pitch was simple: "Describe what you want, Claude builds it." Turns out, that's not how humans and machines actually work together at scale.

What's different now:

1. Rules beat prompts. A well-written Cursor rule or CLAUDE.md file beats a 500-word system prompt. Rules are composable, versionable, and don't get lost in conversation history. Teams that invested in rule libraries in 2024 are 3x faster than teams still winging it with ad-hoc prompts.

2. Workflows are the moat. Raw model capability plateaued. Claude 3.7 isn't drastically smarter than 3.5. But n8n workflows—the ones that chain API calls, validate outputs, retry intelligently, and feed results back into your system—those workflows are where DevX and ROI collide. Every workflow you automate is one less human context-switch.

3. Integration maturity matters. Cursor's deep LSP integration, Claude Code's reasoning-first approach, and n8n's ability to handle state and error recovery. The stack that wins in 2026 isn't the one with the smartest model. It's the one with the tightest integration between editor, reasoning engine, and automation layer.

The Stack That Works

1. Cursor + Claude.md / Cursor Rules

Your source of truth for how AI should behave in your codebase. Not in Slack. Not in some shared notion doc. In version control, alongside your code.

Here's what a production Cursor rule looks like:

# You are a TypeScript/React specialist optimizing for performance and accessibility.
# Context: This is a design system for healthcare applications.

## Core Rules
- All components must pass axe accessibility audit
- Prefer Signals over Context for state when tree depth > 3
- CSS modules for styling; no inline styles
- All async operations must have cancellation tokens

## Code Patterns
- Use `useCallback` only for event handlers passed to children (avoid memoization overhead)
- Never re-export from index files; use explicit imports
- Test files live alongside source; suffix with `.test.ts`

## When to Use Claude
- Refactoring: Always. Especially migrations (e.g., Tailwind → CSS Modules)
- New features: Only after requirements are concrete
- Debugging: Only after you've checked the obvious stuff

## When NOT to Use Claude
- Architectural decisions: These are human calls
- Security logic: Review manually, always
- Package selection: You own the tradeoff analysis

That rule lives in your repo. Every new contributor reads it. Cursor reads it. Claude reads it. Consistency emerges without Slack discussions.

2. n8n for the Workflows That Compound

Not every automation is worth building. But certain ones are:

Code quality gates that run on every PR
Feedback loops that train your Cursor/Claude configuration
Integration glue (Slack → Jira → GitHub → metrics)
Polling and retry logic (the stuff that's boring to write but critical to scale)

Here's a real n8n workflow JSON snippet:

{
  "nodes": [
    {
      "name": "Trigger: GitHub PR Created",
      "type": "webhook",
      "typeVersion": 1,
      "position": [250, 300],
      "parameters": {
        "path": "github-pr-hook",
        "httpMethod": "POST"
      }
    },
    {
      "name": "Run Code Quality Check",
      "type": "n8n-nodes-base.http",
      "typeVersion": 4,
      "position": [500, 300],
      "parameters": {
        "url": "https://api.claude.ai/v1/messages",
        "method": "POST",
        "authentication": "predefined",
        "authType": "bearer",
        "sendBody": true,
        "bodyParameters": {
          "parameters": [
            {
              "name": "model",
              "value": "claude-3-5-sonnet-20241022"
            },
            {
              "name": "max_tokens",
              "value": "2048"
            },
            {
              "name": "system",
              "value": "You are a code reviewer. Check for security flaws, performance issues, and accessibility problems."
            },
            {
              "name": "messages",
              "value": "[{\"role\": \"user\", \"content\": \"Review: {{ $node.\"Trigger: GitHub PR Created\".json.body.pull_request.diff_url }}\"}]"
            }
          ]
        }
      }
    },
    {
      "name": "Post Result to GitHub",
      "type": "n8n-nodes-base.githubTrigger",
      "typeVersion": 1,
      "position": [750, 300],
      "parameters": {
        "comment": "Code Review: {{ $node.\"Run Code Quality Check\".json.body.content[0].text }}"
      }
    }
  ]
}

This workflow runs on every PR, calls Claude, and posts findings to GitHub. No humans in the loop (initially). Humans review the findings. The workflow improves.

What Devs Get Wrong

1. No Cursor rules or CLAUDE.md. They improvise. Every session is a negotiation. This scales to chaos.

2. Building workflows from scratch. There are 350 common patterns. Why reinvent? We ship pre-built n8n templates for: PR review, documentation generation, test case creation, dependency updates, and more. (We literally built this at BLN Craft.)

3. Treating the AI as a oracle, not a tool. The teams winning in 2026 use Claude/Cursor for execution, not ideation. Architects still design. Devs still understand the problem. AI automates the repetitive parts—the parts that are easy to specify, hard to write, and easy to verify.

4. Ignoring error handling in workflows. A workflow that fails silently is worse than no workflow. Add retry logic, fallbacks, and alerts.

How to Start

Write your first Cursor rule. Spend 30 minutes. Commit it. Share it with your team. Iterate based on what works.
Pick one workflow to automate. Not the hardest one. The most repetitive one. The one that feels like busy work. Automate it in n8n.
Measure. How much time did you save? Did quality improve? Did it introduce new bugs? Adjust.

We ship production-ready rules and 350+ workflow templates at blncraft.com for this exact setup. The CLAUDE.md + Cursor Rules Production Pack ($49) has templates you can fork. The n8n AI Workflow Templates ($79) cover most of the patterns we mentioned.

The AI dev stack in 2026 isn't mysterious. It's rules-based, versionable, integrated, and measurable. Build it.

Try it: Head to blncraft.com, grab the Cursor rules pack, and run them in your next PR review. Let us know what breaks. That's how we all get smarter.

Ship n8n Workflows 10x Faster (Stop Building From Scratch)

BLNCraft — Sat, 23 May 2026 09:41:19 +0000

You're staring at a blank n8n canvas. Again.

Your client needs an AI workflow that:

Ingests data from three different sources
Processes it through an LLM
Handles errors gracefully
Logs everything to their data warehouse
Runs on a schedule

Sounds straightforward, right? Except it's 2 AM, you've already burned three hours debugging node configurations, and you're still not sure if your error handling is bulletproof enough for production.

This is the n8n tax. Not the tool's fault—it's powerful and genuinely flexible. But that flexibility comes with a cost: every workflow starts from zero. Every integration needs careful node setup. Every edge case feels like you're inventing it yourself.

The Hidden Cost of Building n8n Workflows from Scratch

Here's what developers don't talk about enough: workflow automation looks simple until it isn't. You'll spend 70% of your time on the same boring stuff:

Configuration boilerplate. Setting up HTTP nodes with proper auth headers, pagination logic, and retry strategies. Setting up database connections with connection pooling. Handling API rate limits. None of this is complex—it's just... tedious.

Error handling patterns. What happens when an API times out? When a webhook fails? When your LLM call costs $50 by accident? You need guards. You need observability. You need to think through failure modes that everyone else already solved.

Integration wiring. Getting Slack → OpenAI → Google Sheets to play nicely together involves remembering node syntax, parameter naming conventions, and data transformation quirks. It's not hard, but it's easy to get wrong.

Testing in production. Because n8n doesn't have a great local testing story, you end up running workflows and watching logs. Finding a bug means updating the workflow, redeploying, and trying again.

Multiply this by every client project, every AI automation you ship, and you've lost weeks of your life to problems that have already been solved.

What Battle-Tested Workflow Templates Actually Solve

A good template isn't just a starting point—it's a working implementation with the boring stuff already handled. You copy it, swap three values, and you're running in production.

Let's be specific. Here's what a real HTTP → AI → Database workflow template needs:

{
  "nodes": [
    {
      "type": "n8n-nodes-base.httpRequest",
      "position": [250, 200],
      "parameters": {
        "url": "https://api.example.com/data",
        "method": "GET",
        "authentication": "oAuth2",
        "headers": {
          "User-Agent": "n8n-automation/1.0"
        }
      },
      "retryOptions": {
        "maxRetries": 3,
        "delayBase": 1000,
        "delayMultiplier": 2
      }
    },
    {
      "type": "n8n-nodes-base.openAi",
      "position": [450, 200],
      "parameters": {
        "model": "gpt-4-turbo",
        "prompt": "Analyze this data: {{ $json.body }}",
        "temperature": 0.7
      },
      "errorHandling": {
        "continueOnFail": false,
        "raiseOnError": true
      }
    }
  ]
}

But there's more. Here's the actual wiring that stops most people:

{
  "type": "n8n-nodes-base.postgres",
  "position": [650, 200],
  "parameters": {
    "operation": "executeQuery",
    "query": "INSERT INTO ai_results (id, input, output, created_at) VALUES ($1, $2, $3, NOW()) RETURNING id",
    "queryParameters": "{{ $json.body.id }}, {{ $json.body.input }}, {{ $json.choices[0].message.content }}"
  },
  "credentials": "postgres-prod"
}

See what just happened? We connected three different systems with proper error handling, credential management, and data transformation. That's roughly 2 hours of debugging and documentation reading compressed into 10 minutes of copy-paste.

The 350-Template Shortcut

Now imagine having this for:

50+ AI automation patterns: LLM-powered data processing, content generation, summarization, classification, RAG pipelines
API integration templates: Slack, Discord, Telegram, email, webhooks—all with proper auth and error handling
Database operations: PostgreSQL, MongoDB, Airtable, Google Sheets—with transaction handling and bulk operations
Data transformation workflows: CSV processing, JSON transformation, PDF extraction, image processing
Monitoring & observability: Error alerting, execution logging, cost tracking, performance metrics
Advanced patterns: Fan-out/fan-in, conditional branching, parallel processing, queue management

Each template is:

✓ Production-ready. Handles errors, retries, timeouts, and edge cases.
✓ Documented. Clear parameter setup with inline comments.
✓ Customizable. Built to be forked and adapted, not dogmatic.
✓ Real-world tested. From actual client work, not theoretical exercises.

You're not learning n8n syntax by trial and error anymore. You're learning it by reading working code. You're shipping faster because 80% of the tedium is already handled.

The Math

If you save 2 hours per workflow (conservative estimate), and you ship 10 workflows a year, that's 20 hours recovered. At a typical developer rate, that's $3,000–5,000 in reclaimed time annually.

The templates cost $79.

I'm not going to pretend this is purely utilitarian—the real win is in how it feels. You're not wrestling with boilerplate. You're architecting solutions. You're thinking about the problem, not about node configuration syntax.

Where to Start

You can grab the full 350-template pack at https://blncraft.gumroad.com/l/kgcfeh ($79)—or start with the free samples at blncraft.com to get a feel for what's inside.

The best template is the one you actually use. The second-best template is the one you started from.

Why Your AI Code Generator Keeps Hallucinating (And How to Fix It)

BLNCraft — Sat, 23 May 2026 09:39:20 +0000

In the world of software development, having an AI that generates code often sounds like a dream. Yet, when the dream AI starts hallucinating more than a psychedelic mushroom trip, things get ugly fast. As a developer, you want your AI to help, not hinder, your path to production.

The Trouble with LLM Hallucinations

When working with AI systems like Claude or Cursor, one major issue developers encounter is the puzzling phenomenon of AI 'hallucinations'. This isn’t your AI taking a lay-down for a mid-morning nap; it's when your AI starts generating code that seems credible but is completely bogus. It’s akin to having a developer who’s confident but terribly wrong (we’ve all been there, right?).

The frustration builds when you realize these hallucinations increase debugging time, reduce code reliability, and ultimately delay shipping your software.

Why AI Hallucinations Happen

The core of these problems stems from the AI's attempt to infer and generate outputs without a clear understanding of the context or incorrect rules configurations. Sadly, default configurations sometimes don't cut it. They leave gaps through which hallucinations comfortably sneak in.

Many developers fail to provide their AI with precise guidelines, thinking the AI is smart enough to interpret all contexts—spoiler alert, it's not. A lack of structured rules within your AI framework leads to the AI filling in the blanks with optimistic guesses that can lead to failure.

Let's explore some typical faux pas with the AI code generation and how to dodge them effectively.

Illustrating the AI Misunderstandings

Imagine you are using a language model to generate a REST API endpoint. You want to create a user profile feature using the AI, expecting it to give you a well-formed function:

// Unreliable AI Output
app.get('/user/:id', (req, res) => {
  const userId = req.params.id;
  let profile = getUserProfile(userId); // AI hallucinated function
  res.json(profile);
});

The AI might create 'getUserProfile', which doesn't exist or call non-existent data fetching logic. The hallucinated function above gets thrown in the mix—sounds credible but is impractical without prior setup.

To prevent such blunders, you might want to define strict rules for your AI about expected functions and data flows.

In another scenario, manipulating an array of numbers is required to calculate their average. Your expectation is straightforward but the AI, alas, might see it differently:

// AI hallucination
function calculateAverage(numbers) {
  return numbers.reduce((a, b) => a + b) / numbers.count(); // What is numbers.count()?
}

The code appears fine at a shallow glance, but that mysterious 'numbers.count()' isn't part of any recognizable API. This mistake is symptomatic of missing configuration rules guiding the AI’s thought process.

The Solution: Configuring AI with Production-Ready Rules

Deploying AI in production requires more than just throwing data at it and hoping for the best. This is where the CLAUDE.md + Cursor Rules Production Pack steps in. These are not just another set of rules but a battle-tested configuration pack that mitigates hallucinations significantly, aiding your AI in shipping reliable code with fewer headaches.

By incorporating precise and structured rules into your AI’s configuration, you guide it to follow established patterns, reducing the risk of fabricating logic and functions:

// Reliable AI Code Generation Example
const fetchUserProfile = (userId) => {
  // Actual data fetching logic
};

app.get('/user/:id', (req, res) => {
  const userId = req.params.id;
  const profile = fetchUserProfile(userId);
  res.json(profile);
});

This approach puts your AI on the right track, providing it the necessary context and APIs to generate solutions beyond the dreams of imaginary functions.

Wrap-up: Why Proper AI Configuration Changes the Game

Investing time in proper rule configuration could be the difference between agile deployments and a quagmire of debug sessions. CLAUDE.md + Cursor Rules Production Pack gives you a leg-up on configuring AI, allowing you to harness the power of AI confidently while keeping reigns on the spontaneous bursts of wrong code.

Grab the full pack at BLN Craft on Gumroad ($49) — or start with the free sample at BLN Craft.

A small investment now can save countless hours in the future.

Why Every Developer's Honest: The Lies AI Won't Catch

BLNCraft — Fri, 22 May 2026 07:05:34 +0000

Secrets We Hide: An Open Confession

Developers, it’s time we admit it: we’ve all got our secret coding fibs. While AI might impress us with code-suggesting wizardry, it still won't put our little white lies on blast.

The Nature of Our Little Secrets

This isn't about the big stuff. We're talking about those minor missteps we sweep under the keyboard: like claiming to understand Regex while heartily consulting Stack Overflow or setting up that ‘temporary’ fix a little too permanently. Why does this matter? Because it's part of our nature and shapes our work in significant ways.

Imagine you're maintaining a legacy codebase. Rewriting it line by line, you tell yourself, "I won’t get tangled in this web again." Yet, two weeks later, there you are, embracing that very web while whispering, "This is temporary, honest." AI might help refactor code or offer suggestions but achieving genuine honesty in coding? That's still a human endeavor.

When Code Reviews Aren't the Solution

If you've ever participated in a code review, you know they’re designed to ferret out issues, not secrets. For instance, a condition might pass a review despite your best guesswork in configuring those timeout settings:

function fetchData(url, retries = 5) { 
  try { 
    return fetch(url); 
  } catch (error) { 
    if (retries > 0) { 
      console.log('Retrying...', retries); 
      return fetchData(url, retries - 1); 
    } else { 
      console.error('Fetch failed:', error); 
    } 
  } 
}

That retry logic is all well and good, but you're secretly hoping no one realizes you picked 5 as the number of retries because it seemed...lucky?

Learning from Our Fibbing

Here's a real doozy: how many developers can honestly say the comments in their code always match the code’s behavior?

def calculate_area(length, width): 
    # Returns area of a square (wait, this comment is a lie!) 
    return length * width

These fibs may seem benign, but there's something deeper at play here: our striving for perfection in an imperfect world. AI can propose better calculations, but it won’t make you label functions more transparently.

Turning Secrets into Success: Practical Takeaways

Embrace Transparency: Don’t embellish. Code comments should accurately reflect what's happening. Utilize thorough documentation to clear up ambiguity.
Assign AI its Limits: Use AI for standard tasks like error detection but take ownership of decisions and changes.
Call Out Myths: During code reviews, don't shy away from discussing those ‘temporary’ fixes.
Self-Review: Regularly assess your motivations. Are you privileging expediency over quality? Who will suffer from your code fib when AI reviews come up short?

Closing Thoughts

The truth is, while AI can facilitate faster, more efficient workflows, it can’t quite diagnose our uniquely human fallacies or fibs. We manufacture those as quickly as we write our bug reports.

For more about innovative developer tools that help you move faster (but only you can handle honesty), check out BLN Craft. Because we’re all about enhancing human capability, not replacing it.

Why Undefined Behavior in C is Every Developer's Worst Nightmare

BLNCraft — Wed, 20 May 2026 08:37:04 +0000

When it comes to C programming, undefined behavior is like finding out your code has been renting a horror movie without your permission. It's unsettling and likely to come back to haunt you.

The Context: Welcome to Horrorland

In the vast spooky landscape of C, undefined behavior (UB) lurks in the shadows, ready to pounce when you least expect it. It's the ghoul that hides in your closet, the monster under your bed, and if you're not careful, your code's potential doom. You might ask, Why does undefined behavior matter? Because it's unpredictable, that's why. It treats the compiler like an improvisational actor who's just gone entirely off-script — who can say what they'll do next?

The International Organization for Standardization (ISO) describes undefined behavior as an ominous absence of restrictions for the code execution. Imagine being perfectly sure that the lights in your dev bunker will turn on, only for them to flicker and throw you into darkness. That's your clue that something UB-like is happening.

Code Examples: Practical Monsters

Let's take a gander at some real code examples, shall we?

Example 1: The Signed Integer Conundrum

#include <stdio.h>

int main() {
    int a = 2147483647;  // Maximum positive value for a 32-bit signed binary integer
    int b = a + 1;  // Say hello to overflow without safety nets!
    printf("Oh no, what happened to 'b'? It's %d!\n", b);
    return 0;
}

In theory, one might expect b to ideally increment to 2147483648, but surprise: C doesn't care. When signed integer overflow happens — consult your fortune teller, because the result is anyone’s guess.

Example 2: Dereferencing Wild Pointers

#include <stdio.h>

int main() {
    int *uninitialized_pointer; // This one's got no name tag, just lurking around
    *uninitialized_pointer = 42; // Accessing verboten memory territory
    printf("This might not print because UB has struck!");
    return 0;
}

In this snippet, we're playing Russian roulette with memory access. Dereferencing pointers without initialization is a standard UB horror route that can send your program spiraling into oblivion.

Practical Takeaways: Keeping the Boogeyman at Bay

How do you protect your code from the dreaded UB? Here's your survival guide:

Initialize Your Variables: Always give them a proper home before inviting them to your party.
Use Compiler Warnings: Compilers like GCC exist to be your best friends. Let them tell you when you're flirting with danger.
Get Comfortable with Static Analysis Tools: Tools like Clang and Valgrind can be tremendously helpful. Think of them as the Ghostbusters for your spooky code.
Avoid Undefined Constructs: Stay away from controversial areas like signed overflows. It’s not worth the headache or ghost sightings.

Closing Thoughts

Undefined behavior is mysterious, treacherous, and exactly why you need to arm yourself appropriately. Banish those developer nightmares by understanding the true nature of the UB beasts.

Ready to exorcise the demons from your code? Head over to BLN Craft, where we ship dev tools for developers who want to move faster and code less hauntingly.

How We Built 162 Production Rules Files for Claude Code and Cursor (And Why You Should Too)

BLNCraft — Tue, 19 May 2026 13:16:40 +0000

Cursor 3.3 just shipped parallel agents and worktrees. If you're using AI coding assistants in production, the quality of your rules files is now a multiplier — not just for one agent, but for every parallel agent running in your workspace.

We've been using Claude Code and Cursor daily across a range of projects. Over the past year, we accumulated a library of rules files for 54 dev stacks. We just packaged and released them.

What are CLAUDE.md and .cursorrules files?

CLAUDE.md is the project-level instruction file for Claude Code (Anthropic's CLI coding agent). It's loaded automatically when Claude Code starts a session in your project. You use it to define conventions, patterns, testing requirements, and constraints.

.cursorrules is the equivalent for Cursor IDE. It's loaded by Cursor's AI features (Composer, Chat, Tab) to guide code generation.

Both serve the same purpose: telling the AI how your project works so it generates code that fits your codebase instead of guessing.

Why generic rules don't work

Most rules files you find online are generic:

- Write clean, maintainable code
- Follow best practices
- Add comments where necessary

This is the equivalent of telling a new hire "write good code." It doesn't work because:

Every stack has specific conventions — React hooks have rules, FastAPI has dependency injection patterns, Rust has error handling idioms
Anti-patterns are stack-specific — the things an AI gets wrong in Go are different from what it gets wrong in TypeScript
Your team's conventions matter — snake_case vs camelCase, barrel exports vs direct imports, test file locations

What's in our pack

We built rules files for 54 stacks:

Category	Stacks
Frontend	React, Next.js, Vue, Svelte, Angular, Astro, Remix, Solid, Qwik
Backend	FastAPI, Django, Flask, Express, NestJS, Hono, Rails, Spring Boot, Laravel
Systems	Rust, Go, C++, Zig
Mobile	React Native, Swift/iOS, Kotlin/Android, Flutter
Infra	Docker, Kubernetes, Terraform, Pulumi
Data	PostgreSQL, MongoDB, Redis, Prisma, Drizzle
Languages	TypeScript, Python, Rust, Go, Java, C#, Ruby, PHP, Elixir

Each stack gets three files:

CLAUDE.md — full rules for Claude Code (typically 100-200 lines of specific conventions)
.cursorrules — condensed version for Cursor IDE (focused on code generation patterns)
README.md — explains what each rule enforces and why

Example: FastAPI CLAUDE.md excerpt

## API Patterns
- Use Pydantic v2 model_validator instead of root_validator
- Return Pydantic models directly from endpoints, never dict()
- Use Annotated[Depends(...)] for dependency injection
- Async handlers only — no sync def endpoints
- HTTPException for client errors, let unexpected errors propagate

## Testing
- Use httpx.AsyncClient, not TestClient
- Fixtures: db_session, async_client, authenticated_client
- Test file mirrors source: tests/api/test_users.py → src/api/users.py

Compare that to "follow FastAPI best practices." One tells the AI exactly what to do. The other tells it nothing.

How to use them

Download the pack
Find your stack folder
Copy CLAUDE.md to your project root (for Claude Code)
Copy .cursorrules to your project root (for Cursor)
Customize for your team's specific conventions

That's it. No setup, no dependencies. Drop in and go.

The Cursor 3.3 multiplier

With Cursor 3.3's parallel agents, good rules files compound. Each agent that spins up in a worktree loads your .cursorrules. If those rules are specific and accurate, every agent produces code that fits your codebase. If they're generic, you're reviewing and fixing output from multiple agents simultaneously.

162 rules files covering 54 stacks. €29 one-time.

Get the pack on Gumroad →