DEV Community: Niki

Defending your codebase from AI slop: guardrails that keep you in control

Niki — Thu, 08 Oct 2026 19:28:53 +0000

AI coding agents are fast. They also write code that compiles, looks fine at a glance, and slowly wears down your architecture. A component imports the database layer directly. A function grows to 200 lines with three nested ternaries. A dependency shows up that nobody asked for. A routes file picks up a formatDate helper, then a slugify, then a retryWithBackoff. Tests run every line but never check a result.

None of this is new. Junior developers in a hurry do the same things. What's new is the volume. If an agent opens ten PRs a day, careful human review alone won't catch everything.

The answer isn't to stop using AI. It's to write your standards down in a form machines can enforce, so the rules hold no matter who or what wrote the code. Here's the stack I usually build for my projects.

1. Write the rules down first

Tools can only enforce rules that exist. Before adding any tooling, I decide how I want my code to look, define the rules, and write them in two files:

ARCHITECTURE.md covers the layers, which layer may import which, where state lives, and how data flows.
AGENTS.md, essential nowadays, is usually created automatically and then edited by me. It covers conventions for AI agents: naming, patterns to use, patterns to avoid, and tools that are off-limits (for example: "we use Biome, don't add ESLint").

Agents read these files. So do new hires. And every tool below points back to a section in one of them, so when a check fails, the message explains why and not just what.

2. Guard the boundaries: dependency-cruiser

Something I've discovered quite recently: dependency-cruiser checks which files import which. You describe the allowed directions between layers, and it fails the build when something crosses a line:

UI components can't import the database layer
modules can't import each other circularly
features can't reach into another feature's internals
orphaned files that nothing imports get flagged

This is the kind of mistake AI makes most, because it takes whatever import path is closest. A rule that always gives the same answer stops it before review.

3. Guard the shape of the code: Semgrep

dependency-cruiser tells you which files talk to each other. It can't tell you what the code inside a file is doing. That's what Semgrep is for.

How Semgrep works

Semgrep is a pattern matcher that understands code. You write a rule that says "code shaped like X, in files matching Y, is a violation." Semgrep parses each file into a syntax tree and reports every match. It doesn't run your code or try to understand your whole app. It only checks shapes.

A rule is a short YAML entry:

rules:
  - id: api-routes-no-helpers
    languages: [python]
    severity: ERROR
    message: >
      routes.py is for route handlers only.
      Move helpers to their own module (see ARCHITECTURE.md → API).
    paths:
      include: [packages/api/src/api/routes.py]
    patterns:
      - pattern: |
          def $FUNC(...):
              ...
      - pattern-not-inside: |
          @$ROUTER.$METHOD(...)
          def $F(...):
              ...

pattern is the code to match. $FUNC matches any name, and ... matches anything.
pattern-not-inside is the exception. Here, functions with a route decorator are allowed.
paths limits the rule to certain files.
message is what the developer (or the AI agent) sees when the rule fails. Write it as an instruction.

Running semgrep --config .semgrep/rules/ checks the whole repo against every rule in that folder. We keep one YAML file per area (app, API, mq) so rules stay easy to find, and each rule gets a small test fixture with code that should match and code that shouldn't, so we know the rule catches what we meant.

Read their docs (or ask your agent to) on what's possible and get creative.

One-purpose files

This was the rule we wanted most. Some files exist for one job, and AI agents love to drop "just one small helper" into them. After a few months, your routes file is half utilities.

So we made it impossible. Each of these files may only contain its one kind of thing:

API route modules (routes.py): route handlers only
App services/: one class, methods only, no loose functions
App functions/: TanStack server functions only
Hooks: hooks only
Route files: route definitions only
DB schema: table definitions only
API models/schemas: models only
API repositories: repository classes only

Helpers go in their own module, where they can be named, tested and reused. The rule message tells the agent exactly that, so it usually fixes itself on the next try.

Other patterns worth enforcing

Once you think in shapes, a lot of review comments turn into rules:

query and mutation keys written inline instead of coming from a key factory
data fetching inside components
raw fetch in routes and server functions
Drizzle queries outside db/queries
exported query functions that default to tx: DbClient = db (this hides transaction bugs)
queue names written as string literals
raw SQL built from strings in the Python API
API routes importing models directly instead of going through a repository

Semgrep works on many languages, so it covers anything you want.

Rule of thumb: if a review comment can be written as a code pattern, make it a Semgrep rule. Then it gets checked the same way on every PR.

Adding it to an existing codebase

You probably have violations already. Don't let that stop you. In CI, Semgrep can compare against a baseline:

On PRs, only violations added in that PR fail the check.
On main, the full scan runs, so you can see the existing debt and pay it down over time.

New code is held to the standard from day one, and nobody has to fix everything first.

4. Scan for vulnerabilities: SAST, SCA and DAST

Architecture rules keep the code tidy. They don't tell you whether it's safe. AI agents write the same security bugs humans do, just faster: SQL built from strings, an endpoint that forgets to check who's calling it, a token pasted into a config file, user input rendered as HTML.

Security tools fall into three groups, and each sees something the others can't:

Kind	Looks at	Finds	Misses
SAST (static application security)	Your source code, not running	Injection, unsafe APIs, hardcoded secrets, tainted data flows	Runtime config, auth bugs that depend on real data
SCA (software composition analysis)	Your dependencies and lockfiles	Known CVEs, malicious packages, licenses	Bugs in your own code
DAST (dynamic application security)	The running app, from outside	Missing auth, exposed endpoints, bad headers, misconfigured servers	Where in the code the bug is; code paths it never reaches

SAST and SCA run on every PR in seconds or minutes. DAST needs a deployed app, so it runs against a preview environment or staging. Most of the tools below cover more than one group:

Tool	SAST	SCA	DAST	Other
Semgrep	✅	✅		Secrets
Trivy		✅		Containers, IaC, secrets
Snyk	✅	✅	✅	Containers, IaC
Checkmarx One	✅	✅	✅	Containers, IaC, secrets, API
GitHub CodeQL	✅			Dependabot covers SCA
ZAP			✅	Free, open source

I am an OSS supporter, so I usually go with Semgrep and Trivy. Companies I've worked for went with whatever suited them best. Choose any; no judgement there.

SAST: your code

Good SAST tools track data flow: they follow user input from a request handler and flag it if it reaches SQL, a shell or HTML unescaped. Ask an agent to "add search" and you may get:

@router.get("/search")
def search(q: str, db: Session = Depends(get_db)):
    return db.execute(text(f"SELECT * FROM products WHERE name LIKE '%{q}%'"))

It works, and it's SQL injection. Semgrep Code catches it with the engine you already run for architecture (add --config p/owasp-top-ten). CodeQL is free for public repos and shows results in the PR. Snyk Code and Checkmarx cover the same ground in their platforms. Fail the build on high-confidence rules only. A noisy check gets switched off.

SCA: your dependencies

Agents add packages freely, sometimes outdated, sometimes made up and squatted ("slopsquatting"). Trivy is the free baseline for vulnerable packages, secrets, container images and IaC:

trivy fs . --scanners vuln,secret,misconfig --severity HIGH,CRITICAL --exit-code 1

Trivy only matches versions, so it flags vulnerable packages whether or not you use the vulnerable part. Semgrep Supply Chain checks reachability: does your code actually call the vulnerable function? Snyk opens fix PRs and alerts when a new CVE hits code you already shipped. Checkmarx One also detects malicious packages such as typosquats.

Require CODEOWNERS approval on package.json and lockfiles, so every new dependency is a human decision.

DAST: the running app

DAST sends real requests to a deployed app, so it catches what code scanning can't: an endpoint the agent left without an auth check, one user reading another's data by changing an ID, missing security headers, exposed debug pages. Run it against a preview deploy or staging:

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
  -t https://preview.example.com/openapi.json -f openapi

ZAP is free. Nuclei checks for known exposures. StackHawk, Snyk API & Web and Checkmarx DAST are paid options. Give the scanner credentials and an API spec, or it will scan your login page and little else.

DAST, I'd say, is a nice-to-have, not a must-have. Folks at Semgrep think so too. Occasional manual testing or pentesting is more than enough.

5. Measure complexity and test quality

Something I've learned about from Uncle Bob. I never thought about it until AI became a thing.

CRAP stands for Change Risk Anti-Patterns, a metric used to identify risky, complex, and poorly tested code. The CRAP Index measures the maintenance risk of a specific function or method.

Rule of thumb: a score above 30 indicates a high-risk, "CRAPpy" method that needs attention or refactoring.

I found two tools I could integrate into my pipelines that would help to keep AI-generated code under control:

crap4ts computes a CRAP score from complexity and coverage. Complex code with weak tests scores high. Set a limit and fail functions that go over it.
ArchUnitTS lets you write architecture rules as unit tests, if you'd rather keep them next to your test suite.

6. AI reviewing AI: CodeRabbit with custom rules

Some rules can't be written as patterns: "does this name match what the code does?" or "is this abstraction premature?" For those, we can use CodeRabbit (or one of many other AI code review tools) with a strict config file, like .coderabbit.yaml:

the strictest review profile, and it requests changes when it finds problems
it reads ARCHITECTURE.md and AGENTS.md as guidelines
instructions for each folder, each linked to the doc section it comes from
pre-merge checks: most only warn, but a few block the merge (for example, a schema change with no migration)

