DEV Community: Mike Written | AI Trends 24

I Stopped Writing Classes in JavaScript 3 Years Ago — Here's What Happened

Mike Written | AI Trends 24 — Mon, 29 Jun 2026 14:39:43 +0000

Three years ago, I made a decision that my senior colleagues thought was career suicide.

I stopped writing ES6 classes in JavaScript.

No more class Foo extends Bar. No more constructor(). No more this.something = something scattered across 40-line boilerplate blocks.

Here's what actually happened.

The Problem With Classes in JS

JavaScript classes are not "real" classes. They're syntactic sugar over prototypal inheritance — a fact the language tries hard to hide from you.

When I was writing class-heavy code, I kept running into the same bugs:

this behaving unexpectedly inside callbacks
Accidentally mutating shared state on the prototype
Confusing super() chains that broke silently
Unit tests that required elaborate mocking just to instantiate a single object

The deeper I went, the more I realized: I wasn't using classes because they were the right tool. I was using them because they felt familiar from Java and Python.

What I Switched To

1. Plain functions and closures

Instead of:

class Counter {
  constructor() {
    this.count = 0;
  }
  increment() {
    this.count++;
  }
  getCount() {
    return this.count;
  }
}

I now write:

function createCounter() {
  let count = 0;
  return {
    increment: () => count++,
    getCount: () => count,
  };
}

No this. No new. No surprises. The state is genuinely private — not just by convention.

2. Pure functions for business logic

Most "methods" in my old classes were just transformations on data. Once I untangled state from behavior, almost everything became a pure function:

// Before
class OrderProcessor {
  applyDiscount(order, percent) {
    order.total = order.total * (1 - percent / 100);
    return order;
  }
}

// After
const applyDiscount = (order, percent) => ({
  ...order,
  total: order.total * (1 - percent / 100),
});

Testable in one line. No setup. No teardown.

3. Composition over inheritance

Inheritance hierarchies were my biggest time sink. Deep extends chains mean a change anywhere can ripple unpredictably. I replaced them with simple function composition:

const withLogging = (fn) => (...args) => {
  console.log(`Calling with`, args);
  return fn(...args);
};

const withValidation = (fn) => (...args) => {
  if (!args[0]) throw new Error('First argument required');
  return fn(...args);
};

const processOrder = withLogging(withValidation(applyDiscount));

What Actually Changed After 3 Years

✅ My code reviews got faster. Reviewers don't have to trace class hierarchies to understand what a function does.

✅ My tests got simpler. Pure functions don't need mocking frameworks. You pass data in, you get data out.

✅ Onboarding juniors got easier. "It's a function that takes X and returns Y" is always easier to explain than "it's a class that extends this abstract base..."

✅ I stopped fighting this. Seriously. Arrow functions and closures just eliminated a whole category of bugs.

❌ Some things still need classes. React components (historically), custom DOM elements, certain library integrations — classes have a legitimate home. I'm not dogmatic.

The Real Lesson

The goal was never "avoid classes." The goal was to write code that's easy to read, test, and change.

For 90% of my day-to-day JavaScript, functions and plain objects accomplish that better than classes do.

If you're class-heavy right now, I'm not saying throw it all away. But next time you reach for class, ask yourself: would a function and a plain object work just as well here?

More often than not, the answer is yes.

Have you moved away from classes in JavaScript? Or do you think I'm totally wrong? Drop your thoughts in the comments — I read every one.

Claude Cowork: The Setup Guide I Wish I'd Had on Day One

Mike Written | AI Trends 24 — Sun, 21 Jun 2026 02:46:39 +0000

I made the mistake almost everyone makes with Cowork the first time.

I opened it, pointed it at my Downloads folder, typed "clean this up," and waited. What came back was fine. Not bad. Just fine — the kind of result that makes you think "okay, neat trick" and close the tab instead of "I need to use this every day."

The problem wasn't Cowork. It was that I was using it exactly like Claude Chat — vague instruction, hope for the best — except Cowork isn't built for that interaction style at all. It's built for something closer to delegation than conversation, and once I understood that distinction, everything about how I used it changed.

This is the setup I'd give myself if I were starting over today.

First, Understand What You're Actually Working With

Before any setup tips, the mental model matters more than any individual setting.

Claude Chat is reactive — you prompt, Claude answers, inside a thread. Good for writing, summarizing, reasoning through ideas. The moment a task depends on many files, repeated steps, or actions across multiple tools, the chat interface starts to show its limits.

Claude Code is the other end — terminal-first, built for software engineering work: reading codebases, running commands, debugging, writing tests.

