#153: The Web Developer's Job Is Moving Up the Stack

Meet the expert: Chris Barin

Chris Barin, who penned the write-up below, is a professional web and app designer, an Adobe Certified Instructor, and a Certified Photoshop Expert with nearly 10 years of experience. Self-taught, he has earned the trust of over 300,000 students worldwide with a hands-on, no-nonsense approach focused on getting maximum results with minimal effort. He started out as a freelance web designer and today runs a 20-strong Android design studio whose apps have surpassed 100 million downloads.

I have been teaching design since 2013, with a focus on web and app design, and I have worked on both sides of the client relationship: as a freelance designer delivering the work and as an entrepreneur hiring people to deliver it. That perspective has made the current AI conversation feel strangely familiar.

Every day brings another announcement. A model can build a landing page, create a polished product image, generate a component, or connect to a design tool. The implied message is always the same: learn this now or fall behind.

That is a powerful way to create anxiety and sell more pricey design subscriptions from AI companies that are incredibly money-hungry.

The web professionals who thrive in the AI era will not be the ones who subscribe to every platform or memorize every feature. They will be the ones who move their attention up the stack: away from producing shiny stuff and more toward understanding the problem, directing the work, verifying the result, and improving the business outcome.

In short: help the company grow. Help the company achieve its goals. The company didn’t hire you to create a sleek product that’s going to look great in your portfolio. No, they hired you to increase their conversion rate, reduce churn, improve onboarding & retention, and other clear-cut objectives.

AI does not remove the need for developers. It changes where good developers create the most value.

Speaking of which, a few stories this week get at exactly that shift:

🔍 Anthropic Is Watermarking Claude's Text, Here's Where It Hides
⚡ MCP Just Went Stateless, and That Changes Everything
💻 Airtable Sold for $1.28B, Is No Code Already Dead?
🕵️ We Put GitHub Copilot Behind a Proxy, Here's What It's Really Sending
📦 Docker Sandboxes Make YOLO Mode Actually Safe for Coding Agents
📄 anydoc Converts Any Office File to Markdown, Right in Your Browser

Consider a routine request: build a promotional landing page for a new product. A capable AI tool can one-shot it – meaning it can create something awesome based on one single prompt. It can scaffold the page, write responsive CSS, suggest copy, create image variations, and revise the result without becoming tired or defensive.

From a client’s perspective, that combination is difficult to ignore. The turnaround is fast, the initial quality is often acceptable, and requesting another version creates almost no social friction. The tool does not sigh when the client changes his mind 10 times and then comes back to the initial version.

This does not mean the entire web development profession has become a commodity. It means that parts of the job that were expensive because they consumed time are becoming cheaper. Boilerplate, first drafts, routine transformations, and basic variations are no longer where a developer can safely build a long-term advantage.

Think of AI as an electric screwdriver. It can help an experienced person assemble something much faster. It can also help an inexperienced person damage the material. The tool amplifies the judgment of the person holding it.

The important question is therefore not, “Can AI build this page?” It is, “Who can tell whether this is the right page, for the right audience, with the right trade-offs?”

Suppose an online food brand asks for a new product page. A feature-focused team might discuss the framework, component library, image carousel, nutrition table, and checkout integration. Those choices matter, but they do not answer the customer’s real questions.

The customer is not buying 12 grams of fiber. That’s too zoomed in. The client is looking for a better breakfast, fewer digestive problems, or a way to eat well on a busy morning. The business does not merely need a nutrition component. It needs a page that connects the product to one of those motivations and then makes purchasing feel safe and easy.

This is where an intermediate developer can become far more valuable than someone who simply converts a ticket into code. Ask what behavior the feature is meant to change. Ask which audience matters most. Ask what evidence would show that the change worked.

Before generative AI, a team might have had enough time and budget to explore two or three substantially different directions. Now it may be possible to produce ten. That sounds like a simple productivity win, but volume alone is not valuable. Ten untested variations are just a larger pile of opinions.

The real advantage is faster learning.

Instead of asking AI for ten cosmetic versions of the same hero section, create three distinct hypotheses. One page can emphasize convenience. Another can lead with the customer’s frustration. A third can focus on trust, proof, and product quality. Decide in advance which metric each direction is meant to influence, then instrument the experience and observe what happens.