The important part is that CodeRabbit is the last layer, not the first. AI review isn't consistent, so anything that can be checked by a tool that always gives the same answer should be. CodeRabbit handles judgement calls.

7. More you can add

What we've set up covers most of it. Here are a few more tools that can help you keep even tighter control over your repo:

Knip finds unused files, exports and dependencies. AI leaves a lot of dead code behind.
Mutation testing (which Uncle Bob is also looking at and seems to think is an essential part of CI/CD checks) (Stryker) changes your code on purpose and checks whether tests fail. It's the best way to catch tests that run code but never check results.
PR size limits: fail or warn on PRs over a few hundred lines. Small PRs actually get reviewed. Not something I'd do, though.
Pre-commit hooks: such as Lefthook or, most commonly in JS-based projects, husky. You can configure them to run anything, including Biome, Semgrep and type checks, locally, so you get feedback before you push.

The principle

Every layer follows the same idea: move each rule to the most reliable tool that can enforce it.

Write the rule in ARCHITECTURE.md / AGENTS.md.
If it's about imports → dependency-cruiser.
If it's about code shape → Semgrep.
If it's a security bug in your code → SAST (Semgrep, CodeQL, Snyk Code, Checkmarx).
If it's about dependencies or secrets → SCA (Trivy, plus Semgrep Supply Chain, Snyk or Checkmarx).
If it only shows up at runtime → DAST (ZAP, Nuclei, StackHawk, Snyk, Checkmarx) against a preview deploy.
If it needs judgement → CodeRabbit, and then a human.

AI can write as much code as it likes. It just has to pass the same checks as everyone else. That's how you stay in control.

The layers of an AI agent product

Niki — Thu, 08 Oct 2026 19:26:45 +0000

Since agents became a thing, I decided that I wanted to build my own. I'm a believer that building your own will teach you more about the technology and make you a better user.

But. What is an "agent"?

"Agent" gets used for everything from a single API call to a full SaaS product. That makes it hard to talk about where a problem lives, or which piece of the stack should solve it. It helps to split an agent product into layers, each with its own job.

To keep it concrete, I'll use one running example throughout: a support agent that can look up orders and issue refunds.

The structure

An AI agent product has distinct layers:

model SDK → agent framework → harness → execution runtime → product

Databases and files store state for several of these layers. Proof, meaning observability and evals, isn't a layer: it measures how well all of them work.

Layer	Job	Examples
Model SDK	One request, one response	OpenAI SDK, Anthropic SDK, Google Gen AI SDK, Vercel AI SDK Core
Agent framework	Run the tool-calling loop	Pydantic AI, Mastra, LangChain / LangGraph, OpenAI Agents SDK
Harness	Define the job, context, and boundaries	Claude Code, Codex CLI, GitHub Copilot CLI, Cursor, your own agent code
Execution runtime	Run the work durably, survive failures	Temporal, Inngest, DBOS, Celery + a queue, LangGraph checkpointers
Product	Users, tenants, UI, billing, reconnecting	ChatGPT, Claude.ai, Cursor, Copilot coding agent, your SaaS
Proof (across all layers)	Show what happened and whether it was good	OpenTelemetry, Langfuse, LangSmith, Logfire, Braintrust, Pydantic Evals

Model SDK

A model SDK makes a request and returns a response. That response might contain text or a request to call a tool, but the SDK does not complete a multi-step task on its own.

Here's what that looks like with the Anthropic Python SDK:

import anthropic

client = anthropic.Anthropic()

tools = [{
    "name": "get_order",
    "description": "Look up an order by ID",
    "input_schema": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"],
    },
}]

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "Where is order 1234?"}],
)

print(response.stop_reason)  # "tool_use"

The model didn't look anything up. It returned a tool_use block that says "please call get_order with order_id="1234"". Running that function, sending the result back, and asking again is your job. The SDK is done.

Agent framework

An agent framework manages that loop:

Assemble context.
Call the model.
Validate the requested tool arguments.
Execute the tools.
Add their results to the conversation.
Call the model again, until it finishes.

Stripped down, this is what's under the hood of every framework:

messages = [{"role": "user", "content": "Where is order 1234?"}]

while True:
    response = client.messages.create(
        model="claude-sonnet-4-5", max_tokens=1024, tools=tools, messages=messages
    )
    messages.append({"role": "assistant", "content": response.content})

    if response.stop_reason != "tool_use":
        break

    results = []
    for block in response.content:
        if block.type == "tool_use":
            output = TOOLS[block.name](**block.input)  # validate first in real code
            results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": str(output),
            })
    messages.append({"role": "user", "content": results})

A framework gives you that loop plus the tedious parts: turning function signatures into JSON schemas, validating arguments, retrying when the model sends bad ones, streaming, and switching model providers. The same agent in Pydantic AI:

from pydantic_ai import Agent

agent = Agent("anthropic:claude-sonnet-4-5")

@agent.tool_plain
def get_order(order_id: str) -> dict:
    """Look up an order by ID."""
    return orders.get(order_id)

result = agent.run_sync("Where is order 1234?")
print(result.output)

Other frameworks make different trade-offs:

Pydantic AI: Python, type-first. Tool arguments and outputs are validated with Pydantic models.
Mastra: TypeScript. Agents, tools with Zod schemas, and workflows in one package.
LangChain / LangGraph: LangGraph models the loop as an explicit graph of nodes and edges, which helps when the flow has branches.
OpenAI Agents SDK: A small loop with handoffs between agents and guardrails.

An agent run may make many model calls; it is not one continuous model request. Our "where is my order" question is already two calls: one that asks for the tool, one that writes the answer.

Harness

The framework is the loop. The harness is the job.

A framework answers how an agent runs: call the model, validate tool arguments, execute tools, append results, call again until it stops. It also covers the tedious parts around that loop: schemas, retries, streaming, provider switching. It doesn't know what the agent is for.

A harness answers what this agent is allowed to be: instructions, which tools exist, what context is loaded, memory, permissions, budgets, and stopping rules. It determines what information reaches the model and what actions the model is allowed to request.

Think of a web app. FastAPI is the framework. Your routes, auth rules, and queries are the harness. FastAPI will route a request. It will not decide that refunds over $100 need a human.

Question	Framework answers	Harness answers
How do I call the model and run tools?	The loop, schemas, validation, retries	n/a
Which tools exist?	How to register them	`get_order` and `refund`, nothing else
What does the model see?	Where to put instructions and messages	This customer's summary, not the full history
What is it allowed to do?	Gives you hooks for checks	Refunds over $100 go to a human
When does it stop?	Stops when the model stops calling tools	After 10 model calls, or when the budget runs out

The swap test makes it concrete. Swap the framework, port the same instructions, tools, and limits, and the agent should still do the same job. Swap the harness and you have a different agent, even on the same library. The same Pydantic AI loop can run a support agent that only reads one customer's orders, or an analytics agent with read access to the whole warehouse. Same loop, different harness, different product.

A note on wording: products often call the whole thing a harness, loop included. Anthropic, for example, describes Claude Code as the agentic harness around Claude. Here, framework means the reusable loop, and harness means the job-specific decisions on top of it.

For our support agent, the harness is the code around agent.run():

from pydantic_ai import Agent, RunContext
from pydantic_ai.usage import UsageLimits

agent = Agent(
    "anthropic:claude-sonnet-4-5",
    deps_type=Customer,
    instructions="You are a support agent. Only discuss the customer's own orders.",
)

@agent.instructions
def customer_context(ctx: RunContext[Customer]) -> str:
    # Context selection: load a summary, not the whole history
    return f"Customer: {ctx.deps.name}. Notes: {ctx.deps.support_summary}"

@agent.tool
def get_order(ctx: RunContext[Customer], order_id: str) -> dict:
    # Scoping: the model can only see this customer's orders
    return db.get_order(order_id, customer_id=ctx.deps.id)

@agent.tool
def refund(ctx: RunContext[Customer], order_id: str, amount: float) -> str:
    # Permissions: large refunds need a human
    if amount > 100:
        return "Refund queued for human approval."
    return payments.refund(order_id, amount)

result = agent.run_sync(
    message,
    deps=customer,
    usage_limits=UsageLimits(request_limit=10),  # Budget and stopping rule
)

Nothing in there is new framework machinery. It's decisions: what the agent is for, what it can see, what it can do, and when it must stop.

Coding agents are the best-known harnesses. Claude Code, Codex CLI, and GitHub Copilot CLI all run roughly the same loop against a model. What makes them different is what's under the hood of the harness:

Instructions: a long system prompt describing how to work in a codebase, plus project files such as CLAUDE.md or AGENTS.md.
Tools: read, edit, and search files; run shell commands; fetch URLs; spawn sub-agents.
Permissions: ask before running a command or editing a file, allow-lists for safe commands, sandboxes that block network or writes outside the project.
Context management: search the codebase instead of loading it, truncate large tool outputs, and summarise (compact) the conversation when it approaches the context limit.
Stopping rules: finish when the model stops calling tools, when the user interrupts, or when a limit is hit.

Swap the model under Claude Code and you still have most of Claude Code. Swap the harness and you have a different product. That's also why Anthropic ships the Claude Agent SDK: it's the Claude Code harness offered as a library.