Cowork sits in a different place entirely. Instead of bringing everything into a chat thread, you point Claude at the workspace where the work already lives — local folders, connected tools, email, calendars, Slack, Google Drive. This changes the interaction from prompting to delegation. The goal stops being "get a response" and becomes "define a finished deliverable, give Cowork the context and boundaries it needs, and let it execute."

That's the shift that matters. Chat is task-first — you describe an action. Cowork works better output-first — you describe the finished thing you want to exist.

Setup Step 1: Stop Using Documents or Desktop as Your Workspace

This sounds like a small detail. It isn't.

Create a dedicated project folder specifically for Cowork — something like a clearly named folder outside your general Documents or Desktop clutter — and grant Cowork access only to that folder, denying everything else.

The reason this matters: every major workflow should live in its own project with dedicated folder access, which prevents context bleed when you're running multiple projects at once. If Cowork can see your entire Desktop, it's also reasoning over every unrelated file sitting there, and you've made its job harder for no benefit. A clean, scoped folder per project keeps each workflow focused on exactly what it needs.

Setup Step 2: Write Your Global Instructions Before You Do Anything Else

This is the single most skipped step, and it's the reason most people's first Cowork experience feels underwhelming.

Inside Cowork's settings, there's a place for global instructions — persistent context that applies across everything you do, not just one task. This is where you set tone, output preferences, and constraints once, instead of re-explaining them every single time.

A genuinely useful starting template looks something like this:

Tone: Direct, no unnecessary preamble.
Output format: Prefer clean, finished deliverables
over draft explanations unless I ask for drafts specifically.
File handling: Never delete anything without explicit
confirmation first.
When uncertain: Ask one clarifying question rather
than guessing and producing the wrong output.
Always tell me what you're about to do before
doing anything irreversible.

That last line matters more than it looks. A global guardrail prompt is what makes Cowork meaningfully safer to use for anything beyond trivial tasks — because unlike Claude Code in a sandboxed environment, Cowork is working with your actual files, on your actual machine.

Setup Step 3: Write the Brief, Don't Just Type a Task

Here's the actual mindset shift that fixed my underwhelming first experience.

Chat-style prompting looks like: "Read these files and summarize them." That's a task. It works fine in Claude Chat.

Cowork-style prompting looks like defining a finished deliverable: what the output should look like, what files or sources it draws from, what's explicitly out of scope, and what "done" actually means.

For something like the classic messy-folder cleanup, the difference between a task and a brief looks like this:

Task-style (weak): "Clean up my downloads folder."

Brief-style (works):

Goal: Organize my Downloads folder into a clean structure.

Categories: Sort into folders by file type — Documents,
Images, Installers, Archives, Other.

Rules:

Anything older than 2 years and unopened goes into an "Archive — Review" folder, not deleted
Never delete anything outright
Show me your plan before executing
Flag any file you're unsure how to categorize instead of guessing

Output: A cleaned folder structure plus a short
summary of what moved where.

The brief-style version takes 90 extra seconds to write. It's also the difference between a result you trust and a result you have to double-check file by file afterward.

Setup Step 4: Use Projects to Keep Workflows From Bleeding Into Each Other

If you're using Cowork for more than one type of recurring work — say, content research and inbox triage — don't run both out of the same project.

Task isolation through separate projects, each with dedicated folder access, is what prevents one workflow's context from contaminating another. Your content research project doesn't need to know anything about your email triage setup, and keeping them separate means each one stays sharp at its specific job instead of getting diluted by irrelevant context.

Setup Step 5: Start With One Scheduled Task, Not Five

Once the basic setup works, the temptation is to automate everything at once. Resist that.

Scheduled tasks are genuinely one of Cowork's most useful features — recurring workflows like a weekly metrics digest, a Monday inbox triage, or a Friday status report pulled from Slack and Drive, designed once and run on a cadence without you touching it again.

But there's a real mechanical detail worth knowing: scheduled tasks run on wake — if your machine is asleep when a task is due, it skips and re-runs on the next boot rather than running continuously in the background. If you're expecting a 6am report and your laptop is closed at 6am, it won't happen until you open it.

Start with exactly one recurring task. Something low-stakes enough that if it goes wrong, nothing breaks — a weekly summary, not a financial report. Get comfortable with how it actually behaves before stacking five automated workflows on top of each other.

What Cowork Genuinely Isn't Good At Yet

In the interest of an honest guide, not a sales pitch — a few things to set expectations on:

Anything requiring real-time responsiveness. Per-step latency adds up fast enough that tasks needing instant back-and-forth aren't a good fit.

