{"slug": "ai-makes-bad-developers-faster-too", "title": "AI Makes Bad Developers Faster Too", "summary": "An engineer argues that large language models amplify the quality of the software development process around them, making skilled developers faster while accelerating confusion and errors in weak processes. The post draws an analogy to carpentry, noting that tools do not replace judgment, and compares scalable software production to IKEA's standardized manufacturing, suggesting the industry has not yet reached that level.", "body_md": "A circular saw does not turn a bad carpenter into a good one. It merely allows him to destroy wood faster.\n\nA skilled carpenter still uses the circular saw. Refusing modern tools would not make him more professional, only slower. The difference is that he understands the material. He knows how wood behaves, where tension builds, how grain direction affects a cut, and when a clean-looking result is structurally wrong.\n\nThe machine provides speed and force. The carpenter provides judgment.\n\nThe same is true for LLMs in software development.\n\nAn experienced developer can use an LLM to explore a codebase, generate implementations, write tests, investigate failures, and compare possible designs much faster than before. But the tool does not provide the developer’s understanding of the system. It does not automatically know which assumptions are valid, which abstractions belong together, or which apparently elegant solution will create maintenance problems six months later.\n\nAn LLM amplifies the process around it.\n\nIn a disciplined engineering process, it accelerates useful work. In a weak process, it accelerates confusion, duplication, security problems, and confidently formatted nonsense.\n\nThis does not mean beginners should avoid LLMs completely. It means they must not outsource the part of learning that creates judgment.\n\nA carpenter’s apprentice may work with a hand saw, a plane, and a chisel before relying entirely on powered machinery. Not because manual tools are morally superior or because suffering builds character, although humanity remains strangely attached to that idea. The apprentice uses them because direct contact with the material teaches lessons that the machine can hide.\n\nThe same principle applies to programming.\n\nA developer must learn to follow control flow, model data, understand HTTP, inspect SQL, debug failures, reason about state, and recognize the consequences of architectural decisions. Those skills create the mental models required to evaluate generated code.\n\nWithout them, the developer may be able to produce software but cannot reliably judge it.\n\nThe output may compile. The tests may pass. The code may even look clean. Yet the developer does not know whether the implementation fits the surrounding system, whether important cases are missing, or whether the design is carrying assumptions that were never verified.\n\nThe problem is therefore not that the apprentice used a machine. The problem is that the machine allowed the apprentice to skip learning what a correct cut actually is.\n\nOnce the craft is understood, the next question is larger than individual skill.\n\nA good carpenter with a circular saw can build faster, but industrial production does not emerge merely because every carpenter receives a more powerful tool.\n\nIndustrial production requires standards, repeatable processes, defined components, quality controls, inspections, and clear responsibility for the final product.\n\nThis is where the IKEA analogy becomes useful.\n\nIKEA does not scale because every employee is the world’s greatest cabinetmaker. It scales because products are designed around standardized materials, documented parts, repeatable manufacturing, controlled tolerances, predictable logistics, and assembly processes that work across millions of units.\n\nThe quality does not depend solely on one person’s memory or intuition. Knowledge has been moved into the production system.\n\nSoftware development has not fully reached that point.\n\nWe have reusable packages, automated tests, static analysis, CI pipelines, containers, coding standards, observability, and increasingly capable coding agents. But many software systems still depend on undocumented assumptions, local knowledge, inconsistent architecture, incomplete tests, and developers who happen to remember why something was built ten years ago.\n\nThat is not industrial production. It is craft production with increasingly powerful machinery.\n\nThis is why calling LLMs the industrial revolution of software is premature.\n\nThey are closer to the steam engine arriving before we have finished building the factory.\n\nThe machine is powerful. It can multiply output dramatically. But the surrounding structures are immature. We do not yet have universally reliable standards for generated code, consistent inspection methods, stable responsibility models, or production systems designed around autonomous implementation.\n\nSo we place the steam engine inside the existing wooden workshop.\n\nSometimes it powers a productive operation. Sometimes it shakes the building apart.\n\nThe limiting factor is no longer only how quickly code can be written. The limiting factor becomes whether requirements are clear, context is available, assumptions are verified, results are tested, and decisions remain understandable after the agent has finished.\n\nLLMs expose this distinction brutally.\n\nWhen implementation becomes cheaper, every weakness around implementation becomes more visible. Poor specifications produce more incorrect code. Weak architecture produces more inconsistent code. Missing tests allow more regressions. Undocumented decisions become harder to reconstruct because the volume of change increases.\n\nThe faster the machine, the more important the production system becomes.\n\nThere is another side to the IKEA analogy.\n\nAn IKEA cabinet can be perfectly adequate. It may be inexpensive, consistent, easy to replace, and durable enough for its purpose. It does not become inferior merely because it was not handcrafted.\n\nGenerated code should be judged the same way.\n\nCode does not gain value because a human typed every character. Nor does it lose value because an LLM produced most of it. What matters is whether it solves the right problem, fits the system, remains maintainable, handles failure safely, and can be verified.\n\nBut IKEA furniture arrives with defined parts, known materials, tested connectors, numbered steps, and a repeatable assembly process.\n\nGenerated software usually does not.\n\nThe output may look standardized, but the assumptions behind it are often specific to the current prompt, context window, repository state, and model behavior. Two apparently similar generations may differ in subtle but important ways. The developer cannot simply assume that generated code is an interchangeable industrial component.\n\nWe have the appearance of mass production without all the guarantees of mass production.\n\nThat is why the human role shifts rather than disappears.\n\nWhen code generation becomes cheap, manually producing every line becomes less important. Understanding the system becomes more important.\n\nThe developer’s responsibility moves toward:\n\nThis is not a retreat from engineering. It is engineering at a higher level.\n\nThe carpenter using a circular saw is not less skilled because the blade moves automatically. Skill appears in how the cut is planned, how the material is secured, how errors are prevented, and how the result is inspected.\n\nLikewise, a developer does not prove competence by typing code slowly without assistance. Competence appears in the ability to direct the tool, detect when it is wrong, and integrate its output into a reliable system.\n\nThe goal is not to protect manual coding as a ritual.\n\nThe goal is to ensure that increased production does not outrun understanding.\n\nThe future of software development is therefore not simply more code generated by larger models.\n\nIt is the gradual construction of a production system around those models.\n\nThat system needs explicit requirements, constrained context, architecture rules, static analysis, automated tests, security checks, traceable decisions, reproducible agent workflows, and clear human approval points.\n\nOnly then does the analogy begin to move from circular saw to IKEA.\n\nThe individual developer still needs craftsmanship, because someone must understand the material and recognize failure. The apprentice still needs fundamentals, because judgment cannot be delegated before it exists. The organization needs production standards, because faster tools alone do not create reliable outcomes.\n\nLLMs are neither magical replacements for developers nor merely fancy autocomplete.\n\nThey are powerful machinery.\n\nA skilled craftsperson can use that machinery to produce better work faster. A weak process can use it to manufacture defects at scale. And an immature industry can mistake increased output for industrialization.\n\nWe have the circular saw.\n\nWe may even have the steam engine.\n\nBut we are still building the factory.", "url": "https://wpnews.pro/news/ai-makes-bad-developers-faster-too", "canonical_source": "https://dev.to/suckup_de/ai-makes-bad-developers-faster-too-2o10", "published_at": "2026-08-02 11:27:04+00:00", "updated_at": "2026-08-02 11:44:05.170479+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools", "ai-agents"], "entities": ["IKEA"], "alternates": {"html": "https://wpnews.pro/news/ai-makes-bad-developers-faster-too", "markdown": "https://wpnews.pro/news/ai-makes-bad-developers-faster-too.md", "text": "https://wpnews.pro/news/ai-makes-bad-developers-faster-too.txt", "jsonld": "https://wpnews.pro/news/ai-makes-bad-developers-faster-too.jsonld"}}