Memory is part of that context strategy. It might be recent messages in a database, a summary, or a file such as MEMORY.md. The file is not inherently "memory": the harness must decide when to write it, how to scope it, and what to load into future model requests. The model sees the context it is given, not everything stored on disk.

In the support agent above, support_summary is memory. Some job has to write it after each conversation, and customer_context decides to load it. Without both, it's just a column in a table.

Execution runtime

The framework can run inside an HTTP request, but a durable service separates accepting a task from executing it. An API records a run; a worker executes it; checkpoints record completed progress so another worker can continue after a failure.

POST /runs  →  insert run (status=queued)  →  202 Accepted { run_id }
                         ↓
                 queue → worker → agent loop → checkpoint after each step
                         ↓
                 run status=completed, events stored

The options range from simple to heavy:

A queue and workers (Celery, BullMQ, SQS + Lambda): easy to start. Checkpointing is up to you.
Durable execution engines (Temporal, Inngest, DBOS): each model call and tool call becomes a recorded step. If a worker dies, another one replays the recorded results and continues from the next step. Pydantic AI has built-in integrations for Temporal, DBOS, and Prefect.
Framework checkpointers: LangGraph saves graph state after each step to Postgres or SQLite, so a thread can resume or pause for human approval. Mastra workflows can suspend and resume.

What a durable execution engine actually is

An event log plus replay. Every engine has the same parts:

Storage: an append-only log per run ("step started", "step completed with this result"), usually in Postgres.
A queue and workers: your code runs in your workers, built with the engine's SDK. Temporal works like BullMQ with Redis: workers pull tasks from the Temporal server, which you self-host or rent as Temporal Cloud.
Replay: when a worker dies, another one re-runs the code from the top. Finished steps return their recorded result instead of running again, so execution continues from the first unfinished step. That's the difference from a plain job queue, which retries the whole job.
Retries and timeouts: per step, with backoff, plus heartbeats so a dead worker's task gets picked up.
Timers and signals: a run can wait days for a human approval without a process sleeping that long.

A basic version is a steps table keyed by (run_id, step_id) and a helper that checks it before running each step. That's roughly how DBOS works, as a library on Postgres. Once you need timers, signals, and deploys while runs are in flight, use an engine.

A checkpoint is different from memory. Memory helps the agent answer the next question; a checkpoint says which steps of the current task have finished. It cannot freeze an in-flight model call or undo an email already sent. Retried actions therefore need idempotency or a way to reconcile their outcome.

For the refund tool, that means passing an idempotency key derived from the run and the step, so a retry after a crash doesn't refund twice:

payments.refund(order_id, amount, idempotency_key=f"{run_id}:{step_id}")

Payment APIs such as Stripe support this directly. For APIs that don't, check whether the action already happened before repeating it.

A database can store memory, checkpoints, and product data. That does not make "database" a separate agent layer. It is infrastructure serving different responsibilities.

Product and proof

The product adds authentication, tenancy, a UI, billing, and a way to reconnect to a run's events. A browser connection should not own the work, and it should not be required for the run to complete or be charged.

The Copilot coding agent and Codex in the cloud are good examples: you assign a task, close the tab, and come back to a pull request. The run lives in the runtime, not in your browser. The UI just subscribes to its events, usually over SSE, and picks up where it left off on reconnect.

Observability shows what happened across model calls, tools, and workers. In practice that's traces: one span per model call and tool call, with tokens, latency, and cost attached. OpenTelemetry has semantic conventions for generative AI, and tools such as Langfuse, LangSmith, and Logfire display them.

Evals measure whether the agent completed useful tasks at acceptable quality and cost. For the support agent, that's a set of real conversations with expected outcomes: did it refund the right order, did it refuse to show another customer's data, did it escalate the $500 refund? Run them on every prompt or model change with Braintrust, Pydantic Evals, or a plain test suite.

Tests and load measurements address operational reliability. Kill a worker mid-run. Deploy during a run. Send a thousand runs at once.

A run can finish reliably and still give a poor answer. It can also give an excellent answer once and fail to survive the next deploy. Both problems need measuring.

The silent promise that will kill your Node.js server

Niki — Fri, 23 Jan 2026 06:35:01 +0000

You've got a production server. It's been running fine for hours. Then suddenly it crashes. No warning, no graceful degradation. Just dead.

The culprit? A single line of code that looks completely innocent:

saveMessageToDatabase(stream);

The Setup

You're building a chat API. When a user sends a message, you want to stream the response back immediately while saving it to the database in the background. Classic fire-and-forget pattern:

async function handleChat(request) {
  try {
    const stream = await callAI(request);

    // Fire and forget - don't wait for this
    saveMessageToDatabase(stream);

    return stream;
  } catch (error) {
    console.error('Failed:', error);
  }
}

Looks fine. What could go wrong?

The Kill Shot

Three hours later, the AI provider has a hiccup. The stream connection drops mid-transfer. saveMessageToDatabase throws an error.

Your server is dead.

"PM2/Docker/Kubernetes will restart it!" Sure — and you've still lost every in-flight request, any unsaved state, and your users just saw an error. Prevention beats recovery.

Why try-catch Didn't Save You

try-catch only catches errors from awaited promises:

// ❌ This try-catch is useless
try {
  saveMessageToDatabase(stream); // Returns immediately
} catch (error) {
  // Never reached
}

Without await, the function returns a Promise and exits the try block successfully. The actual error happens later, asynchronously, after the try-catch is long gone.

When that Promise eventually rejects with no handler attached, Node.js sees an "unhandled rejection" and, depending on your Node version, terminates the process.

The Fix

One character. Well, a few:

saveMessageToDatabase(stream).catch(() => {});

That's it. By attaching .catch(), you tell Node "I know this might fail, and I'm handling it." The callback can be empty if you're logging inside the function. You just need to mark the Promise as "handled."

The Pattern

For any fire-and-forget async operation:

// Always attach .catch() to floating promises
doSomethingAsync().catch(() => {});

// Or log the error if you want visibility
doSomethingAsync().catch(err => {
  console.error('Background task failed:', err);
});

The Lesson

try-catch and async/await are not magic. They follow specific rules:

try-catch only catches synchronous throws and awaited rejections
A Promise without await or .catch() is a ticking time bomb
"Fire and forget" still needs a .catch() — you're forgetting the result, not the error

Your server will thank you.

My go-to patterns for full-stack/frontend projects

Niki — Thu, 15 Jan 2026 11:50:06 +0000

After working on quite a few frontend and full-stack projects (mostly React + TypeScript + some flavour of server/backend), I kept coming back to the same handful of patterns. They bring structure, reduce mental overhead, and make the codebase feel maintainable even as it grows.

These aren't revolutionary, but they're pragmatic choices that have worked well across different apps. Here's the current set I reach for almost every time.

1. React Query + Query Key Factory pattern

I end up using TanStack Query (React Query) in nearly every project. To keep query keys consistent, readable, and refactor-friendly, I follow the query key factory approach.

Centralised factories make keys predictable and give great auto-completion:

// lib/query-keys.ts
export const bookingKeys = {
  all: ['bookings'] as const,
  detail: (id: string) => [...bookingKeys.all, id] as const,
  upcoming: (filters: { patientId?: string; page: number }) => [
    ...bookingKeys.all,
    'upcoming',
    filters,
  ] as const,
};

Then in components:

useQuery({
  queryKey: bookingKeys.detail(bookingId),
  queryFn: () => getBooking(bookingId),
});

The same factory file becomes the single source of truth for invalidations too. You can define an invalidation map and trigger queryClient.invalidateQueries() calls from one place:

// Same file or a companion invalidations.ts
export const invalidateOnBookingChange = (queryClient: QueryClient) => {
  queryClient.invalidateQueries({ queryKey: bookingKeys.all });
  // Or more granular:
  // queryClient.invalidateQueries({ queryKey: bookingKeys.upcoming(...) });
};

Having invalidations centralised means you can easily track and manage data freshness across different parts of the app (dashboard, lists, details pages) without hunting through components or mutations. One change here ripples everywhere consistently.

2. Server Actions / Server Functions

I almost never write traditional API routes anymore. Instead, I use whatever flavour of server actions / functions the framework provides:

These are still essentially API-like endpoints under the hood—they can be called directly (e.g., via fetch or form POST), so you must protect them with authentication, rate limiting, CSRF tokens (where applicable), and input validation just like any API.

The big wins come from less boilerplate and more purpose-driven code:

Direct function calls from client → no manual endpoint definitions
Automatic type safety between client and server
Easier error handling and revalidation
Colocated logic (form → action → DB → response)
Better integration with React's Suspense and transitions

It's not magic, it just removes ceremony while keeping security responsibilities intact.

3. Permission / Authorisation Management with CASL

Most apps end up needing fine-grained permissions. I centralise that logic with CASL.

Define abilities once (often user/session-based):

import { AbilityBuilder, createMongoAbility } from '@casl/ability';

export const defineAbilitiesFor = (user: User | null) => {
  const { can, cannot, build } = new AbilityBuilder(createMongoAbility);

  if (user?.role === 'admin') {
    can('manage', 'all');
  } else if (user) {
    can('read', 'Booking', { patientId: user.id });
    can('create', 'Booking');
    can('update', 'Booking', { patientId: user.id });
    cannot('delete', 'Booking'); // explicit deny example
  }

  return build();
};

Then use in services with simple conditionals:

