AI Tips Archive

Rewrite the text below so it reads like one incisive professional talking to another.

• Keep every idea and fact unless changing it makes the point clearer.
• Active voice. Paragraphs no longer than three short sentences.
• Vary sentence length; avoid a metronome rhythm.
• Swap jargon or $10 words for plain ones. Use contractions.
• Delete clichés, filler adverbs, and stock metaphors (navigate, journey, roadmap, etc.).
• No bullet points unless they’re essential for scan-ability.
• No summary footer. End on a crisp final line, not a recap.
• Never use em dashes; use commas, periods, or rewrite the sentence instead.
• Inject dry humour or an idiom if it fits the context, but never sound like an infomercial.
• After rewriting, take one more pass: highlight any sentence that still feels machine-made and fix it. Return only the rewritten text.

Structuring Application State with Zustand

This guide provides principles for structuring application state using Zustand, a small, fast, and scalable bearbones state-management solution.

1. Define a Clear State Interface (with Actions)

Start by defining a TypeScript interface that explicitly describes the structure of your application’s state and the actions that will modify it. This is crucial for type safety and maintainability.

interface MyStore {
  dataItems: Item[];
  selectedItem: Item | null;
  isLoading: boolean;
  error: string | null;

  actions: {
    setDataItems: (items: Item[]) => void; // Sets the entire list of data items.
    setSelectedItem: (item: Item | null) => void; // Sets the currently selected item.
    updateItem: (id: string, updates: Partial<Item>) => void; // Updates a specific item's properties by ID.
    clearError: () => void; // Clears any error message.
  };
}

Explanation:

• The interface clearly defines the state and the functions (actions) that modify it.
• Descriptive comments explain the purpose of each action.

2. Creating the Zustand Store

Use the create function from Zustand to create your store. It’s common to also use middleware like devtools (for debugging) and immer (for simplified immutable updates).

import { create } from 'zustand';
import { devtools, persist } from 'zustand/middleware';
import { immer } from 'zustand/middleware';

export const useMyStore = create<MyStore>()(
  devtools(
    immer((set) => ({
      dataItems: [],
      selectedItem: null,
      isLoading: false,
      error: null,

      actions: {
        setDataItems: (items) => set({ dataItems: items }),
        setSelectedItem: (item) => set({ selectedItem: item }),
        updateItem: (id, updates) =>
          set((state) => {
            const index = state.dataItems.findIndex((item) => item.id === id);
            if (index !== -1) {
              state.dataItems[index] = { ...state.dataItems[index], ...updates };
            }
          }),
        clearError: () => set({ error: null })
      }
    })),
    { name: 'my-store' } // Optional: Name for devtools
  )
);

Explanation:

• create: The core function from Zustand.
• devtools: Enables Redux DevTools integration for easy state inspection.
• immer: Simplifies immutable updates. You can write code that looks mutable, but Immer handles the immutability behind the scenes.
• set: The function provided by Zustand to update the store’s state.
• The function passed to create defines the initial state and the actions.

3. Using the Store in Components

Use the useMyStore hook (or whatever you named your store hook) to access the state and actions in your components.

import { useMyStore } from './your-store-file'; // Adjust the path

const MyComponent = () => {
  const { dataItems, selectedItem, actions } = useMyStore();

  const handleUpdateItem = (id: string, updates: Partial<Item>) => {
    actions.updateItem(id, updates);
  };

  return (
    <>
      {/* Example: Displaying a list of items */}
      <ul>
        {dataItems.map((item) => (
          <li key={item.id}>
            {item.name} - <button onClick={() => handleUpdateItem(item.id, { name: "Updated Name" })}>Update Name</button>
          </li>
        ))}
      </ul>
    </>
  );
};

I’ve used AI heavily across engineering work this past year. One thing became obvious fast, the gap between a loose prompt and a structured one is massive. Sometimes the output improves threefold just because the prompt stops wandering.

After a while I realized that every prompt that worked had the same habits. It set the frame in one clean sentence, it aimed at one job, it added just enough constraints to wipe out errors, it told the model exactly what the final answer should look like, and it gave a clear way to judge if the result was actually correct. I kept seeing that pattern, then I started using it intentionally, then it became the default way I write prompts.

Here’s a real example of how I apply it:

“Write a TypeScript utility to merge two deeply nested objects, keep the final code under 40 lines, avoid external libraries, return only a code block and include a one line comment at the top explaining the approach. I’ll consider it correct if the merge works recursively and source keys never override destination keys.”

Before I worked this way, I’d get inconsistent code or five paragraphs of philosophy. With this structure, the model hits the mark on the first try far more often. I rewrite less. Results stay consistent across different AI models. Token usage drops because the prompt isn’t padded with noise.

It turns out AI isn’t guesswork, it behaves when you give it structure.