
React is continually improving and evolving. React Hooks are a leap forward in how we develop components and manage state in our React applications. Now you can use state and other React features without having to write a class!

Many React developers have switched from classes to React Hooks and are realizing the benefits of understanding their apps better because:

- Related logic is now located together
- Less code is needed compared to the equivalent class
- Function components better align with React’s mental model
- Hooks are just awesome! 🎉

Do you have a codebase filled with class components? You could leave it that way, but it will become increasingly more “legacy” as time continues to pass by. **Why not change now?**

Is your team still not developing with React hooks? The longer you stick with the “old way,” the harder it will be to change when you need to. **Why not change now?**

Hi, I’m Ben Ilegbodu 👋🏾. In this minishop, not only will you learn the ins and outs of React Hooks, but also how to switch to React Hooks from class lifecycle methods, bringing your codebase and your team into the modern React era.

## Get ready to

- Switch from `setState` to the `useState` hook
- Make API calls with the `useEffect` hook instead of the `componentDidMount`, `componentDidUpdate` & `componentWillUnmount` lifecycle class methods
- Create custom hooks to reuse and compose logic
- Use function closures instead of `this` & `.bind` for callbacks and event handlers
- ...and many other features to help you write modern React code

## You’ll need to have

- Prior experience building React applications, specifically using classes
- Experience with modern JavaScript syntax and asynchronous patterns like `Promise` & `async`/`await`

## This minishop may not be for you if you

- Are still new to React (consider the [Zero to React with Hooks](/minishops/zero-to-react-with-hooks/) minishop instead)
- Already have dabbled with React Hooks (consider the [Sharing React Component Logic](/minishops/sharing-react-component-logic/) minishop instead)

## Code of Conduct

By participating in this minishop, you are agreeing to the [Minishop Code of Conduct](/minishops/conduct/).

## What are “minishops”?

Minishops by Ben Ilegbodu are fully-remote workshops that last about 3 hours. They're highly-focused, covering only the concepts you want to learn so that you can level up your skills and get on with the rest of your day. By keeping it short, you’re able to absorb and retain the information before fatigue sets in and other distractions get in your way.

To learn more about minishops, read the [Introducing Minishops](/blog/introducing-minishops/) blog post.

## Questions

If you have questions about the minishop, feel free to email us at [team@benmvp.com](mailto:team@benmvp.com).


Learn how to migrate to React Hooks from classes for a better way to develop components and manage state in React applications

Migrating to React Hooks


React's component-driven design simplifies reusing UI because blocks of markup can be encapsulated into custom components. Likewise, sharing traditional data utilities is straightforward because React is “Just JavaScript”™. But what about when we want to **share stateful logic and behavior** between components while letting them control some or all of the UI?

React has had several approaches over its lifetime to solve this problem:

- Mixins (legacy)
- `as` props
- Higher-order components (HOCs)
- Compound components
- Render props
- Custom hooks

Each pattern has its pros and cons. And even with hooks, there are still **ideal use cases for all of the patterns**.

Hi, I’m Ben Ilegbodu 👋🏾. In this minishop, not only will we learn how to write these patterns for sharing stateful logic, but we will also learn the best situations to apply these patterns in your codebase. You will be able to **replace your unnecessarily complex components** filled with dozens of configuration props and code branches with **powerful components with flexible APIs**.

## Get ready to

- Support **`as` props** for minimal UI flexibility
- Add **render props** to invert UI rendering control
- Create **compound components** to provide layout control
- Leverage **custom hooks** when no shared UI is needed
- ...and many more techniques for creating reusable components

## You’ll need to have

- Experience building React applications with `useState` & `useEffect` hooks
- Experience creating custom hooks
- Experience with advanced hooks like `useContext` & `useCallback` will also be helpful

## This minishop may not be for you if you

- Are still new to React (try the [Zero to React with Hooks](/minishops/zero-to-react-with-hooks/) minishop instead)
- Have React experience, but don’t yet have experience using hooks (consider the [Migrating to React Hooks](/minishops/migrating-to-react-hooks/) minishop instead)

## Code of Conduct

By participating in this minishop, you are agreeing to the [Minishop Code of Conduct](/minishops/conduct/).

## What are “minishops”?

Minishops by Ben Ilegbodu are fully-remote workshops that last about 3 hours. They're highly-focused, covering only the concepts you want to learn so that you can level up your skills and get on with the rest of your day. By keeping it short, you’re able to absorb and retain the information before fatigue sets in and other distractions get in your way.

To learn more about minishops, read the [Introducing Minishops](/blog/introducing-minishops/) blog post.

## Questions

If you have questions about the minishop, feel free to email us at [team@benmvp.com](mailto:team@benmvp.com).


Learn how to write reusable React components using patterns for sharing stateful logic and behavior

Sharing React Component Logic


TypeScript is a JavaScript superset that compiles down to vanilla JavaScript and has become increasingly popular. TypeScript offers strong typing and compile-time verification to our React applications. As a result, using TypeScript helps eliminate entire classes of bugs that commonly affect our apps.

When adopting new tech for development, we should always focus on the impact to the user. The user doesn’t care what tech we use unless it makes their user experience better (less friction, more delightful, etc.). Users definitely do not want a buggy experience, and of course, neither do we.

Hi, I’m Ben Ilegbodu 👋🏾. In this minishop, you will learn how to use TypeScript to build React applications. But instead of simply covering types and syntax, the minishop will have a focus on how using TypeScript can prevent common bugs that infect our applications.

Maybe you’re concerned about the code health of your app and what to learn how **TypeScript can provide confidence** in making big changes. Or maybe your team is building a new React application and you want to see if **TypeScript makes sense** before kicking off the project. Or maybe you’re just questioning whether **TypeScript is worth the learning curve** when you’re already productive building React applications.

Whether these are your reasons or you have others, you’ll no doubt leave convinced that TypeScript will help you in your current or future React projects.

## Get ready to

- Learn basic TypeScript types and syntax
- Define fully type-safe component props
- Type common React hooks
- Handle forms and other events
- ...and many more features that help you write quality code

## You’ll need to have

- No prior experience with TypeScript is necessary! 🙌🏾
- Experience building React applications using hooks (consider taking the [Migrating to React Hooks](/minishops/migrating-to-react-hooks/) or [Zero to React with Hooks](/minishops/zero-to-react-with-hooks/) minishops first)

## This minishop may not be for you if you

- Already have some experience using TypeScript in React (try the [Sharing React Component Logic](/minishops/sharing-react-component-logic/) minishop)
- Have React experience, but don’t yet have experience using hooks (again consider the [Migrating to React Hooks](/minishops/migrating-to-react-hooks/) minishop instead)

## Code of Conduct

By participating in this minishop, you are agreeing to the [Minishop Code of Conduct](/minishops/conduct/).

## What are “minishops”?

Minishops by Ben Ilegbodu are fully-remote workshops that last about 3 hours. They're highly-focused, covering only the concepts you want to learn so that you can level up your skills and get on with the rest of your day. By keeping it short, you’re able to absorb and retain the information before fatigue sets in and other distractions get in your way.

To learn more about minishops, read the [Introducing Minishops](/blog/introducing-minishops/) blog post.

## Questions

If you have questions about the minishop, feel free to email us at [team@benmvp.com](mailto:team@benmvp.com).


Learn how to use strong types with TypeScript in React applications to prevent common bugs that infect our apps

TypeScript for React Developers


React is a JavaScript UI library that makes creating reusable components easy and efficient. It’s critical to understand the fundamentals of creating custom configurable components, fetching and maintaining state, and rendering UI based upon that state and component configurations.

Maybe your team is **taking on a new React project** and you want to get a handle on React development before your kick off the project. Or maybe you are just starting off your development career and want to learn React in order to **increase your job opportunities**. Or maybe you’ve been in the industry for a while, heard so much about React, and finally want to **see what React is all about**.

