标签：#dev

Hello, I'm Shrijith Venkatramana, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product. A language model can write Python, explain quantum mechanics, and imitate Shakespeare. Show it a screenshot of a production dashboard, however, and suddenly the central question becomes: How does a transformer that was trained on text learn what a pixel means? The naïve answer is: “Give the image to the LLM.” That description hides almost all of the interesting engineering. Modern multimodal systems are usually compositions of several models: a vision encoder turns pixels into vectors, a connector translates those vectors into something the language model understands, and the LLM then reasons over the resulting representation alongside ordinary text tokens. That architectural trick has turned the transformer from a language architecture into something much closer to a general-purpose interface for heterogeneous data. The evolution is worth understanding because it reveals a useful engineering pattern: you often do not need to retrain a giant model to give it a new sensory modality. You need a good representation and a sufficiently expressive interface between representations. 1. The basic mental model: pixels become tokens Start with an ordinary LLM. Its input looks conceptually like: "The server returned HTTP 500. What should I check?" | v tokenizer | v [t1, t2, t3, ..., tn] | v Transformer | v answer Everything is eventually represented as vectors. Multimodal transformers exploit this fact. An image is first converted into a sequence of vectors: image | v vision encoder | v [v1, v2, v3, ..., vm] | v multimodal connector | v [z1, z2, z3, ..., zk] | +------ text tokens [t1, t2, ...] | v LLM | v answer The important conceptual shift is this: The LLM does not have to understand pixels directly. It only has to understand

The cloud bill is the only number in most companies that nobody on the team owns until it's already a problem. Engineering owns latency. It owns error rates, p99, uptime, the whole observability wall. Finance owns the invoice. And between those two ownerships there's a gap wide enough to drive a fifth to a third of your cloud spend straight into a wall — which, across the industry, is roughly what happens. The fix isn't a smarter spreadsheet at month-end. Real cloud cost management isn't an accounting function at all — the fix is to stop treating the bill as accounting and start treating it as a product metric: cost per request, cost per tenant, cost per feature, sitting on the same dashboard as latency and error rate, owned by the same people who own those numbers. That's the whole argument. The rest of this post is why it's true and how it's done. The bill is a lagging accounting artifact, and that's the bug Here's how cloud cost is treated almost everywhere. A bill arrives. Someone in finance reconciles it against a budget. If it's higher than expected, a thread gets opened, an engineer gets pulled in, and everyone spends a week spelunking through Cost Explorer trying to reconstruct why a number that's already been spent is what it is. Then it happens again next month. Every part of that loop is broken. The signal arrives weeks after the decision that caused it. The person reading the signal can't act on it. The person who can act on it never sees it. And the unit of measurement — total dollars — tells you nothing about whether the spend was good . A bill that doubled because you doubled revenue is a triumph. A bill that doubled because someone left a debug log streaming to an expensive tier is a fire. Total dollars can't tell those two apart. They look identical on the invoice. This is the same mistake we'd never make with any other production signal. Nobody reviews latency once a month from a PDF. Nobody waits for finance to tell engineering that p99 regressed.

Most S3 bills are wrong, and the fix takes an afternoon. The data sits in the most expensive class AWS offers (S3 Standard, $0.023/GB-month), nobody set a lifecycle policy, incomplete multipart uploads are silently billing for storage you can't even see in the console, and every byte your EC2 fleet pulls from S3 is routed out through a NAT Gateway when a free VPC Gateway Endpoint would do the same job for $0. None of this needs an architecture rewrite. It needs a checklist run in the right order. Here is the order. The savings depend entirely on your access pattern — I will not promise you a number I can't see — but the mistakes below are so common that the question is usually how much , not whether . One number is just arithmetic: cold data that moves from S3 Standard ($0.023/GB-month) to Glacier Deep Archive ($0.00099/GB-month) drops about 96% on the storage line for those bytes, and on an observability platform I ran — logs aged past 90 days into Deep Archive — that is exactly the lever that did the work. S3 cost optimization is the same boring discipline as the rest of the bill: see it, then decide what each byte should actually cost. First, see the bill before you touch it You cannot optimize what you cannot measure, and S3's default billing view tells you nearly nothing useful. Turn on S3 Storage Lens before anything else. The free tier gives you 62 metrics at the bucket level with 14 days of history, and crucially it includes cost-optimization metrics out of the box — including "Incomplete multipart upload bytes greater than 7 days old," which is the single most common source of money disappearing into storage nobody knows exists ( AWS S3 Storage Lens docs , accessed 2026-06-18). Storage Lens free metrics answer the three questions that decide everything that follows: Which buckets hold the most bytes? What storage class is that data sitting in right now? Where are the incomplete multipart uploads? For deeper per-prefix analysis or a longer history, Advanced

