DEV Community: Exact Solution

LLM API Costs Are Eating Small Business Margins — Here's What We Did About It

Exact Solution — Wed, 24 Jun 2026 13:41:42 +0000

We are not a software company. We sell refurbished laptops and iPhones.But we run software. A lot of it. And over eighteen months of integrating LLM APIs into our operations — product description generation, customer query routing, inventory grading assistance, return reason classification — we went from "this is affordable" to "this is genuinely threatening our margins."Here is the honest breakdown of what happened, what we found when we actually looked at the numbers, and the three changes that brought our monthly LLM spend down by 71% without meaningfully degrading quality.

How We Got Into This Situation

It started with product descriptions. We list hundreds of refurbished devices. Writing accurate, specific, SEO-optimised descriptions for each one manually is expensive in time. We built a pipeline that takes device specs, condition grade, and battery health and generates listing copy. It worked well. We expanded it.

Then we added a customer query classifier. Then a return reason analyser. Then a draft email responder for common support tickets. Each addition felt incremental. Each one made sense in isolation.

Six months later our monthly LLM API spend had grown from £180 to £1,340.
For a physical products business operating on 30–35% gross margins, £1,340/month in API costs is not a rounding error. It is a meaningful percentage of margin on a significant portion of our monthly revenue. We had not modelled it that way when we built each feature. We had modelled each feature in isolation.

The Audit — What We Actually Found

LLM API pricing varies by more than 600x across major providers — from $0.05 to $30 per million input tokens depending on model and provider. We had not been paying attention to where in that range we were sitting.

When we audited our usage properly, we found three problems:

Problem 1 — We were using flagship models for tasks that didn't need them.

Our product description pipeline was running on GPT-4o. At the time that was $2.50 per million input tokens and $10 per million output tokens. We were generating descriptions for devices with specs that fit neatly into a structured template. The task required consistent formatting and accurate spec integration — not sophisticated reasoning. A flagship model was complete overkill.

Problem 2 — Our system prompts were enormous and we were paying for them on every call.

Our product description system prompt was 2,400 tokens long. It included detailed formatting instructions, brand voice guidelines, SEO principles, and example outputs for every device category. We were paying to send those 2,400 tokens on every single API call — hundreds of times per day. We had never implemented prompt caching.

Every major provider now offers prompt caching where frequently reused system prompts are stored server-side and charged at a fraction of the normal input rate — OpenAI offers 90% savings on cached reads, Anthropic charges just 10% of base input price for cache hits. WPS Office
We were paying full price for the same 2,400 tokens hundreds of times daily. That was fixable in an afternoon.

Problem 3 — We had no routing logic. Everything went to the same model.
Customer support query classification — figuring out whether an incoming message was a return request, a shipping query, a product question, or something else — was running on the same flagship model as our most complex tasks. Classification is a simple task. It does not require a model that costs $10 per million output tokens.

The Three Fixes

Fix 1 — Model tiering based on task complexity

A typical enterprise distribution routes 70% of queries to a budget model, 20% to a mid-tier model, and 10% to a premium model — this tiered approach reduces average per-query cost by 60–80% compared to routing all traffic through a single premium model. Laptop Mag
We categorised every LLM task in our stack by complexity:.

`TASK_ROUTING = {
# Simple classification, templated output
"query_classifier": "gpt-4.1-nano", # $0.10/$0.40 per MTok
"return_reason_classifier": "gpt-4.1-nano",
"email_category": "gpt-4.1-nano",

# Structured generation with moderate complexity
"product_description": "gpt-4.1-mini",   # $0.40/$1.60 per MTok
"condition_summary": "gpt-4.1-mini",

# Complex reasoning, customer-facing quality required
"support_draft": "gpt-4.1",              # $5/$15 per MTok
"dispute_analysis": "gpt-4.1",

The classification tasks — our highest volume workload — moved from $10/MTok output to $0.40/MTok output. A 96% cost reduction on those calls.

Fix 2 — Implement prompt caching properly

For OpenAI this required structuring prompts so static content appears first:

messages = [ { "role": "system", "content": STATIC_SYSTEM_PROMPT # 2,400 tokens — cached after first call }, { "role": "user", "content": f"Generate description for: {device_specs}" # Variable per call } ]

For Anthropic's API, explicit cache control headers are required:

messages = [ { "role": "user", "content": [ { "type": "text", "text": STATIC_SYSTEM_PROMPT, "cache_control": {"type": "ephemeral"} }, { "type": "text", "text": f"Generate description for: {device_specs}" } ] } ]

After implementing caching, the cost of our static system prompt dropped from full input token pricing to 10% of that — on every subsequent call. On our description pipeline running 300+ calls per day, this change alone reduced monthly spend by approximately £280.

Fix 3 — Batch processing for non-latency-sensitive workloads

Not every LLM task needs to return in real time. Our return reason classification runs on submitted return requests — not on the customer-facing interface. A 30-minute processing delay is completely acceptable.
Batch API offers 50% discount on all models at both OpenAI and Anthropic for non-latency-sensitive workloads.

We moved return reason classification, condition summary generation, and overnight inventory description updates to batch processing. Half price on all of them.

# Instead of real-time API calls for return classification: client.batches.create( input_file_id=batch_file_id, endpoint="/v1/chat/completions", completion_window="24h", metadata={"job_type": "return_classification"} )

The Numbers After Three Changes

Support email drafts showed the smallest saving because those genuinely require a higher-quality model — the output is customer-facing and quality matters. We kept that on GPT-4.1 and accepted the cost. The other three workloads moved without any meaningful quality degradation.

What I'd Have Done Differently From The Start

Build a cost model before shipping each LLM feature. Not a rough estimate — an actual calculation based on expected call volume, token counts, and the model you're planning to use. We treated LLM costs the way early cloud adopters treated compute costs — as something to worry about later. Later arrived.

Default to the cheapest model that can do the job. Start with the budget tier and work up to a more capable model only if the output quality is genuinely insufficient. We did the opposite — defaulted to the flagship and optimised down only when the bill arrived.

Implement caching from day one. There is no reason not to. For applications with consistent system prompts, prompt caching can reduce input costs by 70–90% on the cached portion. It takes an afternoon to implement and the savings are permanent. Laptop Mag
Separate latency-sensitive from batch-eligible workloads at architecture time. The question "does this need to return in under 3 seconds?" should be asked for every LLM call before it's built. If the answer is no — batch it.

The Broader Point

LLM API prices dropped approximately 80% between early 2025 and early 2026 — which is genuinely good news. But prices dropping doesn't protect you from cost growth if you're scaling usage faster than prices are falling, or if you're using the wrong model tier for the task.

The cost problem in LLM integration is not usually a pricing problem. It is an architecture problem. Flagship model where a budget model would do, uncached system prompts, synchronous calls where batch would work — these are architectural decisions made at build time that compound into significant monthly costs at scale.

The fix is not complicated. It just requires actually looking at the numbers before the bill arrives.

Exact Solution sells professionally refurbished MacBooks, iPhones, and laptops across the UK, Poland, and Europe — tested, graded, warranty backed.
exactsolution.com

I Reviewed 1,000 GitHub Repos This Year — Here Are the 7 Mistakes Every Developer Makes

Exact Solution — Wed, 17 Jun 2026 13:49:02 +0000

This started as an internal audit.

We were reviewing open source dependencies for a project and ended up falling down a rabbit hole — one repo led to another, a pattern appeared, then another, then another. By the time we'd formally tracked the exercise we were somewhere past a thousand repositories reviewed across the year — a mix of solo projects, startup codebases, open source libraries, and internal tools shared publicly by accident.

What we found wasn't surprising in the sense that these were obscure edge cases. It was surprising in the sense that the same mistakes appeared everywhere — in repos with five stars and repos with five thousand, in projects maintained by one person and projects with fifty contributors. The problems don't discriminate by experience level. They discriminate by whether someone told you about them before you made them.

Here are the seven that showed up most consistently.

Mistake 1 — Secrets in Git History That a .gitignore Can't Remove

This is the most dangerous mistake on the list and the most misunderstood fix.

One leaked API key, an exposed database credential, or a mistakenly committed .env file can lead to massive data breaches, unauthorized access, and even financial loss — and private repositories are not safe from this.

Here's the part most developers get wrong: adding .env to .gitignore after you've already committed it once does nothing. The file is in your git history permanently. Anyone who clones the repo and runs git log can find it. Anyone who forks it takes it with them.

`# This is what a lot of repos look like in their history
git log --all --full-history -- .env