Whatever the case may be, you’ll leave the minishop with all the fundamentals you need to build your own modern apps with React using hooks.

## Get ready to

- Write configurable, reusable and composable components
- Use JSX syntax
- Work with the “Virtual DOM”
- Handle user interactions and synthetic events
- Maintain application state using hooks
- Make API calls using hooks
- Apply component styling
- ...and many more tidbits and nuances of quality React development

## You’ll need to have

- No prior experience with React is necessary! 🙌🏾
- Experience building web user interfaces with HTML, CSS, and JavaScript DOM APIs
- Experience with modern JavaScript syntax and asynchronous patterns like `Promise` & `async`/`await`

## This minishop may not be for you if you

- Already have experience developing in React with class components (consider the [Migrating to React Hooks](/minishops/migrating-to-react-hooks/) minishop instead)
- Already have dabbled with React Hooks (consider the [Sharing React Component Logic](/minishops/sharing-react-component-logic/) or [TypeScript for React Developers](/minishops/typescript-for-react-developers/) minishops instead)

## Code of Conduct

By participating in this minishop, you are agreeing to the [Minishop Code of Conduct](/minishops/conduct/).

## What are “minishops”?

Minishops by Ben Ilegbodu are fully-remote workshops that last about 3 hours. They're highly-focused, covering only the concepts you want to learn so that you can level up your skills and get on with the rest of your day. By keeping it short, you’re able to absorb and retain the information before fatigue sets in and other distractions get in your way.

To learn more about minishops, read the [Introducing Minishops](/blog/introducing-minishops/) blog post.

## Questions

If you have questions about the minishop, feel free to email us at [team@benmvp.com](mailto:team@benmvp.com).


An introduction to React to learn the critical concepts needed for building modern React applications using hooks

Zero to React with Hooks


You give the Agent a prompt. It writes 200 lines of code. You review it. The architecture is wrong. You explain what you actually meant. It rewrites everything. Still not quite right. It misunderstood your data model. **10 or more iterations later**, you've got working code... and a lingering feeling that you could have just written it yourself faster.

Sound familiar?