If your AWS bill has a NAT Gateway line, you are paying twice for the same packet: once for the gateway to merely exist, and again for every gigabyte it carries. The fix for most teams is dull and free. Add an S3 and a DynamoDB gateway endpoint, route the heavy traffic away from NAT, and only then argue about anything fancier. That single change is free to turn on, takes minutes, and stops the most expensive traffic from ever touching the meter. This is a playbook, not a lecture. The trick with NAT Gateway pricing is that the two charges hide in different places on the bill, so most teams only ever see half of it. Numbers first, then the fixes, in the order I would actually do them. What you are actually being charged for NAT Gateway has two charges, and people forget the second one until they read the bill closely. Hourly charge — you pay for every hour the gateway is provisioned and available, whether or not a single byte moves through it. In us-east-1 (N. Virginia) and us-east-2 (Ohio) this is $0.045 per NAT Gateway-hour . That is roughly $32.85 a month per gateway just to keep the lights on. Partial hours bill as full hours. Data processing charge — you pay $0.045 per GB processed through the gateway, in the same region, on top of the hourly charge. This applies to every gigabyte, inbound or outbound, regardless of source or destination. And then there is the part the pricing page mentions almost in passing: standard AWS data transfer charges still apply on top. NAT processing is an extra meter on traffic you were already paying to move. The hourly charge is fixed and visible. The per-GB charge is the one that catches teams out, because it scales with traffic you mostly cannot see: package installs, container image pulls, S3 reads from private subnets, telemetry shipped out, cross-region calls. The rate varies by region (it runs higher in places like São Paulo, where both the hourly and per-GB rates sit around $0.093), so check your own region rather than trusti

Give me read access to a $50,000/month AWS account and I will tell you within a day where the first 20-30% is hiding, because on a mid-size bill it is almost always hiding in the same four places, in the same order: data transfer you can't see in the console, instances sized for a load test that ran two years ago, on-demand pricing on a baseline that never moves, and storage rotting in the most expensive class AWS sells. None of this needs an architecture rewrite. AWS cost optimization, at least the first and biggest pass of it, is just the bill read in the right order by someone who knows where AWS buries the meter. This is the order I work. It is the same audit I run on every account I'm handed, and it is the offer — if you want me to run it on yours, the post ends with how. But you can run most of it yourself today, and you should, because nobody is going to care about your bill as much as you do. A note before the recipe: I deal in ranges, not promises. The exact saving on your account depends on what you've built. What I can promise is that the mistakes below are common enough that the question is usually how much , not whether . Hour zero: get the real bill, not the dashboard Before touching a single resource, I want the granular data. The AWS console's cost dashboard rounds, groups, and hides the things that matter. Two tools give you the truth. Cost Explorer , with rightsizing recommendations turned on, is the fast view — group by service, then by usage type, and the bill stops being one big number and starts being a list of decisions. Resource-level and hourly granularity costs extra ($0.01 per 1,000 usage records per month), but for one audit pass it's worth pennies. The Cost and Usage Report (CUR) is the ground truth — line-item, hourly, every charge AWS makes, delivered to your own S3 bucket. Generating it is free; you pay only the few cents of S3 storage. If you're going to do this seriously, set up CUR (now delivered via AWS Data Exports) on day one. E

I'm 12 years old. I build websites and full-stack apps. And recently, I decided to test something I've never seriously tried before: Can I actually make money from coding? Not from ads. Not from selling a course. Not from some complicated SaaS business model. Just by making a simple website for a local business. So I started looking for businesses that could use a better online presence. And then I sent my first message. The idea I noticed that a lot of local businesses have good services and good customer reviews, but their online presence isn't always great. Some don't have a website. Some have an old website. Some mostly depend on WhatsApp and Google Maps. So I thought: «What if I make a simple website demo and show them what their business could look like online?» I already had a generic demo website that I could use to show the idea. It wasn't supposed to be a huge SaaS product. It was just a simple website that looked professional enough to make a business owner say: "Okay, I can see how this could help my business." Then I started messaging businesses I searched for local businesses and looked at what they offered. Electrical shops. Car washes. CCTV companies. Painting contractors. Home service businesses. I didn't send the exact same message to everyone. I tried to mention their actual business and services. Then I waited. And waited. Most of the messages weren't even seen. That's when I learned something important: Building the product is only half the problem. You also have to get someone to care about it. Then one business replied I contacted a local business called DHARSHINI CCTV SURVEILLANCE. I told them I was making simple, modern websites for local businesses and showed them my demo. Then I asked: «"Would you like me to show you?"» A while later, they replied with: "💐" I thanked them and offered to make a free sample specifically for their business. And then they said: "Send" That one word made me ridiculously happy. 😂 Because this wasn't just someone

