# Dudych Blog — Full Post Archive > A personal blog about frontend development, TypeScript, React, Next.js, and modern web tooling, by Marian Dudych — a Full Stack Engineer based in London. > Author: Marian Dudych (https://dudych.com/about) # How to Use Claude Fable 5 to Scan Your Code for Security Vulnerabilities URL: https://dudych.com/blog/how-to-use-claude-fable-5-to-scan-your-code-for-security-vulnerabilities Published: 2026-07-02 Author: Marian Dudych Category: Security Tags: AI, Security, Claude_Code Claude Fable 5 is back. Anthropic restored it globally on July 1st after a three-week outage that had nothing to do with servers and everything to do with the US government. If you missed the saga: on June 12th, export controls were imposed on Fable 5 and Mythos 5 after [Amazon researchers found a way to bypass the model's safeguards](https://www.anthropic.com/news/redeploying-fable-5) by prompting it to hunt for software vulnerabilities and demonstrate how to exploit them. The controls were lifted on June 30th, and the model came back the next day with a new safety classifier bolted on. There is a certain irony in what happened next for people like me. The thing that got Fable 5 in trouble — how good it is at finding vulnerabilities in code — is exactly why I want it back. I have been using Claude for security review on my own projects for a while now, and Fable 5 is a clear step up from anything before it. So this post is about using that capability the way it is meant to be used: scanning code you own, finding problems before someone else does, and fixing them. ## Why an LLM for security scanning at all? Fair question. We already have SAST tools, dependency scanners, linters with security rules. I run those too. But after years of reviewing code for a living, I can tell you where they fall down: they pattern-match. They will catch a `eval()` on user input and an outdated lodash, but they have no idea that your password reset flow lets someone enumerate valid email addresses, or that your authorization check happens after the data has already been fetched and logged. That is the gap Fable 5 fills. It reads code the way a security-minded senior engineer reads code — following data from the request handler down through the layers, noticing what *isn't* there. Anthropic's own testing during the export control episode found that [many less capable models could identify the same vulnerabilities](https://www.anthropic.com/news/redeploying-fable-5), which tells you two things: this class of tool is genuinely useful for defenders, and Fable 5 sits at the top of it. The honest framing: it is not a pentest and it is not magic. It is a tireless reviewer that will read every file you point it at and never gets bored on file forty-three. That alone is worth a lot. ## First, know about the new classifier Before the prompts, one practical thing that changed with the redeployment. Fable 5 now ships with a stricter cybersecurity classifier, and Anthropic has been open about the trade-off: it uses a deliberate "safety margin", meaning it will [sometimes flag requests that are likely benign](https://www.anthropic.com/news/redeploying-fable-5), particularly around vulnerability analysis and certain debugging tasks. When it triggers, your request gets redirected to Claude Opus 4.8 instead. Researchers at the US Center for AI Standards and Innovation tested the updated safeguards and called them ["extraordinarily strong"](https://www.infosecurity-magazine.com/news/anthropic-fable-mythos-back/), which is reassuring and mildly annoying in equal measure. What this means for you is simple: give the model context. A bare "find vulnerabilities in this code" with no framing is exactly the shape of request the classifier is watching for. "This is my own Next.js application, review it for security issues and suggest fixes" sails through, because it is unambiguous about what you are doing and why. Every prompt below follows that pattern — state that the code is yours, ask for defensive findings, and ask for fixes rather than exploits. That is not a trick to get around the safeguards; it is just being clear about legitimate work, which is what the system is designed to let through. ## The easy path: /security-review in Claude Code If you use Claude Code, start here before writing any custom prompts. It ships with a built-in `/security-review` command that audits the pending changes on your current branch. My habit now is to run it before opening a pull request, the same way I run the tests: ``` /security-review ``` It checks the diff for things like injection risks, auth problems, insecure data handling, and secrets, and reports what it finds with file and line references. Because it only looks at your changes, it is fast, and it catches the class of mistake you make at 5pm on a Friday — the debug endpoint you forgot to remove, the query you built with string concatenation because you were prototyping. For anything bigger than a branch diff, though, you will want to drive it yourself. That is where the prompts come in. ## The prompts I actually use These are copy-paste ready. Adjust the stack details to yours. ### 1. The full codebase sweep My starting point on any project I haven't audited before. Run it from Claude Code so the model can read the repo itself: ``` This is my own web application (Next.js + PostgreSQL) and I want a defensive security review of it. Go through the codebase and look for: - injection risks (SQL, command, template) - broken or missing authentication and authorization checks - secrets or credentials committed in code or config - unsafe handling of user input, uploads, and redirects - insecure defaults in headers, cookies, and CORS For each finding, give me the file and line, why it's a problem, a severity rating, and the concrete fix. Rank the findings by severity when you're done. ``` The ranked list at the end matters more than you would think. Without it you get thirty findings of wildly mixed importance and no idea where to start. ### 2. The auth deep-dive Authentication and authorization bugs are the ones that hurt most and the ones scanners miss most, so they get their own pass: ``` Focus only on authentication and authorization in my codebase. Trace every route/endpoint and tell me: which ones are missing auth checks, whether authorization is enforced consistently (or checked in some places and assumed in others), how sessions/tokens are issued, validated, and expired, and whether any user-supplied ID lets one user access another user's data (IDOR). I own this code and want fixes for anything you find. ``` That last check — IDOR, where changing `/api/orders/123` to `/api/orders/124` shows you someone else's order — is embarrassingly common and almost invisible to traditional tools, because the code is *syntactically* fine. It takes something that understands intent to spot it. ### 3. The dependency and supply chain check ``` Review my package.json and lockfile. Flag dependencies that are deprecated, unmaintained, or have known vulnerability history, and any packages that seem unnecessary for what this project does. Then check my code for the places where a vulnerable dependency would actually be reachable — I care more about exploitable paths than raw CVE counts. ``` The second half is the valuable bit. `pnpm audit` will happily tell you about a vulnerability in a dev dependency that never touches production. Asking whether the vulnerable path is actually *reachable* in your app turns a wall of noise into a short list. ### 4. The secrets hunt ``` Scan this repository for anything that looks like a committed secret: API keys, tokens, passwords, connection strings, private keys — including in config files, tests, scripts, and old-looking backup files. For each hit, tell me where it is and remind me that rotation is the fix, since anything committed should be treated as exposed. ``` And it is right to remind you. Deleting the line and force-pushing does not un-leak a key. If it was committed, rotate it. ### 5. The pre-release gate The one I run before anything ships to real users: ``` I'm about to deploy this feature branch to production. Review the diff against main as a security gate: assume the reviewer before you was tired. Check every new input path, every new query, every changed permission check. Also look at what the change removes — did anything that used to be protected lose its protection? Give me a clear ship / fix-first verdict at the end. ``` Asking for a verdict forces the model off the fence. Without it you get a diplomatic summary; with it you get "fix the missing rate limit on the new endpoint first", which is what you actually wanted. ## What I've learned using it this way **Scope beats size.** One focused pass on authentication finds more than one giant "check everything" pass, in my experience. I run the full sweep once for orientation, then follow up per area. The model's attention, like yours, is a budget. **Make it show its working.** When Fable 5 flags something, ask it to trace the exact path from user input to the dangerous sink. Sometimes the trace reveals the finding is a false positive — there is a sanitization step it missed — and sometimes it reveals the bug is worse than reported. Either way, you learn whether to trust it, finding by finding, the same way you would with a new colleague. **Don't paste what you can't leak.** Redact real credentials, customer data, and production connection strings before they go anywhere near a prompt. If the model finds a hardcoded secret during a scan, that credential is burned — rotate it. **It reads code; it doesn't attack systems.** This is the boundary to keep in your head. Fable 5 will tell you your deserialization is unsafe; it will not tell you whether your WAF, your network layout, or your deployed config actually saves you in practice. For anything with real stakes, an AI review complements a professional penetration test, it does not replace one. **Expect the occasional false stop.** With the new safety margin, once in a while a completely reasonable request gets bounced to Opus 4.8. It has happened to me on ordinary debugging. Rephrasing with clearer context about your own project usually resolves it, and honestly, given [what the alternative looked like in June](https://venturebeat.com/technology/anthropic-is-bringing-back-claude-fable-5-globally-after-us-lifts-export-control-order-where-can-enterprises-access-it) — no Fable 5 at all — I will take the friction. ## The bottom line The three weeks without Fable 5 were a decent reminder of how quickly this tool became part of my routine. The capability that made regulators nervous is the same capability that lets a solo developer or a small team get a level of security review that used to require a consultant and a four-figure invoice. Used on your own code, with findings you verify and fixes you review like any other pull request, it is one of the highest-leverage things you can do with a frontier model right now. Start with `/security-review` on your next branch. Then run the full sweep on the project you have been quietly worried about. You will find something — I always do. *Sources: [Anthropic — Redeploying Claude Fable 5](https://www.anthropic.com/news/redeploying-fable-5), [Anthropic — Claude Fable 5 and Claude Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5), [Infosecurity Magazine](https://www.infosecurity-magazine.com/news/anthropic-fable-mythos-back/), [VentureBeat](https://venturebeat.com/technology/anthropic-is-bringing-back-claude-fable-5-globally-after-us-lifts-export-control-order-where-can-enterprises-access-it), [MarkTechPost](https://www.marktechpost.com/2026/07/01/anthropic-redeploys-claude-fable-5-on-july-1-after-us-export-controls-lift-adds-new-cybersecurity-classifier/).* --- # 10 Must-Have Claude MCP Servers I Actually Use in 2026 URL: https://dudych.com/blog/10-must-have-claude-mcp-servers-i-actually-use Published: 2026-06-29 Author: Marian Dudych Category: Development Tags: AI, Claude_Code, Tooling When MCP first showed up I ignored it for a couple of weeks. After years of working as a senior developer, I have built up a healthy resistance to AI hype, and I assumed this was more of it, another announcement that would quietly disappear by the next release. I was wrong, and I do not admit that about new tooling very often. The honest version is this: once I connected Claude to my actual tools, it stopped being a clever autocomplete and started being something closer to a junior engineer who already knows my codebase. That is the whole pitch. I still review everything it produces the same way I would review a teammate's pull request, but the amount it gets right on the first try has changed how I spend my day. So here are the Claude MCP servers I actually keep installed, with my real opinion on each one rather than a copy-paste of the marketing page. ## A quick reminder of what MCP actually is MCP stands for Model Context Protocol. It is an open standard that lets an AI assistant like Claude talk to outside tools and data through small programs called servers. One server might give Claude access to your GitHub repos, another to a real browser, another to your error tracking. The client (Claude Desktop or Claude Code) handles the conversation, and each MCP server hands Claude a set of tools it can call. ![Diagram of how MCP works: the Claude client connecting through MCP servers to external tools such as GitHub, a browser, and error tracking](/images/how_mcp_works.webp) The reason it matters is simple. A model on its own only knows what it was trained on and what you paste into the chat. An MCP server lets it go and fetch the real thing. That difference is bigger than it sounds, and the servers below are where I felt it most. Almost all of the MCP servers for Claude Code below also work in Claude Desktop, so do not worry too much about which client you are on. ![Side-by-side comparison of Claude without MCP versus with MCP, showing how MCP gives the model access to real, up-to-date external data](/images/with_mcp-vs-without_mcp.webp) A small warning before the list. You do not need all ten. I will come back to this at the end, because installing every server you can find is a mistake I already made for you. ## 1. GitHub This is the one I would install first on any machine. The GitHub MCP server lets Claude search code across a repo, read and triage issues, look through pull requests, and pull commit history into context without me copy-pasting any of it. What changed for me day to day is PR review. A good chunk of my week is reviewing my team's pull requests, and that is where this earns its keep. I point Claude at an open pull request, it reads the diff and the linked issue together, and I get a sane summary before I have even opened the files myself. It does not replace my review, but it removes the slow part where I rebuild context in my head every Monday morning. The server itself is free. You will likely need a GitHub personal access token so it can reach private repos, and I would scope that token tightly rather than handing it the keys to everything. ## 2. Context7 If I could only keep one server on this list, it might be this one. The Context7 MCP server pulls up-to-date, version-specific documentation for libraries straight into Claude's context. Here is the problem it solves. I work in React and Next.js, and those move fast. A model with a training cutoff will confidently give you an API that got renamed two minor versions ago, and you waste ten minutes before you realise the suggestion was stale. Context7 fixes that by feeding Claude the current docs for the exact version you are on. The number of wrong-but-confident answers I get has dropped a lot since I started using it. It is free and needs no API key, which makes the decision to install it very easy. ## 3. Chrome DevTools This one genuinely surprised me. The Chrome DevTools MCP server lets Claude drive and inspect a real Chrome instance. It can read the console, look at network requests, pull a performance trace, and inspect the DOM. For frontend debugging this is the difference between me describing a bug and Claude actually seeing it. Instead of pasting a console error and hoping I copied the right lines, I let it read the console directly. When a page is slow, it can look at the trace rather than guess. If you spend your days in the browser like I do, this earns its place fast. It is free and open source. Pair it with a clean editor setup and the feedback loop gets genuinely quick. I wrote about [how I strip my VS Code down to reduce noise](/blog/how-i-transformed-vs-code-into-a-cozy-minimalist-workspace-full-setup-guide) if you want that side of the workflow too. ## 4. Playwright I write Playwright tests at work, so this server slotted straight into how I already operate. The Playwright MCP server gives Claude browser automation through the accessibility tree, which is great for scaffolding end-to-end tests and reproducing bugs on a live page. My favourite use is turning a bug report into a failing test. I describe the steps, Claude drives the browser, and I get a reproducible Playwright spec out the other side. That is the part of testing I always procrastinate on, so handing it off has been a quiet win. Free and open source, maintained by the Playwright team, so it stays close to the real tool rather than drifting. ## 5. Sentry Once something is in production, the questions change, and Sentry is where I answer them. The Sentry MCP server pulls error data, issue details, and stack traces into Claude so it can help with real production debugging instead of hypotheticals. The workflow I like is boring but effective. I give Claude a Sentry issue, it reads the stack trace and the surrounding context, and it comes back with a short list of likely causes. Most of the time one of them is right, and even when it is not, it has saved me the first twenty minutes of staring at a trace. The server is free. You will need a Sentry account and a token for it to read your project, which most teams using Sentry already have. ## 6. Sequential Thinking This is the odd one on the list because it does not connect to any outside service. Sequential Thinking gives Claude a structured space to reason in steps, revise earlier thoughts, and branch when a problem is messy. I do not reach for it every day. But when I am untangling a gnarly bug or planning a migration with a lot of moving parts, having the model think out loud in a more disciplined way produces noticeably better plans. Think of it as the server you are glad you installed on the hard days rather than the easy ones. Free and open source, and it costs you nothing to leave it sitting there until you need it. ## 7. DuckDuckGo Sometimes you just need a quick web search and you do not want to wire up a paid search API to get it. The DuckDuckGo MCP server does web search with no API key at all. It is not going to replace a dedicated research setup, and I am honest with myself about that. For everyday lookups though, checking whether a library is still maintained, finding a changelog, confirming a syntax detail, it is more than good enough and the zero-setup part is the real selling point. Free and open source, which fits the theme of this whole list. ## 8. Notion A lot of my thinking lives in Notion. Specs, loose notes, half-finished ideas for posts like this one. The Notion MCP server lets Claude read and update pages and databases, which means I can pull a spec into context instead of copying it across by hand. The thing I did not expect was how useful the write side is. I can ask Claude to drop a summary back into the right Notion page after a session, and my notes stay current without me babysitting them. If your team runs on a wiki, this connects the AI to where the knowledge already is. The server is free. You will need a Notion account and an integration token so it can see the right workspace. ## 9. Stripe This one is more specialised, so install it only if you actually touch payments. The Stripe MCP server lets Claude work with billing and subscription data, customers, and the rest of the Stripe object model. When I am building subscription logic, being able to ask Claude to inspect test-mode data and reason about edge cases has been handy. The honest caveat matters more here than anywhere else on the list: be very careful with keys, keep it on test mode while you are experimenting, and do not casually point it at live billing data. Money bugs are the kind you remember. The server is free, but you need a Stripe account and an API key, and I would treat that key with respect. ## 10. Postgres I saved a practical one for last. The Postgres MCP server lets Claude read your database schema and run read queries, so it understands your data model without me describing every table from memory. This kills one of the most tedious parts of working with an AI on a real app, which is explaining your schema over and over. Instead it just looks. I keep mine strictly read-only, and I would strongly suggest you do the same. Letting a model run write queries against a real database is a horror story waiting to happen. Free and open source. Point it at a read-only connection and relax. ## The honest downside nobody mentions Here is the part the excited blog posts skip. Every MCP server you add hands Claude more tools, and every tool takes up room in the context window. Install all ten on every project and you will actually make the model worse, because it has to wade through a huge menu of options before it does anything useful. So I do not run all of these at once. I keep a small core that is on everywhere, GitHub, Context7, and Chrome DevTools, and I switch the rest on per project. Stripe only exists on the apps that bill people. Postgres only on the ones with a database I care about. Sentry only where I have real production traffic. Treat MCP servers like dependencies, not like browser extensions you collect and forget. The same instinct that makes me [picky about my package manager](/blog/npm-vs-yarn-vs-pnpm-vs-bun-which-package-manager-should-you-use-in-2026) applies here. Less, chosen on purpose, beats more. ## The short version If you want the quick reference, here is the whole list in one place. | Server | What it does | Cost and setup | |---|---|---| | GitHub | Issues, PRs, code search, repo work | Free server, GitHub token usually needed | | Context7 | Up-to-date library docs in context | Free, no API key | | Chrome DevTools | Real Chrome debugging and inspection | Free and open source | | Playwright | Browser automation and end-to-end tests | Free and open source | | Sentry | Error tracing and production debugging | Free server, Sentry account needed | | Sequential Thinking | Better multi-step reasoning and planning | Free and open source | | DuckDuckGo | Web search without an API key | Free and open source | | Notion | Docs and wiki workflows | Free server, Notion account needed | | Stripe | Billing and subscription workflows | Free server, Stripe account needed | | Postgres | Read your schema and run safe queries | Free and open source | ## Final thoughts MCP is the thing that moved Claude from a helpful chat window to an actual part of my workflow. These are the best MCP servers I have found so far, the must-have MCP servers that survived a year of me trying everything and quietly uninstalling most of it. If you are putting together your MCP servers in 2026, my advice is to start small. Install GitHub and Context7, live with them for a week, and add the rest only when you hit a wall they would solve. The best setup is not the one with the most servers. It is the one where every server you have is pulling its weight, and you could tell me exactly why each one is still there. If you end up with a setup you love, I would genuinely like to hear what made your list and what did not. --- # Top Web Design Tips for Modern Websites URL: https://dudych.com/blog/top-web-design-tips-for-modern-websites Published: 2026-06-29 Author: Marian Dudych Category: Design Tags: Web_Design, UX, Best-Practices I am an engineer, not a designer, and I want to get that out of the way first. I spend my days in React and TypeScript, not in Figma. But after years of shipping production websites as a Senior developer, I have learned that the line between design and engineering is a lot blurrier than either side likes to admit. The developer who understands a few design fundamentals ships better work, full stop. So this is not a designer lecturing you about golden ratios. It is a list of the web design tips that have actually held up for me across real projects, including this blog. Some of them are opinions, and I will tell you when they are. If you build for the web and want your modern websites to feel less amateur, this is where I would start. Think of it as web design for developers: the parts of modern web design that give you the most visible improvement for the least effort. ## Start with typography, not color If you only fix one thing, fix your type. Good web typography does more for a modern website than any color scheme or hero animation, and most sites get it wrong by treating it as an afterthought. Pick one solid typeface and learn to use it well before you reach for a second. Set a sensible base size (16px is not too big, despite what your design instincts say), give your body text a line height around 1.5 to 1.6, and stop your line length somewhere around 60 to 75 characters so people can actually read it. That single change, comfortable measure and generous line height, makes more difference than people expect. My honest opinion: most websites would look more professional overnight if the designer just deleted the second font and bumped the body text up two pixels. ## Let the layout breathe White space is not wasted space. It is the thing that makes a page feel calm and expensive instead of cramped and cheap. When I review a junior's work, the most common note I leave is some version of "give this room." The fix is rarely to add more. It is to remove things and to push the rest apart. Increase the padding inside your cards. Add margin between sections so they read as separate ideas. Resist the urge to fill every corner. A modern website earns trust by looking confident, and nothing looks less confident than a wall of content with no air in it. ## Commit to a small, consistent spacing scale This is the tip that separates sites that feel designed from sites that feel assembled. Pick a spacing scale, something like 4, 8, 12, 16, 24, 32, 48, 64, and use only those values for margins, padding, and gaps. No random 13px here and 27px there. The reason it works is rhythm. When every gap on the page is a multiple of the same base unit, the layout feels intentional even if the visitor could never tell you why. I treat my spacing scale as design tokens and never deviate from them, and it is the cheapest way I know to make a site look coherent. ## Use color with discipline Most modern websites need far less color than they use. My default is a neutral base, plenty of grays for text and surfaces, and exactly one accent color that does the heavy lifting for links, buttons, and anything I want you to click. Minimalist web design is not about empty pages, it is about restraint, and restraint reads as taste. When everything is colorful, nothing stands out, and your most important action drowns in the noise. Pick your one accent, use it sparingly, and let it actually mean something. If you need a second color, make it a quiet supporting role, not a competitor. ## Design mobile first, and on a real phone Responsive web design starts on the small screen, not the big one. More than half your visitors are on a phone, so designing the desktop version first and squashing it down later is backwards. Start with the narrow layout, get it genuinely good, then let it expand into the extra space on larger screens. And please, test on an actual device. The browser dev tools mobile preview is useful, but it lies about tap target sizes, about how your fixed header eats the screen, and about how that elegant hover effect does absolutely nothing on touch. I have shipped layouts that looked perfect in the simulator and felt clumsy in my hand. Now I keep a cheap old phone around specifically to catch that. ## Treat performance as a design decision A beautiful site that takes four seconds to load is not a beautiful site. Speed is part of the experience, and it is a design concern as much as an engineering one. The two things that wreck most sites are unoptimized images and too many fonts. Serve images at the size they actually display, use modern formats, and lazy load anything below the fold. Limit your font weights, because every extra one is another file the visitor waits on. When I cut a project from five font weights down to two, the page felt faster and, weirdly, looked cleaner at the same time. Constraints tend to do that. ## Make interactive states impossible to miss A lot of the best UX design tips come down to one idea: make the interface honest about what it is doing. Every element a person can interact with should make that obvious, and should react when they do. Buttons need a clear hover state, a pressed state, and a disabled state that genuinely looks disabled. Links should look like links. The one almost everyone forgets is focus. When I tab through a site with my keyboard and the focus indicator is invisible, I know nobody tested it that way. A visible focus ring is not ugly, it is the difference between a site that works for everyone and one that quietly excludes people. Style it to match your brand if the default offends you, but never remove it. ## Treat accessibility as design, not cleanup Accessibility is not a checklist you run at the end. It is baked into good design from the start, and the two goals almost never conflict. Solid color contrast helps everyone read in bright sunlight. A clear heading structure helps screen readers and skim readers alike. Real focus states help keyboard users and power users both. If you want the technical side of this, I wrote a whole piece on [why semantic HTML matters more than most tutorials admit](/blog/what-is-semantic-html-and-why-does-it-matter), and most of it is really a design argument in disguise. Build the structure right and a lot of accessibility comes for free. ## Use motion, but keep it on a short leash A little motion makes an interface feel alive. Too much makes it feel like a toy. My rule is that animation should help someone understand what just happened, not show off that I know how to animate. Keep transitions fast, somewhere in the 150 to 250 millisecond range for most UI, and keep them subtle. A button that gently responds to a hover, a panel that slides in instead of snapping, that is plenty. And always respect the prefers-reduced-motion setting, because for some people heavy animation is not delightful, it is nauseating. Honoring that preference is a few lines of CSS and it is simply the right thing to do. ## Design with real content, never lorem ipsum This one has burned me more than once. A layout that looks gorgeous full of placeholder text falls apart the moment you drop in the real thing, with its awkward long headline, its short paragraph, and the product name that is three words longer than you planned for. Design with content that resembles reality. Test your headings with a title that actually wraps to two lines. Check what an empty state looks like, and what a cluttered, overflowing one looks like too. Real websites are messy, and a design that only works with perfect content is a design that does not work. ## Do dark mode properly or not at all Dark mode is expected on a modern website now, but a lazy dark mode is worse than none. Inverting your colors and calling it done gives you harsh pure black backgrounds, glaring pure white text, and shadows that have quietly stopped doing anything. If you build it, build it on purpose. Use a soft dark gray rather than true black, dial your text back from pure white so it does not vibrate against the background, and rethink your shadows, since they barely register in the dark and you often need a subtle border instead. This blog has a dark mode I am actually happy with, and getting there took real effort, not a single toggle. ## Steal taste, on purpose Nobody develops an eye in a vacuum. The fastest way to get better at web design as a developer is to pay deliberate attention to sites that feel good and ask why. Keep a folder of screenshots. When something stops you, figure out what it was: the spacing, the type, the one confident color, the restraint. You are not copying, you are training your taste. After a while you stop needing to ask why, because you can feel when something is off. That instinct is the real skill, and it only comes from looking closely at a lot of good work. ## Where I would start If this list of web design best practices feels like a lot, do not try to do all of it at once. Fix your typography first, because it gives you the biggest visible return. Then tighten your spacing onto a consistent scale. Then cut your colors back to a neutral base and a single accent. Those three alone will pull most websites from looking homemade to looking intentional. The rest is refinement, and refinement is the fun part. Modern web design, like code, rewards the people who care about the small stuff that nobody can quite name but everybody can feel. If you build for the web, that caring is well within your reach, designer job title or not. --- # What Is Semantic HTML and Why Does It Matter? URL: https://dudych.com/blog/what-is-semantic-html-and-why-does-it-matter Published: 2026-03-07 Author: Marian Dudych Category: Development Tags: Accessibility, Best-Practices Early in my career I wrote a lot of `
` soup. Everything was a div. The header was a div. The nav was a div. The sidebar was a div with a class called `sidebar-right-wrapper` because apparently I needed two words to describe something that could have just been an `