The old argument is dead

For a long time the advice was: specialize. Pick one language, go deep, become the expert. That made sense when writing code was the bottleneck. If it took a week to build a feature, the person who could do it in three days had a real edge.

That world is over. I was an early user when ChatGPT launched. Within the first few weeks, I made my first $1,000 just by using it the generalist way: not deep expertise in one thing, but the ability to connect problems across domains with a tool that amplified whatever skill I pointed it at. Design briefs, code scaffolding, data cleaning, client proposals. The people who benefited most from AI were not the specialists. They were the generalists who knew enough about enough to aim it at the right problems.

Now I live inside Claude Code and Codex most of my working day. The code itself is no longer the hard part. What is hard is knowing what to build, how systems connect, where the failure points are, and how to keep something running reliably after the first version ships.

I have built scrapers in Python, APIs in Node, frontends in React and Next.js, automation workflows in n8n, data pipelines that land in Postgres and BigQuery, and design work that I would do for free because I genuinely enjoy it. None of that breadth was planned. It accumulated because every project demanded a different tool, and I learned each one by shipping something that depended on it.

That is the generalist advantage. Not knowing everything. Knowing enough about everything to see how the pieces fit.

What AI changed

When I started freelancing three years ago, clients hired me because I could write the code. Now they hire me because I can architect the system. The code is the easy part. Claude Code writes a working scraper in 10 minutes. What it does not do is:

  • Decide whether the project needs a scraper, an API call, or a data vendor
  • Design the schema normalization layer so output from 12 different sources looks identical
  • Figure out that the bottleneck is not the scraper but the delivery pipeline that chokes on 50,000 rows
  • Notice that the county website changed its URL structure at 2 AM and the monitoring should have caught it
  • Know that the client's CRM webhook has a 30-second timeout and you need to batch the write-back

These are architecture decisions. They require understanding how databases work, how APIs fail, how browsers render, how proxies route, how CRMs ingest, how cron jobs break, and how clients actually use the data downstream. No single-language specialist knows all of that. A generalist who has built across the stack does.

Why "just hire four specialists" does not work

The alternative to a generalist is a team. The client who needs a scraper, a pipeline, a database, and a dashboard hires four people: one for the scraping, one for the database, one for the automation, one for the frontend.

The work gets done. But the handoffs multiply. The scraper developer builds the output in a format the database developer did not expect. The automation engineer discovers the webhook the scraper team built has no error handling. The frontend developer gets the data but the schema changed last week and nobody told them. Four people, four communication gaps, four places where context gets lost.

One generalist who builds and owns the entire thing eliminates all of that. One person who knows why the scraper writes to this table, why the schema looks like this, and why the delivery goes to that webhook. The result is more coherent, usually cheaper, and definitely faster to debug when something breaks at 2 AM.

The premium is not in any single skill. The premium is in eliminating handoffs.

Design is where it started

I do not mention this enough: design is where I started. Not development. Not scraping. Design.

I would spend hours pushing pixels for no reason other than I enjoyed it. Layout, typography, color, spacing. It was the first thing I ever did on a computer that felt like creating rather than consuming. And it is still the only thing I can do for free without it feeling like work.

That background shapes everything I build now. When I deliver a client dashboard, it does not look like a developer built it. When I build a landing page, the spacing system is intentional, the typography is paired, the interaction design has a reason behind it. When I scope a data pipeline, I think about what the person consuming the output will actually see and whether the delivery format respects their workflow.

Most developers treat the frontend as an afterthought. Most designers treat the backend as someone else's problem. Having started on the design side and moved into development means I see both halves of every project. That is not a skill you learn from a course. It is a perspective you build by doing both for years.

What I actually use day to day

This is not a theoretical argument. Here is what a typical week looks like:

Python for scraping, data processing, and anything that touches raw data extraction. Playwright and requests for the actual scraping. pandas or polars for data cleaning when the volume warrants it.

TypeScript and Next.js for anything web-facing. This site, client dashboards, API endpoints. React for interactive components. ScrapeBase, the API I built at scrapebase.io, runs on this stack. It started as a weekend project and grew into a product with 16 platform endpoints because I could build both the scraping backend and the developer-facing API in the same codebase. A pure backend developer would have shipped the endpoints. A generalist ships the endpoints, the docs page, the landing page, and the billing integration.

n8n for workflow automation when the logic is "if this, then that" and the client wants to see it visually. Webhooks, conditional routing, scheduled triggers. Faster to build and easier for clients to understand than custom code.

SQL (Postgres, BigQuery) for anything that stores or queries data. Every recurring pipeline I build writes to a database, not a CSV.

Claude Code and Codex for first drafts of everything. I write the architecture, the AI writes the implementation, I review and fix. My output per day roughly doubled when I started working this way. The skill is not typing faster. The skill is reviewing faster and catching what the AI gets wrong.

None of these make me an expert in any single one. All of them together make me the person who can deliver a complete system, not just a component.

The generalist premium

There is a pricing dynamic that works in the generalist's favor. A specialist charges for one piece. A generalist charges for the whole system. The client who needs a scraper, a pipeline, a database, and a dashboard has two options:

Option A: Hire 3-4 specialists. Coordinate handoffs. Manage communication. Accept that nobody owns the full picture. Total cost is the sum of the parts plus the coordination overhead.

Option B: Hire one generalist who builds and owns the entire thing. One point of contact. One person who knows why the scraper writes to this table, why the schema looks like this, and why the delivery goes to that webhook. Total cost is usually less than Option A, and the result is more coherent.

The premium is not in any single skill. The premium is in eliminating handoffs.

When specialization wins

I am not arguing that specialization is wrong. If you are building a machine learning model, you want a specialist. If you are optimizing a database that handles 10 million queries per day, you want a specialist. If you are doing anything at the frontier of a single domain, depth beats breadth.

But most of the projects I work on are not at the frontier. They are at the intersection. A scraping project is also a data engineering project is also an automation project is also a delivery project. The frontier is where the pieces connect, not where any single piece goes deepest.

The bottom line

The generalist advantage in 2026 is that AI has commoditized the code. What it has not commoditized is the judgment to choose the right architecture, the experience to predict where it will break, and the breadth to build the whole thing without handoffs.

I started with design. I moved to development. My brother pulled me into scraping. I learned databases because projects needed them. I learned automation because clients asked for it. I learned to build with AI because it made me faster. None of it was a career plan. All of it was "this project needs this, so I learned it."

Three years and 200+ projects later, the breadth is the product. Not any single skill inside it.