I rent six dedicated servers from a company in Germany. Together they have more cores, more memory, and more SSD than most production clusters I worked on a decade ago. I run my own Kubernetes on them. Not managed. Not EKS. Not GKE. The whole stack, from the immutable OS up to the workloads. People who hear this ask me why, and the question usually arrives in one of two tones. The dangerous tone is "that's amazing, how do I do it" . The responsible tone is "why on earth would you do that to yourself" . This post is for the second group. Why the cloud is the right answer for almost everyone Let me get this out of the way honestly: by every conventional metric, I should be using the cloud. Managed Kubernetes has become genuinely good. EKS has dramatically improved over the last three years. GKE has always been better than people gave it credit for. The serverless options are mature. The serverless databases are mature. The observability is mature. The bill is predictable in the way a Tuesday is predictable. Self-hosting violates almost every assumption that makes a startup productive. Time is the most expensive resource you have. The cloud sells you abstractions that turn that time into product. Running your own substrate means the time goes into the substrate. If you are trying to ship a product to customers — go use the cloud. Stop reading this post. It will only confuse you. What the cloud does not sell you Here is what the cloud will not sell you, even if you are willing to pay extra: control over your own roadmap. The cloud's roadmap is the cloud's. They decide which APIs deprecate. They decide which regions get the new feature. They decide what your egress bill looks like. They decide whether your monitoring vendor — sitting on top of their infrastructure — is allowed to charge you eight times what it would cost you to host the same software yourself. They decide whether the small ML company hosting your fine-tuned model gets acquired by someone with very differ

DevTools responsive mode has one limitation that's never been fixed: you see one device at a time. You check iPhone. Looks fine. Switch to iPad. Fix padding. Switch back to iPhone. Was the header already broken or did you just break it? I got tired of holding layouts in my head, so I built a tool that shows all three at once. Responsive Tool — free, no signup Paste a URL → phone, tablet, and desktop load at one time. That's it. A few things that make it actually useful day to day: Swap one pane to a different device without losing the other two Refresh one pane after a code push — no need to reload everything Share your exact setup via URL — a teammate sees the same device comparison you do Sync scroll across all panes with a one-line script snippet Every viewport is a real verified CSS size , not a guess No account. No extension. No download. Runs in the browser. I don't see or store the URLs you test. Also: way more sites block iframes via X-Frame-Options than you'd think. I tested ~60 real sites — 93% of developer portfolios loaded fine, but only 44% of framework/marketing sites did. If your site doesn't load, that's the server blocking iframes, not a bug in the tool. Stack Next.js 16 · React 19 · TypeScript · Tailwind v4 · Cloudflare Workers Bonus I also built a CSS breakpoints reference that maps common breakpoints to real device viewports. Handy even without the tool. 👉 responsivetool.com What do you use for responsive checking? Still just DevTools? I want to know what I'm up against.

The bill that started this I was paying $40/month for a PDF generation API to power a tiny internal invoicing tool for a client project. Forty bucks a month to convert some JSON into a PDF. That's it. That's the whole service. I finally sat down on a Saturday to see if I could kill that subscription. Three weekends later, not only did I kill it — the replacement is faster than the API ever was, because there's no network round-trip at all. This post is the log of how it went, in the order I actually hit the problems, not the order that makes me look competent. Attempt #1: jsPDF on the main thread (it worked, until it didn't) First pass was the obvious one — jsPDF running directly in the click handler: function generateInvoice ( data ) { const doc = new jsPDF (); doc . text ( data . clientName , 20 , 20 ); data . lineItems . forEach (( item , i ) => { doc . text ( ` ${ item . description } — $ ${ item . amount } ` , 20 , 40 + i * 10 ); }); doc . save ( ' invoice.pdf ' ); } Fine for a 3-line invoice. Once I tested with a 40-line-item invoice (a real client sent me one to test against), the tab froze for almost two full seconds. Not crashed — frozen. Scroll didn't work, buttons didn't respond, and on a mid-range Android phone it was closer to five seconds. The main thread doing synchronous PDF math while also being responsible for painting the UI is exactly the kind of thing that looks fine in a demo and falls apart the moment a real user pastes in real data. Attempt #2: move it to a Web Worker Web Workers get talked about like they're this exotic tool for WASM and video processing. They're also just... a really good fit for "expensive synchronous work that a user is waiting on." I'd never reached for one before this project, mostly out of habit. The tricky part isn't the worker itself, it's that jsPDF assumes it has access to document and window in a couple of code paths (font metrics, mostly), which don't exist inside a worker. I ended up switching to pdfkit compiled