Here's the thing: **the problem isn't the Agent. It's the process.** The write-review-write loop is the easiest approach, but it's inefficient and error-prone because the Agent makes incorrect assumptions without sufficient context. Yes, tools like [Cursor's Plan Mode](https://cursor.com/docs/agent/modes) try to help by asking clarifying questions upfront, but they don't go deep enough on shared context and decision-making.

There's a better way. I call it **deliberation-first coding**: structured conversations with AI Agents that front-load shared context so the Agent implements _your_ decisions correctly the first time. The key insight? **The best AI conversations happen before any code is written.**

---

## The Solution: The Deliberate Skill

I've formalized this process into a reusable skill for VS Code Copilot, Cursor, and Claude Code. [**Get the skill here on GitHub Gist.**](https://gist.github.com/benmvp/957f267b3643d629d20c5120ef29a3a6)

Save it to your skills directory (`~/.claude/skills/deliberate/SKILL.md` or equivalent), and invoke it with:

```
/deliberate I want to... [describe your task with background context]
```

The skill handles the rest: the Agent reflects back its understanding, asks clarifying questions with A/B/C options and recommendations, provides critical feedback on your answers, summarizes all decisions, and iterates with follow-up questions until you reach convergence. Then it produces an implementation plan or spec.

**That's all you need to get started!** If you want to understand **why** this works, **how** I developed the process through trial and error, and see it in action with a real production example, read on. 👇

---

## The Payoff

I recently added a [CSS Validator tool](https://codemata.benmvp.com/validators/css-validator) to [Codemata](https://codemata.benmvp.com), my suite of free developer tools. Instead of jumping straight to implementation, I spent 30 minutes in structured conversation with the Agent first. The result? The Agent wrote the tool correctly on the first pass, needing only 1-2 rounds of minor edge case refinements instead of the usual 3-5 rounds of architectural rewrites.

Here's exactly how that conversation went, and why it works.

---

## Phase 1: Reflect & Clarify

The foundation of deliberation-first coding is **front-loading shared context**. This doesn't always mean a huge initial prompt. If you've captured earlier decisions in specs or existing code, reference those. The key is making sure the Agent understands your codebase patterns, constraints, and goals before writing any code. Then you ask the Agent to reflect back its understanding and pose clarifying questions.

Here's my initial prompt for the CSS Validator:

```
Ok I'm ready to start on Phase 9.5 CSS validator in #phase-9-validators.md.
It should work very similarly to the HTML validator, just w/ a different
validator library. Give me the implementation overview. Then ask a few
clarifying questions. Use a/b style options + your recommendation.
```

That's it! No wall of context. Why? Because I had already written a spec for the validators (also using this deliberation-first process!) that included the architecture patterns, UX requirements, and constraints. The Agent could read that spec file and the existing HTML Validator code to understand the context.

> 💡 **Working from a spec**: This is deliberation-first coding in practice. The upfront thinking was captured in the spec, so the prompt could stay focused on the specific decisions for this tool. The Agent is smart enough to figure out implementation details by reading code. What it needs from YOU is the "why" (goals, constraints) and "how" (UX patterns, architecture decisions). If those are already documented, reference them.

The Agent asked clarifying questions in A/B/C format with recommendations:

```
**Q1: Which CSS validation approach should we use?**
- A) W3C CSS Validation API (external, authoritative, but has rate limits)
- B) CSS parser library like `postcss` or `csstree` (local, fast, but less comprehensive)
- C) Hybrid: simple parse errors locally, optional deep validation via W3C API

→ Recommendation: B, because Codemata tools feel instant and you already have API-based validators. Local validation keeps the experience snappy.

**Q2: What level of validation feedback should users get?**
- A) Binary valid/invalid with error count
- B) Detailed error messages with line numbers and severity levels
- C) Full report with warnings, suggestions, and best practices

→ Recommendation: B, matching the detail level of your other validators without overwhelming users.

**Q3: Should we support CSS preprocessors (SASS, LESS)?**
- A) Plain CSS only (simplest, clear scope)
- B) Auto-detect and validate preprocessors
- C) Let users choose input type

→ Recommendation: A, because preprocessors have their own validation tooling and this keeps scope focused.

**Q4: How should we handle large files?**
- A) No limit (trust browser memory constraints)
- B) Hard limit with error message (e.g., 1MB)
- C) Soft warning but allow validation

→ Recommendation: B, prevents performance issues and aligns with other validators' constraints.
```

This is where the magic happens. **The Agent hasn't written a single line of code yet**, but we're already aligned on architecture, scope, and trade-offs.

> 💡 **The real win**: When you capture architectural decisions in specs (created via deliberation!), future features become much faster to implement. The context compounds. This is the full cycle: deliberate → spec → implement → deliberate next feature. Each conversation builds on the last.

---

## Phase 2: Iterative Refinement (The Secret Sauce)

Now comes the critical part. Most developers would answer the questions and say "okay, build it." Instead, I answer the questions _and then ask for three specific things_:

1. **Critical feedback** on my responses
2. **Decision summary** of what we've agreed to so far
3. **Follow-up questions** to dig deeper

Here's my response to the Agent:

```
My answers:
- Q1: B (postcss library) - Agreed, keeping it local and fast aligns with the Codemata experience
- Q2: B (detailed errors with line numbers) - Yes, matches our other validators
- Q3: A (plain CSS only) - Good call, keeps scope manageable
- Q4: B (hard 1MB limit) - Makes sense for consistency

Additional context: I'm thinking we should also show a character/line count like
our other text tools, and maybe a "pretty print" toggle to help users fix
formatting issues they discover.

Now:
1. Give me critical feedback on my responses and surface any gotchas I should consider
2. Summarize the decisions we've made
3. Ask 2-3 follow-up questions to finalize the design
```

The Agent's response included **critical feedback**, and this is where things get interesting:

```
**Critical Feedback:**

Your answers look solid, but a few gotchas to consider:

- **On postcss validation**: While `postcss` is great for parsing, it's permissive by design (to support future CSS features). You might get false positives where technically-invalid-but-parseable CSS passes. Consider adding `stylelint` or a stricter validator on top, or accept that this trades strictness for speed.
- **On the 1MB limit**: This is reasonable, but CSS files from build tools (especially with sourcemaps inlined) can exceed this. Consider either raising to 2MB or adding a clear error message like "This appears to be a compiled CSS file—try validating your source files instead."
- **On the pretty print feature**: Great idea, but this creates scope creep toward a formatter. If you add it, you're building two tools in one (validator + formatter). Consider whether this belongs in a separate CSS Formatter tool instead, following your existing pattern of one tool = one job.
```

**This is the game-changer.** Even though I picked the Agent's recommended options, it still surfaced risks I hadn't considered. The Agent isn't just agreeing with me. It's actively challenging assumptions and making me think harder about edge cases.

> 💡 **The critical feedback revelation**: I added this after discovering models are inherently sycophantic (they'll agree with whatever you suggest). The game-changer? Even when I pick the Agent's recommended option, the critical feedback surfaces potential gotchas I hadn't considered. It's not about being right or wrong, it's about making **informed decisions**.

The Agent then provided a decision summary:

```
**Decisions So Far:**
1. CSS validation using `postcss` library (local, fast)
2. Detailed error feedback with line numbers and severity
3. Plain CSS only (no preprocessor support)
4. 1MB file size limit (consider 2MB adjustment)
5. Standard ToolPage layout with textarea input
6. Character/line count display (confirmed)
7. Pretty print feature (needs scope decision)
```

And follow-up questions:

```
**Q5: How should we handle the postcss permissiveness issue?**
- A) Accept it—speed over strict validation
- B) Add stylelint for stricter checking
- C) Show two modes: "Quick Check" and "Strict Validation"

→ Recommendation: A, with clear messaging that this validates syntax, not best practices.

**Q6: What should we do with the pretty print feature?**
- A) Include it in this tool
- B) Defer to a separate CSS Formatter tool
- C) Add "Format & Validate" combo button

→ Recommendation: B, maintains single responsibility and matches your tool architecture.
```

I answered these follow-up questions, and the cycle repeated: I got critical feedback, an updated decision summary, and a few final questions.

**By this point, we'd gone through several rounds of Q&A with roughly a dozen questions total**, covering everything from API choices to error handling to user messaging. Each time, I had to type: "Now give me critical feedback on my responses. Then summarize all decisions. Lastly give me follow-up questions."

It was getting tedious.

> 💡 **Evolution of the process**: I didn't always structure it this way. Initially, I only asked for follow-up questions. But the Agent would mostly agree with me. Then I started requesting a decision summary after seeing someone else recommend it. As chats grow long, it reaches the model's context window limits, so Agents start summarizing the chat history and "forgetting" previous details. The summary keeps us aligned. The critical feedback request came last, and that's when the quality shot up. Each addition solved a real problem I'd encountered.

---

## Enter the Skill

The repetitive meta-prompting was a clear signal: **this process worked, but it needed to be DRY'd up.** Modern AI editors like [VS Code Copilot](https://code.visualstudio.com/docs/copilot/copilot-chat), [Cursor](https://cursor.com/), and [Claude Code](https://code.claude.com/) support **skills** (reusable prompt templates that standardize workflows across conversations and even across models).

I formalized the deliberation-first coding process into a skill that:

1. **Normalizes structure** across Claude, GPT, and other models (they used to vary wildly in how they formatted questions and decisions)
2. **Condenses meta-prompting** into a single invocation. No more typing "give me critical feedback, then decisions, then questions" every round
3. **Enforces the pattern** automatically. The Agent knows to provide all three components without being reminded

With the skill active, I just answer the Agent's questions naturally. It automatically provides critical feedback, updates the decision log, and asks follow-ups (every time, consistently).

Here's what the CSS Validator conversation looked like with the skill:

- **Me:** [answers to questions 5 & 6]
- **Agent:** [critical feedback on my answers] → [updated decision summary] → [2 final follow-up questions]
- **Me:** [answers final questions]
- **Agent:** [final critical feedback] → [complete decision log] → "We've reached convergence. Ready for implementation plan?"

No manual prompting. The skill enforces the structure. I focus on thinking through decisions, and the Agent handles the workflow mechanics.

> Want to learn more about skills? Check out [Claude Code's documentation on creating custom skills](https://code.claude.com/docs/en/skills). I've included my full deliberate skill at the end of this post.

---

## Phase 3: Exit Path (Plan & Implement)

Once we reached convergence (no meaningful open questions remaining), I asked for an implementation plan. The Agent produced a detailed breakdown covering core validation, UX enhancements, and verification steps. With this shared understanding, it generated the CSS Validator code.

I reviewed it, made 2 small tweaks for edge cases around sourcemap comments, and shipped it.

**What used to take 5+ rounds of "no, that's not what I meant", architectural rewrites became 1-2 rounds of edge case refinement.** The architecture was mine. The implementation was the Agent's. Both were better for it.

---

## The Meta Moment

Here's where it gets fun: **this entire blog post was created using the [deliberate skill](https://gist.github.com/benmvp/957f267b3643d629d20c5120ef29a3a6).**

Here's the prompt I used:

```
/deliberate

I want to create a new GenAI blog post about my structured "vibe coding" process.
It involves lots of conversations with the Agent before actually writing out the code,
as opposed to the write-review-write loop that I believe is inefficient and error-prone.
Ultimately the blog post is an explanation of how I came to my deliberate skill.
I did this process over and over so many times and that's what skills are for.

Here's my working outline:
[... included my rough outline ...]

Example to use throughout: Adding the CSS Validator tool to my CodeMata app

Follow the tone & voice of the other GenAI-related blog posts
```

The Agent asked clarifying questions about audience, structure, example depth, and how to handle the evolution story. I answered. It gave critical feedback on my responses (challenging my framing, surfacing risks about dismissing non-skill-users, questioning whether two examples would create fatigue). **We went through 4 rounds of Q&A with 12 questions total**, plus my additional notes and thoughts along the way.

We iterated until convergence. Then the Agent produced an implementation plan which it then implemented into what you're reading right now. I'm refining and expanding as I write, but the architecture (the structure, the insights, the flow) came from that deliberate conversation.

**The process works for code, docs, specs, architecture, anything requiring thoughtful planning.** And because it's formalized as a skill, I can use it across all my repos with a single line.

---

## Why Deliberation-First Coding Works

Let me synthesize the key principles that make this approach effective:

**1. Front-loaded shared context removes incorrect assumptions**

The Agent needs to understand your codebase patterns, constraints, and goals. Without this context, it's guessing. With it, it's collaborating. This is similar to what I wrote about in my [GenAI shift-left architecture](../genai-shift-left-software-architecture) post (moving quality upstream by deliberating before generating).

**2. Adversarial partnership (critical feedback) surfaces risks for informed decisions**

Models are sycophantic by default. They'll agree with you even when you're wrong. By explicitly requesting critical feedback, you turn the Agent into a constructive challenger that surfaces gotchas, edge cases, and trade-offs you haven't considered. This isn't about the Agent being "right", it's about making informed decisions.

**3. Decision continuity (summaries) prevents Agent "forgetting" in long chats**

As conversations grow long, context windows get crowded and Agents start losing track of earlier decisions when they summarize the chat history. Regular decision summaries act as a running record, ensuring nothing gets lost or contradicted 10 questions later.

**4. Structural consistency (via skill) normalizes output across models**

Different models format responses differently. Claude might use tables, GPT might use bullets, and the structure can even vary within chat sessions. The skill enforces a consistent format, making the process predictable and reliable regardless of which model you're using.

**The value proposition:** The Agent becomes autonomous in HOW it writes code, while YOU retain control over WHAT gets built and WHY. That's true collaboration, not micromanagement.

**Reality check:** You'll still iterate after the first implementation, but on refinement and polish, not fundamental rewrites. The architecture is yours. The implementation is the Agent's. Both are better for it.

---

## Conclusion

Remember those 5+ frustrating iterations rewriting AI-generated code because it didn't understand what you meant? They're gone. Replaced by one focused conversation that gets it right the first time.

This is the natural evolution of the ideas I've been exploring in my [Mythical 10x Developer](../mythical-10x-developer) and [shift-left architecture](../genai-shift-left-software-architecture) posts. If AI commoditizes code implementation, **deliberation-first coding** commoditizes the path to correct implementation. You're not just moving faster, you're moving smarter, with fewer mistakes and less frustration.

**If you're using AI Agents and still fighting the write-review-write loop, try deliberating first.** Start with the manual process:

1. Provide rich context upfront
2. Ask for reflection + clarifying questions with options
3. Answer questions, then request critical feedback + decision summary + follow-ups
4. Iterate until convergence
5. Get an implementation plan
6. Review and refine the generated code

When it clicks (and it will), [grab the skill](https://gist.github.com/benmvp/957f267b3643d629d20c5120ef29a3a6) and make it automatic. Your future self will thank you.

Keep learning my friends. 🤓


How structured deliberation with AI Agents eliminates rewrites by front-loading decisions and shared context

From Vibe Coding to Deliberation-First Coding with AI


The AI hype cycle has convinced us that every app needs a conversational interface, a RAG pipeline, or an autonomous agent. Meanwhile, most of us are just trying to ship features, fix bugs, and (just) maybe reduce the amount of repetitive nonsense we do every day. The reality? **The highest ROI AI integration isn't a chatbot. It's the stuff users don't even notice.**

I call it "Sneaky AI": using simple LLM API calls to eliminate toil, generate intelligent defaults, and make your existing features feel magical—without rewriting your architecture or hiring a PhD. If you're interested, I gave a talk on it at [All Things Open AI 2025](https://2025.allthingsai.org/) entitled ["Sneaky Ways to Integrate GenAI"](https://www.benmvp.com/ato-sneaky-ai).

---

## The "Sneaky" Philosophy

Sneaky AI isn't about building AI products. It's about making your _existing_ products smarter with minimal effort.

In the talk I mention three principles that define the approach:

1. **Minimal Overhead** - A single API call to [OpenAI](https://platform.openai.com/docs/overview), [Anthropic](https://platform.claude.com/docs/en/home), or [Gemini](https://ai.google.dev/gemini-api/docs). No vector databases, no fine-tuning, no infrastructure setup.
2. **Enhanced Workflows** - Find the friction points where users have to think too hard or type too much. That's where AI shines.
3. **Invisible UX** - The AI is a "ghost" in the machine. Users get the answer before they realize they had a question.

This isn't about impressive demos. It's about compounding small wins that make your app feel thoughtful and polished.

---

## The Four "Sneaky" Strategies

Also in my talk, I broke down the practical applications into four categories:

**1. Content & Pre-generated** - Use AI during build time or in scripts to create static content. Think: SEO meta descriptions, OpenGraph images, or auto-generated documentation. (more on this in a bit)

**2. AI-Powered Content Tools** - Help users write or edit within your app. Examples: "Summarize this ticket," "Suggest a commit message," or "Generate test descriptions."

**3. Insights & Recommendations** - Analyze existing data to suggest the "Next Best Action." This could be project suggestions based on past behavior, or highlighting anomalies in analytics.

**4. Real-time Decisions** - Use an LLM as a sophisticated `if/else` block for dynamic UI logic. Classify user intent, route support requests, or provide contextual help without hardcoded rules.

The beauty? You can implement any of these with a prompt and an afternoon.

---

## Case Study: How I Built Codemata "Sneakily"

I recently launched [**Codemata**](https://codemata.benmvp.com), a suite of free developer tools (formatters, minifiers, etc.). I wanted each tool to have:

- Unique SEO-optimized meta descriptions
- Educational "How it works" sections
- Use case examples
- Best practice guides

As of writing, there are 14 tools so writing this copy manually for 14+ tools? That's _hours_ of tedious copywriting. And I'm a developer, not a marketer. It just wouldn't get done. 😅

**The Sneaky Solution:**

I built a script that pipes each tool's functionality description into [Gemini](https://ai.google.dev/gemini-api/docs) (shout-out to Gemini 3!), which generates all the metadata and content during the build process. The result? [Professional-grade SEO content](https://codemata.benmvp.com/formatters/typescript-formatter) that will rank for technical keywords, without me writing a single meta tag by hand.

> **Why build-time AI?** Cost, speed, and SEO. Pre-rendering content means search engines see complete HTML immediately, users get instant loads, and I'm not burning API credits on every page view. My bill remains constant even if traffic grows exponentially. It's sneaky _and_ smart.

The entire [Codemata](https://codemata.benmvp.com) site is [open source](http://github.com/benmvp/tools-app), so you can see exactly how this works. The AI content generation lives in the build pipeline, not the runtime. Users get a fast, polished tool site. I get to focus on building features instead of marketing copy.

---

## Why "Sneaky" Beats "Flashy"

The industry is obsessed with flashy AI demos, autonomous agents, multi-step reasoning, real-time voice interfaces. Those are impressive (and [get you funding](https://www.ycombinator.com/companies/industry/ai)), but they're also:

- Expensive to build and maintain
- Fragile (hallucinations, latency, API costs)
- Overkill for most problems

**Sneaky AI is the opposite.** It's:

- Fast to implement (hours, not weeks)
- Low-risk (isolated failures don't break core features)
- High-impact (users feel the quality difference immediately)

When someone uses [Codemata's JSON minifier](https://codemata.benmvp.com/minifiers/json-minifier) and sees a well-written "Did you know?" tip, they don't think, "Wow, AI wrote this." They think, "This tool is professional." **That's sneaky AI working.** 😉

---

## Getting Started: Find Your Toil

Here's my challenge: **Don't look for an "AI project." Look for a boring task.**

Ask yourself:

- What do I copy-paste repeatedly?
- What takes me 15 minutes that _should_ take 15 seconds?
- What content do I avoid creating because it's tedious?

That's your sneaky AI opportunity.

For this project, it was writing SEO copy. For you, it might be generating test fixtures, summarizing PRs, or auto-tagging support tickets. The LLM doesn't need to be perfect, it just needs to be better than doing it manually.

---

## Resources

If you want to dig deeper:

- 🎥 Watch the [full "Sneaky AI" All Things Open AI talk](https://www.youtube.com/watch?v=KkYIY1DT3wo)
- 📊 Browse the [slide deck](https://www.benmvp.com/ato-sneaky-ai)
- 💻 Check out the [code examples on GitHub](https://github.com/benmvp/sneaky-ai-demo)
- 🛠️ See the results live at [Codemata](https://codemata.benmvp.com)

And yes, I'm fully aware this post is also a "sneaky" way to get more links to Codemata for SEO. Meta-sneaky? 😅

Keep learning my friends. 🤓


How to integrate AI into existing apps without becoming an AI expert or building a chatbot

Being Sneaky with GenAI


Nearly 100% of my code is AI-assisted, but not via giant one-shot prompts. For me, useful output emerges from an iterative loop: **clarify intent → shape a plan → refine a spec → generate → review**. In my previous [Mythical 10x Developer](../mythical-10x-developer) post I called out the trap of equating GenAI value with raw code volume. Faster bad code is still bad code. Real leverage comes from shifting effort _earlier_: framing the problem and planning well. If we can express a solution crisply (objectives, constraints, interfaces, edge cases, etc.), implementation becomes an execution detail. Languages start to matter less when we feed specs to an agent and pick a runtime.

## Architecture-driven development (meta-spec ideation)

Lately, I've been practicing **architecture-driven development**: AI-assisted reasoning _before_ the spec exists. When I'm unsure how a project should even be built, I ask the Agent to assess the current structure, surface option sets, compare trade-offs, and converge on a plan that _then_ becomes the spec. **If spec-driven development commoditizes implementation, architecture-driven development commoditizes the path to the spec.** Cursor's [Plan Mode](https://cursor.com/docs/agent/planning) accelerates turning fuzzy intent into execution structure. Historically you'd grab a colleague for that early architecture jam; now the Agent bootstraps a first draft worth reviewing.

I went through this with a recent refactor. If I had to manually map dependencies just to decide _whether_ it was worth doing felt too expensive; I would have abandoned it. Instead I had the Agent analyze the existing architecture (pain points + benefits) and propose option sets (“modular split,” “layered façade,” “event-driven extraction,” etc.). Then I selected an option, and we co-shaped a phased plan (objectives, constraints). Finally the Agent implemented the plan and I iterated on edge cases. **Idea → plan → executed refactor in ~2 hours** instead of at least a half day of exploratory mapping with a colleague. This compressed loop is becoming typical. AI pairing moves architectural certainty earlier, not just code faster.

## Shift-left implications

This mirrors “shift-left” testing, but for architecture: exploring structure near ideation so **spec** becomes a downstream commodity, just like code. While this acceleration trims that "let's whiteboard this" time, it also risks losing the potential serendipitous knowledge transfer between colleagues. Even with using GenAI for architectural planning, humans still supply vision, domain nuance, judgment, and guardrails. GenAI abstracts the _how_ of implementation, and now it's abstracting the _how_ of architectural exploration, freeing us to focus on the _why_. Of course we still pull in humans for high-stakes domains: regulatory or compliance-heavy surfaces, cross-team boundary / contract shifts, ambiguous product intent, or when interacting constraints defy simple pattern matching.

Some risks that rise as we move GenAI earlier in the process: **hallucinated architectures, generic templates, missed domain constraints.** The need for our accountability _intensifies_ to:

1. Craft high-quality intent & evaluation criteria
2. Select + refine the best option (never blindly accept the first)
3. Review generated code for correctness, performance, fit-for-purpose

Regardless of who typed the line, integrity is ours.

## Horizon: true meta architecture?

If AI can co-create the _plan_ before the spec, what happens when it reliably co-generates _vision_ and strategic context? That future layer, true **meta architecture**, would encode principles, constraints, and evolutionary goals as durable intent artifacts for agents to adapt whole systems. We're not there yet, but the ground is shifting under our feet. The role of a developer is moving left, away from pure implementation and toward strategic guidance.

Keep learning my friends. 🤓


Using GenAI to co-architect pre-specification decisions now that code has been commoditized

How GenAI is shifting architecture left


For decades, our industry has been obsessed with the "10x developer" -- that mythical engineer who's supposedly 10 times more productive than the rest of us. It's always been a bit of a loaded concept if you ask me, often rewarding behaviors that aren't necessarily great for teams or codebases. But with the arrival of powerful GenAI coding assistants, the "10x" conversation is back in full force.

Here's the thing though: **we're thinking about it all wrong**.

When I first started hearing the AI hype, it seemed like everyone was defining a 10x developer as someone who can crank out 10 times more code. As someone who now uses GenAI for 90%+ of my output (yep, including writing this blog post!), I can tell you that's a complete trap. If we're optimizing for lines of code, we're basically optimizing for bloat, complexity, and a whole lot of future technical debt. Not exactly what I'd call "winning." 😅

Don't get me wrong -- the GenAI revolution absolutely does unlock 10x potential. But it's not just about volume. It's about being 10x more **thoughtful**, 10x more **robust**, and 10x more **innovative** in how we approach our work.

I've been thinking about this a lot lately, and I see this new kind of productivity happening across four key areas.

---

## Pillar 1: Velocity & Execution

This is the most obvious gain, but it's deeper than just raw speed. It's about accelerating the entire core development loop and removing friction.

- **Accelerated Code Generation**: This is the baseline, table-stakes benefit. The AI can generate boilerplate, functions, and components faster than I can type. We've all seen this.
- **Developer Parallelization**: This is where it gets interesting. I can assign a complex, time-consuming task to the AI agent—like refactoring a large file or generating a suite of data models—and while it works, I can switch my focus to a high-value human task like a thoughtful code review or planning the next feature in Slack.
- **The Autonomous Debug Loop**: This truly feels like magic. Instead of me writing code, hitting an error, and starting the debug cycle, I can give the agent a directive and let _it_ handle the loop. It writes the code, runs the linters and tests, reads the error output, formulates a fix, and tries again. It repeats this process until the tests pass, allowing me to step away and come back to working, validated code.
  > For example, I'll give a conceptual prompt like: _"Implement the `useUserProfile` hook based on this spec, create a comprehensive Jest test file for it, and do not stop until all tests pass."_
- **Bridging Skill & Language Gaps**: I've written more Bash scripts in the last six months than in my entire 20-year career. I can _read_ Bash and understand what it's doing, but I could never write it fluently with all its esoteric flags. Now, I don't have to. The AI can write code I couldn't, in languages I don't know well, and I can act as the expert reviewer.

**How do you measure it?** You could look at quantitative metrics like **cycle time**, but that's easily gamed. Unfortunately, the more meaningful measure is subjective: a massive reduction in the **time spent on toil and boilerplate**.

---

## Pillar 2: Quality & Robustness

Faster isn't always better if the result is potentially buggy and unmaintainable. The real unlock is using AI to build higher-quality software from the start.

- **Enhanced Test Coverage**: Let's be honest: writing tests can be tedious. AI completely lowers the activation energy required. It's now trivial to generate comprehensive tests for every piece of code, which means I'm adding tests to edge cases I likely would have skipped before.
- **Intelligent Refactoring**: This is worlds beyond "find and replace." The AI understands the abstract syntax tree. It knows the difference between a variable name in a comment and one in the code, allowing for massive, intelligent refactors that would have been manual, risky, and time-consuming.
- **Automated Documentation**: Good documentation is critical for team velocity but is often the first thing dropped under pressure. Now, I can generate high-quality, explanatory docs directly from the code. It turns a chore into a nearly "free" byproduct of development.

**How do you measure it?** You could track **test coverage percentage** or **production bug counts**. But the real metric is the team's **confidence in shipping code** and the quality of the shared knowledge base. Again, this is often more of a feeling than a hard number.

---

## Pillar 3: Knowledge & Comprehension

Modern codebases are massive and complex. GenAI acts as a force multiplier for understanding, effectively democratizing knowledge across the team.

- **On-Demand Subject Matter Expert**: I no longer have to interrupt a coworker to ask, "Hey, how does this legacy module work?" I can just ask the AI, which has context of the entire codebase. It's like having an infinitely patient expert available 24/7.
- **Onboarding Accelerator**: When I need to work in a part of our large codebase I'm unfamiliar with, my process has changed. I point the AI to the directory, give it our rudimentary docs, and ask it to explain how everything works. Then, in a "pay it forward" moment, I use that more complete understanding to have the AI flesh out and commit improved documentation for the next developer.

**How do you measure it?** You might try to measure something like **time-to-first-meaningful-commit** for new hires, but a better indicator is probably a reduction in **"how does this work?" questions** in team channels and a developer's self-reported confidence when navigating unfamiliar territory. That's a tough one to measure.

---

## Pillar 4: Strategy & Innovation

This is the highest-leverage pillar. By commoditizing the act of writing code, AI frees up our cognitive bandwidth to focus on what actually matters: solving the right problems in the right way.

- **Ideation Partner**: The AI is an incredible thinking partner. Before writing a line of code for a complex feature, I'll provide a lengthy backstory and a goal. Then I'll prompt it to act as a collaborator.
  > For example: _"Here's the problem I'm trying to solve... Before you generate anything, **ask me 3 clarifying questions to resolve potential ambiguities**. Then, propose two distinct technical approaches (A and B), and tell me which one you recommend and why."_ This process sharpens my own thinking and ensures the AI's first attempt is much closer to the mark.
- **AI-Assisted Design**: My workflow now heavily favors detailed planning. I spend more time in markdown, writing a tech spec and clarifying the architecture. The code becomes an implementation detail that the AI can handle. My focus has shifted from _how to implement_ to _what we should build_.
- **Low-Cost Experimentation**: Exploring a new idea or going down a "rabbit hole" used to be expensive in terms of time. Now, it's incredibly cheap. I can "vibe-code" a quick prototype to see if an idea has merit, getting feedback in minutes or hours instead of days.

**How do you measure it?** This is the hardest to quantify. It's less about engineering metrics and more about **business impact** and the team's perceived **pace of innovation**. This may be where I'm most productive, even if it's the hardest to measure.

---

## The Great Skill Shift: From Code Implementer to AI Partner

Historically, becoming more productive meant mastering your tools —- learning all the details of the TypeScript type system, becoming a debugger wizard, or deeply understanding a language's internals. That's changing.

The new path to maximizing productivity is about becoming an effective **AI partner**. The developer's primary role is shifting from implementation to direction. The new core skills are:

1.  **Expert Prompting**: Knowing how to ask the right questions to get the desired output.
2.  **Precise Specification**: The ability to clearly and unambiguously define the problem in a spec _before_ code is written.
3.  **Rigorous Verification**: Using your expert judgment to critically review, validate, and refine the AI's output.

The one constant is **System Architecture**. This remains the pinnacle of human contribution—designing how all the pieces fit together.

---

## Conclusion: Productivity is a Feeling, Not a Number

The "10x developer" is here, but it's not a code monkey on steroids. It's a high-leverage architect, a thoughtful problem-solver, and a skilled AI collaborator who delivers 10x the _value_, not necessarily 10x the code.

While we can try to measure these new forms of productivity, the ultimate metric is likely highly subjective. Perhaps the most important gain is **developer happiness from the reduction of toil**. We get to spend more time on the creative, strategic parts of the job we love and less time on the frustrating, tedious parts we don't. The goal isn't just to be more productive, but to make the work of software development more impactful and, ultimately, more joyful. Good luck measuring that! 😅

Keep learning my friends. 🤓


Why the "10x developer" is real, but not in the way you think.

Have We Finally Reached the Mythical "10x Developer"?


There are times in a Jest test when we have a module where the majority of the functions need to be mocked, but we have one (or two) that need to be left alone. Likely in this case most of the functions have side effects. But there are some that are normal input/output (aka "pure") functions that need to work when they are called during a test run. We can use a combination of [`jest.requireActual()`](https://jestjs.io/docs/jest-object#jestrequireactualmodulename) and [`jest.createMockFromModules()`](https://jestjs.io/docs/jest-object#jestcreatemockfrommodulemodulename).

```js
// app.test.js

// create a mock of the `../utils/players` module that is called
// from `app.js` (the code being tested)
jest.mock('../utils/players', () => {
  // use auto-mocking system to get an object that mocks all
  // of the module's functions, just like what `jest.mock()`
  // (w/ no parameters) would do
  const allAutoMocked = jest.createMockFromModule('../utils/players')

  // grab all the *real* implementations of the module's functions
  // in an object
  const actual = jest.requireActual('../utils/players')

  // return a new module implementation
  return {
    __esModules: true,

    // first start with all of the module's functions auto-mocked
    ...allAutoMocked,

    // then optionally include any override module mocks
    getPlayers: jest.fn(() => []),
    getTeams: jest.fn(() => []),

    // lastly override w/ any of the module's functions that
    // we want to use the *real* implementations for
    formatPlayerName: actual.formatPlayerName,
  }
})
```

If you are like how I was looking for how in Jest to mock a JavaScript module to keep the real implementation of one function, but mock the rest, here's your answer! 🎉 Feel free to return to your test code so you can continue writing high-quality tests. 😉 But... if you're interested in learning how all of this works, by all means, read on!

---

[Jest](https://jestjs.io/) has pretty sophisticated mocking utilities, including mocking modules. The [`jest.mock()`](https://jestjs.io/docs/jest-object#jestmockmodulename-factory-options) method allows us to mock a JavaScript module with an auto-mocked version when it is used in a test run.

Let's say we have a `players.js` file with several functions in it.

```js
// players.js

export const getPlayers = (season) => {
  // makes some sort of API call to get all of the players
  // in a given NBA `season`
}

export const writePlayersData = (players, filePath) => {
  // writes `players` data to a JSON file at the
  // specified `filePath`
}

export const getTeams = (playerId) => {
  // makes some sort of API call to get all the teams
  // the specified player has played for
}

export const formatPlayerName = (playerData) => {
  // given the `playerData`, returns a formatted version of
  // their name, including team & jersey number
}
```

And let's say we have an `app.test.js` file, containing tests for `app.js` which uses functions in `players.js`.

```js
// app.test.js

// mock the `../utils/players` module
jest.mock('../utils/players')

// calls to any of the 4 functions in `app.js` will return
// `undefined` because they've been auto-mocked
```

Auto-mocking means that Jest will replace any function within the mocked module (`../utils/players` in this case) with a new function that just returns `undefined`. **So if `app.js` calls `writePlayersData()` during a test run, it'll do nothing instead of writing to the filesystem** (which we probably don't want to do in a unit test).

We can even assert that `writePlayersData` is called in a test by importing it.

```js
// app.test.js

import { run } from './app'
import { writePlayersData } from '../utils/players'

// create a mock of the `../utils/players` module
jest.mock('../utils/players')

// calls to any of the 4 functions in `app.js` will return
// `undefined` because they've been auto-mocked

it('calls `writePlayersData` when the `write` option is true', () => {
  run({ write: true })

  // verify only writing once
  expect(writePlayersData).toHaveBeenCalledTimes(1)

  // verify called with the expected params
  expect(writePlayersData).toHaveBeenCalledWith(/* ... */)
})
```

The `jest.mock()` method also supports parameters that allow us to specify a new implementation for a module instead of the default auto-mocking.

```js
// app.test.js

// create a mock of the `../utils/players` module
// but instead of auto-mocking, provide mock
// implementations
jest.mock('../utils/players', () => {
  // return a new module implementation
  return {
    __esModule: true,

    getPlayers: jest.fn(() => []),
    getTeams: jest.fn(() => []),
    writePlayersData: jest.fn(),
    formatPlayerName: jest.fn(() => ''),
  }
})

// calls to any of the 4 functions in `app.js` during a
// test run will return the mocked values above
```

Now the 4 functions are replaced with the specified mock functions (via [`jest.fn()`](https://jestjs.io/docs/jest-object#jestfnimplementation)) that return mock data. If any of them are called from `app.js` in a test case, the mock functions are used. **These explicit mocks are especially useful for `getPlayers()` and `getTeams()` because they are expected to return data not `undefined` when called.**

There are two problems with this approach. First, even though we're fine with `writePlayersData` being auto-mocked, we still have to include it with the default `jest.fn()`. **Otherwise, `writePlayersData` wouldn't exist at all during a test run.** Second, we have to provide a mock implementation for `formatPlayerName` even though we can (and probably should) use its real implementation.

We can use the [`jest.requireActual()`](https://jestjs.io/docs/jest-object#jestrequireactualmodulename) method to grab the actual implementation of a module instead of a mock.

```js
// app.test.js

// create a mock of the `../utils/players` module
jest.mock('../utils/players', () => {
  // return a new module implementation
  return {
    __esModule: true,

    // spread in the *real* implementations of all the
    // module's functions (especially `formatPlayerName`)
    ...jest.requireActual('../utils/players'),

    // override the following module functions with
    // mock implementations
    getPlayers: jest.fn(() => []),
    getTeams: jest.fn(() => []),
    writePlayersData: jest.fn(),
  }
})

// during a test run, calls to `formatPlayerName()` will be
// normal, but the other 3 will be mocked 👍🏾
```

Using `jest.requireActual()` solves our problem with having to specify a mocked version of `formatPlayerName`. However, our first problem still exists. We still have to specify a default mock for `writePlayersData`. And if the module had more than one function that could be auto-mocked, having to specify them all would be a pain. **It would also be error-prone for when we add or remove functions from the module.**

If we combine `jest.requireActual()` with the [`jest.createMockFromModule()`](https://jestjs.io/docs/jest-object#jestcreatemockfrommodulemodulename) method, we can get the best of both worlds.

```js
// app.test.js

// create a mock of the `../utils/players` module that is called
// from `app.js` (the code being tested)
jest.mock('../utils/players', () => {
  // use auto-mocking system to get an object that mocks all
  // of the module's functions, just like what `jest.mock()`
  // (w/ no parameters) would do
  const allAutoMocked = jest.createMockFromModule('../utils/players')

  // grab all the *real* implementations of the module's functions
  // in an object
  const actual = jest.requireActual('../utils/players')

  // return a new module implementation
  return {
    __esModules: true,

    // first start with all of the module's functions auto-mocked
    ...allAutoMocked,

    // then optionally include any override module mocks
    getPlayers: jest.fn(() => []),
    getTeams: jest.fn(() => []),

    // lastly override w/ any of the module's functions that
    // we want to use the *real* implementations for
    formatPlayerName: actual.formatPlayerName,
  }
})
```

The `jest.createMockFromModule()` method uses the auto-mocking system to generate a mocked version of the module as an object. We use that as our base for the new module implementation (`allAutoMocked`). In our example, this would be for `writePlayersData`, but in a bigger module, this could be for many more functions.

Now since `allAutoMocked` contains all of the auto-mocked functions, we need to override with the ones we care about. We could next provide explicit mocks for `getPlayers` and `getTeams`. More than likely each test case will probably want different implementations for these functions, so in reality we could leave these auto-mocked as well. We would provide implementations in `describe()` blocks below.

Then last, and most importantly, we provide the real implementations of the one (or more) functions we want "un-mocked". **The result is that most of the functions in the module are mocked, and only one or two are using their real implementations.**

---

Like most of my posts, this is a real problem I came across. I had a module where most of the functions had side effects so they needed to be auto-mocked in my tests. But I had one "pure" function that I absolutely could not mock because it was necessary for the code to run.

I found [one answer on StackOverflow](https://stackoverflow.com/a/58607108) written back in October 2019 that created `allAutoMocked` using `jest.requireActual` but replacing the values with `jest.fn()`. That _was_ my implementation until PR feedback pointed me to `jest.createMockFromModule()`. It was introduced somewhat recently in [Jest 26](https://jestjs.io/blog/2020/05/05/jest-26) (May 5, 2020) so I didn't even know about it. Obviously, it didn't exist when the StackOverflow answer was written either.

My hope is that this post saves somebody from multiple hours of searching for a reasonable answer. 😃 But if you've got any questions about this problem or other JavaScript testing questions, feel free to reach out to me on Twitter at [@benmvp](https://twitter.com/benmvp).

Keep learning my friends. 🤓


A shorthand way with jest.mock() to auto-mock all functions in a JavaScript module yet use the real implementation of one function

Mock all functions in a JavaScript module except one using Jest


I use [`semantic-release`](https://github.com/semantic-release/semantic-release) for both personal and work projects to automate version management and publishing of packages. It's nice because it takes care of the entire release flow, like figuring out the [next version](https://docs.npmjs.com/cli/v8/commands/npm-version) (using [Angular Commit Message Conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format)), auto-generating GitHub release notes, and finally [publishing the package](https://docs.npmjs.com/cli/v8/commands/npm-publish) to the npm registry.

I like `semantic-release` for the handful of personal projects I work on because package publishing is a part of DivOps that I don't want to deal with. Developing the library is enough. 😃 At work `semantic-release` **provides a centralized point in CI that handles releasing a package** so that individual developers aren't trying to figure it out on their machines.

The default `semantic-release` configuration does all that I described, so initially I could release without an explicit config. Then I use [npx](https://www.npmjs.com/package/npx) to run it in CI. For example, a `release.yml` [Github workflow](https://github.com/features/actions):

```yml
name: Release

on: push

jobs:
  main:
    name: NPM Release
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Use Node v16
        uses: actions/setup-node@v2
        with:
          node-version: '16'

      - name: Install dependencies
        run: npm ci

      - name: Run unit tests
        run: npm test
        env:
          CI: true

      - name: Run integration tests
        run: npm run integrate
        env:
          CI: true

      - name: Release new version to NPM
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
        # highlight-next-line
        run: npx semantic-release
```

> I don't even install `semantic-release` as a dependency in the project. I always use the latest version.

However, sadly the default configuration [still uses `master` as the default branch](https://github.com/semantic-release/semantic-release/issues/1581). Since all of my repos use `main` as the default branch, I now need a `release.config.js` to configure the [supported branches](https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#branches).

```js {3}
module.exports = {
  branches: [
    'main',
    'next',
    'next-major',
    // version number branches will release that version
    '+([0-9])?(.{+([0-9]),x}).x',
    { name: 'beta', prerelease: true },
    { name: 'alpha', prerelease: true },
  ],
}
```

And because all of my libs are written in TypeScript, I also have a build step before releasing the pacakge. The build step allows the project to transpile TypeScript into vanilla JavaScript and auto-generate TypeScript declaration files (`*.d.ts`). As a result, **I need to specifically configure the [`@semantic-release/npm` plugin](https://github.com/semantic-release/npm) to specify the build directory (typically `lib/` for me)**. But to configure the plugin, I also must include all of the [plugins](https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#plugins) used by default.

```js {19-21}
module.exports = {
  branches: [
    'main',
    'next',
    'next-major',
    '+([0-9])?(.{+([0-9]),x}).x',
    { name: 'beta', prerelease: true },
    { name: 'alpha', prerelease: true },
  ],

  plugins: [
    // analyzes commits w/ conventional-changelog
    '@semantic-release/commit-analyzer',

    // generates a changelog w/ conventional-changelog
    '@semantic-release/release-notes-generator',

    // publishes the npm package from the specified folder
    ['@semantic-release/npm', {
      pkgRoot: './lib'
    }]

    // Publishes changelog as a GitHub release and
    // comments on released Pull Requests & Issues
    '@semantic-release/github',
  ],
}
```

> FYI: at work I also use [`semantic-release-slack-bot`](https://github.com/juliuscc/semantic-release-slack-bot) to get release notifications in Slack from a Slack bot, but I'm leaving it out to simplify the discussion.

With the addition of the build step, the `release.yml` Github workflow now looks like:

```yml
name: Release

on: push

jobs:
  main:
    name: NPM Release
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Use Node v16
        uses: actions/setup-node@v2
        with:
          node-version: '16'

      - name: Install dependencies
        run: npm ci

      - name: Run unit tests
        run: npm test
        env:
          CI: true

      - name: Run integration tests
        run: npm run integrate
        env:
          CI: true

      # highlight-start
      - name: Build package
        run: npm run build
      # highlight-end

      - name: Release new version to NPM
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
        run: npx semantic-release
```

Because `semantic-release` relies on a strict commit format (by default [Angular Commit Message Conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format)) in order to auto-determine the next version, **I also set up all of my GitHub projects to only support [squash merge commits](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-pull-request-commits) in Pull Requests**. I've found that it's the least painful way to ensure developers use the proper commit format because I also add another GitHub workflow to validate the Pull Request title using the [`amannn/action-semantic-pull-request`](https://github.com/amannn/action-semantic-pull-request) GitHub action. An example `validate-pr.yml` workflow file looks like:

```yml
name: Pull Request

on:
  pull_request_target:
    types:
      - opened
      - edited
      - synchronize

jobs:
  main:
    name: Validate PR title
    runs-on: ubuntu-latest
    steps:
      ## highlight-next-line
      - uses: amannn/action-semantic-pull-request@v4
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```

---

## Supporting one-off releases

**When working on a library project, at times I need to test how it'll work in a host application before merging a Pull Request.** There are some features that automated tests just cannot cover. They are best verified by using the library in a host app. We need to add a "dev" version of the package as a dependency in the app, just like we would for a real released version. But how exactly do we do that?

Back in the day I would use [`npm link`](https://docs.npmjs.com/cli/v8/commands/npm-link) to symlink the dependency in the app's `node_modules` to the library project folder. But that stopped working once I started transpiling code and the project folder looked different than the package folder. This difference is also why using a GitHub project reference also doesn't work.

So on a library that I develop solely by myself, I would run [`npm pack`](https://docs.npmjs.com/cli/v8/commands/npm-pack) locally to create a tarball (`.tgz`) of the package. An app's `package.json` can [install](https://docs.npmjs.com/cli/v8/commands/npm-install) a tarball from a local path instead of a version in the registry. So I would `npm pack` the package, put it somewhere on the filesystem, and reference it in my test app's `package.json`. But that's not an easily repeatable pattern for multiple devs on a team, especially when some are infrequently contributing to the lib.

So when on a team, **I initially ab-used the `alpha` pre-release branch.** When someone on the team needed to test a release, they merged their (properly-titled) commits into the project's `alpha` branch. And when they pushed it to `origin`, the `release.yml` workflow would run. And since `alpha` is listed in the `branches` of the `release.config.js` as a pre-release, the new code would release at a new alpha version.

This approach worked okay. The `alpha` branch ended up having a lot of trial and error code. But as long as we merged `main` into it regularly, it cleaned up pretty well. **However, when we had multiple developers who wanted to test their dev branches with `alpha` releases simultaneously, we ran into trouble.** We had to get the "all clear" to release alphas in serial. And since we could have multiple dev branches merging into alpha sequentially, the branch itself could get into a pretty gnarly state.

We need to isolate the dev branches into their releases. We need something akin to running `npm pack` locally, but with the consistency that running `semantic-release` in CI provides. **So what we can do is add another pre-release branch, but use a pattern for multiple branch support.**

```js {10-12}
module.exports = {
  branches: [
    'main',
    'next',
    'next-major',
    '+([0-9])?(.{+([0-9]),x}).x',
    { name: 'beta', prerelease: true },
    { name: 'alpha', prerelease: true },

    // Any branch starting with `test-` will be auto-released
    // as a pre-release (e.g. `1.3.0-test-add-cool-new-feature.1`)
    { name: 'test-*' prerelease: true},
  ],

  plugins: [
    '@semantic-release/commit-analyzer',
    '@semantic-release/release-notes-generator',
    ['@semantic-release/npm', {
      pkgRoot: './lib'
    }]
    '@semantic-release/github',
  ],
}
```

Let me break down how I can release a new "dev" version for my PR branch.

1. I do my dev work on a branch named `add-cool-new-feature`
1. I merge the (properly-titled) commits into a `test-add-cool-new-feature` branch (creating it if this is the first time)
1. I push `test-add-cool-new-feature` to `origin`
1. CI runs and releases the one-off version (e.g. `1.3.0-test-add-cool-new-feature.1`)

Instead of including "alpha" or "beta" in the version, it includes the entire name of the branch. If I continue to push new commits to the branch the `.1` part will be `.2`, `.3`, etc. **And now I can create my test release branches while other developers can do the same in parallel.** And once we're done, we delete our branches from `origin`. The `alpha` and `beta` [pre-release branches](https://github.com/semantic-release/semantic-release/blob/master/docs/recipes/release-workflow/pre-releases.md#publishing-pre-releases) remain as they should be.

---

Well, hopefully, this example helps you out! The configuration for `semantic-release` itself is surprisingly uncomplicated. It's just an additional entry in the `branches` config. But I think what's most interesting is the concept itself. Even though `semantic-release` has a pretty strict commit syntax which enables it to publish a real versioned release on every commit, we can still configure it to act like our old strategies from before.

I would love it if you could let me know if you found this post helpful. Feel free to reach out to me on Twitter with comments or questions at [@benmvp](https://twitter.com/benmvp).

Keep learning my friends. 🤓


How to configure semantic-release to release one-off test branches in an app in order to test dev code prior to merging a Pull Request

Create one-off releases with semantic-release

AI is no longer just a buzzword; it's a transformative force poised to reshape how we interact with technology. Everyone is trying to create the latest game-changing AI-driven app, but how can we developers leverage GenAI without becoming full-fledged AI experts or overhauling our existing applications?

This talk will move past the academic exercises and explore the "sneaky" ways GenAI can be seamlessly integrated into existing applications to create subtle yet powerful enhancements that elevate the user experience. Through real-world examples and engaging demos, we'll uncover the hidden potential of GenAI to personalize user experiences and unlock new levels of creativity and efficiency.

Leave this talk empowered to harness the power of GenAI, even if you're new to AI. Discover practical strategies and inspiring ideas to infuse your apps with intelligence, delight your users, and stay ahead of the curve in this rapidly evolving technological landscape.

Sneaky Ways to Integrate GenAI for Real-World Impact

All Things Open AI 2026

While "Lines of Code" (LoC) has never been a perfect metric for developer productivity, it has served as a default proxy for output. However, in an era where modern AI code editors like Cursor or Claude Code can generate thousands of lines instantly, LoC doesn't just miss the point. It actively obscures the real value we deliver. We risk optimizing for volume when we should be optimizing for leverage.

Let's explore the "Agentic" shift, moving beyond the hype of raw coding speed to reveal how AI agents provide true leverage across four critical dimensions. We will look at how agents help us maintain flow by handling execution details, hardening our software through rigorous quality checks, instantly deepening our knowledge of complex codebases, and freeing us to focus on high-level strategy and innovation.

We will leave this session with a practical, qualitative framework to evaluate and advocate for these tools. We'll stop trying to prove we can type faster and start demonstrating how we are building smarter, more robust systems with greater strategic focus.


Hi, I'm Ben Ilegbodu. I want to help you level up your frontend skills.

Attend

Durham, North Carolina (Carolina Theater)

All Things Open AI 2026

Read

From Vibe Coding to Deliberation-First Coding with AI

Being Sneaky with GenAI

How GenAI is shifting architecture left

Have We Finally Reached the Mythical "10x Developer"?

Mock all functions in a JavaScript module except one using Jest

Create one-off releases with semantic-release

Watch

Sneaky Ways to Integrate GenAI for Real-World Impact

JavaScript fwdays 2025

Sneaky Ways to Integrate GenAI for Real-World Impact

All Things Open AI 2025

Develop

Migrating to React Hooks

TypeScript for React Developers

Zero to React with Hooks