Irreversible actions without a safety net. Cowork has no built-in rollback. Don't hand it access to live financial systems, production databases, or anything where a mistake can't be undone, without approval gates explicitly built into your brief.

High-precision creative execution. Use Claude for the planning and structure; keep pixel-level creative execution in human hands for now.

Desktop software with no API or MCP bridge. If a tool isn't web-accessible or connected through MCP, Cowork genuinely struggles to interact with it.

The Mental Model Worth Keeping

If you take away one idea from this entire setup guide, it's this: stop thinking of Cowork as "an assistant that writes." Start thinking of it as "an assistant that does."

That single reframe is what separates a frustrating first session from a tool you end up relying on daily. Chat answers questions. Cowork finishes deliverables. Once your prompting style matches the one you're actually using, the experience changes completely.

I write about Claude, Cowork, and practical AI workflows — every week in my free newsletter.

👉 Subscribe here →

If you want 75 tested Claude prompts for coding, research, productivity, and more:

👉 The Claude Playbook →

Why I Stopped Using ChatGPT for Product Research — Claude Does This Better

Mike Written | AI Trends 24 — Sun, 14 Jun 2026 14:27:59 +0000

I want to be upfront about something before we start.

I'm not here to tell you ChatGPT is bad. It isn't. I use it. Many people I respect use it. Anyone who writes a "ChatGPT vs Claude" piece with a definitive winner is either selling something or hasn't tested both seriously.

What I am here to tell you is this: for one specific category of work — research, synthesis, and deep analysis — I switched from ChatGPT to Claude six months ago. And I haven't gone back.

Here's exactly what happened and why.

How This Started

I run a newsletter and publish on Medium. My work is research-heavy — I'm constantly synthesizing information, comparing tools, building arguments from multiple sources, and writing long-form pieces that need to hold up to scrutiny.

For the first year, I used ChatGPT for almost everything. It was fast, familiar, and good enough.

Then I started testing Claude seriously. Not for writing — I'd tried that before and the difference felt marginal. But for research.

The difference wasn't marginal.

The Test I Did

Simple setup. I gave both tools the same research task: synthesize everything important about a topic I was writing about, identify the key debates, find the strongest counterargument to the mainstream view, and tell me what I was probably missing.

I did this across 12 different research tasks over 30 days. Topics ranging from AI tools to content strategy to technical concepts I needed to explain to non-technical audiences.

I tracked:

Depth of the response
Accuracy of claims
Whether it surfaced insights I wouldn't have found myself
How useful the output actually was when I sat down to write

*Here's what I found.
*

Where Claude Won — And Why

*1. It Holds More Context Without Losing the Thread
*
This is the biggest practical difference for research work.

Claude's context window is 200,000 tokens by default — versus ChatGPT's 128,000 at the standard paid tier. More importantly, research from multiple independent sources shows Claude maintains accuracy across its full context window, while GPT models show some degradation in the middle of very long conversations.

In practice: when I paste a long document and ask Claude a specific question about it, the answer reflects the whole document. With ChatGPT, on long inputs, I occasionally got answers that felt like they were based on the beginning and end — not the middle.

For research, where you're feeding in multiple sources and asking for synthesis, this matters.

*2. It Reads Between the Lines Better
*
Here's a specific example.

I gave both tools the same task: analyze this industry report and tell me what the authors believe but aren't explicitly saying.

ChatGPT gave me a good summary of what the report said.

Claude gave me the summary — and then told me three things the data implied that the authors appeared to have deliberately avoided stating directly. One of those observations became the central argument of the article I was writing.

This pattern repeated across multiple research tasks. Claude seemed better at the adversarial reading that good research requires — not just what's there, but what's missing, what's implied, what's being carefully avoided.

*3. It Pushes Back More Honestly
*
This one is subtle but important.

When I told ChatGPT my hypothesis and asked it to stress-test it, it found some counterarguments — but they felt polite. Manageable. The kind of objections that were easy to address.

When I gave Claude the same hypothesis and the same instruction, it found the uncomfortable one. The objection I hadn't thought of that actually required me to rethink part of my argument.

I don't know exactly why this happens. But after 30 days of testing, the pattern was consistent enough that I started using Claude specifically for the "what am I missing" and "what's wrong with this" questions.

*4. The Writing Quality of Summaries Is Better
*
This is the one that surprised me most, because I expected this to be a wash.

When I ask Claude to synthesize research into a summary I can actually use in an article, the output reads like writing. It has a point of view. The sentences have varied structure. It doesn't feel like a list wearing a paragraph costume.