class BookingService {
  static async updateBooking(user: User, bookingId: string, data: Partial<Booking>) {
    const ability = defineAbilitiesFor(user);

    const booking = await getBookingDetails(bookingId); // from queries
    if (!ability.can('update', booking)) {
      throw new Error('Not authorized to update this booking');
    }

    // Proceed with update...
    await updateBooking(bookingId, data);
  }
}

Or inline:

if (ability.can('read', subject('Booking', { ownerId: user.id }))) {
  // show sensitive data
}

Keeps permission logic declarative, testable, and out of business-flow code.

4. Lightweight Repository / Query pattern

I keep a queries/ folder with plain async functions that are pure DB statements and nothing else:

// queries/bookings.ts
export async function getBookingDetails(id: string): Promise<Booking | null> {
  // Drizzle/Prisma/etc. query only
  return db.select().from(bookings).where(eq(bookings.id, id)).limit(1);
}

export async function updateBooking(id: string, data: Partial<Booking>): Promise<void> {
  // Pure update, no side effects
  await db.update(bookings).set(data).where(eq(bookings.id, id));
}

Strict rules for these functions:

Only data access (i.e. SELECT, INSERT, UPDATE, DELETE)
No business logic
No authorisation checks
No emails, queues, external calls, or side effects
Reusable from any service

This thin Data Access Layer makes swapping ORMs trivial (change only queries/ files) and keeps services focused on orchestration.

5. Optimistic Initial Data in React Query

Pass SSR/SSG-fetched data as initialData to avoid loading flashes:

useQuery({
  queryKey: bookingKeys.upcoming({ page: 1 }),
  queryFn: () => actions.bookings.getUpcomingBookings({ page: 1 }),
  initialData: page === 1 ? initialUpcoming : undefined,
});

SSR is non-negotiable today. The era of plain Create React App SPAs is over. Even the React team officially deprecated CRA for new apps in early 2025 and recommends frameworks instead. Modern file-based routing frameworks (Next.js, Tanstack Start, Astro, etc.) all have SSR/SSG built in. Leveraging that initial data improves perceived performance, reduces layout shifts, and gives users something meaningful on first paint. Why throw it away?

6. Container / Presentational aka Smart / Dumb Components pattern

I still like this classic separation:

Presentational (dumb): only props, no hooks/state/fetching → pure UI, very easy to unit test and reason about
Container (smart): handles data, state, orchestration, passes props down

Example:

// Presentational – great for snapshot/visual testing
function BookingListView({ bookings, isLoading, page, totalPages, onPageChange }) {
  if (isLoading) return <Skeleton />;
  return (
    <>
      <ul>{bookings.map(b => <BookingItem key={b.id} booking={b} />)}</ul>
      <Pagination page={page} total={totalPages} onChange={onPageChange} />
    </>
  );
}

// Container
function BookingList() {
  const { bookings, isLoading, page, setPage, totalPages } = useBookings();
  return <BookingListView {...{ bookings, isLoading, page, totalPages, onPageChange: setPage }} />;
}

The dumb components become trivial to test in isolation, since it requires no mocking data layers or auth.

7. Custom Hook pattern

Any time you see a component growing fat with state + data fetching + pagination + error handling → extract it to a custom hook.

Before: 50+ lines of useQuery/useState/session logic inside the component.

After:

function PatientDashboard({ initialUpcoming, initialPast, initialNext }) {
  const {
    upcoming,
    past,
    nextAppointment,
    isLoadingUpcoming,
    upcomingPage,
    setUpcomingPage,
    // ...
  } = useDashboard({ initialUpcoming, initialPast, initialNext });

  return (
    <div className="space-y-8">
      <NextAppointmentCard booking={nextAppointment} isLoading={isLoadingNextAppointment} />
      <BookingList bookings={upcoming.data} page={upcomingPage} onPageChange={setUpcomingPage} />
      {/* ... */}
    </div>
  );
}

The rule: If you see useState, useEffect, useQuery (or similar) clustered together for one clear purpose → extract to a custom hook.

Components stay focused on rendering.

8. Strategy pattern (e.g. for third-party providers)

When you might switch providers (Zoom → Google Meet → others), hide the implementation behind a unified interface.

// services/meeting.ts
class MeetingService {
  static async createMeeting(input: CreateMeetingInput) {
    // strategy selected by config / env
    return activeMeetingProvider.create(input);
  }
}

Keeps services clean and future-proof.

Wrapping Up

These patterns show up in almost every project I work on now. Together they deliver:

Readable, well-organised code
Fewer weird logic bugs (everything has its place)
Lower maintenance cost (easier tests, fewer surprises)
Faster feature development (less time fighting structure)

And most importantly, when everything follows clear conventions (and you document them in a single ARCHITECTURE.md or similar) AI tools like Cursor or Copilot suddenly become much more accurate. They "get" the patterns right away and generate code that actually fits, without you prompting it 10 more times to put it all in the right folders, in the right format.

All the classic engineering benefits, without overcomplicating things.

I am an AI Engineer

Niki — Mon, 20 Oct 2025 20:14:41 +0000

Over the past year, I've completed five projects for medium and large established companies. Four were greenfield builds from scratch; the other involved integrating AI features into an existing platform.

I'm fundamentally a software engineer who's deeply curious about AI. I've gravitated here because it's fascinating.

That said, if you need to pin me on the AI spectrum, AI Engineer fits best. The field is still evolving, so titles are a bit of a mess. I mean, we're still debating software engineering titles after decades!

In this post, I thought I'd tell you more about what I actually do day-to-day and what I believe makes me an AI Engineer.

Why "AI Engineer"?

While looking for gigs, I’ve seen a LOT of job titles. They're like a startup's org chart - fluid and confusing. Here's some that I saw and what job descriptions and requirements they had:

Machine Learning Engineer: Heavy on deploying ML models at scale, often with a focus on production pipelines (e.g., using Kubernetes for model serving). It's more ops-intensive.
Data Scientist: This is a classic data role. They dive into data analysis, hypothesis testing, and storytelling with stats. They might build prototypes in Jupyter notebooks and prepare a presentation about findings, but they're not usually wiring it all into a full app.
Data Engineer: The pipeline maestro. They build ETL processes, manage data lakes on AWS S3 or GCP BigQuery, and ensure data flows cleanly.
Deep Learning Engineer: Specialised in neural nets, often researching architectures like transformers or GANs. Think tweaking layers in PyTorch for cutting-edge performance.
AI Solutions Architect: Basically a Solutions Architect (or DevOps?) that knows how to work with AI-specific tools. They design high-level systems, advise on cloud setups (e.g., Azure AI vs. Google Vertex), and align tech with business goals. Less coding, more diagramming and cloud infrastructure setup.
Research Engineer: Academia-adjacent, pushing boundaries with papers. They invent new algorithms, not integrate them into products.
Algorithm Engineer: I've seen this pop up too: focused on optimising core math, like efficient sorting for AI inference.

The AI space is still nascent, so overlap is huge, and for some roles the title and description were completely different from what I have here.

For me, AI Engineer screams hands-on builder. I'm not theorising in a lab or handling streams of petabytes of data, but rather I'm crafting end-to-end solutions that work in the real world.

What does an AI Engineer actually do?

At my core, I'm solving software engineering problems in an AI context. I take AI capabilities (like pre-trained models from Azure AI Foundry or OpenRouter) and make them work in production.

Here's a breakdown of my toolkit and typical tasks:

1. Model setup and tweaking

On every project I had to choose a foundation model (e.g., OpenAI GPT-5, XAI Grok-4, Gemini-2.5 from Google AI, or Google Vertex).

So far I never had to fine-tune a model for a production-ready project; most things were resolved via different prompting or extra context. I did fine-tune once in a hackathon we had at Sainsbury’s, and if I had to do it for a project, I would just use standard platform-provided tools.

For example, Azure has a guide on techniques, fine-tuning data formats, and tools it has to improve general LLMs. This would be my starting point.

Another important and frequent task I found myself doing is testing and experimenting with prompts, handling token limits, and just making sure it behaves more or less deterministically.

“Deterministic” as in “trying to control” or “predict” what the output will be so that we could prep our code/app/ui for this.

Counterintuitive? Yes. But that’s what a lot of companies want, that’s what I’ve seen the most amongst requirements.

2. Integration and infrastructure

LLM calls are just API calls to someone else’s infrastructure. These calls can’t exist on their own; you have to embed them into a framework.

Of course, some LLM- or AI agent-oriented frameworks have a built-in server, like LangGraph server, but not all, and quite often those are raw. I, personally, don’t like using those in production.

So what I did was set up either a FastAPI server, where I could add auth middleware, database integrations, custom routing, or just use existing Next.js or Astro API routes as a back-end to expose AI models or agents, and custom SSE or WebSockets setup to handle real-time responses in the front-end.

With that setup came lots of Docker containers. Lots and lots of Docker images… 😄

3. Frontend and user experience

Why would you do all this infrastructure if no one will be able to interact with it? So we’re putting on a front-end engineer hat and handle all those streaming chat responses token-by-token for that snappy feel with React and TypeScript.

Moreover, LLMs not only generate text but also images. And they accept images and docs. So I spent a lot of time debugging multimodal issues, figuring out why an LLM rejects an image, converting it to base64, and sending it correctly via REST API.

And then doing the same vice versa.

