I taught myself frontend development the hard way. YouTube tutorials, W3Schools reference pages, and broken code at 2 AM. When DeepSeek dropped, everyone around me panicked. "Developers are finished," they said. I watched the hype cycle spin up and then die down, and I realized the same thing I always do: tools change, but understanding doesn't. Then I tried Z AI — just once — and it was so good it actually scared me. I thought it was built only for senior engineers. That moment pushed me to stop writing lazy prompts and start thinking like an engineer again. Through trial and error, I learned prompt engineering before it had a name. And that changed everything.
This isn't a rant against AI. I use it daily. This is about the difference between using AI to amplify your skills and using it to replace your knowledge — and why the second path collapses the moment something goes wrong.
What Vibe Coding Actually Is
Vibe coding is the practice of describing what you want in natural language, letting an AI generate the implementation, and iterating through conversation until the result feels right. No syntax memorization. No documentation diving. Just intent and refinement. I built an entire production-ready website this way without manually writing a single line. It looked professional. It deployed cleanly. And I had no idea how any of it worked under the hood.
When DeepSeek hit the scene, people treated it like an extinction event for junior developers. It wasn't. It was just better at pattern matching than ChatGPT at the time. Then there was Z AI — powerful, precise, and barely discussed in the mainstream. I used it once for a complex refactoring task and the output was so clean I assumed I wasn't qualified to review it. That was my first warning sign. If the tool makes you feel obsolete, you're probably using it wrong.
The Hype vs. The Reality
AI makes starting easier. It lowers the barrier to entry. But it also lowers the barrier to shipping dangerous code. I watched beginners vibe-code authentication systems, payment flows, and admin panels without understanding session management, SQL injection, or CSRF protection. The code runs. The demo looks great. The security model is nonexistent.
Where It Falls Apart
The problem isn't the tool. It's the gap between "it works" and "I know why it works."
Frontend vs. Backend
Frontend is forgiving. You can vibe-code a React component, break the layout, and fix it by asking the AI again. The cost of failure is a misaligned div. Backend is not forgiving. A vibe-coded authentication flow might look correct, but if the AI used a deprecated hashing algorithm, missed rate limiting, or stored tokens in localStorage instead of httpOnly cookies, you won't know until someone exploits it.
I learned this when I asked an AI to build a file upload handler. It wrote the code in seconds. It also accepted any file extension, didn't validate MIME types, and placed uploads in a web-accessible directory. If I had shipped that, I would have handed attackers a shell upload vector. I only caught it because I knew what to look for.
The Security Blind Spot
Cybersecurity professionals face the same trap. I considered automating my Python recon scripts with AI. But then I asked: what if the model imports a malicious package disguised as a helper library? What if it adds a subtle network callback that exfiltrates scan results? AI doesn't intentionally backdoor your code, but it confidently hallucinates. And confidence in the wrong place is a vulnerability.
When you vibe-code, you lose the ability to trace intent. If an attack happens at 3 AM and your application is down, you can't ask an AI to "just fix it" if you don't understand the architecture. You'll be staring at complex generated code you didn't write, under pressure, with no mental model of how the pieces connect. That's not a coding problem. That's a business continuity problem.
Vibe coding a backend you don't understand is not development. It's delegation to an intern who types fast, never sleeps, and occasionally adds a backdoor because it looked like a valid pattern in the training data.
How I Actually Use AI Now
I stopped treating AI like a replacement and started treating it like a senior pair programmer who types fast but sometimes lies. My workflow changed completely.
Prompt Engineering by Necessity
I don't write "build me a login form" anymore. I write: "Build a login form in PHP 8.2 using PDO prepared statements, CSRF tokens, bcrypt via password_hash(), rate limiting with Redis, and httpOnly session cookies. Do not use md5, sha1, or client-side storage for credentials." The output is dramatically different because I defined the guardrails.
I learned this by failing. Early prompts gave me garbage. I would paste errors, ask for fixes, and copy-paste whatever came out. The code worked until it didn't. Over a year, I realized the quality of the output was directly tied to the quality of my input. Prompt engineering isn't a separate skill. It's just knowing what you actually need and being specific enough to enforce it.
The Audit I Run on Every Output
Every line of AI-generated code gets reviewed before it ships. I check for:
- Hardcoded credentials or API keys
eval(),exec(), orsystem()calls- Unvalidated file uploads or path traversal risks
- Unnecessary dependencies with no clear purpose
- Inline event handlers or
innerHTMLthat could carry XSS - Deprecated functions or weak cryptographic algorithms
I also run dependency audits on any package the AI suggests. I treat AI output like code from an unknown freelancer: functional, maybe clever, but absolutely untrusted until proven otherwise.
For my own tools, I use Cursor and Claude to accelerate boilerplate and refactor repetitive logic. But I design the architecture. I own the security model. I choose the database schema. The AI fills gaps, it doesn't make decisions.
Production Checklist
AI-assisted development is here to stay, but these four rules keep me from shipping disasters:
- Never vibe-code anything you can't debug by hand; if you don't understand the logic, you don't ship it
- Audit every AI-generated dependency and function call for unnecessary permissions, deprecated APIs, and suspicious imports before it touches your repo
- Use AI as a coding accelerator, not an architecture designer — own the security model, database design, and authentication flow yourself
- If you automate security tools with AI, run the generated code in an isolated environment first and review it line by line before it touches production data
AI didn't replace developers. It separated the ones who understand the craft from the ones who only know how to ask. I still use YouTube and W3Schools when I need to understand a concept deeply. The AI just gets me to the interesting part faster. But when the server is on fire at midnight, the prompt won't save you. Only your understanding will.
The Full HTTP Request Lifecycle
When you type a URL and press Enter, you trigger a chain of network operations that most developers never think about. Understanding each step made me dramatically better at debugging performance problems, security issues, and mysterious failures. Here is exactly what happens.
First, DNS resolution. Your browser checks its own cache, then the OS cache, then queries a DNS resolver (usually your router, then an upstream like 8.8.8.8). The resolver walks the DNS tree — root servers, TLD servers, authoritative servers — until it gets an IP address. A slow DNS resolution adds 50–300ms before any byte of your page moves. I've seen production sites that lost half a second on every fresh connection simply because their DNS TTL was set to 30 seconds and they weren't using any pre-resolve hints.
Once you have an IP, the browser opens a TCP connection. TCP requires a three-way handshake: SYN from client, SYN-ACK from server, ACK from client. That round trip costs one RTT before anything else can happen. On a 100ms latency connection, the handshake alone costs 100ms.
If the site uses HTTPS (and it should), a TLS handshake follows. TLS 1.3 reduced this from two round trips to one, but it still involves exchanging cipher suites, server certificates, and session keys. Older TLS 1.2 sessions can cost two additional RTTs. Certificate validation — checking the chain of trust, verifying OCSP status — adds latency unless you enable OCSP stapling on your server.
After TLS, the actual HTTP request fires. The browser sends a request line, headers (Host, Accept, Cookie, User-Agent, etc.), and optionally a body. The server processes the request, hits the database or cache, and returns a response with status code, headers, and body. With HTTP/1.1, only one request can be in flight per connection at a time, which is why browsers open six parallel connections per domain. That limit drove the bundling and domain-sharding tactics that still haunt many codebases.
Key point: Every DNS miss, TCP handshake, and TLS negotiation costs real milliseconds before a single byte of your content moves. Use dns-prefetch, preconnect, and persistent connections to eliminate these cold-start costs on critical third-party origins.
What This Means for Security
The HTTP lifecycle is also where several attack vectors live. DNS can be poisoned or hijacked, redirecting users to malicious servers. TLS certificate pinning prevents MITM attacks but complicates updates. HTTP response headers like Strict-Transport-Security, Content-Security-Policy, and X-Frame-Options are set during the response phase — if you miss them, you miss an entire layer of browser-enforced security.
Browser Rendering Pipeline
Once the browser receives HTML bytes, it runs through a multi-stage process before anything appears on screen. Misunderstanding this pipeline is responsible for most of the jank I've seen in production web apps — and for many of the performance regressions I've introduced myself before I learned to measure properly.
The browser parses HTML incrementally, building the Document Object Model (DOM) as a tree of nodes. When it encounters a <link rel="stylesheet">, it fetches and parses CSS to build the CSS Object Model (CSSOM). The browser cannot render anything until both trees are ready, because it needs to know which CSS rules apply to which DOM nodes. This is why render-blocking CSS is a real performance problem — every stylesheet you load synchronously delays the first pixel on screen.
The DOM and CSSOM are combined into the Render Tree, which contains only the visible nodes with their computed styles. Hidden elements (display: none) are excluded entirely. From the Render Tree, the browser runs Layout (also called Reflow) — calculating the exact size and position of every element on the page. Then comes Paint, where the browser fills in pixels: colors, borders, shadows, text. Finally, Compositing assembles any independently-painted layers (transforms, opacity, fixed positioning) into the final image.
JavaScript is the disruptor. A parser-blocking <script> tag stops HTML parsing, waits for the script to download and execute, then resumes. Scripts can modify the DOM or CSSOM, forcing the browser to recalculate layout and repaint — sometimes multiple times per frame. I've seen a single poorly-placed analytics script add 800ms to Time to Interactive on a mobile device. The fix was simple: defer or async on the script tag. But the problem would have been invisible without understanding what the browser was actually doing.
Key point: Triggering Layout is expensive. Reading then writing DOM properties in a loop — like reading offsetWidth, updating a style, reading offsetWidth again — causes Layout Thrashing. Batch your DOM reads before your writes, or use requestAnimationFrame to schedule mutations safely.
Compositing Layers and GPU Acceleration
CSS properties that trigger compositing (transform, opacity, will-change) move elements to their own GPU-backed layer, bypassing the main thread entirely for animations. This is why transform: translateX() animates at 60fps while left: causes janky repaints. I always animate with transform and opacity when performance matters, and I use the Chrome DevTools Layers panel to verify the compositor boundaries before shipping.
HTTP/2 and HTTP/3
HTTP/1.1 was designed for a web of simple documents. It is fundamentally sequential — one request per connection, blocking. The workarounds we built around it (bundling, spriting, domain sharding, inlining) were coping mechanisms for a protocol limitation. HTTP/2 and HTTP/3 eliminate most of those limitations.
HTTP/2 introduced multiplexing: multiple requests and responses can be in flight over a single TCP connection simultaneously. No more six-connections-per-domain workaround. Header compression (HPACK) reduces the repetitive cost of sending the same headers on every request — particularly useful for APIs with large cookie or authorization headers. Server Push, though largely deprecated in practice, allowed servers to send resources proactively before the client asked.
The practical result is that many of the optimizations we applied for HTTP/1.1 become counterproductive under HTTP/2. Bundling all JavaScript into one giant file made sense when opening connections was expensive. Under HTTP/2, many smaller files often perform better because the browser can prioritize what it needs and the server can respond to multiple requests simultaneously. I've seen teams shave 300–400ms off their page loads simply by serving HTTP/2 and switching from monolithic bundles to granular code-split chunks.
HTTP/3 goes further by replacing TCP with QUIC, a transport protocol built on UDP. QUIC eliminates head-of-line blocking at the transport level — a problem that HTTP/2's multiplexing couldn't fully solve because a single lost TCP packet still stalled all streams. QUIC handles packet loss per stream independently. It also reduces connection establishment to a single round trip (or zero for resumed sessions), and TLS 1.3 is baked into the protocol rather than layered on top.
Key point: HTTP/3 makes the biggest difference on lossy or high-latency connections — mobile networks, international users, unreliable Wi-Fi. If your audience is global, enabling HTTP/3 on your CDN is one of the highest-value low-effort improvements you can make. Cloudflare and Vercel both support it by default.
Security Implications
HTTP/2 and HTTP/3 require TLS, which is a security win — you can't accidentally serve over plain HTTP. But they also introduce new attack surfaces. HTTP/2 rapid reset attacks (CVE-2023-44487) exploited stream cancellation to trigger server-side denial of service at scale. Major CDNs patched this quickly, but it's a reminder that transport protocol complexity is attack surface. I always serve through a CDN that handles protocol-level protections rather than exposing origin servers directly.
Web APIs You Should Know
The browser platform has expanded dramatically beyond DOM manipulation and event listeners. These APIs are the difference between building something that feels native and building something that feels like 2010.
The Fetch API replaced XMLHttpRequest as the standard for HTTP requests from the browser. The key difference isn't just the cleaner Promise-based syntax — it's the control surface. Fetch gives you fine-grained control over request mode (cors, same-origin, no-cors), credentials (include, omit, same-origin), caching policy, and redirect behavior. XHR doesn't expose these cleanly. When I build AI-powered features that stream responses, I use ReadableStream via the Fetch Response body rather than waiting for the full response to buffer.
const response = await fetch('/api/stream');
const reader = response.body.getReader();
const decoder = new TextDecoder();
while (true) {
const { done, value } = await reader.read();
if (done) break;
const chunk = decoder.decode(value, { stream: true });
// Append to UI incrementally
outputElement.textContent += chunk;
}WebSockets provide a persistent full-duplex connection between browser and server. Once the upgrade handshake completes, either side can send messages without the overhead of HTTP headers on every exchange. I use WebSockets for real-time features like live collaboration, chat, and dashboards that need sub-second updates. The security consideration: WebSocket connections bypass CORS but still respect the Origin header — validate it on the server side to prevent cross-site WebSocket hijacking.
Server-Sent Events (SSE) are the underrated alternative for one-way real-time data. The server sends a stream of events over a plain HTTP connection; the client receives them through the EventSource API. SSE automatically reconnects on disconnect, supports event types and IDs, and works over HTTP/2 without the connection count limitations that plagued SSE under HTTP/1.1. For AI chatbots, live log streaming, or stock price feeds, SSE is often simpler and more appropriate than WebSockets.
The Intersection Observer API is how I implement lazy loading, infinite scroll, and analytics tracking without polling or layout-thrashing scroll listeners. Instead of listening to scroll events and computing bounding rectangles on every tick, I declare which elements I want to watch and what threshold triggers a callback. The browser handles the geometry efficiently. Same pattern for ResizeObserver — watching element size changes without window.resize events that fire on every frame.
Key point: Choose WebSockets for bidirectional real-time communication (gaming, collaboration). Choose SSE for server-to-client streams (AI responses, notifications, live feeds). Choose Fetch with streaming for one-off large responses. Don't reach for WebSockets by default just because the word "real-time" appeared in the requirements.
Performance Budgets and Core Web Vitals
Google's Core Web Vitals are the most operationally useful performance metrics I've worked with, because they measure user experience rather than synthetic benchmarks. They're also real ranking signals. A site that scores poorly on CWV loses organic search placement, which in a production context is a business problem, not just a technical one.
Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element — usually a hero image, background image, or large text block — to render. The target is under 2.5 seconds. Common causes of slow LCP: unoptimized images served without modern formats (WebP, AVIF), render-blocking resources that delay the page, slow server response times, and client-side rendering that requires JavaScript to execute before any content appears. I fix LCP by serving images with width and height attributes to prevent layout shift, using <link rel="preload"> for the hero image, and measuring server response times separately from frontend rendering time.
Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness metric. Where FID measured only the first interaction, INP measures the worst-case responsiveness across all interactions during a visit. Long JavaScript tasks that block the main thread are the primary culprit. A 300ms script that runs synchronously during a click handler will fail INP even if it runs reliably. I use the Chrome DevTools Performance profiler and PerformanceObserver with the event type to identify the exact tasks causing delays, then break them up with scheduler.postTask() or requestAnimationFrame.
Cumulative Layout Shift (CLS) measures visual instability — how much content moves unexpectedly during page load. The classic causes: images and iframes without explicit dimensions, dynamically injected content that pushes existing content down, and web fonts that cause text reflow when they load. I set explicit aspect ratios on all images, use font-display: optional for non-critical fonts, and test CLS with mobile throttling enabled because layout shifts are harder to see on fast desktop connections.
Key point: Core Web Vitals are measured in the field (real users) not just in the lab. PageSpeed Insights shows both. A site that passes Lighthouse on a fast desktop can still fail CWV for 70% of real mobile users on 4G. Always check the field data before declaring a performance problem solved.
Setting a Performance Budget
A performance budget is a constraint I set before I start building: total JavaScript budget under 200KB compressed, LCP under 2.5s on 4G, no render-blocking resources above 100KB. Budgets prevent death by a thousand cuts — the incremental feature additions that each seem harmless but collectively tank a page's performance. I enforce budgets in CI using Lighthouse CI or bundlesize checks so no PR can silently ship 50KB of new JavaScript without a review.
