Anas Chakroun says AI can't build

Developer Anas Chakroun used a May 19 post on X to push back on claims that AI can independently build durable software products. He wrote that “AI still can’t build and evolve complex products alone,” then listed the areas he said still depend on human judgment: architecture, tradeoffs, product direction, scalability, debugging and long-term maintainability. The post circulated inside a broader set of engineering discussions about how much responsibility AI tools can take on in software teams. It also intersected with adjacent threads about who has to be involved when product decisions spill into security, legal and platform operations. ### What, exactly, did Chakroun argue? Anas Chakroun’s post framed the issue less as raw code generation and more as ownership over a product’s evolution. His point was that shipping software is not the same as sustaining it through changing requirements, failures, scale and maintenance work over time. The phrase “build and evolve complex products” was doing most of the work in the post. Chakroun did not say AI is useless for engineering tasks; he argued that the parts that make software durable — architectural choices, tradeoffs between speed and reliability, debugging under production conditions, and maintainability over the long term — still require human engineers. ### Why did that resonate with developers? Software engineers have spent the past two years testing AI on tasks that are easy to demo but harder to operationalize. Code generation can accelerate scaffolding, documentation, test drafts and routine refactors, but production systems usually force choices between competing constraints such as performance, cost, security and maintainability. Research and industry writing on architecture tradeoffs make the same underlying point: system design is shaped by competing requirements, not just by whether code compiles. McKinsey made a similar distinction in a recent essay on AI adoption, arguing that durable advantage comes less from access to tools than from how organizations apply them to real business problems at scale. That aligns with Chakroun’s emphasis on engineering thinking rather than model output alone. ### Why do architecture and maintainability matter more than a demo? (arxiv.org) Complex products accumulate history. A feature that works in isolation can still create operational debt if it breaks observability, complicates deployments, weakens security boundaries or makes later changes harder. Architecture tradeoff frameworks describe those choices as balancing qualities such as modifiability, performance, security and scalability rather than maximizing a single metric. (mckinsey.com) Debugging is another dividing line. Production failures often involve missing context, partial data, legacy dependencies and team knowledge that is not present in a prompt. Chakroun’s list put debugging next to scalability and maintainability, which suggests he was talking about software operated over time, not one-off code output. ### How did the post connect to wider stakeholder debates? Other recent discussions in engineering and cybersecurity have focused on stakeholder alignment — especially when technical choices trigger compliance, security or operational consequences. (arxiv.org) Those sources describe coordination across engineering, security, executives and governance teams as a prerequisite for coherent decision-making. That is where Chakroun’s post fits a wider conversation. If AI can draft code but cannot own tradeoffs across legal exposure, platform constraints, reliability targets and maintenance costs, then a human team still has to make and defend those decisions. ### Does this mean developers are rejecting AI tools? The evidence around the post points to a narrower claim. Chakroun argued against autonomy, not against assistance. His wording left room for AI as a tool inside engineering workflows while rejecting the idea that it can replace the people who set direction, judge tradeoffs and carry responsibility for what ships. (sprinto.com) On May 19, the post was still available on X at the AnasChakrounX account. The next step in this debate is likely to remain practical rather than theoretical: teams will keep measuring where AI speeds up coding work and where human engineers still have to make the final call.