You'll find something like:

commit a3f9d12

Author: Developer Name

Date: Mon Jan 15 2024

"remove .env file" ← too late`

Even if credentials are deleted at a certain point in time, they remain in git history and allow a determined adversary to access those assets — the combination of code sprawl and persistence means secrets in code can be exploited long after developers have moved on from a project.

The actual fix requires rewriting history with git filter-repo — not git filter-branch, which is deprecated and slow — and then rotating every credential that was ever committed. Not just removing it. Rotating it. The key is compromised the moment it touches a commit.

`# Install git-filter-repo (pip install git-filter-repo)
git filter-repo --path .env --invert-paths

Then immediately rotate every key, token, and credential

that appeared in that file. Every single one.`

Prevention is a pre-commit hook with git-secrets or trufflehog that blocks the commit before it ever enters history. Set it up once per machine, never think about it again.

`# Install trufflehog as a pre-commit hook
pip install pre-commit

Add to .pre-commit-config.yaml:

- repo: https://github.com/trufflesecurity/trufflehog

hooks:

- id: trufflehog`

Mistake 2 — No Branch Protection on Main

We found this in the majority of repos with more than one contributor. Main branch sitting completely unprotected — anyone with write access can push directly, force push over someone else's work, or delete the branch entirely.

Using branch protection rules and required reviews significantly reduces risk — without them, developers may unintentionally introduce security risks or break production with a direct push. Technical Ustad
The specific configuration most repos were missing:

GitHub Settings → Branches → Branch protection rules → Add rule

✅ Require a pull request before merging
✅ Require approvals: 1 minimum
✅ Dismiss stale pull request approvals when new commits are pushed
✅ Require status checks to pass before merging
✅ Require branches to be up to date before merging
✅ Do not allow bypassing the above settings
❌ Allow force pushes → OFF
❌ Allow deletions → OFF

The "Do not allow bypassing" setting is the one most people miss. Without it, admins and repo owners can bypass every rule you just set — which makes the protection meaningless in any repo where the lead developer is also the one most likely to push something broken on a Friday afternoon.

Mistake 3 — PRs So Large Nobody Actually Reviews Them

This one doesn't show up in a security scan. It shows up in your commit history as a 4,000-line PR that was approved in eleven minutes.
We saw this pattern repeatedly — a developer works on a feature for two weeks, accumulates changes across fifteen files, and opens a single pull request for all of it. The reviewer is faced with a diff that's physically impossible to review properly in less than an hour. So they scan the obvious parts, leave a comment about a variable name, and approve it. The substantive logic goes unreviewed.

The research on this is unambiguous. Studies on code review effectiveness consistently show that reviewers find progressively fewer defects per line as PR size increases — after about 400 lines of changed code, review quality degrades significantly. Past 1,000 lines, it's essentially ceremonial.

The fix is structural, not a matter of discipline:
Rule: No PR merges if diff exceeds 400 lines of changed code.
Enforcement: GitHub Actions status check that blocks merge if line count exceeded.

# .github/workflows/pr-size-check.yml name: PR Size Check on: [pull_request] jobs: size-check: runs-on: ubuntu-latest steps: - name: Check PR size run: | LINES=$(curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \ "https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.number }}" \ | jq '.additions + .deletions') if [ "$LINES" -gt 400 ]; then echo "PR too large: $LINES lines changed. Break it into smaller PRs." exit 1 fi

Large PRs are a process failure before they're a code quality failure. The automation removes the conversation entirely.

Mistake 4 — README That Describes What the Project Is, Not How to Use It

Technical README failure is less dramatic than a security breach but it's one of the most consistently damaging mistakes in terms of project adoption and maintainability.

The pattern we saw most often: a README that explains what the project does in one paragraph, has a features list, and then drops a single installation command with no context about prerequisites, environment setup, expected output, or what to do when something goes wrong.

A README that actually works contains:

`## Prerequisites

Node.js 18+ (not 16, not 20 — this project uses fetch natively available in 18)
PostgreSQL 14+
An .env file based on .env.example (copy it first, then fill in values)

Installation

`\bash
cp .env.example .env
npm install
npm run db:migrate
npm run dev
\`

Expected output

Server running at http://localhost:3000
Database connected: true

Common errors

ECONNREFUSED 5432: PostgreSQL isn't running. Start it with brew services start postgresql
MODULE_NOT_FOUND: Run npm install first `\`

The "Common errors" section is the one that almost nobody writes and the one that saves every new contributor thirty minutes of debugging. Write it from memory — you know exactly what went wrong the first time you set this up.

Mistake 5 — Issues and PRs With No Template, No Labels, No Triage

Repos with active contributors but zero issue structure. Every issue is a blank text field. No labels. No assignees. No milestones. The result is an issue tracker that looks busy but functions as a to-do list nobody owns.

`# What most repos have:
Issue #47: "it doesn't work"
Issue #48: "bug with login"
Issue #49: "can you add dark mode"

What a maintainable repo has:

[BUG] Login fails with OAuth providers when redirect URI contains query params
Labels: bug, authentication, priority:high
Assignee: @dev-name
Milestone: v2.1.0`

GitHub issue templates take twenty minutes to set up and eliminate the entire category of "it doesn't work" issues by forcing reporters to provide reproduction steps, environment info, and expected versus actual behaviour.

`# .github/ISSUE_TEMPLATE/bug_report.yml
name: Bug Report
description: File a bug report
body:

type: textarea id: what-happened attributes: label: What happened? description: What did you expect to happen? validations: required: true
type: textarea id: reproduction attributes: label: Steps to reproduce validations: required: true
type: dropdown id: version attributes: label: Version options: - Latest - Other (specify in description) validations: required: true`

Mistake 6 — Dependencies Nobody Has Audited Since the Initial Commit

This one compounds silently. A project is started, dependencies are installed, the project ships, and nobody runs npm audit or pip check again for eighteen months. By that point the dependency tree has accumulated multiple known vulnerabilities that have been publicly disclosed, patched in newer versions, and ignored entirely because nobody set up automated alerts.

GitHub is extremely proactive about protecting the security of its users — it has developed tools to help prevent sensitive information from being exposed — but the majority of GitHub-related security incidents are caused by mistakes by its users, not platform failures.

Dependabot takes four minutes to enable and runs automatically:

`# .github/dependabot.yml
version: 2
updates:

package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" open-pull-requests-limit: 10 labels:
- "dependencies"
- "automerge-patch"`

The automerge-patch label combined with a GitHub Action that auto-merges Dependabot PRs for patch-level updates removes the entire maintenance burden for minor security fixes. You review minor and major updates manually. Patches merge themselves.

# .github/workflows/dependabot-automerge.yml name: Dependabot Auto-merge on: pull_request jobs: automerge: runs-on: ubuntu-latest if: github.actor == 'dependabot[bot]' steps: - name: Auto-merge patch updates run: gh pr merge --auto --squash "$PR_URL" env: PR_URL: ${{ github.event.pull_request.html_url }} GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Mistake 7 — GitHub Actions Workflows With Excessive Permissions

This is the fastest-growing category of GitHub security mistakes we saw this year and the least understood by the developers making it.

By default, GitHub Actions workflows may receive broader repository permissions than they actually require — one of the most overlooked security features is the permissions setting. Technical Ustad
The default GITHUB_TOKEN in many workflows has write access to the entire repository. A workflow that only needs to run tests and post a comment has no business with write access to deployments, packages, or repository contents. But because the default is permissive, most workflows never have their permissions scoped.

`# What most workflows look like (dangerous default):
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm test

GITHUB_TOKEN has write access to everything by default

What they should look like:

permissions:
contents: read # Only what checkout needs
checks: write # Only what test reporting needs
pull-requests: write # Only if you're posting PR comments

jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm test`

The principle is minimal permissions per workflow. A build job needs contents: read. A deployment job needs specific deployment permissions. A release job needs contents: write. Nothing needs blanket write access to the entire repository.

Add this to the top of every workflow file as a default:

permissions: read-all # Deny everything by default, grant explicitly per job

The Pattern Underneath All Seven

Looking across everything we reviewed, the common thread isn't incompetence or carelessness. It's that these mistakes are invisible until they're not. A .env file in git history doesn't announce itself. An unprotected main branch doesn't cause a problem until someone force-pushes on a Friday. Outdated dependencies sit quietly until they're in a CVE.

The fixes for all seven take less than a day to implement across an entire repository. Most of them take twenty minutes. The reason they're not already in every repo isn't that developers don't care — it's that nobody told them what to look for before the problem appeared.

Consider this that conversation.

The Seven-Minute Repo Audit Checklist
Run this on any repository you maintain:

✅ Search git history for .env, secrets, API keys: git log --all -S "SECRET"
✅ Branch protection enabled on main with required reviews
✅ Average PR size under 400 lines — check last 10 PRs
✅ README has prerequisites, installation steps, and common errors section
✅ Issue templates exist in .github/ISSUE_TEMPLATE/
✅ Dependabot enabled and dependency PRs are being reviewed
✅ GitHub Actions workflows have explicit permissions: read-all default

About Exact Solution

We sell professionally refurbished MacBooks and laptops across Europe and the UK — tested, graded, and warranty backed. We also ship code to production and write about what breaks when we do.
https://www.exactsolution.com/collections/laptops

Your AI-Generated Code Is Passing Tests and Failing in Production — Here's Why

Exact Solution — Tue, 16 Jun 2026 14:04:58 +0000

The test suite is green. The PR was reviewed. The feature shipped Friday afternoon. By Monday morning you have an incident.

This is the story of 2025 in production engineering. Not because AI coding tools are useless — they're genuinely, measurably productive. But because the way most teams are using them creates a specific class of failure that standard testing practices were never designed to catch.

I want to show you exactly what that failure looks like, why it passes every check you have, and what you actually need to do about it.

First, the Numbers — Because This Is Not Anecdotal

Before getting into the mechanics, it helps to understand the scale of what we're actually dealing with.

Stanford and NYU tested Copilot across 89 code-generation scenarios. 40% of the output contained security vulnerabilities mapped to known CWEs — SQL injection, XSS, buffer overflows, hardcoded credentials.

Veracode tested over 100 large language models across 80 coding tasks in Java, Python, C#, and JavaScript. 45% of AI-generated samples failed security tests overall, with Java performing worst at a 72% failure rate. 86% of generated samples failed to defend against cross-site scripting, and 88% were vulnerable to log injection.

AI included bugs like improper password handling and insecure object references at 1.5–2x the rate of human coders. Excessive I/O operations were roughly 8x higher in AI-generated code. AI was twice as likely to make concurrency and dependency correctness mistakes.

Here's what makes these numbers particularly uncomfortable: a benchmark study tested an agentic coding workflow and found that 61% of solutions were functionally correct. Only 10.5% were secure. Those two numbers are basically uncorrelated.

Your tests verify functional correctness. The security and reliability failures are in an entirely different dimension — one your test suite isn't looking at.

Why AI Code Passes Tests and Fails in Production

There are three distinct reasons this happens. They compound.

1. AI optimises for the happy path

LLMs are trained on code that largely demonstrates working implementations. Tutorial code, Stack Overflow answers, documentation examples — all of it shows the thing working correctly under normal conditions. The model has seen very little training data that shows robust error handling, edge case coverage, and adversarial input management. So it generates code that works exactly like the examples it learned from. Which means it works when you test it the way the examples work, and fails when reality introduces anything the training distribution didn't cover.

2. Tests test what you thought of

Unit tests and integration tests cover the scenarios you imagined when you wrote them. AI generates code to pass the tests you give it — or implies tests based on the happy-path implementation it just wrote. Semantic errors — where the code compiles but behaves incorrectly — account for more than 60% of faults in AI-generated code. These errors don't trigger exceptions. They don't fail assertions. They produce wrong output confidently and silently.

3. AI has no architectural context

AI doesn't understand your full architecture — it just predicts likely code. It doesn't know that the function it just wrote for you will be called from a context where the input has already been partially sanitised — or hasn't been at all. It doesn't know that the authentication check it generated sits behind a middleware layer that will sometimes be bypassed. It doesn't know your database schema has a race condition window during high write volume. It generates locally plausible code. Local plausibility and system-level correctness are not the same thing.

The Real Example — A Support Ticketing Tool That Lasted One Week

A startup shipped a support ticketing tool built entirely with AI. Within one week, 3,000+ customer tickets were exposed. Accio
Here's what that failure likely looked like in code. This is a representative reconstruction — the pattern is real, the specific implementation is illustrative:

# What the AI generated — looks completely fine in isolation @app.route('/api/tickets/<ticket_id>', methods=['GET']) def get_ticket(ticket_id): user_id = request.headers.get('X-User-ID') ticket = db.query( "SELECT * FROM tickets WHERE id = ?", (ticket_id,) ) return jsonify(ticket)

The test written alongside it:

def test_get_ticket(): response = client.get( '/api/tickets/123', headers={'X-User-ID': '456'} ) assert response.status_code == 200 assert response.json()['id'] == 123

Test passes. Every time. Completely green.

The problem: the function retrieves a ticket by ID. It accepts a user_id header. It never once checks whether the authenticated user actually owns that ticket. Any authenticated user can request any ticket ID and receive that ticket's full contents — including other customers' support conversations, attachments, and whatever PII they contained.

This is called an Insecure Direct Object Reference (IDOR) — it's OWASP Top 10. The AI generated it because most tutorial code demonstrating database retrieval doesn't include ownership validation. The test didn't catch it because the test was written to verify the happy path, not to attempt unauthorised access.

What the code needed:
`@app.route('/api/tickets/', methods=['GET'])
def get_ticket(ticket_id):
user_id = request.headers.get('X-User-ID')

# Validate user owns this ticket BEFORE returning it
ticket = db.query(
    """SELECT * FROM tickets 
       WHERE id = ? AND user_id = ?""",
    (ticket_id, user_id)
)

if not ticket:
    # Return 404 not 403 — don't confirm the ticket exists
    return jsonify({'error': 'Not found'}), 404

return jsonify(ticket)`

One extra condition in the query. The entire breach surface disappears. The AI didn't generate it. The test didn't catch its absence. Production exposed it immediately.

The Three Failure Patterns You Will See

Pattern 1 — Client-side auth without server-side enforcement

AI tools generate auth guards in React but skip server-side validation, so anyone with browser dev tools can bypass them.

`// AI generates this on the frontend — looks correct
if (user.role !== 'admin') {
return ;
}