ChatGPT's summaries are accurate and well-organized — but they often feel templated. Clean, but formulaic. Professional sources consistently note that Claude produces more natural prose with better tone matching, while ChatGPT tends to follow instructions literally and produce clean but formulaic output.

For research I'm going to build writing from, Claude's output is closer to what I'd write myself — which means less rewriting.

Where ChatGPT Is Still Better

I told you I'd be honest, so here's where ChatGPT wins for my use case:

Real-time information. ChatGPT's browsing is more comprehensive than Claude's. If I need current data — recent news, updated statistics, things that happened last week — ChatGPT is better.

Brainstorming at speed. When I need a lot of ideas quickly without needing depth, ChatGPT generates faster and wider. Claude goes deeper. For early-stage brainstorming where quantity matters more than quality, ChatGPT is the right tool.

Ecosystem integrations. ChatGPT connects to more third-party tools. If your workflow depends on integrations — code interpreters, specific apps, Canvas for document editing — ChatGPT's ecosystem is broader.

Image generation. DALL-E is built in. Claude doesn't have this.

The Honest Conclusion

Here's the thing most comparison articles don't say:

The gap between Claude and ChatGPT on most tasks in 2026 is smaller than it's ever been. Both are excellent. Multiple independent sources confirm that on most benchmarks, the two models are within a few percentage points of each other.

Anyone claiming one is definitively better across the board is either not testing both seriously or has an incentive to pick a winner.

What I can tell you is this:

For research-heavy work — deep synthesis, long document analysis, finding the uncomfortable insight, writing summaries that read like writing — Claude is the better tool for me. That's based on 30 days of parallel testing across 12 real research tasks.

For everything else, I use whatever fits the task. Sometimes that's Claude. Sometimes that's ChatGPT. Increasingly, serious AI users split tasks between them rather than forcing one tool to do everything.

The question isn't which AI is better.

The question is which AI is better for the specific thing you're trying to do right now.

For research? Claude.

The 5 Research Prompts I Use With Claude Every Week

If you want to try this yourself, here are the exact prompts I use for research work:

*Prompt 1 — The Deep Synthesis:
*
You are a senior research analyst.

I need to understand [TOPIC] for [PURPOSE].

Give me:

The most important thing to understand first
The 3 key insights most people miss
What the experts genuinely disagree about
The strongest argument against the mainstream view
What changed in the last 12 months that matters
The one piece of information that would change everything if it turned out to be wrong

Go deep. Don't summarize what I could find in 5 minutes.

*Prompt 2 — The Uncomfortable Question:
*
Here is my argument/hypothesis: [YOUR ARGUMENT]

Find the strongest counterargument I haven't considered.
Not the obvious objections — the one that would actually
require me to rethink my position.

Then tell me: is it fatal to my argument, or can it
be addressed?

*Prompt 3 — The Between the Lines Reader:
*
Here is a document/report I need to analyze:
[PASTE DOCUMENT]

Tell me:

What it explicitly says (brief summary)
What the data implies that isn't stated
What the authors appear to have deliberately avoided
What's missing that should be here
What I should be skeptical about

*Prompt 4 — The Gap Finder:
*
I've been researching [TOPIC] and here's what I know:
[PASTE YOUR NOTES]

What am I missing?
What important angle have I not considered?
What would a domain expert tell me that isn't in
the mainstream coverage of this topic?

*Prompt 5 — The Usable Summary:
*
Synthesize the following research into a summary
I can actually write from:
[PASTE YOUR SOURCES]

Write it as a knowledgeable colleague would explain
it — not as a list, not as bullet points.
Prose that has a point of view.
Include the 3 most important insights and
the 1 most important caveat.

The right tool for research isn't the one with the most features. It's the one that helps you think better.

For me, that's Claude.

I write about Claude, practical AI tools, and workflows that save real time — every week in my free newsletter.

👉 Subscribe here →

And if you want 75 copy-paste Claude prompts for research, writing, coding, and more:

👉 The Claude Playbook →

I Use These 7 Claude Prompts Every Day as a Developer — Copy Them

Mike Written | AI Trends 24 — Thu, 11 Jun 2026 10:30:22 +0000

I've been using Claude seriously for about six months now.

Not casually — seriously. Every bug, every code review, every documentation task, every technical decision.

After six months of daily use, I've narrowed it down to 7 prompts I actually reach for every single day. Not the flashy ones. The ones that quietly save me 2-3 hours of work.

Here they are — copy them directly into Claude.

*1. The Bug Finder That Explains Itself
*
Most AI bug-finders just show you the fix. This one explains the mental model you were missing — which means you stop making the same mistake.