Also, lots of parsing and formatting tasks, because LLMs don’t like HTML. So if you scraped a page and want to feed it into an LLM, then you better convert it to markdown.

Same goes for tables. LLMs don’t understand tables. Transforming them to an LLM-appropriate markdown or JSON is what I did.

4. End-to-end problem solving

Just like any software project, there’s a lot more to handle end-to-end, like observability and monitoring with tools like Azure Insights, Sentry, LangSmith; ensuring low latency; adding guardrails and AI configs so that AI doesn’t say anything inappropriate; API rate limiting; error handling (do you send an error as a chat message or show a toast with an error message?); handling secrets (because we’re not inexperienced vibe coders who push secrets to public repos, are we?)…

Essentially, all of the classical software engineering, I’d say. Just with a bit of AI twist. 🤷

What I’m not touching

I'm not touching the "data territory" much. If you need me to:

Scour datasets, clean outliers with Pandas,
Train from scratch on SageMaker,
Evaluate with metrics like ROC-AUC or Weights & Biases dashboards,
Iterate on hyperparameters...

...I can do it (I know the theory from self-study and curiosity). But that's veering into Data Scientist/Engineer land, and if you’re not doing PoC you better find someone who’s better at this.

My sweet spot is software issues. Things like:

Debugging why a model inference fails in production.
Optimising API endpoints for 100ms response times.
Ensuring cross-browser compatibility for AI-generated content.
Scaling from prototype to handling 10k concurrent users.
Integrating with legacy systems (e.g., bridging AI outputs to a monolithic Java backend).

I’m a blue-collar worker of the AI World

In essence, as an AI Engineer, I'm the bridge between fancy AI models and real apps. I handle the coding, setup, and fixes to make everything work smoothly in production. From my five projects with different companies, I've learned this role is all about practical building, not data crunching or research.

No PhD needed. Just strong coding skills and a love for getting AI into users' hands.

Understanding the Agentic Commerce Protocol: your guide to selling on ChatGPT

Niki — Mon, 06 Oct 2025 09:13:12 +0000

The e-commerce world just got a major upgrade with the launch of ChatGPT’s Instant Checkout, powered by the Agentic Commerce Protocol (ACP). If you haven’t checked it out yet, go to agenticcommerce.dev to see what it is. As a software engineer with zero experience in ACP let me tell you how I understand it (in simple terms).

Because I know that starting tomorrow, companies will start posting job listings asking for “5+ years of ACP experience”. So, let’s figure out what it takes to get shops selling on ChatGPT.

The Easy Way In: Etsy and Shopify Merchants

If you run your shop on Etsy or Shopify, you’ve hit the jackpot. These platforms are already integrated with ChatGPT’s Instant Checkout. No extra coding, no fuss. Your products are automatically eligible to appear when users search for stuff like “large t-shirt under $40.” OpenAI has done the heavy lifting, so Etsy and Shopify merchants are live (or rolling out soon) with zero setup. Lucky you!

For Everyone Else: Here’s the Work

If you aren’t on Etsy or Shopify, integrating with ChatGPT requires some effort. Don’t worry - it’s manageable, especially if you’ve built e-commerce APIs before. The process boils down to four steps:

Registering
Pushing products
Setting up checkout endpoints
Capturing payments

Let’s walk through it.

Step 0: Register as a Merchant

First, you need to get your shop approved by OpenAI. Head to chatgpt.com/merchants and fill out the merchant application form. It’s straightforward - provide details about the business, primary product categories, and whether you’re setting up a product feed or checkout integration. OpenAI reviews submissions on a rolling basis (expect 1-2 weeks). This step ensures only vetted merchants join the ecosystem, keeping things secure and trustworthy.

Step 1: Push Products to ChatGPT’s Collection

Once approved, you need to make ChatGPT aware of your products. This isn’t a public web search. ChatGPT uses a curated registry of approved ACP implementers to ensure compliance, accuracy, and trust. You’ll provide a product feed in a structured JSON format, either via an endpoint (e.g., /products/feed) or a file, following OpenAI’s Product Feed Spec.

Here’s what goes in the feed:

Product details: ID, name, description, price, images.
Variants: Size, color, etc. (e.g., “large blue t-shirt”).
Availability: Stock status, shipping options.

You can update the feed every 15 minutes to reflect price changes or stock levels or whatever. Right now, product rankings are organic, based purely on relevance to the user’s query (e.g., “large t-shirt under $40”). No paid promotions yet, but I bet OpenAI will add that soon. Capitalism always finds a way!

Step 2: Set Up Checkout Endpoints with ACP

When a user finds a product in ChatGPT and clicks “Buy,” the magic happens through the Agentic Commerce Protocol. Think of ACP as a standardized API with predictable inputs and outputs that any AI agent (like ChatGPT) can understand. It’s like USB-C for commerce - universally agreed-upon formats that make life easier. My iPhone’s Lightning cable still drives me nuts in a USB-C world! But I digress.

Here’s how it works:

Initiate Checkout: ChatGPT sends a POST request to your /checkout_sessions endpoint to start the process. The payload includes buyer info (name, email, maybe address—ChatGPT often pre-fills this to speed things up), items, and shipping details.
Iterate and Update: As the user selects sizes, delivery options, or tweaks the cart, ChatGPT sends more requests to update the session (e.g., POST to /checkout_sessions/{id}).
Complete Purchase: When the user enters payment details (e.g., card or Apple Pay), ChatGPT sends a secure payment token to /checkout_sessions/{id}/complete. You create the order and process the payment.

These endpoints map to your client’s existing backend (e.g., inventory, tax calculations), so you’re just wrapping your current APIs in ACP’s format.

Step 3: Capture Payments and Orders

Payments are handled via your existing provider, with Stripe being the easiest (it supports ACP’s Shared Payment Token out of the box). ChatGPT passes a secure token (no raw card data, keeping it PCI-compliant), and you charge it using your usual payment flow. If you’re not on Stripe, you’ll need to align your provider with ACP’s Delegated Payments Spec. Fulfillment (shipping, returns) stays with your existing systems, and you update ChatGPT via webhooks (e.g., “order shipped”).

Why This Matters

ACP makes AI-driven commerce predictable and scalable. Unlike custom APIs that vary by platform, ACP’s standardized endpoints mean your shop can work with ChatGPT today and other AI agents tomorrow. It’s a win for developers like me who love consistency. Plus, you stay in control as the merchant of record, owning the customer relationship without ChatGPT getting in the way.

Getting Started

Here’s the plan if you already want to get your e-shop on ChatGPT:

Apply: Submit the merchant form at chatgpt.com/merchants.
Build Feed: Create a product feed endpoint or file with your client’s product data.
Add Endpoints: Implement ACP’s /checkout_sessions and related endpoints, mapping to your existing APIs.
Test and Launch: Use OpenAI’s sandbox to test, get certified, and go live.

This is just a generic overview guide. Didn't want to get into the weeds too much. But if you have any questions or want some assistance making this work for your shop - get in touch, I'll be happy to help. 🙌

From 60 to 25 hours: practical tips for effective AI-assisted development

Niki — Thu, 15 May 2025 21:06:31 +0000

TL;DR

Cut development time by 60% (from 60 to 25 hours) using AI tools effectively
Choose your tech stack yourself - don't let AI make these decisions
Set up your project structure manually - AI tends to use outdated packages and weird folder structures
Break down tasks into small, specific requests for AI - don't ask it to build entire features at once
Provide relevant documentation snippets to help AI understand framework-specific requirements
Keep context minimal - attach only relevant files, not entire codebases
Start fresh sessions for new features to avoid recurring patterns
Always refactor AI-generated code - it tends to be messy and needs cleanup
Try different AI models to find what works best for you (Claude, Gemini-2.5, etc.)

Bottom line: Use AI to handle tedious tasks while maintaining control over architecture and design decisions

I was doing one of the projects, I was using Copilot and I noticed that I finished this project way faster than I ever finished a similar project in the past. 25 vs 60 hours. AMAZING, no?! 🔥

I was like turbo-charged! I was able to do code as fast as my ADHD mind was thinking about different aspects of it: layout, styling, state management, comms with back-end API, DB schema and relationships, error handling…

All of this I was able to keep in my head AND be productive! Which is usually not the case, and I end up with a bunch of TODO comments and no code (at first).

And then refactoring all that multiple times using a different design pattern!

So this blog post is an instruction on how to make yourself productive with AI copilot/cursor/whatever, instead of fighting with LLM, swearing at it and rejecting all of its work.

You don't need AI to select the stack

Maybe a little bit of DeepSearch.

When starting you should already know what tech stack and patterns you're going to use.

The only reasons you should use AI at the start of the project if you wanna compare frameworks for your particular use case, e.g. zustand vs jotai.

In my case I knew I had to use Astro, because it was a front-end project with only some back-end required. It was perfect.

This was a "live app", i.e. all users needed to be notified of the changes, so obviously I had to use WebSockets for that.

And then data was of predictable shape, had lots of relationships, so it meant SQL, and PostgreSQL in particular. LOVE it! I'm even subscribed to Postgres Weekly! 🐘

I also wanted Drizzle ORM to manage all the migrations and CRUD operations.

I knew that multiple components in React would need to interact with the same state, so I went with effector. It's my favourite because of the sample , you can do some crazy logic with it, e.g.

