{"slug": "ai-can-write-the-code-who-gives-it-the-context", "title": "AI Can Write the Code. Who Gives It the Context?", "summary": "A developer argues that successful AI adoption in software engineering depends on context engineering rather than code generation speed. Without sufficient engineering context, AI tools produce plausible but inconsistent code that leads to duplication and long-term maintainability issues. The post warns that optimizing for development speed without architectural consistency creates a feedback loop of weak context and increasingly divergent code.", "body_md": "When you talk to ChatGPT about a subject you understand well, you quickly notice something.\n\nThe first answer is rarely the final answer.\n\nYou add context.\n\nYou correct an assumption.\n\nYou explain what has already been tried.\n\nYou point out that one proposed solution conflicts with another part of the system.\n\nAfter a few iterations, the answer becomes useful.\n\nThe same thing happens when **AI writes code** for real products.\n\nThe difference is that a slightly incorrect explanation in a chat is usually harmless. Slightly incorrect code can become part of your product, pass a superficial review, and remain there for years.\n\nThis is why successful **AI adoption in software engineering** is not primarily about generating more code.\n\nIt is about **context engineering**: giving AI enough context, constraints, and feedback to generate code that belongs in your system.\n\n**AI coding tools** are very good at producing plausible solutions.\n\nThat word matters: plausible.\n\nThe code may compile.\n\nThe tests may pass.\n\nThe implementation may even look clean when reviewed in isolation.\n\nBut software does not exist in isolation.\n\nA change must fit the broader **system architecture**:\n\nAn AI assistant does not automatically understand those things.\n\nIt knows the code it can see and the **engineering context** you provide. Everything outside that window must be inferred.\n\nAnd inference is where divergence begins.\n\nIf you trust the first response without validating its assumptions, you are usually not accelerating engineering.\n\nYou are accelerating uncertainty.\n\nOne of the first visible effects is duplication.\n\nAI does not necessarily know that your application already has:\n\nWithout sufficient **engineering context**, it creates another one.\n\nThe new implementation may be technically correct. It may also be slightly different from the existing implementation.\n\nNow the system has two ways to solve the same problem.\n\nRepeat this across dozens of AI-generated changes and the codebase slowly breaks a basic rule engineers call **DRY** (**don't repeat yourself**). The same problem should be solved once, in one place, not rebuilt slightly differently every time. Not because anyone deliberately chose duplication, but because each generated change was created from a partial view of the system.\n\nThis is one of the biggest risks of optimizing purely for development speed.\n\nThe individual pull request looks faster.\n\nThe product becomes slower to change.\n\nMany companies currently measure AI adoption by how much faster engineers can produce code.\n\nThat is understandable.\n\nGenerated code is visible. **Long-term maintainability** is not.\n\nYou can measure how quickly a feature reached production. It is much harder to measure how much architectural inconsistency was introduced along the way.\n\nThe cost appears later:\n\nThe system becomes harder for humans to understand.\n\nIt also becomes harder for AI to understand.\n\nThis creates a feedback loop.\n\nWeak context produces inconsistent **AI-generated code**. Inconsistent code produces weaker context for the next generation.\n\nCoding has always contained an element of craft.\n\nExperienced engineers develop preferences around naming, abstractions, interfaces, failure modes, and the shape of a maintainable system.\n\nIn that sense, software development has often resembled building artisanal furniture.\n\nEach piece receives attention. Decisions are made by someone who understands the material, the environment, and the intended use.\n\nAI changes the economics.\n\nWe are moving from artisanal furniture towards IKEA.\n\nSoftware components can be produced faster, in greater volume, and by more people. That is not necessarily bad.\n\nMost companies do not need every internal tool to be a handcrafted masterpiece.\n\nMass production works when the pieces are standardized and the person assembling them has reliable instructions.\n\nWithout the instructions, you do not get scalable production.\n\nYou get a room full of boards, screws, and several pieces that look almost identical but are not interchangeable.\n\nIn software organizations, those instructions are created by experienced engineers with product knowledge.\n\nSenior and staff engineers understand more than the syntax of the codebase.\n\nThey know:\n\nThat knowledge needs to become accessible to both people and machines.\n\nThis includes:\n\nThe goal is not documentation for its own sake.\n\nThe goal is to turn organizational knowledge into usable **engineering context**.\n\nA codebase without recorded decisions already creates problems for junior developers.\n\nAI amplifies the same problem.\n\nWhen there are no written **ADRs**, your junior AI engineer will happily make a different architectural decision in every pull request.\n\nCreating a knowledge base is not enough.\n\nIt must remain current.\n\n**Outdated documentation** can be worse than missing documentation because it gives the model confidence in the wrong constraints.\n\nImagine that your architecture document still recommends a pattern the team abandoned six months ago.\n\nA human engineer may notice the discrepancy through conversations, recent pull requests, or experience with the system.\n\nAI may treat the document as authoritative.\n\nIt then generates code that follows an obsolete direction, while appearing perfectly aligned with the company's written standards.\n\nThis means engineering knowledge must be treated like code:\n\nAI can help here too.\n\nIt can compare documentation with current implementation, detect references to removed services, identify conflicting instructions, and highlight architectural patterns that are no longer followed.\n\nBut the final responsibility still belongs to the organization.\n\nAutomating knowledge checks does not remove ownership.\n\nIt makes ownership easier to exercise.\n\nGood **prompt engineering** helps.\n\n**Engineering guardrails** matter more.\n\n**AI-generated code** should move through the same engineering system as human-generated code, with stronger automation where appropriate.\n\nThat means proper **CI/CD controls**:\n\nWhere rules can be expressed automatically, they should not depend on someone remembering them during every conversation with an AI assistant.\n\nA prompt can say:\n\nDo not access the database directly from this layer.\n\nAn architectural test can enforce it.\n\nThe second one scales better.\n\nThe most successful AI-enabled teams will not be those with the longest prompt files. They will be those that convert important engineering decisions into **automatically verifiable constraints**.\n\nNot every change requires the same level of human attention.\n\nGenerating a small internal tool is different from changing payment processing, authorization, infrastructure, or a financial ledger.\n\nOrganizations need to decide where a human must remain directly involved.\n\nCritical areas may include:\n\nHuman review is not there because AI is useless.\n\nIt is there because responsibility cannot be delegated to a probabilistic system. That is the core of **human-in-the-loop** validation.\n\nThe important question is not whether AI participated in the change.\n\nThe important question is whether the organization applied the right level of control to the risk involved.\n\n**Code review** remains crucial.\n\nBut reading every generated line manually is becoming less realistic as the volume of AI-generated code increases.\n\nThe answer is not to stop reviewing.\n\nThe answer is to change how review works.\n\nEngineers increasingly guide AI to examine changes from multiple perspectives:\n\nThe reviewer moves from inspecting every character to directing a structured investigation.\n\nAI generates code.\n\nAI can also criticize it, compare it with the rest of the system, and search for inconsistencies.\n\nThe human decides which questions matter and whether the answers are sufficient.\n\nThat is still **engineering judgment**.\n\nJunior engineers are still welcome.\n\nAI does not remove the need for people entering the profession. It changes the environment in which they learn.\n\nPreviously, juniors often developed their skills by writing relatively simple implementations and receiving feedback from more experienced engineers.\n\nAI can now produce many of those implementations faster.\n\nBut generating the implementation was never the final objective.\n\nThe objective was learning how to reason about a system.\n\nJuniors still need to understand:\n\nCompanies should not optimize juniors purely for prompt throughput.\n\nThey should optimize for how quickly people build reliable mental models of the product.\n\nThat requires access to knowledge, mentorship, and clear **engineering standards**.\n\nThe same **context engineering** that makes AI better also makes junior engineers better.\n\nThere is another longer-term concern.\n\nAI models are trained on existing knowledge.\n\nThey naturally lean towards technologies, libraries, and architectural patterns that appear frequently in their training data and online documentation.\n\nThat gives established technologies an additional advantage.\n\nA mature framework has:\n\nA new framework has very little of this.\n\nEven when the new framework offers a better approach, AI may produce weaker results because it has less knowledge about how to use it correctly.\n\nThis may create an unexpected effect.\n\nAI could accelerate development inside established ecosystems while slowing the adoption of genuinely new ones.\n\nTeams may avoid newer technologies not because they are worse, but because their AI tools are less effective with them.\n\nThe internet was already influenced by popularity.\n\nAI may reinforce that influence by turning popularity into implementation quality.\n\nNew frameworks will need to treat machine-readable documentation, examples, migration guides, and strong tooling as core parts of adoption.\n\nIt will no longer be enough for a technology to be good.\n\nAI must also be able to understand it.\n\nNot all software should become mass-produced furniture.\n\nThere will remain areas where code itself carries unusual value:\n\nThese are places where the available training data may be limited and where correctness depends on knowledge that cannot be reconstructed from common public patterns.\n\nThere will also always be engineers who treat code as a form of art.\n\nThere is a place for that.\n\nBut most commercial software is not valuable because every function is uniquely beautiful.\n\nIt is valuable because it solves a real problem reliably and can continue evolving.\n\nAI can help us build more of it.\n\nThe condition is that we stop treating generated code as the finished product.\n\nThe difficult part of **practical AI adoption** is not selecting a coding assistant.\n\nIt is preparing the organization around it.\n\nDo engineers have access to reliable product context?\n\nAre architectural decisions documented?\n\nIs outdated knowledge removed?\n\nCan important rules be checked automatically?\n\nDoes **CI/CD** prevent unsafe shortcuts?\n\nAre humans involved where the consequences justify it?\n\nAI makes producing code cheaper.\n\nIt does not make understanding the product less important.\n\nIn fact, as implementation becomes easier, **context engineering** becomes the scarce resource.\n\nThe companies that benefit most from AI will not necessarily be those that generate the most code.\n\nThey will be those that provide the clearest instructions for how all the pieces should fit together.", "url": "https://wpnews.pro/news/ai-can-write-the-code-who-gives-it-the-context", "canonical_source": "https://dev.to/icetique/ai-can-write-the-code-who-gives-it-the-context-2l1b", "published_at": "2026-06-18 18:21:05+00:00", "updated_at": "2026-06-18 18:59:56.002218+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "developer-tools", "ai-products", "ai-agents"], "entities": ["ChatGPT", "AI", "IKEA"], "alternates": {"html": "https://wpnews.pro/news/ai-can-write-the-code-who-gives-it-the-context", "markdown": "https://wpnews.pro/news/ai-can-write-the-code-who-gives-it-the-context.md", "text": "https://wpnews.pro/news/ai-can-write-the-code-who-gives-it-the-context.txt", "jsonld": "https://wpnews.pro/news/ai-can-write-the-code-who-gives-it-the-context.jsonld"}}