{"slug": "i-can-tell-within-5-minutes-whether-someone-is-using-ai-as-an-engineer-or-as-a", "title": "\" I Can Tell Within 5 Minutes Whether Someone Is Using AI as an Engineer or as a Gambler \"", "summary": "An engineer can determine within five minutes whether someone is using AI as an engineer or as a gambler, based on whether they start with architecture or a prompt. The developer warns that AI-generated code often produces demos rather than production systems, and that the gap between generating code and building software is where systems fail. The engineer argues that AI cannot discover what users actually need, making user research and architectural discipline more critical than ever as the speed of building wrong solutions increases.", "body_md": "The engineer starts with architecture.\n\nThe gambler starts with a prompt.\n\nI have been both. And I have watched enough codebases collapse under the weight of AI-generated confidence to know exactly where the line is.\n\nThis is not a piece about whether you should use Claude Code, Cursor, or any other AI coding tool. You should. The productivity advantage is real, and ignoring it is its own form of professional negligence. This is about the gap between *using these tools* and *understanding what you are actually building* — a gap that is wider than most people want to admit, and more expensive than most people expect.\n\nThere is a moment every vibe coder knows. You type a prompt, the code appears, you run it, and it works. The UI renders. The API responds. You feel, briefly, like you have unlocked something.\n\nWhat you have unlocked is a demo. What you have not built is a system.\n\nI learned this the hard way — not by shipping something catastrophic, but by inheriting a codebase someone else had vibe-coded their way through. On the surface it looked complete. Routes, components, a database, even some auth. But the moment I tried to understand it — really understand it, the way you have to when something breaks at 2am — I found a system that nobody, including the person who built it, could explain. No one knew the request flow. No one knew why certain database calls were where they were. The “auth” was a thin wrapper that could be bypassed with a single malformed header.\n\nThe code existed. The system did not.\n\nThat experience changed how I think about AI-assisted development entirely. Because the problem was not that the developer used AI. The problem was that they confused generating code with building software. Those are not the same thing, and the distance between them is exactly where production systems go to die.\n\nBefore a single line of code gets written — AI-generated or otherwise — there is a question that most vibe coders never ask: *does anyone actually need this, in this form, for this reason?*\n\nMost production software does not fail because of bad code. It fails because of bad understanding.\n\nI have seen this pattern more than once, and lived a version of it myself. A developer builds exactly what was asked for. The code is clean, the deployment is smooth, the demo goes well. And then it turns out the workflow was wrong. The permissions model did not match how the organisation actually worked. The pricing assumption baked into the data model conflicted with what sales had already promised customers. The feature solved a problem that was not actually the problem anyone had.\n\nAI can generate code. It cannot discover what users actually need.\n\nIt cannot sit in a user interview and notice the person keeps reaching for a feature that does not exist. It cannot read the Slack message where a stakeholder quietly changed their mind about scope. It cannot sense the tension between what a product manager says they want and what they actually mean. It cannot tell you that the permissions model you are building assumes a flat organisation, when the client has four layers of hierarchy and an approval workflow nobody mentioned.\n\nBefore you open Cursor, you need to be able to answer: who uses this, in what context, doing what task, and why does it matter to them? If your only source of truth is the prompt you are about to write, you are building on assumption. And AI will execute on that assumption with complete confidence, in exactly the wrong direction, at impressive speed.\n\nThe discipline of talking to users, mapping real workflows, validating understanding before building — that discipline has not been automated. It has become *more* important, because the cost of building the wrong thing is now higher. You can build faster. Which means you can be more wrong, more completely, in less time.\n\nWhen requirements change, the engineer updates the architecture. The gambler adds another prompt.\n\nOnce the business context is clear, there is still a long list of things that never appear in the first prompt — or the second, or the tenth. Not as criticism. I have skipped all of these myself at some point.\n\n**Authentication and authorisation** — not just a login page, but token lifecycle, session invalidation, refresh rotation, role-based access control, and protection against IDOR vulnerabilities that let one user access another’s data by changing a single ID in the URL.\n\n**Database design** — indexing strategy, migration safety, transaction boundaries, connection pooling, and the question nobody asks until it is too late: what happens to your schema when you have six months of production data inside it and you need to change a column?\n\n**API design** — versioning, idempotency, rate limiting, consistent error contracts, and backward compatibility when clients you do not control are depending on your endpoints.\n\n**Security surface area** — input validation, secrets management, dependency vulnerabilities, and what happens when someone sends your API something it did not expect.\n\n**Observability** — structured logging, distributed tracing, alerting thresholds. The ability to answer, with actual evidence, what happened when something went wrong at 3am.\n\n**Failure modes** — what does the system do when the payment gateway times out? When the database is under load? When a background job fails silently and no one notices for four days?\n\nNone of these appear in the first prompt. Most never appear at all. The AI does not volunteer them. And the vibe coder, focused on features, does not think to ask.\n\nWhen auth breaks, the engineer investigates the token lifecycle. The gambler asks Cursor to regenerate the middleware.\n\nThere is a spiral I fell into early with these tools, and I see it constantly now:\n\nThis is not a tool failure. It is a process failure. The tokens are not the cost. The lack of clarity going *in* is the cost. Token burn is just the symptom.\n\nThe engineers getting disproportionate value from Claude Code and Cursor are not the ones typing the most prompts. They are the ones doing the most thinking before they open the tool. A page of plain prose describing the system — the actors, the data, the edge cases, the constraints — saves more tokens than any prompt engineering trick. Because what it actually saves is rework.\n\nHere is the line I wish someone had told me before I first opened Claude Code seriously: AI does not just accelerate feature development. It accelerates technical debt creation too.\n\nEvery time you accept a generated abstraction without understanding it, you are borrowing from your future self. Every pattern that does not quite fit your architecture but “works for now,” every inconsistency left because the AI made it easy — these compound. And they compound faster than manually written debt, because the volume of generated code is so much higher.\n\nI have watched codebases that took a few weeks to build with AI take months to stabilise — not because the features were wrong, but because the underlying structure was incoherent. Functions doing too much. State managed in three different ways across the same application. Error handling thorough in some places and completely absent in others.\n\nThe code was generated consistently. The *system* was not designed consistently. Those are different things, and only one of them is something the AI can ensure.\n\nManaging this means being deliberate about patterns before you start. Decide how errors propagate, and enforce it. Decide how data is fetched, and stick to it. Review generated code not just for correctness but for consistency with what already exists. The AI will not do this for you. It will cheerfully produce something that works in isolation and clashes with everything around it — and it will do so confidently, at speed, without any indication that there is a problem.\n\nThe engineer reviews for consistency. The gambler merges and moves on.\n\nThe argument for skipping tests when using AI goes something like: the AI generated this quickly, it is probably fine, I will add tests later. I have made this argument. It is wrong.\n\nAI generates more code, faster. That means more execution paths. More edge cases. More surface area for regressions. The testing burden *increases* when AI is in the loop, not decreases.\n\nWhen I write code manually, I have an implicit model of what it does and does not handle — because I wrote it, I thought about it. When AI generates code, that model does not transfer to me automatically. Tests are not just quality assurance in this context. They are how I verify that my understanding of what the AI produced matches what it actually does.\n\nBeyond that: AI-generated code handles the happy path well and edge cases poorly, almost by default. It rarely adds validation for empty arrays, null responses from external APIs, or concurrent writes to the same record — unless you ask for it explicitly, with specificity. Tests surface exactly these gaps. They are the thing that tells you the difference between code that *runs* and code that *works*.\n\nThe rule I have settled into: if I cannot write a test for something, I do not fully understand it. And if I do not fully understand it, it does not go to production.\n\nThis is the one I feel most strongly about, because I see it most clearly and because I almost became it.\n\nWhen AI-generated code breaks — and it will break — the vibe coder has no mental model to fall back on. No understanding of the request lifecycle. No picture of how authentication state moves through the system. No intuition about why the database query is failing under load. No idea what “deployed” actually means in terms of how code travels from file to running process.\n\nSo they do what feels natural: they ask the AI to fix it.\n\nSometimes it does. Sometimes it generates a fix that introduces a subtler problem. And the developer, having never built a real model of how the system works, cannot tell the difference until something else breaks downstream, in production, in front of a user.\n\nThe dependency becomes total. The developer is no longer using AI as a tool. They are a human sitting in the loop of a process they cannot override, cannot explain, and cannot recover from without the tool they are now completely dependent on.\n\nThe question I now ask about everything I ship: *if Cursor disappeared tomorrow, could I explain how this application works?*\n\nNot what it does. How it works. The request lifecycle. The database connection model. What the authentication middleware actually checks. What the deployment pipeline does with the code between commit and production.\n\nIf the answer is no, I have not built something. I have supervised something being built in a language I do not speak. That is a dangerous place to operate from professionally, and an increasingly common one.\n\nThe solution is not to stop using AI. It is to use it in ways that build your understanding, not bypass it. Ask the AI to walk you through what it generated. Ask why it made the choices it made. Ask what would break first under load. Use the tool to compress the time it takes to learn, not to skip the learning entirely.\n\nWhen something breaks in production, the engineer traces the request flow. The gambler opens a new Claude chat.\n\n**Start with the business, not the build.** Before you write a prompt, be able to answer who uses this, in what workflow, with what permissions, for what outcome. If the only person who can answer that is the AI, you are not ready to build.\n\n**Design before you delegate.** A rough architecture document — even a page of prose — clarifies your constraints, surfaces your gaps, and gives the AI real instructions instead of freedom to guess. The investment always pays back in fewer iterations.\n\n**Work in vertical slices.** One complete, production-quality feature at a time — database to API to UI. Own the contract for each slice. Let the AI implement. Review with genuine scrutiny, not optimistic hope.\n\n**Treat generated code as a first draft.** Check for hardcoded values, missing validation, naive error handling, security assumptions, N+1 queries, and tests that only cover the happy path. Review it the way you would review a pull request from someone talented but completely unfamiliar with your system — because that is exactly what it is.\n\n**Manage context deliberately.** Start new conversations for new concerns. Summarise and reset when a thread grows long. Front-load your constraints — the stack, the existing patterns, the things that must not change — at the top of every substantive prompt. The AI works better when you act like a senior engineer giving a thorough brief, not a user typing a wish.\n\n**Own every architecture decision.** Which database, which auth strategy, synchronous or event-driven, how errors surface — these belong to you. Make them explicitly, document them briefly, give them to the AI as hard constraints. The AI will make choices if you do not. Those choices will be generic, reasonable, and frequently wrong for your specific situation.\n\nIf any answer is no, the feature is not done. It is a draft wearing production’s clothes.\n\nThe engineers extracting the most from these tools have made one specific shift: they use AI to accelerate their thinking, not replace it.\n\nThey spend more time on design than they ever did before — because they know implementation will be fast. They invest in precise, constraint-rich prompts not because they have memorised prompt tricks, but because they have thought clearly about what they actually want. They review generated code not with the hope that it is correct, but with the expectation that it will need judgment applied to it.\n\nVibe coding as a philosophy — the belief that the prompt is the engineering — produces systems that demo well and fail quietly. It produces security vulnerabilities, incoherent architectures, developers who cannot explain what they have built, technical debt accumulating faster than anyone can manage, and a growing dependency on a tool that cannot debug itself.\n\nUsed by someone with genuine engineering discipline, Claude Code and Cursor and everything that follows them are among the most powerful productivity multipliers this craft has ever seen.\n\nThe difference is not the tool. It is whether the person holding it understands what they are building — before, during, and especially after the prompt returns.\n\n*If you have learned a version of this the hard way, I would genuinely like to hear about it.*", "url": "https://wpnews.pro/news/i-can-tell-within-5-minutes-whether-someone-is-using-ai-as-an-engineer-or-as-a", "canonical_source": "https://dev.to/akshay_mali_837a6ec7bd92a/-i-can-tell-within-5-minutes-whether-someone-is-using-ai-as-an-engineer-or-as-a-gambler--26ap", "published_at": "2026-06-04 12:31:58+00:00", "updated_at": "2026-06-04 12:43:28.758781+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "ai-products", "generative-ai", "ai-agents"], "entities": ["Claude Code", "Cursor"], "alternates": {"html": "https://wpnews.pro/news/i-can-tell-within-5-minutes-whether-someone-is-using-ai-as-an-engineer-or-as-a", "markdown": "https://wpnews.pro/news/i-can-tell-within-5-minutes-whether-someone-is-using-ai-as-an-engineer-or-as-a.md", "text": "https://wpnews.pro/news/i-can-tell-within-5-minutes-whether-someone-is-using-ai-as-an-engineer-or-as-a.txt", "jsonld": "https://wpnews.pro/news/i-can-tell-within-5-minutes-whether-someone-is-using-ai-as-an-engineer-or-as-a.jsonld"}}