// And generates this on the backend — missing the check entirely
app.delete('/api/users/:id', async (req, res) => {
await User.findByIdAndDelete(req.params.id);
res.json({ success: true });
});`

Frontend gate. No backend gate. One API call from any authenticated user deletes any record.

Pattern 2 — Race conditions under concurrent load

AI generates code that works correctly for a single user. Under concurrent load, shared state assumptions break.

# AI-generated balance deduction — passes every unit test def deduct_balance(user_id, amount): user = db.get_user(user_id) # Read if user.balance >= amount: user.balance -= amount # Modify db.save_user(user) # Write return True return False

Two concurrent requests for the same user hit the read simultaneously. Both see sufficient balance. Both deduct. The user spends money they don't have. AI was twice as likely to make concurrency and dependency correctness mistakes compared to human developers.

The fix — atomic database operation:

def deduct_balance(user_id, amount): result = db.execute( """UPDATE users SET balance = balance - ? WHERE id = ? AND balance >= ?""", (amount, user_id, amount) ) return result.rowcount > 0 # False if balance was insufficient

Pattern 3 — Hallucinated APIs that exist but behave differently

AI often introduces predictable issues like hallucinated APIs — or more precisely, real APIs used with subtly wrong assumptions about their behaviour.

// AI assumes Promise.all fails fast on first rejection // This is correct — but AI also assumes all requests run sequentially // They don't. All fire simultaneously. const results = await Promise.all( userIds.map(id => fetchUserData(id)) // 10,000 concurrent requests );

Works perfectly in tests with three user IDs. Fires 10,000 simultaneous API requests in production, hits rate limits, crashes the integration, and potentially gets your IP banned from the external service.

What Actually Fixes This

Threat-model your AI output, not just test it

For every function an AI generates that touches data, ask: who else could call this, with what inputs, and what would happen? This is not a review of whether the code works — it's a review of whether the code is safe when used outside the happy path the AI imagined.

Write adversarial tests, not just functional tests

def test_get_ticket_unauthorized(): # Test that user CANNOT access another user's ticket response = client.get( '/api/tickets/123', # Ticket owned by user 456 headers={'X-User-ID': '789'} # Different user attempting access ) assert response.status_code == 404 # Not 200, not 403

The AI didn't write this test. You have to write it. Security tests require thinking about failure — something the model optimises away from by default.

Use static analysis tools on AI output before review

Semgrep, Bandit (Python), ESLint security plugins, Snyk — run these automatically on every PR. They catch the mechanical security failures that code review misses because the code looks syntactically correct and reviewers are reading for logic, not vulnerability patterns.

Never merge AI-generated auth, payment, or data access code without a dedicated security pass

Not a standard code review. A specific pass asking: is ownership validated? Is input sanitised at the boundary? Are concurrent operations atomic? Is error information leaking through response codes?

The Replit Incident — When It Goes Further Than Security

The Replit AI catastrophe in July 2025 occurred during a vibe-coding session. Despite receiving explicit instructions not to touch anything, the LLM tool deleted a live production database.

This is the extreme end of the spectrum, but it illustrates the core problem clearly: when developers treat AI output as peer review rather than a first draft, insecure and incorrect patterns reach production at scale and at speed.

The model isn't your peer reviewer. It's a very fast junior developer who has read every piece of code on the internet, has zero context about your specific system, and will confidently do exactly what you asked in a way that seems reasonable but might be catastrophically wrong.

Treat the output accordingly.

The Audit Checklist for AI-Generated Code
Before any AI-generated code merges to main:

✅ Every data retrieval function — does it validate ownership?
✅ Every write operation — is it atomic under concurrent access?
✅ Every input boundary — is sanitisation happening server-side, not just client-side?
✅ Every external API call — is rate limiting and error handling implemented?
✅ Every auth check — is it enforced on the server, not just the UI?
✅ Every error response — is it leaking information through status codes or messages?
✅ Static analysis tool run and findings reviewed
✅ At least one adversarial test written per endpoint

About Exact Solution**

We sell professionally refurbished MacBooks and laptops across
Europe and the UK — tested, graded, and warranty backed. We also
ship code to production and write about what breaks when we do.

exactsolution.com

Your Client-Side Rendered E-commerce Site Is Invisible to AI Search.

Exact Solution — Thu, 11 Jun 2026 13:38:49 +0000

MacBook Air 13.3-inch Retina (2019)

Exact Solution — Tue, 09 Jun 2026 13:19:13 +0000

When Apple introduced the MacBook Air 13.3-inch Retina (2019), it refined one of the most beloved laptops in the world. Combining a sleek design, Retina display, all-day battery life, and reliable performance, this model quickly became a favorite among students, professionals, and casual users alike.

Even years after its release, the 2019 MacBook Air continues to attract attention from buyers looking for a dependable and budget-friendly Apple laptop. But what makes it so special? Let’s explore why this lightweight powerhouse still deserves a spot on your shortlist.

A Premium Design That Never Goes Out of Style
The MacBook Air 13.3-inch Retina (2019) features Apple’s signature aluminum unibody design, making it both durable and elegant. Weighing just around 1.25 kg (2.75 pounds), it is designed for users who are constantly on the move.

Whether you’re working from a coffee shop, attending classes, or traveling for business, this laptop offers excellent portability without compromising on build quality.

Key Design Highlights:

Ultra-thin and lightweight construction
Premium aluminum chassis
Available in multiple stylish finishes
Compact form factor for easy portability
Stunning Retina Display for Everyday Use

One of the biggest upgrades in this model is its 13.3-inch Retina display. With vibrant colors, sharp text, and impressive clarity, everything from documents to movies looks significantly better compared to older non-Retina MacBook Air models.

The Retina display is especially beneficial for:

Content consumption
Photo editing
Web browsing
Productivity tasks
Online learning

The True Tone technology also adjusts the screen’s color temperature according to ambient lighting, providing a more comfortable viewing experience.

Performance That Handles Daily Tasks Smoothly

Powered by Intel Core processors, the MacBook Air 2019 delivers reliable performance for everyday computing needs. While it isn’t designed for intensive gaming or high-end video rendering, it performs exceptionally well for common tasks.

Ideal For:

Office productivity
Web browsing
Email management
Video conferencing
Content streaming
Light creative work

The combination of SSD storage and macOS optimization ensures quick boot times and smooth multitasking.

Comfortable Keyboard and Responsive Touch ID

Apple improved the overall user experience by integrating Touch ID, allowing users to unlock their device, authorize purchases, and access secure applications with a simple fingerprint scan.

Become a Medium member

The spacious trackpad remains one of the best in the industry, offering precise navigation and smooth gesture controls.

Impressive Battery Life for Productivity on the Go

Battery performance remains one of the strongest selling points of the MacBook Air lineup. The 2019 model can comfortably last through a typical workday with moderate usage.

This means fewer charging interruptions and greater convenience for students, remote workers, and travelers.

Why Many Buyers Still Consider the MacBook Air 2019

Despite newer models entering the market, the MacBook Air 13.3-inch Retina (2019) continues to provide excellent value for users who need a reliable Apple laptop without paying premium prices for the latest hardware.

Its combination of:

Premium build quality
Retina display
Long battery life
Lightweight design
macOS ecosystem
makes it a practical option for many users.

Where to Find Reliable Support and Solutions

If you’re experiencing setup issues, performance concerns, or hardware-related questions regarding your macbook air, finding the right guidance is essential. At exact solution, users can access helpful resources, troubleshooting guides, and expert assistance to maximize the performance and lifespan of their Apple devices.

Final Verdict

The MacBook Air 13.3-inch Retina (2019) proves that great laptops can remain relevant long after their release. Its beautiful Retina display, premium design, dependable performance, and exceptional portability make it a compelling choice even today.

Whether you’re a student, professional, or casual user, this model continues to deliver the quality and user experience that have made the MacBook Air one of Apple’s most successful laptop series.

If you’re looking for a capable and stylish laptop that balances performance, portability, and value, the MacBook Air 13.3-inch Retina (2019) remains a worthy contender.
https://www.exactsolution.com/products/macbook-air-133-inch-retina-inch-2019-core-i5-16ghz-dual-core-and-intel-uhd-graphics-617-8gb-ram-ssd-128gb-space-gray-6968dd2115a80d5aea4e6de9

Redux vs Zustand: I Migrated and Here's What I Learned

Exact Solution — Fri, 05 Jun 2026 13:03:14 +0000

I spent about three weeks migrating a React application from Redux Toolkit to Zustand earlier this year. The app had around 40 components, 12 slices of state, and a few hundred users. It wasn't huge, but it was complex enough to feel the real differences between the two libraries.

This post covers what I actually learned — what got better, what got worse, where Zustand surprised me, and where I missed Redux. Plus working code examples for the patterns that mattered most.

The Quick Verdict

Use Zustand if: You want minimal boilerplate, you're working on a small-to-medium app, your team is comfortable making decisions about state organization themselves, and you don't need extensive middleware ecosystems.

*Use Redux Toolkit if: * You're working on a large app, you need predictable state management across a large team, you rely on the DevTools extensively, or you need middleware like Redux Saga / Redux Observable.

The decision usually comes down to team size and predictability needs, not technical capability. Both libraries can build the same applications. They just have different opinions about how much structure you need.

Why I Migrated (Honestly)

I'll be upfront about my reasons because they affect what you should take from this comparison.

The Redux Toolkit codebase wasn't broken. It worked. The migration wasn't driven by a performance problem or a bug. It was driven by team friction.

Our team had grown from 2 developers to 5 in six months. The new developers found Redux Toolkit's mental model intimidating — even Redux Toolkit, which is the friendliest Redux has ever been. They struggled with concepts like slices, reducers, actions, selectors, and the dispatch pattern. Every state change required reading through 3-4 files.

Three of our newer developers had used Zustand on side projects and kept asking why we couldn't use it at work.

Eventually I gave in and ran a proof-of-concept migration on one feature. It went well. We migrated the rest over three sprints.

This is the most important context for everything that follows: I migrated because of team friction, not because Redux was technically worse.

The Core Differences in Code

Before getting into lessons learned, let me show the same feature in both libraries. This is a simple shopping cart store.

Redux Toolkit Version

// store/slices/cartSlice.ts
import { createSlice, PayloadAction } from '@reduxjs/toolkit';

interface CartItem {
  id: string;
  name: string;
  price: number;
  quantity: number;
}

interface CartState {
  items: CartItem[];
  isLoading: boolean;
}

const initialState: CartState = {
  items: [],
  isLoading: false,
};

const cartSlice = createSlice({
  name: 'cart',
  initialState,
  reducers: {
    addItem: (state, action: PayloadAction<CartItem>) => {
      const existing = state.items.find(i => i.id === action.payload.id);
      if (existing) {
        existing.quantity += action.payload.quantity;
      } else {
        state.items.push(action.payload);
      }
    },
    removeItem: (state, action: PayloadAction<string>) => {
      state.items = state.items.filter(i => i.id !== action.payload);
    },
    clearCart: (state) => {
      state.items = [];
    },
  },
});

export const { addItem, removeItem, clearCart } = cartSlice.actions;
export default cartSlice.reducer;

// store/index.ts
import { configureStore } from '@reduxjs/toolkit';
import cartReducer from './slices/cartSlice';

export const store = configureStore({
  reducer: {
    cart: cartReducer,
  },
});

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

// Component usage
import { useSelector, useDispatch } from 'react-redux';
import { addItem, removeItem } from './store/slices/cartSlice';
import { RootState, AppDispatch } from './store';

function CartButton({ product }) {
  const dispatch = useDispatch<AppDispatch>();
  const items = useSelector((state: RootState) => state.cart.items);

  return (
    <button onClick={() => dispatch(addItem({ ...product, quantity: 1 }))}>
      Add to Cart ({items.length})
    </button>
  );
}

Zustand Version (Same Feature)

// stores/useCartStore.ts
import { create } from 'zustand';

interface CartItem {
  id: string;
  name: string;
  price: number;
  quantity: number;
}

interface CartStore {
  items: CartItem[];
  isLoading: boolean;
  addItem: (item: CartItem) => void;
  removeItem: (id: string) => void;
  clearCart: () => void;
}

export const useCartStore = create<CartStore>((set) => ({
  items: [],
  isLoading: false,

  addItem: (item) => set((state) => {
    const existing = state.items.find(i => i.id === item.id);
    if (existing) {
      return {
        items: state.items.map(i =>
          i.id === item.id ? { ...i, quantity: i.quantity + item.quantity } : i
        ),
      };
    }
    return { items: [...state.items, item] };
  }),

  removeItem: (id) => set((state) => ({
    items: state.items.filter(i => i.id !== id),
  })),

  clearCart: () => set({ items: [] }),
}));

// Component usage
import { useCartStore } from './stores/useCartStore';

function CartButton({ product }) {
  const items = useCartStore((state) => state.items);
  const addItem = useCartStore((state) => state.addItem);

  return (
    <button onClick={() => addItem({ ...product, quantity: 1 })}>
      Add to Cart ({items.length})
    </button>
  );
}

What the Code Comparison Shows

The Zustand version is roughly 40% less code. No separate slice files. No store configuration. No Provider wrapper needed in your app root. No typed dispatch hook. No RootState type to maintain.

For a small feature, that's significant. For a complex application, the savings compound.

But code length isn't the only thing that matters. Let me get into what actually happened during the migration.

What Got Better After Migration

1. Onboarding Time Dropped Significantly

The biggest win wasn't technical — it was team-related. New developers became productive faster.

With Redux Toolkit, a new developer needed to learn slices, actions, reducers, selectors, thunks, the dispatch pattern, and how all of these connected. Even with good documentation, that's a lot.

With Zustand, the mental model is: "It's just a custom hook with state in it." That sentence is the entire architecture.

Onboarding time for state management went from about 2 days to about 2 hours. For a growing team, this matters more than I expected.

2. File Count Dropped by Roughly 60%

The Redux Toolkit version of our app had a store folder with 12 slice files, 3 middleware files, a root reducer, and a store configuration file. Plus typed hooks in another file. Plus selectors organized by domain.

The Zustand version has 12 store files, each fully self-contained. That's it.

For a small to medium app, fewer files means less cognitive overhead. New developers can navigate the codebase faster.

3. TypeScript Inference Got Better

Both libraries support TypeScript well, but Zustand's inference is noticeably better for selectors.

In Redux Toolkit, you write:

const items = useSelector((state: RootState) => state.cart.items);

You have to manually annotate RootState because the selector doesn't know what shape state has.

In Zustand, you write:

const items = useCartStore((state) => state.items);

TypeScript infers state from the store definition. No manual RootState maintenance. When you add a new field to a store, every selector using it gets type-checked automatically without you updating a separate types file.

4. Testing Got Simpler

Testing Redux requires setting up a test store, wrapping components in a Provider, and dispatching actions. Even with Redux Toolkit's setupListeners and test utilities, there's setup.

Testing Zustand: just call useCartStore.getState().addItem({...}) in a test and assert against useCartStore.getState().items. No provider, no mock store, no dispatching.

For unit tests, this saved time. For component integration tests, the savings were smaller because you still mount the component either way.

5. Bundle Size Decreased

The Redux Toolkit + React Redux combination adds about 12kb gzipped to a bundle. Zustand adds about 1kb gzipped.
For most apps, this doesn't matter. But if you're optimizing aggressively (mobile, slow networks, edge computing), it's a real difference.

What Got Worse After Migration

This is the part most migration blog posts skip. Here's what I miss about Redux.

1. The Redux DevTools Are Better

Redux DevTools is genuinely incredible. Time-travel debugging, action replay, state diffing — it's a mature, polished tool.

Zustand has DevTools support via middleware (zustand/middleware/devtools), but it's noticeably less polished. Time-travel works, but the UX for action history is rougher. State diffing is less detailed.

If you debug heavily through DevTools, this is a real downgrade.

2. The "Single Source of Truth" Principle Weakened

In Redux, all state lives in one store. There's exactly one place to look for any piece of state.

In Zustand, the pattern is multiple small stores. We had 12 stores after migration. The trade-off is flexibility — but the cost is that "where does X state live?" becomes a question new developers ask.

This can be solved by writing internal conventions ("user state goes in useUserStore, never anywhere else"), but Redux enforces this structurally. Zustand requires discipline.

3. Middleware Ecosystem Is Smaller

Redux has Redux Saga, Redux Observable, Redux Logger, Redux Persist, RTK Query, and dozens of other mature middleware libraries. Zustand has middleware for persistence, DevTools, immer, and a smaller set of community options.

We hit this problem when we wanted to add complex async logic that we'd previously handled with Redux Toolkit's createAsyncThunk + RTK Query. Zustand has options, but they're less mature.

4. Predictability for Large Teams Decreased

This is the same point as "single source of truth" from a different angle. Redux's verbose structure forces a specific architecture. Zustand lets you do whatever you want.

In a 5-person team, this was fine. If our team grew to 15, I'd be nervous. Without enforced patterns, every developer would solve state problems slightly differently, and the codebase would diverge.

For teams over 10 developers, I'd consider this a serious downside.

5. Async Patterns Are Less Standardized

Redux Toolkit Query (RTK Query) is one of the best data fetching solutions in any framework. The cache invalidation, automatic refetching, optimistic updates, and TypeScript integration are all excellent.

Zustand has no equivalent built-in. We ended up using TanStack Query (React Query) alongside Zustand, which works well but adds another dependency to learn.

If you're already using RTK Query, replacing it with TanStack Query + Zustand is a lateral move at best.

The Patterns I Wish I'd Known Earlier

Three Zustand patterns saved significant time once I learned them.

Pattern 1: Selectors with shallow for Performance

By default, Zustand triggers a re-render any time the selected state changes. If you select an object, every property change re-renders.

// This re-renders any time anything in the cart changes
const { items, isLoading, totalPrice } = useCartStore((state) => ({
  items: state.items,
  isLoading: state.isLoading,
  totalPrice: state.totalPrice,
}));

Use shallow to compare equality field-by-field:

import { shallow } from 'zustand/shallow';

const { items, isLoading, totalPrice } = useCartStore(
  (state) => ({
    items: state.items,
    isLoading: state.isLoading,
    totalPrice: state.totalPrice,
  }),
  shallow
);

Without shallow, this pattern causes unnecessary re-renders. With it, performance matches what Redux's useSelector does by default.

Pattern 2: Persisting State to localStorage

This was much easier than I expected.

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

export const useCartStore = create(
  persist<CartStore>(
    (set) => ({
      items: [],
      addItem: (item) => set((state) => ({ items: [...state.items, item] })),
      removeItem: (id) => set((state) => ({
        items: state.items.filter(i => i.id !== id),
      })),
    }),
    {
      name: 'cart-storage',
      storage: createJSONStorage(() => localStorage),
    }
  )
);

Three lines of middleware setup and the entire store persists automatically. No redux-persist configuration. No rehydration logic to write.

Pattern 3: Computed/Derived State

Zustand doesn't have a useSelector equivalent for derived state, but you can compute it inside the selector:

// Computed total price
const totalPrice = useCartStore((state) =>
  state.items.reduce((sum, item) => sum + item.price * item.quantity, 0)
);

This recomputes only when items changes. For more complex derived state, you can use useMemo:

const items = useCartStore((state) => state.items);
const totalPrice = useMemo(
  () => items.reduce((sum, item) => sum + item.price * item.quantity, 0),
  [items]
);

I missed reselect initially but ended up not needing it.

Migration Strategy That Actually Worked

If you're considering this migration, here's the approach that worked for us.

Step 1: Start With One Feature

Pick a self-contained feature (we used the shopping cart). Migrate it to Zustand while keeping Redux running for everything else. Both libraries can coexist in the same app.

Step 2: Run Both for a Sprint

Live with both libraries for at least a sprint. This reveals friction points you wouldn't notice in a small POC.

Step 3: Migrate Stores One at a Time

Pick stores in order of independence. Migrate the ones with fewest connections first. Don't try to migrate everything at once.

Step 4: Migrate Selectors and Hooks Together

When you migrate a store, migrate every component using it in the same PR. Don't leave a state mid-migration. It creates confusing code where some components use useSelector and others use useCartStore.'

Step 5: Remove Redux Last

Only remove @reduxjs/toolkit and react-redux from package.json after every store is migrated. Run the app one more time to confirm nothing breaks.
For us, this took three weeks of part-time work alongside normal feature development. It would have taken about two weeks if we'd dedicated full focus.

When NOT to Migrate

Be honest with yourself if any of these apply:

Your team is happy with Redux Toolkit. "It would be nice" isn't a strong enough reason. Migrations have real costs.
You have heavy RTK Query usage. TanStack Query is great but the migration cost is high.
You depend on Redux DevTools for debugging. Zustand's DevTools are real but inferior.
Your team is large (10+). The structural enforcement Redux provides becomes more valuable as team size grows.
You have complex async middleware (Sagas, Observables). Zustand has no equivalent.

In all of these cases, sticking with Redux Toolkit is the smarter choice.

My Honest Recommendation

For small-to-medium apps with small-to-medium teams: Zustand wins. It's less code, faster onboarding, simpler testing, smaller bundle. The trade-offs (worse DevTools, less enforced structure) are minor at this scale.

For large apps with large teams: Redux Toolkit is still the better choice. The enforced structure becomes a feature, not a bug. The mature ecosystem matters more. The DevTools matter more.

The migration isn't a "Zustand is better" story — it's a "different tools for different stages" story. We migrated because our stage changed. If our team grew to 15 next year, we'd seriously consider migrating back.

Both libraries are good. Pick the one that fits the team you have today.

_If you're considering this migration or already did one, I'd love to hear what went differently for your team. The decision is much more about team dynamics than tech specs, and I think we under-discuss that.
_

About Exact Solution:
Exact Solution is an e-commerce store specializing in refurbished electronics — laptops, smartphones, tablets, and game consoles. Our team writes about the technical decisions behind building and scaling our platform, sharing practical lessons from running a modern product business.
Browse our refurbished laptops, refurbished smartphones, or visit exactsolution.com.

I Shipped a Bug to Production That Cost Us 3 Hours of Downtime

Exact Solution — Thu, 21 May 2026 12:43:22 +0000

It was a Tuesday afternoon. Nothing felt different about the deploy. Same process as always. Green tests. Approved PR. Merged to main. Deployed.
Seventeen minutes later the alerts started.

What Happened

We had a background job that processed orders and updated inventory counts across our marketplace. The job ran every few minutes and had been running reliably for months without a single issue.

I had made what I genuinely believed was a minor change. A refactor. Cleaner logic, same behavior. I had tested it locally. The tests passed. A colleague reviewed it and approved it. Everything looked fine.

What I had not accounted for was a race condition that only appeared under concurrent load.

In local testing and in our staging environment, the job ran sequentially. In production it ran concurrently across multiple workers. The refactored logic I had written assumed sequential execution. Under concurrent load two workers would occasionally read the same inventory record at the same time, both calculate an update based on the same stale value, and both write back — the second write overwriting the first.

The result was inventory counts that drifted further from reality with every job run. Orders were being accepted for products that were no longer in stock. The customer facing side kept working normally which is why the alerts took seventeen minutes to fire. By the time we caught it the damage was done.

Three hours to identify, roll back, audit the affected records, correct the data, and verify the fix. Three hours of degraded service. A handful of orders that had to be manually cancelled and refunded. A postmortem that took longer than the incident itself.

All of it from a change I had described in the PR as "minor refactor, no behavioral changes."

The Mistakes I Made

Looking back there were several distinct failures that each independently could have prevented this.

I did not read the existing tests carefully enough.

The existing tests covered the sequential case because the original code had been written with sequential execution in mind. The tests passed because I had not broken the sequential behavior — I had broken the concurrent behavior that the tests never covered. I looked at green tests and assumed coverage. Green tests mean the tested cases pass. They say nothing about the cases that were not tested.

I assumed staging was representative of production.

Our staging environment runs a single worker. Production runs multiple. This difference had never mattered before because nothing we had deployed before this change was sensitive to concurrency. I knew staging was a single worker. I did not think about whether that mattered for this specific change. It did.

I described the change inaccurately in the PR.

"Minor refactor, no behavioral changes" is the kind of description that makes reviewers less careful not more. My colleague approved it quickly because the description signaled low risk. If I had described it accurately — "refactoring the inventory update logic, please check whether the new approach handles concurrent writes correctly" — the review would have been different. The description I wrote was not intentionally misleading. It reflected my own incorrect assessment of the risk. That is worse in some ways. I had convinced myself it was minor before I convinced anyone else.

I had no concurrency testing in my local verification process.

I ran the job locally once and watched it complete successfully. I did not run it concurrently. I did not run it under load. I did not simulate multiple workers. Running a background job once in a local environment and calling it tested is not testing the job — it is testing one execution path under ideal conditions.

What We Changed After

We added a staging environment worker count that matches production.

This sounds obvious in retrospect. It was not obvious until it cost us three hours. Staging now runs the same number of workers as production for any service where concurrency matters. The environment is still not a perfect replica but the concurrency profile now matches.

We added explicit concurrency tests for any job that touches shared state.

Not just unit tests for the logic. Integration tests that spin up multiple workers, run them simultaneously against the same test data, and verify the outcome is consistent. These tests are slower. They are also the only tests that would have caught this specific failure.

We changed how we describe PR risk in reviews.

We added a required field to our PR template: "Concurrency considerations." It can be filled with "N/A — this change does not touch shared state" which takes ten seconds. For changes that do touch shared state it forces the author to think about and articulate the concurrency implications before a reviewer sees the code. The reviewer then knows to focus there specifically.

We introduced a pre-deploy checklist for background jobs.

Not a long checklist. Four questions. Does this job touch shared state? Does the logic assume sequential execution? Has it been tested under concurrent load? Does the rollback procedure work without manual data correction? The checklist takes two minutes. The incident it is designed to prevent took three hours.

The Thing I Keep Coming Back To

The bug itself was not the most interesting part of this story.
The most interesting part is how many independent checkpoints it sailed through without being caught.

I did not catch it in my own review of the change. My colleague did not catch it in the PR review. The automated tests did not catch it. The staging deployment did not catch it.

Each of those checkpoints failed for a different reason. My self review failed because I had already decided the change was minor and was not looking carefully. The PR review failed because my description set a low risk frame that the reviewer accepted. The automated tests failed because they covered the wrong execution model. Staging failed because the environment did not match production on the one dimension that mattered.
A failure that gets through four independent checkpoints is not bad luck. It is a systems problem. The checkpoints were not actually independent — they were all downstream of my initial incorrect assessment that the change was low risk. Once I had decided it was minor, every subsequent checkpoint was biased toward confirming that assessment.

This is the uncomfortable version of the lesson. It is not just "write better tests" or "stage more carefully." It is that your own confidence in a change actively degrades the quality of the checks that follow it. The times you are most certain a change is safe are the times you most need to deliberately stress test that certainty.

What I Do Differently Now

Before merging anything that touches background jobs, queues, or shared state I now ask one question regardless of how minor the change feels:
What would have to be true about the execution environment for this to fail silently?

Not loudly. Not with an immediate error that gets caught in tests. Silently — in a way that produces correct looking output under normal conditions and wrong output under specific conditions that do not exist in development or staging.

That question changes how I look at a change. It forces me to think about the gap between the environment where I tested and the environment where it will run.

It would have caught this one. It has caught two potential issues since. Neither of them made it to production.
The best lesson from a production incident is not a new process. It is a new question you ask yourself before you need the process.

Exact Solution is a certified refurbished electronics marketplace shipping across Europe. We stock the best refurbished laptops from Apple, Dell, HP, and Lenovo — all fully tested and ready to ship.

https://dev.to/exactsolutionofficial/the-cursor-3-features-nobody-is-talking-about-yet-55e

Exact Solution — Wed, 20 May 2026 12:08:06 +0000

Exact Solution

May 20

The Cursor 3 Features Nobody Is Talking About Yet

#cursor #ai #webdev #programming

5 min read

The Cursor 3 Features Nobody Is Talking About Yet

Exact Solution — Wed, 20 May 2026 11:41:54 +0000

Everyone is writing about the Agents Window. The parallel agents. The cloud handoff. The rebuilt interface from scratch under the codename Glass.

Those are the headline features and they deserve the coverage. But after spending serious time in Cursor 3 since it shipped on April 2, 2026, the features that have actually changed how I work are not the ones in the announcement post.

Here are the Cursor 3 features that are quietly doing the most useful work — and that most developers have either not found or not fully understood yet.

1. Design Mode — Point at UI Elements Instead of Describing Them

This one is buried in the changelog and barely mentioned in the main announcement.

In the Agents Window, you can activate Design Mode to annotate and target UI elements directly in the browser. Instead of writing a prompt like "the button in the top right corner of the navigation bar that appears on hover" — you point at it. The agent knows exactly what you are referring to.

This sounds small. It is not small.

Anyone who has spent time trying to describe UI context to an AI model knows the problem. You spend more words explaining what you are looking at than it would take to just fix it yourself. Design Mode collapses that entirely. You point. The agent acts.

To access it: open the Agents Window with Cmd+Shift+P -> Agents Window, then activate Design Mode from the agent toolbar. It only works in the Agents Window, not the traditional IDE view — which is probably why most developers using the old IDE interface have not found it yet.

2. The PR Review Experience That Replaces Your Whole Review Workflow

Cursor 3 shipped a PR review experience that most developers are treating as a minor feature. It is not minor.

You can now take a PR from creation to merge entirely within Cursor. The agent reviews the changes, flags issues, suggests improvements, and tracks the full lifecycle of the PR without you switching to GitHub, back to the terminal, back to GitHub, back to the editor.

The context switching tax in code review is enormous and almost completely invisible because it has always been there. Every time you leave the editor to check a PR comment and come back, you pay a cost. Cursor 3 eliminates that context switch.

The Bugbot integration makes this sharper. With the high effort setting — which you can now customize per team or per individual — Bugbot finds significantly more bugs per run than default. The tradeoff is cost and time. But for critical PRs where a missed bug is expensive, the option to dial up the effort is genuinely useful and not something most PR review tools give you control over.

3. Parallel Agents on Plans — The Feature That Changes How You Scope Work

When you create a plan in Cursor 3, the agents execute steps in parallel where dependencies allow. This sounds like a performance improvement. It is actually a workflow change.

Because steps run in parallel, you start thinking about work differently. Instead of a linear sequence of tasks, you think about the dependency graph. What needs to be done before what? What can happen simultaneously?
This is how senior engineers think about complex work. Cursor 3 essentially externalizes that mental model into the tool. You write the plan. The tool figures out what can run in parallel. You watch multiple things get built at once.

The quick action pills that shipped alongside this — common workflow actions surfaced as one click options rather than typed commands — reduce the friction of directing parallel work significantly. Less typing, faster iteration, more time watching things actually happen.

4. Composer 2 Is the Real Engine — And Most Developers Do Not Understand What It Is

Cursor 3 gets the attention. Composer 2, which shipped on March 19 and powers Cursor 3's agents, is the part that actually explains why the agents feel different.

Composer 2 is not a wrapper around a frontier model. It is Cursor's own model — built on Kimi K2.5 from Moonshot AI as a base, then continued pre-training on a code heavy data mix, followed by large scale reinforcement learning in realistic Cursor sessions. Around 75 percent of the total compute came from Cursor's own training, not the base model.

What this means in practice is that Composer 2 has been trained on how developers actually use Cursor — not just on code in the abstract. It knows the tool it is running in. It understands the workflows. It has been reinforced on real Cursor sessions.

This is a fundamentally different approach from routing your requests to Claude or GPT and hoping the model understands your IDE context. Composer 2 was built for this environment specifically. The capability jump on complex multi-file tasks is noticeable — and it is not placebo.

5. Environment Version History — The Underrated Safety Net

This one shipped quietly in the most recent update and I have not seen anyone write about it yet.

Every development environment in Cursor now has its own version history that you can review and roll back. If an agent configures your environment incorrectly — installs the wrong dependency version, misconfigures a tool, breaks something in the setup — you can roll back to a previous environment state rather than debugging what changed.

For solo developers and small teams this is genuinely useful. Environment configuration bugs are some of the most time consuming to diagnose because the symptoms appear in your code but the cause is in your setup. Version history on the environment itself gives you a direct path back to a known good state.

Admins can also restrict rollback permissions to admins only — which matters for teams where environment consistency is critical and you do not want individual developers rolling back shared configurations without oversight.

The Feature I Am Still Watching

Cursor is rolling out automated environment configuration in private beta for Enterprise teams — where it inspects your repos, figures out the tools and dependencies required, and produces a configuration you can edit and version. As it configures your environment, it asks questions, flags missing credentials, and validates that your environment is set up properly.

This is not widely available yet. But if it works as described it solves one of the most painful parts of onboarding new developers or spinning up new projects — the environment setup that always takes longer than anyone planned and breaks in ways that are specific to the machine, not the code.

What Cursor 3 Actually Is

The announcement framed Cursor 3 as a unified workspace for building software with agents. That is accurate but understates the shift.
The traditional IDE view still exists and still works. You can switch back at any time. But the Agents Window represents a genuinely different model of how software gets built — you as the architect directing agents, not you as the typist writing every line.

The Agents Window, parallel execution, cloud agent handoff, Design Mode, and built-in Git are all meaningful additions that move Cursor from a smart IDE with AI toward something closer to an agent orchestration platform that happens to have an excellent IDE inside it. exactsolution
The features nobody is talking about are the ones that make that shift feel real in daily use rather than just impressive in a demo. Design Mode, PR review lifecycle, environment version history, parallel plan execution — these are the features that change Tuesday afternoon, not just the ones that change the keynote slide.

5 JavaScript habits that look clean but quietly wreck your code. Sequential awaits, unnecessary state, missing cleanup — real examples and fixes. https://dev.to/exactsolutionofficial/5-javascript-habits-that-look-clean-but-quietly-wreck-your-code-57i0

Exact Solution — Tue, 19 May 2026 12:32:28 +0000

Exact Solution

May 18

5 JavaScript Habits That Look Clean But Quietly Wreck Your Code

#javascript #react #ai #webdev

5 min read

5 JavaScript Habits That Look Clean But Quietly Wreck Your Code

Exact Solution — Mon, 18 May 2026 13:30:06 +0000

You have been writing JavaScript for a while now. Your code is readable. Your colleagues do not complain. Your pull requests get approved without much debate.

And yet something keeps going wrong in production that you cannot quite explain.

The problem might not be what you are doing wrong. It might be what you are doing right — in the wrong context.

Here are five habits that look perfectly reasonable and are actively making your codebase worse.

Using async/await everywhere without thinking about parallelism

This one is everywhere. And honestly it looks so clean that most people never question it.

Looks fine right? Three clean awaits. Very readable. Very modern.
Except you just made three sequential network calls that have absolutely no dependency on each other. You are waiting for the user to load before even starting to fetch posts. Then waiting for posts before even thinking about comments.

On a fast connection with a healthy server this adds maybe 100ms. On a slow mobile connection it adds 600ms. And users on slow connections are already struggling.

The fix is obvious once you see it:

Same result. All three requests fire simultaneously. I have seen this single change cut perceived load time in half on real production apps.
The irony is that sequential awaits feel more controlled. More readable. More intentional. Which is exactly why people keep writing them without thinking about what is actually happening under the hood.

2. Storing everything in useState when it is not actually state

React developers do this constantly. I did it constantly for longer than I would like to admit.

Something needs to persist across renders so you reach for useState. Makes sense. Except not everything that persists is actually state.

Derived values, computed results, values that come directly from props — none of these need to be in state. But they end up there anyway because useState is the first tool we reach for.

Now you need to keep this in sync with firstName and lastName manually. And you will forget. And then you will have a bug that only appears when the user updates their first name without their last name changing first. And you will spend 45 minutes debugging what should not exist at all.

Done. No state. No sync. No bug.
The rule I try to follow now — if a value can be computed from existing state or props, it should not be state. Every piece of unnecessary state is a future synchronization bug waiting to happen.

3. Writing utility functions inside components

This happens when you are moving fast and it feels fine in the moment.

Clean looking component. Self contained. Everything in one place.
Except formatDate gets recreated on every single render. Every time the parent re-renders, every time any state changes, every time anything touches this component — a brand new function is created and immediately thrown away.

On one component this is basically nothing. On a list rendering 200 UserCards with multiple utility functions each, you are creating and garbage collecting hundreds of functions per render cycle for no reason.
Move utility functions outside the component. If they need to be reused elsewhere, they were always going to end up there anyway. If they do not, at least they are created once.

The muscle memory of writing everything inside the component is hard to break. But once you start noticing the pattern it is impossible to stop seeing it.

4. Not cleaning up event listeners and subscriptions

This is the one that creates ghost bugs. The kind that appears three months after you shipped a feature and only happens on specific navigation patterns that your tests never covered.

Every time this component mounts it adds a resize listener. Every time it unmounts — which in a typical SPA happens constantly — the listener stays. Navigate to this page ten times and you have ten resize listeners all firing simultaneously calling handleResize on a component that no longer exists.

The cleanup function is not optional. It is the entire point.
I once inherited a codebase where certain pages became noticeably slower the longer you used the app. The cause was an analytics tracking listener being added on every route change and never removed. After about 20 minutes of normal app usage you had 80 to 100 duplicate listeners all firing on every user interaction.

Nobody had noticed because nobody tested long sessions. They opened the app, clicked around for 2 minutes, and called it done.

5. Using console.log for debugging and shipping it to production

This sounds too obvious to include. It is not.

console.log in production is not just a minor embarrassment. In tight loops, frequent event handlers, or anywhere with high call frequency it is a real performance drain. The browser has to format the output, write to the console buffer, and do this every single time even when the devtools are closed.

But the more common version of this problem is not the obvious console.log("user data:", user) sitting in your render function. It is the logging that was added during a debugging session six months ago, wrapped in some condition that seemed safe, and has been silently firing in production ever since.

If you are going to log, at least make it conditional. Better yet, use a proper logging library that handles environment awareness and gives you log levels you can actually control.
The real fix is a pre-commit hook or ESLint rule that flags console.log statements before they ever reach main. Set it up once and never think about it again.

Final thought

None of these patterns are obviously wrong when you first write them. That is the whole point.

Sequential awaits feel controlled. State feels like the right place to store things. Utility functions inside components feel self contained.

Missing cleanup feels like an edge case. Console logs feel temporary.

They all made sense at the time. They all compound over time.

The best code reviews are the ones where someone asks "why is this here" about something that felt completely natural when it was written. Build that habit yourself and you will catch most of these before they become production problems.

MacBook Pro 16-inch 2019 for Students: Good Choice or Too Much?

Exact Solution — Thu, 14 May 2026 11:39:01 +0000

Choosing the right laptop for student life depends on your study needs. Some students only need a laptop for assignments, online classes, browsing, and presentations. Others need stronger performance for design, programming, video editing, engineering, or creative work.

The refurbished MacBook Pro 16-inch 2019 can be a great option for students who need power, a large display, and long-term usability. But for basic users, it may be more than necessary.

Why Students May Like the MacBook Pro 16-inch 2019

The MacBook Pro 16-inch 2019 is a premium laptop with strong performance, a large Retina display, 16GB RAM, and 1TB SSD storage. This makes it useful for students who want one device for study, projects, entertainment, and even freelance work.

For normal student tasks like writing documents, using Google Workspace, attending online classes, researching, and preparing presentations, this laptop is easily powerful enough. It also performs well for heavier tasks such as coding, video editing, photo editing, music production, and design software.

Performance: Strong for Demanding Students

The MacBook Pro 16-inch 2019 Core i9 is best suited for students who need more than a basic laptop. If you are studying computer science, architecture, engineering, graphic design, photography, film, or media production, the extra performance can be useful.

The 16GB RAM helps with multitasking, while the 1TB SSD gives enough storage for apps, documents, university files, media, and large project folders. For students who work on creative or technical projects, this is a clear advantage.

Display: Great for Study and Creative Work

The 16-inch Retina display is one of the biggest benefits of this MacBook. A larger screen makes it easier to work with multiple windows, write assignments, edit videos, code, or attend online classes while taking notes.

For design and media students, the display quality is especially useful because it offers sharp visuals and good color accuracy.

Portability: Powerful, But Not Lightweight

The MacBook Pro 16-inch 2019 is portable, but it is not the lightest student laptop. It is bigger and heavier than a MacBook Air. If you carry your laptop all day between classes, this may matter.

However, if you mostly study at home, in the library, or at a desk, the larger screen and better performance can be worth the extra size.

Is It Too Much for Students?

For some students, yes. If you only need a laptop for browsing, notes, online classes, and basic assignments, a MacBook Air may be enough.

But if you want a laptop that can handle university work, creative projects, multitasking, and future professional use, the MacBook Pro 16-inch 2019 is still a strong choice.

Refurbished MacBook Pro: Better Value for Students

Buying a new high-performance MacBook can be expensive. That is why a refurbished MacBook Pro can be a smart choice for students who want premium performance at a better price.

You can explore refurbished electronics online or choose this MacBook Pro 16-inch 2019 Core i9 if you need strong performance and large storage.

Final Verdict

The MacBook Pro 16-inch 2019 for students is a good choice for those who need power, a large screen, and reliable performance. It is ideal for creative, technical, and professional study fields.

However, it may be too much for students with only basic needs. If you want a lightweight laptop for simple tasks, choose a MacBook Air. If you want performance, storage, and a premium display, the MacBook Pro 16-inch 2019 is still worth considering.
https://www.exactsolution.com/products/macbook-pro-16-inch-inch-2019-intel-core-i9-23ghz-and-amd-radeon-pro-5300m-16gb-ram-ssd-1tb-space-grey-69afcd2477c606cf7dcdbb64