A random game is easier to debug when the same inputs produce the same result. In HoopTrait, a browser basketball project, the Lab mode combines eight selected traits and generates a fictional career. The interesting engineering problem is keeping replay, sharing and validation consistent. This is a technical development note, not a claim that a game score predicts an athlete's real performance. Store the decisions, not just the result The Lab state records a seed, a dataset version and an ordered list of actions. An action is a pick or a reroll. Replaying those actions reconstructs the build. A seed alone is not a complete replay contract: changing the player pool or its order can change a seeded draw. A dataset version therefore matters alongside the random seed. For a future release, the same principle should apply to changes in the rules themselves. Test invariants across many runs The Lab test suite iterates through 1,000 seeds. For each seed it shuffles the order of the eight skills, uses the two allowed rerolls, and completes a build. It checks that: Eight distinct players were selected. All eight traits are present, and no player remains to be drawn after completion. The overall game score stays between 0 and 99 and matches the shared rating function. Packing and unpacking the share state returns the original state. Recomputing the fictional career returns the same output. The ten simulated seasons sum to the displayed career earnings. Those assertions catch different problems. A stable score does not prove that a shared link reproduces the same selections. A complete build does not prove that its season totals add up. Reject impossible histories A share payload is untrusted input, even in a client-side game. Negative or fractional seeds, duplicate skill picks, a third reroll, unknown action types, a mismatched dataset version and actions after completion are rejected. The tests also cover malformed encoded payloads and unexpected fields. Local state is usef

This is a submission for Weekend Challenge: Generosity Edition What I Built My late...

This is a submission for Weekend Challenge: Generosity Edition What I Built A donation ledger for a group too small to buy software. It is a Google Sheet, some Apps Script, and one public page a donor can open. The group I had in mind is the kind that exists on every street: a neighbourhood fund, a school parents' group, a committee that collects for winter coats. Money arrives over WhatsApp and leaves in cash, and somebody keeps it in a notebook. The arithmetic is not the hard part. The hard part arrives three months later when a donor asks where their money went, and answering needs the notebook, the person holding it, and an afternoon. Software for this exists and is priced for organisations with a finance team. So the ledger stays in a spreadsheet a volunteer already knows how to open, and the only thing added is what a spreadsheet cannot do alone: read messy human messages, refuse to trust its own reading , and publish the page that answers the question before it is asked. Demo The public page a donor opens → That page is the deployed page, byte for byte, with one line changed: where the Apps Script version writes <?= data ?> , the demo fetches the same JSON from a file so you can read it without a Google account. The JSON is produced by running the sample month through the same recordEntry() and publicView() the real script uses, so if the ledger rules change, the demo changes with them or the build fails. The sample month deliberately includes the things that go wrong: a receipt two volunteers forwarded, a donation typed with one zero too many and later corrected, and a reading the checks refused to trust. What the model read, and whether it was allowed to count → The ledger page shows the result. This one shows the part worth showing. Pick any of six real donation messages and it highlights the exact characters Gemini says it read the amount from, lists the three checks with their outcomes, and says why the row was posted or held. It is fed by a recorded run