This changes the developer’s role. You are not only implementing the selected design. You are helping the team create a system in which decisions can be tested. Feature flags, analytics events, performance budgets, accessible interaction states, and clean experiment boundaries become part of product thinking rather than chores added at the end.

There is an important limit here: more variants do not automatically create reliable evidence. A low-traffic product may not support a complex experiment, and small metric movements can be noise. The point is not to A/B test everything. The point is to replace taste and confidence with hard data.

Use AI to expand the option space, then use engineering discipline to reduce uncertainty.

Tool comparison can become a full-time hobby. One developer says a platform is astonishing; another says it is unusable. Both are right. Results vary with the task, the context provided, the codebase, model updates, and the way a particular person works.

For most developers, the gap between learning a tool and constantly switching among several strong tools is more important than the gap between the tools themselves. Otherwise said – practice one kick ten thousand times, exactly like Bruce Lee famously said.

Choose a platform that fits your budget and environment. Give it real work for a few weeks. Learn where it tends to misunderstand your architecture, invent APIs, broaden scope, or produce code that looks finished before it is production-ready. Create a repeatable way to supply context and define what success means.

The most important skill is not knowing which AI platform tops the charts today. It is knowing how to frame your work, constrain it, and verify it when the tools change tomorrow.

When output becomes cheap, verification becomes more important. “The page looks right” is not a sufficient completion signal for work that affects real users.

Before asking an AI to implement a meaningful change, write down five things:

• The user problem: What frustration or unmet need are we addressing?

• The intended change: What should the user be able or more likely to do?

• The constraints: What must remain stable, secure, accessible, and fast?

• The done signal: Which tests, checks, and acceptance criteria must pass?

• The learning signal: Which metric or qualitative evidence will we examine after release?

This short brief is useful even if you never show it to an AI. It forces the team to separate an implementation request from a product decision.

It also gives automated tools something concrete to work against. Type checks, tests, lint rules, accessibility checks, performance budgets, schemas, and observable acceptance criteria turn part of the team’s judgment into a repeatable gate. They do not eliminate human review, but they prevent reviewers from carrying every requirement in their heads.

The goal is not autonomous coding at any cost. The goal is delivery that you can count on.

A tool badge ages quickly. A case study built around an outcome does not.

If your portfolio says you used a particular framework or AI platform, it proves that you encountered the tool. If it explains how you reduced checkout friction, improved task completion, made a page measurably faster, increased qualified sign-ups, or reduced support requests, it shows that you understand why the work exists.

Getting that evidence requires curiosity after the pull request is merged. Ask for access to the relevant analytics. Talk to design, marketing, support, and operations. Watch how the feature behaves in production. Propose a small follow-up change that is inexpensive to test. Record what worked, what failed, and what you would do differently.

This is one reason proximity to the business matters. When developers only receive isolated tickets, they see requirements. When they talk to the people around the product, they see patterns: the repeated customer question, the manual workflow everyone accepts, the form users abandon, or the internal tool that costs hours every week.

Being an introvert is no longer an option. You have to talk to people and get their perspective. Clients have many choices when it comes down to skilled developers. Your moat now becomes how affable you are. How you make the client feel like. How you interact with his team. Soft skills are the biggest thing in an AI future.

You do not need to reinvent your role or become a product manager. Start with one feature in your next sprint.

Before implementation, replace the ticket title with a one-sentence outcome. Identify one meaningful constraint and one signal you can observe after release. Ask AI to help explore genuinely different approaches, not merely different syntax. Choose an approach deliberately, implement it with mechanical checks, and return to the data after users encounter it.

Then write down the lesson.

You’re not replacing a landing page because it’s ugly. You’re doing it to improve certain KPI.

Repeat this and you will accumulate something more valuable than prompt tricks: a body of evidence about how product decisions, interface choices, technical constraints, and user behavior interact.

The tools will keep changing. Some tasks will become dramatically faster, and some skills that once looked central will become background knowledge. Prompt engineering is a great example – 12-18 months ago it was an essential skill, now it’s nearly irrelevant.

