"If you don't understand the topic, everything will fall apart and nothing will work."<\/p>\n
Opponents of AI write this phrase as if copied from the same Luddite playbook, across every topic, so often and so identically that the wording barely changes. New headlines, new speakers, new occasions \u2014 the argument never moves. The reflex is always the same: if you don't read code by hand, you have no right to manage its creation.<\/p>\n
Here is the question that dismantles the whole pose: how do you think clients and managers ran software development for decades without understanding your handwritten code?<\/p>\n
They managed. Somehow, they managed.<\/p>\n
<\/p>\n
Managing what you don't understand hands-on is the foundational skill of management. Without it, you are a hands-on engineer who was handed a couple of supervisory duties. This is exactly where the dividing line runs: whether a manager is one more participant on the team, or an external multiplier of its effort.<\/p>\n
The ability to direct work you cannot do yourself separates a craftsman from a manager. If a manager were forced to understand every detail personally, they would instantly become the bottleneck of the entire process. The whole team would hit the throughput of one head, and the multiplier would never materialize \u2014 you'd get a bottleneck with a director's salary.<\/p>\n
The stake here is concrete. Demanding that a manager personally understand every line is, in practice, demanding that the organization return to a state where the speed of all development equals the speed of its busiest expert. That is not caution. That is a built-in growth ceiling, paid for in money, deadlines, and projects that never ship.<\/p>\n
This is why non-engineers are now building agentic pipelines on their own \u2014 and succeeding. Not because they suddenly learned assembly, but because they always had a different skill: managing a result they cannot produce by hand.<\/p>\n
To see why the Luddite scare story fails, look at how managers and clients handled live performers. Not in theory \u2014 in the routine that has always existed.<\/p>\n
The model wrote an incomprehensible spec? No problem. Live contractors wrote incomprehensible specs too, and there is a validation procedure for that. You've been running it for years: clarifying questions, acceptance criteria, a line-by-line breakdown of the brief before anything goes into work.<\/p>\n
The model made architectural decisions you can't verify by eye? No problem. Live architects spoke in jargon too, and you have a procedure for converting their talk into the language of numbers and risks. Not "does it look elegant on the diagram" \u2014 how much it costs, what it breaks, where the tail extends for years.<\/p>\n
The model wrote bad code? No problem. Live contractors wrote such leaky garbage that you long ago installed linters, UAT, and hard security gates. Nothing holds on trust. It holds on gates that any external result must pass through, regardless of who produced it.<\/p>\n
And so on.<\/p>\n
This is not a "maybe it will work" hypothesis. It is exactly what stands in enterprise delivery pipelines and has been running for years.<\/p>\n
At Askona, technical validation of contractors before they entered work was a regular task. The company brought in contractors constantly, and every one went through a competence check before touching production. Vendor failures \u2014 incompetence, missed deadlines, integration problems \u2014 were recorded and fed into future architectural decisions. The client systematically evaluated the quality of work from performers they did not replace themselves, whose code they did not write.<\/p>\n
When AI tools got access to production data, the same gates went up around them: read-only database access, validation of table and column names. Not "let's trust the model" \u2014 guardrails, the same logic used to restrict any new performer in a sensitive environment.<\/p>\n
At a large systems integrator, delivery manageability was built on automated tests \u2014 PHPUnit, Cypress \u2014 and release reliability tracking, while subcontractor relationships rested on selection criteria, quality gates, and contractual accountability. The result of live contractors is filtered by automation and procedure, not by a delivery director personally reading every line. The entire point of governance is to remove the dependence of the outcome on the manual heroism of one person.<\/p>\n
And where there was neither engineering resource, nor budget, nor timeline for a business task, managers were taught to assemble the solution themselves \u2014 a computational mechanism, a microservice, a dashboard. A non-engineer who builds a working tool without understanding its internals is not a novelty of the agent era. It is a long-observed practice.<\/p>\n
Now the client does the same thing with agents. What difference does it make where the spec, the architecture, or the code came from, if the validation procedure for the result is identical?<\/p>\n
None.<\/p>\n
Luddites skip this: their argument doesn't hit AI. It hits the entire institution of management, which has always directed work it didn't do by hand. An agent at the entrance of the conveyor broke nothing in this scheme \u2014 it simply took the place of the next performer, whose result went through acceptance anyway. The gates stood before it, stand during it, and will not notice if the performer is swapped out again tomorrow.<\/p>\n
Clients don't care about the scare stories. For them, validating the output of a model is a routine \u2014 familiar, simple, and clearly executable without a human expert in the loop. They are not "taking risks without understanding." They are applying a procedure debugged on live contractors to a new source of the same result.<\/p>\n
A practical conclusion follows from this, and it is uncomfortable for a whole class of people.<\/p>\n
Someone who genuinely believes you cannot manage development without personally reading the code is telling you exactly who they are. They are not describing a limitation of technology. They are describing their own ceiling. For them, management is personal doing, because they know no other way and have never held another role. They project the structure of their own head onto all of management \u2014 a head where the boss must be the strongest performer in the room.<\/p>\n
A lack of programming knowledge has never been an obstacle to managing development. Clients have been building software with other people's hands for decades and are building it with agents now, through the same acceptance procedure \u2014 because what changed was not the procedure, only the name at the entrance of the conveyor.<\/p>\n
Anyone claiming otherwise is a routine performer. Stop listening to them.<\/p>\n","protected":false},"excerpt":{"rendered":"
Clients have validated work from contractors for decades without reading a line. AI agents change nothing about the procedure.<\/p>\n","protected":false},"author":0,"featured_media":199,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-200","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t