Docker management, monitoring that goes deeper than a green dot, backups I have actually restored, and everything else that showed up once deploying stopped being the hard part. Moving off Vercel solved exactly one problem: deploying. Everything else I used to get for free, quietly, as part of the platform, I now had to go find and wire up myself. A month into running my own server, I had a list of ten tools taped to the inside of my head, each one solving a problem I did not know I had until it happened to me at a bad time. This is that list, in the order I actually needed them, with the mistake or the moment that made me install each one. I lean JS and Rust wherever I can, partly out of preference and partly because those are the tools that keep pace with how fast the rest of my stack moves. A couple of these are not JS or Rust at all, and I kept them anyway because they were simply the best tool for the job. 1. Dokploy, for everything I wrote about yesterday This is the one I already spent an entire post on, so I will keep it short here. Push to main, Dokploy builds the container, Traefik points a domain at it, done. Four apps running on one $24 droplet, and adding a fifth would not move the bill. If you deploy anything with Docker and are still doing it over SSH, start here. Everything else on this list assumes you already have a platform under you, not just a server. 2. Neon, for the database half of preview environments The first crack after Dokploy was previews. Dokploy gives every pull request its own preview URL, which is one of the nicest things about the whole setup, right up until every preview hits the same production database. I corrupted a batch of test data twice before I noticed what was happening. Neon branches Postgres the way git branches code, copy-on-write, so a preview PR gets its own preview database that costs almost nothing until it actually diverges from main. The storage engine underneath is written in Rust, and it quietly closed the othe