Businesses will still need people who can identify the destination, make trade-offs, recognize weak output, and connect software to a real result.

AI can do more of the driving. Your job is to choose where the product should go, keep it on the road, and know whether arriving there made anything better.

🔍 Where an AI Watermark Can Hide in Plain Text: Anthropic quietly announced it’s watermarking Claude’s text output, but won’t say how. This piece makes a compelling case that the mark most likely lives in word-choice statistics, not hidden characters, which is exactly why copy-paste doesn’t kill it but a real paraphrase does. Worth reading if you’ve ever wondered whether “AI detection” is even the right question to ask.

🎨 State of CSS 2026: Nearly 5,000 developers weighed in, and Anchor Positioning is the runaway favorite feature, despite (or because of) still being a browser-support minefield. The more telling stat: CSS code is still 76% hand-written, making it one of the last corners of the frontend stack that AI hasn’t fully colonized. A fun state-of-the-union for anyone shipping styles in 2026.

⚡ The next generation of MCP: MCP just went stateless, and that’s a bigger deal than it sounds. It means agent servers can now run as plain Workers instead of babysitting sticky sessions and open streams. If you’ve ever cursed session management while building an MCP server, this is the fix you didn’t know you were waiting for.

🚂 Agents on Rails: The LLM Benchmark Project: The Rails Foundation commissioned Evil Martians to stop the vibes-based debate and actually benchmark which coding agents write good Rails code, at what cost, in how many tokens. Refreshing to see a language community demand receipts instead of just repeating “Rails and AI pair well” anecdotally.

💻 The End of No Code: Airtable just sold for $1.28B, and this piece argues that’s the No Code industry peaking, not thriving, because coding agents have made “just build it on Linux” cheaper than learning a proprietary platform’s quirks. A provocative, if self-interested (the author sells VMs), read on where internal tools are headed.

✍️ 5 CSS Properties You Should Know for Better Text Designs: A tidy grab-bag of underused CSS, like background-clip: text and box-decoration-mode, for anyone whose typography still looks like a Bootstrap default. Nothing revolutionary, but the letter-spacing reveal-animation trick alone is worth stealing.

🕵️ I Put GitHub Copilot Behind a MITM Proxy. Here’s What I Found.: This is the deep-dive every AI coding tool user should read: Copilot keeps a full local SQLite history of your prompts and responses in plain text, no redaction, and will happily send unrelated file content (including stray secrets) to the model as “recent edits” context. The real takeaway isn’t the leak, it’s that context, not the model, is quietly becoming the product.

🏗️ Angular Architecture Guide To Building Maintainable Applications at Scale: A solid, if Nx-flavored, refresher on ditching layered folders for domain-driven boundaries in Angular apps: feature, UI, and data-access libraries, with enforced dependency rules. Useful even if you never touch Nx, since the “thin app shell, fat domain libraries” mental model travels well.

😤 “Code was never the hard part” is an insult to all programmers: A sharp, funny rebuttal to the increasingly common AI-era take that coding was always the easy bit. The “if coding is easy, why isn’t everyone just building ten variations of a thing” line alone makes this worth the five minutes, a good gut-check before you nod along to that narrative again.

🦀 Understanding the Rust hype for the busy developer: A no-holy-war explainer aimed squarely at people who’ve heard “Rust is great” for years but never got a straight answer why. If you keep meaning to figure out what the fuss is about without committing a weekend to the Rust Book, this is the shortcut.

📦 Docker Sandboxes: MicroVM-isolated, disposable sandboxes purpose-built for running Claude Code, Copilot CLI, Codex, and friends in full YOLO/--dangerously-skip-permissions mode without risking your actual machine. If you’ve been letting coding agents run wild locally out of laziness rather than confidence, this closes that gap cheaply.

📄 anydoc: A blazing-fast (sub-5ms median), pure-Rust converter that turns Word, PowerPoint, Excel, PDF, and more into clean Markdown, running entirely as WebAssembly in your browser so files never leave your machine. The most refreshing pitch here is the benchmark claim: only converter of seven tested that handled all fourteen formats.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan

👋 Advertise with us
Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.