sample({
    // Watch for submitForm event, when it gets triggered ...
  clock: submitForm,
  // ... take the $userName store's state ...
  source: $userName
  // ... and transform the state (`name`) AND the parameters from the submitForm function (`password`)
  // into parameters that signInFx would accept...
  fn: (name, password) => ({ name, password }),
  // ... and then call the function with signInFx({ name, password })
  target: signInFx,
});

Isn't that awesome?! AND it all lives outside of your UI logic. SO clean!

I could've also gone with nanostores, that Astro is promoting.

And, obviously, shadcn for UI components. Is there any other option?

Ok, I like HeroUI as well.

The rest feel raw or just weird.

To sum up:

Don't let AI choose your tech stack for you.

Init the project

Don't ask AI to do it. It's just gonna do the shit job, use outdated packages, and setup weird-ass folder structure.

Set it up yourself. The way YOU like. The way YOU are used to work.

So I did. Just followed the Astro setup on shadcn basically

npx create-astro@latest astro-app  --template with-tailwindcss --install --add react --git

I needed a dashboard. So I just took blocks from shadcn and adjusted items to just the ones I need.

No AI. You're gonna spend more time explaining AI what you want.

Same with things like Dockerfile . There are templates, you can just copy and tweak it. Do it yourself, it's quicker.

Release the Kraken AI!

Once you have the setup ready, it's time to outsource some work.

The only way I felt productive and content with what AI was giving me, is when I described step by step how I'd do it myself.

So for the form I went

Create a AddItem form React component using Tanstack Form.
It should have 3 inputs: customer (text, required), order number (text, required), vehicle (select field with Van and Truck as options, required)
It should have 2 buttons add (submit) and reset (nullify all the values in all the fields).
onSubmit create a function with empty body. We'll implement it later.

Keep it short

Notice how I didn't let it go further. If I didn't it might've went ahead and created some weird function, and an /api/form route, it would've made all decisions for me.

And I didn't want it to. I wanted it to make it the way I think is right.

So that's one of the key secrets to make AI productive.

Stop Copilot from going. Don't ask it to do the entire project. Just ask it do a component.

Then an endpoint. Then a util function. Then ask it to put it all together. AI is like children. Asking it too many things at once, will make it ignore your important details that you gave it.

It's never OpenAI

For programming, I noticed, I never use any models released by OpenAI.

It's always Claude, either Sonnet 3.5 or 3.7 or, now, Gemini-2.5.

Gemini-2.5 is actually considered the best as of today.

Although GPT-4.1, they said, should be good at coding. And vibing…? Or is that GPT-4.5?

Anyway, switch some models up, see which ones vibe the best with you.

It's all about vibes these days, isn't it?

Help it see what you see

I've noticed that Cursor is doing web search. But Copilot isn't yet. So the model will not know everything, especially if it's new or rarely used.

Like Astro. All models are really shit at Astro. Try asking it create an action with a certain input and output. Any one of them is gonna do such a shit job, that you'd start doubting the rest of its abilities.

Insert snippets from Get Started or Example pages from the docs. This context would really help AI in generating the code that you have in your head and not a random shit from the internet.

Or you can setup MCP for yourself that would do the docs search for you, e.g.

I haven't done that for myself yet tho.

Don't overdo the context

You know how most (?) AI code editors let you attach files for context? This is an awesome feature!

They also let you attach code bases. This is dumb.

Remember, LLMs are like children: you give them too much, they'll forget most of it, you'll get garbage.

Attach only the relevant files for the ask.

Don't let it see all of it. In fact...

Close the session once you done the feature/ask. Let it start over.

That way you don't get it stuck in a recurring shit-generating pattern. Let it be a gold fish with a memory limited to a feature.

Refactor

Once the feature is done, you won't be able to look at it, it's gonna be heinous.

ABR - Always Be Refactoring.

The generated code will be all over the place, it's gonna have weird if/else logic, triple and quadruple ternary operators, repeated code… Complete unreadable mess!

So you need to go through it with a fresh eye, move some functions out, change the logic… Refactor!

Notice your wins