In a previous post , I covered why TypeScript types alone can't protect you from a backend that returns something you didn't expect, and how to build a small apiRequest boundary that validates both the outgoing request and the incoming response against Zod-style schemas before your application ever touches the data. That post answered one question: Is this data actually shaped the way I think it is? It left another question open: When the answer is no, or when the request fails for a completely different reason (like a timeout or a dropped connection), what does the rest of the app do with that failure? In practice, "the rest of the app" usually does something different depending on who's writing it: One component checks error.response?.status directly. Another checks error.code === "ECONNABORTED" . A form manually digs through the error to find field-level messages. A toast just displays whatever string happens to be on error.message . The app works, but every layer speaks a different error dialect. This post is Part 2: it takes the validation boundary from Part 1 and builds the missing piece on top of it, a single, normalized ApiError shape that every layer of the app can speak, plus the logging, messaging, and form-mapping that make it actually usable. Quick Recap: The Validation Boundary From Part 1, the apiRequest wrapper validates request payloads and response bodies against schemas, and throws one of two typed errors when something doesn't match the contract: export class ApiRequestValidationError extends Error { constructor ( public readonly url : string , public override readonly cause : unknown ) { super ( `API request input does not match the contract for ${ url } .` ); this . name = " ApiRequestValidationError " ; } } export class ApiResponseValidationError extends Error { constructor ( public readonly url : string , public override readonly cause : unknown ) { super ( `API response does not match the contract for ${ url } .` ); this . name = " ApiRespon

Run this against the real, published image and watch it fail: docker run --rm --entrypoint trelix-mcp ghcr.io/sairam0424/trelix:3.2.1 --version Exit code 127. Not a crash inside trelix-mcp, not a stack trace, not a permissions error — 127 is the shell's own way of saying the binary you asked for does not exist. And it didn't. The console script trelix-mcp is supposed to install as part of every trelix package was simply absent from the image, on both the slim tag and the -local tag, for the entire life of the 3.2.1 release. Every unit test in the suite was green. Every line of source that builds trelix-mcp was correct. The thing a user would actually get from docker pull did not have the binary its own --version flag implies exists. This article covers four releases — v3.2.2, v3.2.3, v3.2.4, and v3.2.5 — spanning 173 commits and 88 changed files since v3.2.1, which is where the last article in this series left off. That one was about tests that pass without exercising the code they claim to cover: a MagicMock standing in for a real embedder, an all-ones attention mask that makes masked and unmasked math identical, a unit test that asserted a bug as its own specification. This one, on the heels of the mutation-testing push that closed out that arc, is about a different and in some ways more uncomfortable failure mode: tests that pass while exercising the wrong artifact entirely. A green pytest run against src/ says nothing about whether the wheel on PyPI, the image on GHCR, or the binary on the GitHub Releases page actually does what it claims. Those are three separate build products, built by three separate pipelines, and none of trelix's 4,353 collected unit tests had ever touched any of them directly. v3.2.2 through v3.2.4 is the story of finding that gap and closing it with an actual gate, not a promise to be more careful next time. v3.2.5 is a short postscript proving the discipline stuck. The Docker image that shipped without its own server The 127 above wasn't

In December 2024, Google quietly updated its closed testing rules for personal developer Console accounts. For months, indie developers had to recruit at least 20 testers to keep their app opted in for 14 consecutive days before applying for production access. Under the revised guidelines, that threshold dropped from 20 to 12 testers. Understanding the nuances of the Google Play 20 testers vs 12 testers shift helps you plan your release schedule accurately without running into unexpected delays during Google Play Console verification. While lowering the number by eight testers sounds like a major relief, the core requirements behind closed testing have not changed. Google still enforces a strict 14 consecutive day duration, and the Play Console continues to monitor tester retention and engagement. A lower numerical requirement means less logistical hassle, but maintaining a stable group of committed testers remains the primary hurdle for independent developers. The Policy Shift: From 20 to 12 Testers Google originally introduced mandatory closed testing in November 2023 to improve app quality and curb low-effort submissions on the Play Store. Initially, all new personal accounts registered on or after November 13, 2023, were required to run a closed test with at least 20 opted-in testers for 14 days without interruption. After roughly a year of developer feedback regarding how difficult it was for solo creators to find 20 reliable participants, Google reduced the requirement to 12 testers in December 2024. It is crucial to understand who this rule applies to. The requirement exclusively targets personal developer accounts created on or after November 13, 2023. If you operate an organization or business developer account, or if your personal account was registered before November 13, 2023, you are currently exempt from this mandatory closed testing gate. However, if you fall under the new personal account category, reaching 12 continuous opt-ins is a strict prerequis

readm3 can edit now, and it speaks Reddit readm3 started as a markdown reader for the terminal. File browser on the left, rendered document on the right. Version 0.3.0 adds the obvious missing half: you can change the file you are looking at. Press e , type, press esc . The preview has already re-rendered by the time you get back to it, because both modes read the same buffer. There is no second preview to keep in sync, which is the part that usually goes wrong in editors with a live preview pane. ctrl+s saves. Quitting with unsaved work asks first. enter continues the list you are in, so the same bullet, the next number, or an unchecked box for a task, and pressing it on an empty item ends the list. There is no selection and no cut and paste. This is for fixing a typo and adding a paragraph. Your editor is still your editor. Two dependencies, not forty The old parser was a few hundred lines of hand-rolled regex, and it got reference links, nested lists and bare URLs wrong. Every fix was another regex. Parsing moved to marked. The reason it won was not features, it was weight: marked is CommonMark plus GFM with zero dependencies of its own . readm3 went from one dependency to two. markdown-it would have been seven. A remark and micromark pipeline is somewhere between twenty and forty packages, for a program whose whole point is that it starts instantly in a terminal. Only the parsing moved. The layout code that wraps text, draws code gutters and sizes tables is untouched, so readm3.com still renders through the exact same functions the terminal does. There is still no second renderer. The swap fixed reference links, nested and loose lists, bare URL autolinks and hard line breaks for free. The dialects actually disagree marked does not ship GitHub alerts, footnotes, :emoji: , or anything Reddit added. Those are tokenizer extensions in readm3 now, still with no new dependency. They are behind a --flavor switch rather than all on at once, because the dialects contradic

This is a submission for Weekend Challenge: Generosity Edition What I Built Every...

AI can write code now. That part is no longer surprising. You can describe a feature to Copilot, Claude Code, Cursor, Codex, or another coding agent and get a working implementation in minutes. Sometimes it is genuinely impressive. But there is a bigger question: Can you actually trust the code enough to ship it? According to the Stack Overflow 2025 Developer Survey, 84% of developers use or plan to use AI tools . At the same time, trust in AI-generated output is still limited. One of the biggest frustrations developers report is getting an answer that is almost right, but not quite . Source: https://survey.stackoverflow.co/2025/ai And that “almost right” part is exactly where developers still matter. AI may write more code. But humans still need to decide whether that code is correct, secure, maintainable, and actually worth merging. So here is a simple review workflow I think every developer should practice. 1. Start With the Requirement, Not the Diff Imagine you tell an AI agent: Add password reset support. A few minutes later, it generates the full feature. The code may compile. The UI may work. The tests may even pass. But before reading the implementation, ask: How long should reset tokens remain valid? Can the same token be used twice? What happens if the email does not exist? Should existing sessions be logged out? Are we exposing whether a user account exists? This matters because AI can build the wrong thing very cleanly. So before asking: Does this code work? Ask: Does this solve the correct problem? That one question can save a lot of time. 2. Check the Architecture Before the Syntax AI is usually good at writing a function. It is not always good at understanding where that function belongs inside your system. For example, an agent might create something like: components/ ├── PaymentForm.tsx ├── PaymentAPI.ts ├── StripeService.ts └── Database.ts Everything may technically work. But should database access really live beside your UI components? Probably no