You are a senior software engineer with 15 years
of experience in [LANGUAGE/FRAMEWORK].

Here is my code:
[PASTE CODE]

Find every bug — including ones not causing errors yet.
For each bug:

What's wrong (exact location)
WHY it's wrong (the mental model I'm missing)
The corrected code with comments

Don't just fix it. Teach me why it broke.

Why it works: The "teach me why" instruction changes the output from a patch to actual learning.

*2. The Code Review I Actually Want
*
Not "looks good!" — the review that catches what will break at scale.

You are a lead engineer doing a thorough code review
before production deployment.

Code: [PASTE CODE]
Context: This will handle [EXPECTED LOAD/SCALE]

Review for:

Logic errors (including latent bugs)
Security vulnerabilities — be specific
Performance at scale
Edge cases I haven't handled
What a malicious user could do with this

Format: Issue → Severity (Critical/High/Medium/Low)
→ Why it matters → The fix

End with: the single highest-risk thing in this code.

*3. The Function Writer That Saves Me From Blank Page
*
I know what I want the function to do. I don't want to think about the syntax.

You are an expert [LANGUAGE] developer.

Write a function that does:
[DESCRIBE IN PLAIN ENGLISH]

Input: [DESCRIBE INPUT]
Output: [DESCRIBE OUTPUT]
Edge cases to handle: [LIST THEM]

Also:

Add comments explaining the logic (not the syntax)
Show one working example call
Write 3 unit tests

Why it works: The unit tests request is the part most people skip. Getting them for free changes how fast you ship.

*4. The Error Message Translator
*
I've spent more time on cryptic error messages than I want to admit. This prompt ends that.

I'm getting this error:
[PASTE EXACT ERROR]

My code:
[PASTE RELEVANT CODE]

Setup: [LANGUAGE/FRAMEWORK + VERSION]
What I was doing when this happened: [DESCRIBE]

Tell me:

What this error means in plain English
The most likely cause in MY code specifically
Step-by-step fix
How to prevent this type of error going forward
Other possible causes if the first fix doesn't work (in order of likelihood)

Why it works: The "in my code specifically" instruction stops Claude from giving you generic Stack Overflow answers.

*5. The SQL Query Builder That Doesn't Waste My Time
*
You are a SQL expert specializing in [PostgreSQL/MySQL/BigQuery].

I need a query that does:
[DESCRIBE IN PLAIN ENGLISH]

My schema:
Table: [NAME]
Columns: [LIST WITH DATA TYPES]

Requirements:

Will run on [TABLE SIZE] rows
Performance matters — optimize it
I need: [SPECIFIC OUTPUT FORMAT]

Give me:

The complete query
Plain English explanation of how it works
Any indexes I should add to speed it up
How to modify it if I need [COMMON VARIATION]

*6. The Context Template I Paste at the Start of Every Session
*
This is the one most developers don't know about — and it's the highest-leverage habit I've built.

Claude doesn't remember previous conversations. Every session starts from zero. Most developers waste the first 10 minutes re-explaining their stack.

Before we start, here's my context:

Stack: [YOUR TECH STACK]
Current project: [WHAT YOU'RE BUILDING]
Experience level: [YEARS + BACKGROUND]
Preferences:

Show working code examples, not pseudocode
Explain tradeoffs, not just solutions
Be direct — skip the preamble
When uncertain, give your best answer and flag the uncertainty

Confirm you have this, then ask what I need.

Paste this at the start of every session. It takes 15 seconds. The output quality difference is real.

*7. The Legacy Code Explainer
*
You've inherited code you didn't write. You need to understand it fast. This prompt is for that moment.

I've inherited this legacy code and need to understand it:
[PASTE CODE]

Tell me:

What does this code do? (plain English summary)
What problem was it written to solve?
Step-by-step: how does it actually work?
What would break if I changed [SPECIFIC PART]?
What parts are dangerous to touch and why?
If you were modernizing this — what would you change first, and what would you leave alone?

Assume I'm a competent developer who just doesn't
know this specific codebase.

One Thing I'd Add

All 7 of these prompts follow the same structure: role → specific context → exact deliverable → what NOT to do.

That's it. That's the prompting pattern that separates "Claude is pretty good" from "Claude is indispensable."

The role tells Claude who to be.
The context tells it what's actually real.
The deliverable stops vague answers.
The constraint stops the output you don't want.

Master that structure and you'll write your own prompts that work just as well.

If you found these useful, I've put 75 more tested prompts (covering data analysis, ML workflows, productivity, and tech writing) in one place.

👉 The Claude Playbook →