{"slug": "ai-can-write-the-code-but-can-you-prove-its-correct-the-skill-every-developer-in", "title": "AI Can Write the Code. But Can You Prove It’s Correct? — The Skill Every Developer Needs in 2026", "summary": "A developer argues that as AI-generated code becomes more common, the ability to verify its correctness is becoming more valuable than writing it. Citing a 2025 Stack Overflow survey showing 84% of developers use or plan to use AI tools, but only 33% trust their accuracy, the piece emphasizes the danger of 'almost correct' code and outlines verification steps such as understanding requirements, testing, and review.", "body_md": "AI can now generate a feature before you finish explaining it.\n\nYou describe an API endpoint.\n\nA few seconds later, you have the controller, service, database query, validation, tests, and maybe even the Docker config.\n\nIt compiles.\n\nThe tests are green.\n\nThe UI looks fine.\n\nSo the code is correct… right?\n\nNot necessarily.\n\nAnd this may be one of the biggest changes happening in software engineering right now:\n\nWriting code is becoming cheaper. Proving that code is correct is becoming more valuable.\n\nThis isn't really a new engineering principle.\n\nProfessional software teams have always relied on review, testing, security analysis, CI/CD checks, monitoring, and other forms of verification before trusting software.\n\nWhat AI changes is the **amount of code we can produce before a human fully understands it.**\n\nThat makes verification a much bigger part of the developer's job.\n\nDevelopers are adopting AI quickly.\n\nThe 2025 Stack Overflow Developer Survey reported that **84% of respondents were using or planning to use AI tools in development**, and 51% of professional developers said they used them daily.\n\nBut something interesting happened at the same time.\n\nOnly 33% said they trusted the accuracy of AI output, while **46% actively distrusted it**.\n\nAnd the most common frustration wasn't:\n\n\"AI can't write code.\"\n\nIt was almost the opposite.\n\n**66% reported frustration with AI solutions that are almost correct but not quite.** Another 45% said debugging AI-generated code could take more time.\n\nThat \"almost correct\" category is dangerous.\n\nObviously broken code is easy.\n\nYou see the error.\n\nYou fix it.\n\nAlmost-correct code is different.\n\nIt looks professional.\n\nIt uses sensible variable names.\n\nIt follows your framework conventions.\n\nIt may even pass the tests.\n\nAnd somewhere inside it is one assumption that isn't true.\n\nThere is an important distinction here.\n\nThere is no single universal rule saying:\n\n\"Every American software company must follow exactly these seven steps.\"\n\nStartups, banks, defense contractors, SaaS companies, healthcare organizations, and small agencies operate differently.\n\nBut mature engineering organizations tend to converge around the same idea:\n\n**Code is not trusted merely because somebody wrote it. Evidence has to support it.**\n\nIn the United States, NIST's Secure Software Development Framework describes practices such as reviewing or analyzing human-readable code and testing executable code to identify vulnerabilities and verify security requirements.\n\nNIST specifically discusses techniques including:\n\nCISA's Secure by Design guidance similarly recommends practices such as peer review, SAST, DAST, unit testing, and integration testing as complementary techniques rather than treating one check as sufficient.\n\nThat's the mindset we should bring to AI-generated code.\n\nNot:\n\n**AI → Merge**\n\nBut:\n\n**AI → Understand → Verify → Attack → Review → Observe → Merge**\n\nHere's how.\n\nThis sounds obvious.\n\nIt isn't.\n\nSuppose you tell an AI agent:\n\n```\nCreate an endpoint for deleting a user's account.\n```\n\nIt generates:\n\n```\nDELETE /users/:id\n```\n\nThe implementation might be technically perfect.\n\nBut what was the actual requirement?\n\nShould users permanently disappear?\n\nShould records be soft-deleted?\n\nDo invoices have to remain for accounting?\n\nWhat happens to shared workspaces?\n\nWhat happens to API tokens?\n\nShould the user receive an email?\n\nCan an administrator restore the account?\n\nDoes deleting an account violate another data-retention requirement?\n\nThe AI can produce perfectly valid code for the **wrong specification**.\n\nSo before reviewing implementation details, ask:\n\nI often find this question more useful than:\n\n```\nIs this code correct?\n```\n\nAsk instead:\n\n```\nList every important assumption you made while implementing this feature.\n```\n\nYou may discover that the model assumed:\n\nThat is your first verification layer.\n\nThis is where AI coding becomes dangerous for inexperienced developers.\n\nAn agent changes 17 files.\n\nYou read the summary:\n\n```\n✓ Added authentication\n✓ Updated schema\n✓ Added validation\n✓ Added tests\n✓ Fixed lint errors\n```\n\nLooks good.\n\nMerge.\n\nNo.\n\nThe summary is not the implementation.\n\nIf you're responsible for the pull request, you should understand the important changes.\n\nYou don't necessarily need to memorize every generated line.\n\nBut you should be able to explain:\n\nIf you cannot explain those things, your confidence comes from the AI's writing style rather than engineering evidence.\n\nStart with the cheap checks.\n\nFor a TypeScript project that might mean:\n\n```\nnpm run typecheck\nnpm run lint\nnpm run build\n```\n\nFor another stack it could include:\n\n```\ndotnet build\ncargo check\ngo vet ./...\npython -m mypy .\n```\n\nAI often generates code that looks syntactically reasonable while misunderstanding:\n\nCompilation doesn't prove correctness.\n\nBut code that cannot compile has already failed one very inexpensive proof.\n\nAutomate this in CI.\n\nAsk:\n\nSuppose AI writes:\n\n```\nasync function transferMoney(\n  fromAccount: string,\n  toAccount: string,\n  amount: number\n) {\n  await debit(fromAccount, amount);\n  await credit(toAccount, amount);\n}\n```\n\nHappy path:\n\n```\nA → -$100\nB → +$100\n```\n\nGreat.\n\nNow ask:\n\nWhat happens if `credit()`\n\nfails?\n\nYour system could become:\n\n```\nA → -$100\nB → +$0\n```\n\nThe function worked halfway.\n\nAnd halfway is worse than completely failing.\n\nNow you're thinking like a verifier.\n\nYou might need:\n\n``` js\nawait db.transaction(async (tx) => {\n  await debit(tx, fromAccount, amount);\n  await credit(tx, toAccount, amount);\n});\n```\n\nThis is why experienced developers constantly think about failure modes.\n\nAI loves the happy path.\n\nProduction loves everything else.\n\nFor every important function, check at least:\n\n```\nNormal input\nEmpty input\nNull / undefined\nMinimum value\nMaximum value\nIncorrect type\nMalformed input\nDuplicate operation\nUnauthorized request\nConcurrent request\nNetwork failure\nDatabase failure\nTimeout\nRetry\nPartial failure\n```\n\nImagine an AI-generated signup form.\n\nIt works with:\n\n```\njohn@example.com\n```\n\nBut what about:\n\n```\nJOHN@example.com\njohn+test@example.com\n\"\"\n5000-character input\nUnicode\nduplicate email\ndatabase timeout\ntwo simultaneous signups\n```\n\nCorrectness lives at the edges.\n\nThis is an important engineering habit.\n\nInstead of only testing:\n\n```\n10 + 20 = 30\n```\n\ntest the rule that should always remain true.\n\nFor example, in a payments system:\n\nMoney cannot disappear.\n\nIn an inventory system:\n\nStock cannot become negative.\n\nIn an authorization system:\n\nA user cannot access another organization's private resources.\n\nIn a billing system:\n\nRetrying the same webhook must not charge the customer twice.\n\nThese are **invariants**.\n\nAI-generated implementation can change.\n\nYour invariants should not.\n\nWhen reviewing AI-generated systems, identifying invariants may be more valuable than reading hundreds of generated lines.\n\nHere's a subtle trap.\n\nYou ask AI:\n\n```\nImplement this feature.\n```\n\nThen:\n\n```\nWrite tests for it.\n```\n\nThe AI made assumption X while implementing the feature.\n\nNow it writes tests based on… assumption X.\n\nImplementation:\n\n```\nwrong assumption → code\n```\n\nTests:\n\n```\nsame wrong assumption → test\n```\n\nResult:\n\n```\n✅ 47 tests passed\n```\n\nBut the system can still be wrong.\n\nTests prove that the implementation satisfies the tests.\n\nThey do not automatically prove that the tests represent reality.\n\nSo use independent verification.\n\nFor example:\n\n```\nImplement this feature.\n```\n\nGive it only the requirements and resulting diff:\n\n```\nAct as a hostile reviewer.\n\nFind incorrect assumptions, security vulnerabilities,\nrace conditions, missing edge cases and ways this\nimplementation could fail in production.\n\nDo not try to defend the implementation.\n```\n\nNow AI is being used as an adversary rather than merely an author.\n\nThat is much more powerful.\n\nAI-generated code frequently introduces packages.\n\nFor example:\n\n```\nnpm install some-amazing-auth-helper\n```\n\nDon't blindly run it.\n\nCheck:\n\nAnd most importantly:\n\nDid we need another dependency at all?\n\nDependencies become part of your software supply chain.\n\nTreat them accordingly.\n\nThese are not the same thing.\n\nAuthentication asks:\n\nWho are you?\n\nAuthorization asks:\n\nAre you allowed to do this?\n\nAI frequently handles authentication correctly while missing authorization.\n\nImagine:\n\n```\nGET /projects/:projectId\n```\n\nThe route checks:\n\n```\nif (!user) {\n  return 401;\n}\n```\n\nGreat.\n\nBut where is:\n\n```\nif (project.organizationId !== user.organizationId) {\n  return 403;\n}\n```\n\nWithout it, every authenticated user may be able to access every project by changing the ID.\n\nThat's not hypothetical \"AI safety.\"\n\nThat's ordinary application security.\n\nWhich is exactly the point:\n\n**AI-generated code still has to survive ordinary engineering standards.**\n\nAI agents can now:\n\n```\nmodify files\nrun terminal commands\nexecute migrations\ncall APIs\ncreate infrastructure\ndelete resources\npush code\ndeploy\n```\n\nThat's a very different risk level from autocomplete.\n\nBefore allowing destructive operations, ask:\n\n```\nCan it delete production data?\nCan it modify production?\nCan it rotate credentials?\nCan it change infrastructure?\nCan it force-push?\nCan it publish packages?\n```\n\nA useful principle is:\n\nIf an agent only needs to modify source files, it probably doesn't need production database credentials.\n\nIf it only needs to analyze logs, it probably doesn't need write access.\n\nCapability should be earned, not assumed.\n\nTests execute known scenarios.\n\nStatic analysis looks for suspicious patterns without necessarily running the application.\n\nDepending on the stack, this could include tools for:\n\n```\nlinting\nSAST\ndependency scanning\nsecret scanning\ntype checking\ncode quality\nlicense checks\n```\n\nA CI pipeline might conceptually look like:\n\n```\nPull Request\n      ↓\nType Check\n      ↓\nLint\n      ↓\nUnit Tests\n      ↓\nIntegration Tests\n      ↓\nSecurity Scan\n      ↓\nDependency Scan\n      ↓\nHuman Review\n      ↓\nMerge\n```\n\nNotice something important?\n\nThere is no:\n\n```\nWas generated by AI? → skip everything\n```\n\nAI code should pass the same gates as human code.\n\nPossibly stricter gates when the author didn't fully understand the generated implementation.\n\nA unit can be correct while the system is wrong.\n\nYour payment service works.\n\nYour database service works.\n\nYour webhook handler works.\n\nThen production does this:\n\n```\nStripe webhook\n      ↓\ntimeout\n      ↓\nStripe retries\n      ↓\nyour endpoint processes again\n      ↓\nduplicate transaction\n```\n\nNothing was wrong with the individual function.\n\nThe interaction was wrong.\n\nAI agents are particularly good at generating locally reasonable components.\n\nThat makes integration testing extremely important.\n\nNIST's current DevSecOps reference material also describes automated test suites spanning functional and non-functional requirements, including unit, integration, regression, smoke and acceptance testing before artifacts advance further through delivery.\n\nSuppose your AI generates code based on:\n\n```\nPOST /v1/payments\n```\n\nMaybe the actual provider changed it.\n\nMaybe the response field is:\n\n```\n{\n  \"payment_status\": \"paid\"\n}\n```\n\nwhile the AI assumed:\n\n```\n{\n  \"status\": \"success\"\n}\n```\n\nThis is why documentation matters.\n\nThe Stack Overflow survey still shows technical documentation as the most commonly used learning resource among developers.\n\nFor external integrations, verify against:\n\nNot:\n\n\"The AI sounded confident.\"\n\nBecause it does.\n\nAI-generated migration:\n\n```\nALTER TABLE users\nDROP COLUMN legacy_id;\n```\n\nLooks clean.\n\nDid the AI check whether:\n\n```\nanother service still reads it?\nanalytics depends on it?\na rollback requires it?\nmillions of rows need migration?\nthe operation locks the table?\n```\n\nSchema changes deserve a different level of caution.\n\nFor dangerous migrations, think about:\n\n```\nexpand\nmigrate\nverify\ncontract\n```\n\ninstead of:\n\n```\nchange everything immediately\n```\n\nHere's another important distinction.\n\nTests answer:\n\nDid it behave correctly in scenarios we predicted?\n\nMonitoring answers:\n\nWhat is happening in scenarios we didn't predict?\n\nProduction needs:\n\n```\nlogs\nmetrics\ntraces\nerror reporting\nalerts\naudit events\n```\n\nImagine an AI feature passes every test but causes API latency to go from:\n\n```\n180 ms\n```\n\nto:\n\n```\n2.8 seconds\n```\n\nTechnically correct.\n\nOperationally terrible.\n\nCorrectness includes production behavior.\n\nThis may be the most useful technique in this article.\n\nBefore saying:\n\n```\nBuild this feature.\n```\n\nwrite:\n\nExample:\n\n```\nFeature: Password Reset\n\nRequirements:\n\n[ ] Token expires after 15 minutes\n[ ] Token can only be used once\n[ ] Existing sessions can be revoked\n[ ] Email enumeration is prevented\n[ ] Rate limiting exists\n[ ] Password policy is enforced\n[ ] Reset attempts are logged\n[ ] Unit tests pass\n[ ] Integration tests pass\n[ ] Security scan passes\n[ ] Another developer reviews the PR\n```\n\nNow the conversation changes.\n\nInstead of asking AI:\n\n\"Make password reset.\"\n\nyou're asking:\n\n\"Produce an implementation that satisfies these observable conditions.\"\n\nThat is much closer to engineering.\n\nHere's the workflow I'm increasingly convinced developers should learn:\n\n```\n            ┌───────────────┐\n            │  REQUIREMENT  │\n            └───────┬───────┘\n                    ↓\n            ┌───────────────┐\n            │   GENERATE    │\n            └───────┬───────┘\n                    ↓\n            ┌───────────────┐\n            │  UNDERSTAND   │\n            └───────┬───────┘\n                    ↓\n            ┌───────────────┐\n            │     TEST      │\n            └───────┬───────┘\n                    ↓\n            ┌───────────────┐\n            │    ATTACK     │\n            └───────┬───────┘\n                    ↓\n            ┌───────────────┐\n            │    REVIEW     │\n            └───────┬───────┘\n                    ↓\n            ┌───────────────┐\n            │    OBSERVE    │\n            └───────┬───────┘\n                    ↓\n            ┌───────────────┐\n            │     SHIP      │\n            └───────────────┘\n```\n\nNotice how little of this is about typing code.\n\nThat's probably where software engineering is heading.\n\nI sometimes see advice like:\n\n\"AI writes code now, so learning fundamentals doesn't matter.\"\n\nI think the opposite is happening.\n\nIf AI gives you this:\n\n``` js\nconst results = await Promise.all(\n  users.map(user => processUser(user))\n);\n```\n\nyou need enough engineering knowledge to ask:\n\nAI makes syntax less valuable.\n\nIt makes **judgment more valuable**.\n\nLearn:\n\n```\ndatabases\nnetworking\nHTTP\nauthentication\nauthorization\ntransactions\nconcurrency\ncaching\nqueues\ndistributed systems\ntesting\nsecurity\nobservability\nsystem design\n```\n\nNot because AI can't generate code involving them.\n\nBecause you need those concepts to determine whether the generated code makes sense.\n\nSenior engineering may also change.\n\nA senior developer's leverage used to be partly:\n\n\"I can write this implementation much faster than a junior.\"\n\nNow AI may generate both implementations quickly.\n\nThe senior developer's advantage becomes:\n\n\"I know which implementation will survive production.\"\n\nThey recognize:\n\nThose skills become more important when implementation becomes cheap.\n\nBefore merging a significant AI-generated PR, I want to be able to answer these questions:\n\nIf I cannot answer important questions on that list, I'm not ready to say:\n\n\"The code is correct.\"\n\nThis is the mindset shift I think matters most.\n\nInstead of prompting:\n\n```\nBuild authentication.\n```\n\ntry:\n\n```\nImplement authentication.\n\nThen provide:\n\n1. assumptions you made\n2. threat scenarios\n3. tests covering happy and failure paths\n4. authorization checks\n5. dependency changes\n6. migration implications\n7. commands I can run to verify everything\n8. unresolved risks\n```\n\nNow you're not merely asking AI for code.\n\nYou're asking AI to help produce **evidence**.\n\nAnd you independently verify that evidence.\n\nAI is rapidly reducing the effort required to turn an idea into source code.\n\nBut companies don't really pay engineers for producing characters in a `.ts`\n\n, `.py`\n\n, `.go`\n\n, `.rs`\n\n, or `.java`\n\nfile.\n\nThey pay engineers to make systems work.\n\nReliably.\n\nSecurely.\n\nAt scale.\n\nWith real users.\n\nWith real money.\n\nWith real data.\n\nAnd with somebody accountable when something goes wrong.\n\nAI can generate:\n\n```\n10,000 lines\n```\n\nbefore lunch.\n\nProduction doesn't care.\n\nProduction asks:\n\n```\nDoes it work?\n\nWill it keep working?\n\nIs it secure?\n\nCan it fail safely?\n\nCan we monitor it?\n\nCan we recover?\n\nCan another engineer maintain it?\n\nCan you prove those things?\n```\n\nThat is software engineering.\n\nLearn AI coding.\n\nUse Copilot.\n\nUse Claude.\n\nUse ChatGPT.\n\nUse coding agents.\n\nAutomate repetitive work.\n\nGenerate tests.\n\nGenerate migrations.\n\nGenerate documentation.\n\nGenerate prototypes.\n\nMove faster.\n\nBut don't make:\n\n\"AI generated it successfully\"\n\nyour definition of done.\n\nMake this your definition:\n\n\"I have enough evidence to trust this in production.\"\n\nBecause as code becomes easier to generate, one developer skill becomes harder to automate:\n\nOne question for developers working with AI every day:\n\n**If AI generated 80% of a production pull request, how much of that implementation would you personally need to understand before pressing Merge?**\n\n**A)** Every important line\n\n**B)** Architecture + critical paths\n\n**C)** I mainly need strong tests and CI evidence\n\n**D)** If the agent can prove the behavior, I'll merge it\n\n**E)** I genuinely don't know yet\n\nI'm especially curious how this differs between startups, enterprise teams, solo developers, and regulated industries.\n\nWhat is your standard?", "url": "https://wpnews.pro/news/ai-can-write-the-code-but-can-you-prove-its-correct-the-skill-every-developer-in", "canonical_source": "https://dev.to/robertadam987_/ai-can-write-the-code-but-can-you-prove-its-correct-the-skill-every-developer-needs-in-2026-3ln4", "published_at": "2026-08-30 05:27:30+00:00", "updated_at": "2026-08-30 05:52:05.385583+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-safety"], "entities": ["Stack Overflow", "NIST", "CISA"], "alternates": {"html": "https://wpnews.pro/news/ai-can-write-the-code-but-can-you-prove-its-correct-the-skill-every-developer-in", "markdown": "https://wpnews.pro/news/ai-can-write-the-code-but-can-you-prove-its-correct-the-skill-every-developer-in.md", "text": "https://wpnews.pro/news/ai-can-write-the-code-but-can-you-prove-its-correct-the-skill-every-developer-in.txt", "jsonld": "https://wpnews.pro/news/ai-can-write-the-code-but-can-you-prove-its-correct-the-skill-every-developer-in.jsonld"}}