If you don't notice any significant wins when working with AI help, then you're either a) been working with AI for ages now and used to it (not the case today, I'd say) or b) it didn't work for you, fix it.

For me I noticed these wins:

I switched from React provider pattern (I forgot I was using Astro) to state management in "vanilla JS" way in under 2 mins;
I quickly scaffolded a gigantic switch statement for handling events for WebSockets on the server and associated actions it needs to take, e.g. call to DB, filter and map things out, handle errors, etc.;
I created effector stores and events and connected all of them in multiple samples in under 5 mins with minor refactors, a thing I was always dreading to do even considering my admiration for sample ;
I went from using react-use-websocket hook, to using socket.io after realising that islands architecture wouldn't work with the hook, to native implementation of WebSockets, after learning that socket.io has a compatibility issue with my server;
I scaffolded (and later refactored into a decent code) forms with validation and styling with a UI and form libraries of my choice in 5 mins. And I hate doing forms. This is the best win of all.
I then refactored, cleaned and made all of my components, util functions, API endpoints, etc. small, testable, humanly readable, and DRY in less than 10 mins.

Most important win is, I didn't lose myself, the coder, the programmer that likes to write code, create and make shit work.

I just outsourced the annoying and tedious bits that made my job soulless and energy draining.

That's what AI is good for.

Creating a simple RAG in python with AzureOpenAI and LlamaIndex

Niki — Thu, 24 Oct 2024 12:33:53 +0000

During a recent stream, I explored the process of ingesting a PDF using LlamaIndex and AzureOpenAI. This blog post will guide you through the steps to accomplish this task.

The objective was straightforward: answer questions based on information contained in PDF files stored in a folder. Here's the process we'll follow:

Embed the PDF data: Convert PDFs into a format comprehensible for AI
Initialise AzureOpenAI and provide it with the embedded data
Ask a question and analyse the response

While the LlamaIndex documentation provides an excellent guide, I've included some visual aids to enhance clarity.

Setting Up the Environment

First, let's install the necessary packages:

pip install dotenv llama-index llama-index-llms-azure-openai llama-index-embeddings-azure-openai

Note that AzureOpenAI is not included in the llama-index package and must be installed separately.

Configuring AzureOpenAI

Navigate to Azure AI Studio and deploy your chosen model.

Once deployed, configure LlamaIndex to use it with the following settings:

Settings.llm = AzureOpenAI(
    engine="gpt-4o-mini",
    api_key=os.environ.get('AZURE_OPENAI_API_KEY'),
    azure_endpoint=os.environ.get('AZURE_OPENAI_ENDPOINT'),
    api_version="2024-05-01-preview",
)

BUT.

Azure openAI resources unfortunately differ from standard openAI resources as you can't generate embeddings unless you use an embedding model.

This means that we need a separate embedding model for generating embeddings. Let’s do that.

Deploy an embedding model that starts with text-embedding-*, since in this case we're working exclusively with text.

Configure LlamaIndex to use the embedding model:

Settings.embed_model = AzureOpenAIEmbedding(
    model="text-embedding-3-small",
    deployment_name="text-embedding-3-small",
    api_key=os.environ.get('AZURE_OPENAI_API_KEY'),
    azure_endpoint=os.environ.get('AZURE_OPENAI_EMBEDDING_ENDPOINT'),
    api_version='2023-05-15',
)

Implementing the RAG System

With the setup complete, let's load PDFs into the data folder and query the model:

def main():
    documents = SimpleDirectoryReader("data").load_data()
    index = VectorStoreIndex.from_documents(documents)
    query_engine = index.as_query_engine()
    response = query_engine.query("Can we advertise online gambling to under 18 year olds?")
    print(response)

To run the script in our virtual environment:

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python ./src/main.py

And we get a response of

No, advertising online gambling to under 18 year olds is not permitted. Marketing communications must not exploit the vulnerabilities of this age group, and any advertisements that feature under-18s or are directed at them are likely to be considered irresponsible and in breach of established rules.

Future Improvements

We can make it better by embedding the data once and storing it in a database like Azure CosmosDB, which is a MongoDB at its core. This means we get rid of repetitive embedding overhead every time we run the script, allowing the LLM to access pre-embedded data directly from the database. I'll cover this in my future posts.

And here is the repo with this and any future code.

How I cut the deployment time of an Astro (Node.js) site on Azure from 1 hour to ~3 mins

Niki — Mon, 23 Sep 2024 13:54:04 +0000

Before:

After:

The way Azure sets it up for you when you go through the steps of deploying a new Azure Web App service is objectively horrible. This is what Azure pushes to your repo:

# Docs for the Azure Web Apps Deploy action: https://github.com/Azure/webapps-deploy
# More GitHub Actions for Azure: https://github.com/Azure/actions

name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js version
        uses: actions/setup-node@v3
        with:
          node-version: "20.x"

      - uses: pnpm/action-setup@v4
        with:
          version: 9

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present

      - name: Zip artifact for deployment
        run: zip release.zip ./* -r

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v4
        with:
          name: node-app
          path: release.zip

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: "Production"
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    permissions:
      id-token: write #This is required for requesting the JWT

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v4
        with:
          name: node-app

      - name: Unzip artifact for deployment
        run: unzip release.zip

      - name: Login to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZUREAPPSERVICE_CLIENTID }}
          tenant-id: ${{ secrets.AZUREAPPSERVICE_TENANTID }}
          subscription-id: ${{ secrets.AZUREAPPSERVICE_SUBSCRIPTIONID }}

      - name: "Deploy to Azure Web App"
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v3
        with:
          app-name: "app-name"
          slot-name: "Production"
          package: .

So what’s happening here is that we

Build the project in GitHub actions
Zip it
Send it to Azure
Unzip it
Run it

The problem is that we’re zipping it together with node_modules folder. So sending it and unzipping it takes a LOT of time. 🤯

I’m not sure why they recommend it this way, but after reading a bunch of poorly worded and outdated Azure guides and some short StackOverflow posts, I’ve figured out the way a Node.js app should be deployed.

Essentially we need to only send the code from GitHub to Azure and build right there. For that you don’t need to do any post-install scripts or anything, Azure App Service does it for you, here are the steps that it goes through as soon as the code reaches the service.

But it doesn’t do that by default, so you need to enable it. You do that by setting the environment variable SCM_DO_BUILD_DURING_DEPLOYMENT to true in Settings > Environment variables in Azure Portal.

Once we’ve done that, we now need to remove the build step from our GitHub Actions workflow and we’re done. Here is how the template looks like now. 👇

# Docs for the Azure Web Apps Deploy action: https://github.com/Azure/webapps-deploy
# More GitHub Actions for Azure: https://github.com/Azure/actions

name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  prepare:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - uses: actions/checkout@v4

      - name: Zip artifact for deployment
        run: zip release.zip ./* -r

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v4
        with:
          name: node-app
          path: release.zip

  deploy:
    runs-on: ubuntu-latest
    needs: prepare
    environment:
      name: "Production"
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    permissions:
      id-token: write #This is required for requesting the JWT

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v4
        with:
          name: node-app

      - name: Unzip artifact for deployment
        run: unzip release.zip

      - name: Login to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZUREAPPSERVICE_CLIENTID }}
          tenant-id: ${{ secrets.AZUREAPPSERVICE_TENANTID }}
          subscription-id: ${{ secrets.AZUREAPPSERVICE_SUBSCRIPTIONID }}

      - name: "Deploy to Azure Web App"
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v3
        with:
          app-name: "web-app"
          slot-name: "Production"
          package: .

There are also a few “gotchas” I’ve noticed when deploying to Azure Web App service:

Forget yarn or pnpm. npm only. There is no way you can get those into App Service environment. And if there is, I really don’t think it’s worth the effort. Azure is using Kudu so you better know its ins and outs, I feel like, if you decide to install additional packages there.
HOST=0.0.0.0 PORT=8080 before your start script, which in my (Astro) case was node ./dist/server/entry.mjs . You can’t pick the port. I tried. Didn’t work.
Node version 20.14 is what it’s currently running in Azure as of the moment of writing this post. It was hard to find, they don’t print it in the dropdown when you select the environment when deploying the App Service. I got a few errors because the Node version wasn’t what my app was expecting 🤷‍♂️

And most important tip: upgrade your service to paid. The whole build and deploy process is unbearably slow on a free plan. But, frankly, that’s not an Azure specific issue, that’s most of PaaS nowadays, isn’t it?

Hope that helps! 😎

Astro.js as an alternative to Next.js: pushing the limits

Niki — Wed, 17 Apr 2024 10:02:29 +0000

I’m tired of Next. I want to try something fresh. So I thought this was the time I look into other frameworks. Where would I go? Nuxt? Remix? Nah…

Astro! Let’s test it and see if it can handle modern project requirements.

Here is the repo, follow along!

Why am I doing this?

Next.js is complicated. But some of the best websites out there use a plain, vanilla JS. We don’t need anything fancy to build great products. I mean, we could use a bit of help from a simple (!!) framework that gets out of your way and lets you deliver. And I want to find that framework.
Next.js v13 was a ~~shit~~ shift. In v13 Next.js introduced a mentality shift with RSC on how we develop an app, and since I have to shift my mentality, I’d like to shift it in all possible directions. Open my mind a little bit more than I have to.
Vercel is not your friend. And Next.js is THEIR product. Sooner or later I feel like we’ll be shifting our mentality to adjust to how Vercel wants us to do things. I don’t wish to be locked in like that.
I’m just tired of Next.js. Every company makes me work with Next.js. Always Next. I don’t really mind, but I miss those times when I was talking about Next as a “new framework” that we “should look into adopting”! I and others like me did a very good job. Well done, folks! But now I want to mix things up a bit, time to try something fresh! Again! 😅

So I guess you could say that Next.js is the reason I’m looking into Astro. 😁

Enter Astro.js

I’ve been ignoring it like I do with Remix and Svelte and a bunch of other frameworks. However, I’ve learned that Astro is different, and I’m gonna talk about how it’s different later in the post.

First, I needed to define a set of criteria with which I could judge its usefulness. How do I identify whether I should choose it (or recommend it) for a new project?

So I started thinking and reflecting on all the companies and all the projects I ever I worked with. What was I doing there? What requirements they had in common? What kind of work they were assigning to me?

And so I defined a list of such things, things that I was doing on EVERY job or contract. This is what everyone wanted me to do from tiny startups to humongous enterprises.

Has React & TypeScript: because I’ve rarely seen a company that wants Vue or plain JavaScript. Everyone wants React and it has to be with TypeScript.
Static pages: Fetch content from headless CMS at build time, create the HTML page and host it somewhere on a simple host.
Global state management shared between components without prop drilling: Because there’s always at least a menu of some sort that you need to control from 3 different places.
Custom theme (global): everyone has its own colours, fonts, etc. No hardcoding and repeating/copy+pasting those HEX values all over the CSS files!
Scoped CSS (e.g. .module.css): no one wants to load ALL of the CSS for every page and then use 1/100th of it.
SSR rendered content that needs to be changed or updated from the client (e.g. using @tanstack/query), e.g. you know that sidebar with filters on a page that lists a couple of dozens of products?
User Authentication with multiple hidden pages: we don’t want to need to auth the user only on the client side. Let’s redirect the user on the server, i.e. BEFORE they get to the protected page.
Localisation and internationalisation: I’ve done a bunch of projects that needed two or more languages. I’m doing one now that requires more than eight languages and more than ten geos/territories!
Embedding Google Analytics and other tracking tools: because if it’s a client-facing site we gots to know about our visitors, right?
Design System in a Storybook: every company I joined (and I do mean EVERY) wanted their React components displayed neatly in a Storybook for all kinds of stakeholders to see/play with.
Testing, incl. unit, integration and visual (i.e. snapshot testing).
Server API function (or action) where secret keys can be used.
Incremental Static Regeneration (ISR), for cases when we have hundreds or even thousands of pages.
Deploy to a custom Docker-based environment somewhere to AWS Fargate, because not every company out there wants to use Vercel, Railway, and other “cool” and “hip” platforms.

So I did this silly “Frankenstein” project with those requirements. Let’s talk about the results!

Findings

Astro is EXPLICIT

The main conclusion that I got out of it is that Astro.js is like putting your project on a diet. On a JavaScript diet.

The thing about Astro is that it promotes the ****“reduced JavaScript” approach. That’s a whole other kind of mentality shift than what I initially was hoping for.

So it doesn’t render JavaScript unless you EXPLICITLY tell it to.

“Explicit” is the word I’d associate with Astro. While Next hides a lot of implementation details, Astro does nothing of such a thing and leaves implementation to us, developers.

If you want some interactivity with JavaScript on the front-end - you need to write it, e.g. addListeners in the script tags. Otherwise, Astro ships nothing to the browser.

Before I wasn’t really thinking explicitly much about how much JavaScript is and isn’t used in the browser. Most of the time, I just let frameworks figure this out for me, and only when we were starting to have issues with performance, etc. only then I start looking “under the hood” and optimising.

All in all, I’m happy with this approach. I kinda like it. Cognitively it feels easier to work this way.

This leads to the next point.

React is just a sprinkle on top

Astro allows you to use ALL sorts of UI frameworks. Including React. BUT!

React is a UI library. And Astro is using it as such. RSC is not a thing there (yet?). So if you’re writing a .tsx/ .jsx file, you can be 100% sure it’s going to be rendered, live and work only in the browser.

Yes, you can certainly feed it server-fetched data, so the user doesn’t see the loader for too long. But it still remains a client only component.

For that reason, you can’t really use React ONLY or go too deep component-wise. They’re all end up on the client.

Do you want that? Is that a good thing? It depends on the project.

If you need to render things on the server first, say, for SEO reasons, and make it interactive, then I’d assume you’d need to have a conditional variable, e.g.

const hasBeenChangedByUser = false

return {hasBeenChangedByUser ? <ReactComponent /> : <AstroComponent /> }

And both <AstroComponent /> and <ReactComponent />, in this case, would look very similar. You could do a sharable code though, because Astro still allows rendering .tsx component on the server, it just strips them of all the JavaScript, making them redundant for React purpose but great for layout, etc.

In my experience, there weren’t many cases when we’d had to create something drastic like that, rather a healthy balance of server vs client. So this “React == UI only” approach doesn’t really bother me. I can render what I need on the server inside .astro component, and components that need to be overly interactive, they’re client in any framework anyway, because interactivity == JavaScript.

No providers!

With Astro, we have two types of files: .astro and .tsx. Guess what .astro components can’t have that React just LOVES?

Providers!

Here’s another mentality shift for you. If you were thinking in a providers pattern, you need to snap out of it. You can no longer store your theme in a provider. No more RadixUI or MantineUI for you.

So to have a theme and reusable CSS variables you’d need to go with how Tailwind works. Tailwind doesn’t use providers. It stores all the variables in it’s own config file.

Something like NextUI would work, i.e. a “New Gen” UI framework. It’s Tailwind based AND it works in both .astro and .tsx files. Amazing!

To be frank, my last 4 projects were Tailwind-based. So I don’t see a problem with that. I can live with that choice.

Guess WHAT also generally uses providers?

State managers!

The time has come for the new kind of state managers

We want to store state across Astro and React components. One state, two frameworks. How do you do that?

Framework agnostic state managers!

In its docs, Astro recommends nanostores, but I’ve used effector in the past. And LOVED IT. So I’ve used it for this project as well.

State managers like these are just JavaScript. They don’t care what frameworks they’re used with. They do have wrappers for them, e.g.

import { useUnit } from "effector-react";
// ...
const { text, size } = useUnit({
  text: $text,
  size: $size,
});

but you can do without them.

Have you noticed that in v5 @tanstack/query moved on from using provider pattern for their QueryClient, e.g.

import { QueryClient, QueryClientProvider } from "react-query";

const queryClient = new QueryClient();

function App() {
  return <QueryClientProvider client={queryClient}>...</QueryClientProvider>;
}

to a more function-based approach, e.g.

import { QueryClient, useQuery } from '@tanstack/react-query'

const queryClient = new QueryClient()

function App() {
    const query = useQuery({ ... }, queryClient)
  //...
}

There’s a reason for that, I think. It’s more flexible, more universal, doesn’t lock you into a particular framework. You can fetch data on the server in .astro component, store it in your queryClient and then use it in a React component on the client with useQuery.

Switch React to Vue and you won’t need to touch the state in any way. Amazing refactoring experience, isn’t it? 🤯

Following the providers rant…

i18n

Since there are no providers, we need to somehow communicate the language we’re working with to every component when setting up our localisation. So we do it this way 👇

// In Astro component
---
const lang = getLangFromUrl(Astro.url);
---
return <Modal client:only="react" lang={lang} />

// Then in Modal.tsx
export const Modal = ({ lang }) => {
    const t = useTranslations(lang);

    return (
        <ModalHeader>
           {t("modal.header")}
        </ModalHeader>
    )
}

So the language won’t be coming from a provider, but rather as a prop. And we’ll be getting it from our server .astro pages.

Which, again, to me isn’t a big deal. It’s just different. It works and it still looks nice. We can even define a “parent” interface that we’ll be using for all the prop types, e.g.

interface PropsBase {
    lang: string
}

interface ComponentProp extends PropsBase {
    //...
}

Astro is just like Next but more explicit

I keep coming back to that word.

In a lot of other aspects, Astro is not that different from Next developer experience and mentality-wise. I didn’t even feel pain when switching. I already knew where things would go, where things would come from, how to structure a project, etc.

Astro has its own place for getServerSideProps (or use server); it has an api folder you can create to store some serverless functions in; it runs in node and you can build a Dockerfile for it. and you can throw all your Google Analytics scripts to PARTYTOWN, just like you’d do in Next.

And if you need to set up SSR authentication, you can do that, it’s pretty straightforward. I was able to set up one with Supabase Auth.

So it’s just like Next, but better.

Just a few ‘gotchas’ though…

The “gotchas”

Astro has no runtime. This means no unit tests. This also means no Storybook for your Astro components (although, they’re working on it!)

Can you live with that?

I’d say yes. When it comes to testing, server-rendered components don’t have much interactivity going on anyway, no user clicks, no state changes, etc. So tests might be considered redundant or over-engineer.

And the layout render we can always test in e2e/integration/visual kinds of tests with Cypress or PlayWright.

As for Storybook, well, not everything needs to be in a Storybook. Surely we can find a nice balance.

Astro needs more work

At the moment ISR comes down to cache control/invalidation in SSR pages, not static page regeneration.

There is no per-page building, no ISR. If you rebuild static pages, you rebuild all of them.

The build is fast though, as it was pointed out, Astro certainly can handle 10K+ pages.

Nonetheless, the Astro team is already thinking and working on the build engine. So it will only become better.

Not even more confusing as it was in Next.js case, I hope… 😅

To sum up

Astro is great. But it is slightly different from the way Next.js projects are done and not everyone would be happy to compromise. And that’s ok. We all have our own set of requirements, values, goals, the environment we work in, etc.

However, I think Astro is the future. And I don’t mean Astro framework. I think the Astro way of doing things: explicit, transparent, and minimalistic. This is the future where all the frameworks work as one, and where frameworks don’t overwrite standardised APIs and expose important bits to the developers allowing us to modify and hack it to each project’s own needs.

The future is simple, vanilla JavaScript because simplicity always wins. 🚀

For more talking and less reading, feel free to watch my stream.

Creating an autogrowing textarea with React and Typescript

Niki — Thu, 28 Dec 2023 13:57:58 +0000

In my 6 years career I almost never had to make an autogrowing textarea field like the ones we have in Jira or Linear (i.e. description fields) 👇

But recently, I had to make one. While there are already some posts about this, e.g. THIS post by Owen, I thought I'd post my solution, which covers a slightly different scenario.

So basically, I create a hook

export const useInputHeight = (name: string, value: string | undefined) => {
  const setInputHeight = useCallback(() => {
    const textarea: HTMLTextAreaElement | null = document.querySelector(name);
    if (!textarea) return;
    textarea.style.height = textarea.scrollHeight + "px";
  }, [name]);

  useEffect(() => {
    setInputHeight();
  }, [value, setInputHeight]);

  return setInputHeight;
};

It returns a setInputHeight function that we call in our onChange function.

const setNameInputHeight = useInputHeight('textarea[name="email"]', emailValue);
// ...
const handleInputChange = (e: React.ChangeEvent<HTMLTextAreaElement>) => {
  setInputHeight();
  // ... other functionality
};

Do you need a value argument? No, you don't, but in my case, the value was being updated on the client, so I had to adjust the field height every time it updated without me triggering the onChange event.

If that's not the case, simplify it to be

export const useInputHeight = (name: string) => {
  const setInputHeight = () => {
    const textarea: HTMLTextAreaElement | null = document.querySelector(name);
    if (!textarea) return;
    textarea.style.height = textarea.scrollHeight + "px";
  };

  return setInputHeight;
};

That's all you'd need.

You may have also noticed that I'm not using useRef() and simply doing document.querySelector.

Would ref work? Yes, yes it should. The only reason I was using querySelector was because I was using a UI library and textarea there wasn't allowing a ref prop. So I didn't want to do all those workarounds, querySelector seemed like a great option.

Do feel free to use a ref if you'd like, after all, it IS a more 'React way' of doing things 😁👍

Storybook 7.0 + React.js + TailwindCSS + CSS modules + Typescript setup that #$%& works

Niki — Mon, 20 Feb 2023 22:48:18 +0000

UPDATE: when writing this I have found THIS article, that, coincidentally, was also updated around the same time.

<rant>

Setting up a storybook project should NOT be THAT hard. I mean, everyone uses Storybook, it’s the only viable option out there when working on a design system.

TailwindCSS is at the stage when it’s already gained the momentum. Even large companies are considering it. Practically EVERY front-end dev has already worked with it.

And CSS modules have beed out there for more that 6 years I believe. And even though in JavaScript terms it’s a dinosaur, a legacy, it’s very much not dead and still a top choice for many, including moi.

Not even going to say anything about Typescript and React. If you’re not using TS or never worked with TS today - you’re unemployable. And React is a standard.

Surely there should be an article somewhere on how to set all this up correctly. SURELY?!

</rant>

Well, after 4 hours of googling and trial and error, I finally was able to crack this “OH SO UNUSUAL” tech stack setup. Here is the repo, and let me highlight two points.

Point 1: Webpack 5 builder and framework

Webpack 4 is still the default choice for Storybook, but Storybook has already released support for Webpack 5, so I see no reason why we’d stick to v4. Important note here is that since we’re updating the core property, we should also update the framework

// main.ts
export default {
  framework: '@storybook/react-webpack5',
  core: {
    builder: '@storybook/builder-webpack5',
  },
}

Point 2: Don’t overwrite default Webpack rules, but add more instead

It (unfortunately!) became a habit for whatever reason, that if I need to add some custom loader, I exclude the default rule from the array and re-create it. We shouldn’t do that, because it messes up the Storybook config in a way that it becomes hard to unfuck it.

Because we need to add a PostCSS loader to our .css files, don’t try to re-create css rule with all the css-loader and style-loader etc., but just push that extra rule to the end of that array, and be done with it.

// main.ts
export default {
  ...
  webpackFinal: async config => {
    config.module.rules.push({
      test: /\.css$/,
      use: [
        {
          loader: 'postcss-loader',
          options: {
            postcssOptions: {
              plugins: { tailwindcss: {}, autoprefixer: {} },
            },
          },
        },
      ],
      include: path.resolve(__dirname, '../'),
    })
    return config
  },
  ...
}

That’s pretty much all I wanted to say. Those two points took me a while to understand, so hope your found my post within your first hour of searching. 😅