Harness engineering is not the bridge to citizen development

Following a previous discussion on harness engineering, Safdar Mahmood posed an important question: whether this approach enables citizen development for serious enterprise applications. The answer is no.

This conclusion doesn't stem from citizen development lacking value — it demonstrably does. Rather, software engineering encompasses diverse disciplines, and merging these distinct domains creates complications that technology cannot resolve. As these tools become increasingly sophisticated and widely implemented, recognizing these boundaries becomes essential. AI tools excel at experimentation, teamwork, and rapid iteration. However, prototyping differs fundamentally from production environments.

The brother-in-law test

Consider an accomplished amateur renovator. His completed kitchen, bathroom, and basement showcase genuine skill without formal credentials. Yet when constructing an apartment complex, professional expertise becomes mandatory. Considerations including structural calculations, safety regulations, mechanical infrastructure, and occupancy limits demand specialized knowledge. The scope, coordination demands, and risk profile diverge completely.

Software development currently occupies this identical position.

Where citizen development succeeds

Organizations increasingly benefit from citizen development. Platforms including Microsoft Power Platform and Retool enable business professionals to construct workflow automations, internal reporting interfaces, and compact applications without traditional programming. This represents meaningful progress. A marketing analyst automating approval routing solves genuine operational issues. Finance groups building budget-tracking applications eliminate email correspondence and spreadsheet complications.

These represent constrained initiatives with limited failure consequences. Recovery happens swiftly, and damage typically remains localized. This environment encourages experimentation and rapid concept validation — precisely where AI-assisted development demonstrates its capabilities, facilitating exploration, process reimagining, rapid prototyping, and collaborative innovation.

Where it falters

Enterprise software construction operates differently. Systems managing millions of transactions, maintaining regulatory adherence, coordinating numerous integrations, and requiring sustained multi-year reliability necessitate fundamentally altered methodology. These represent extended-duration systems with accumulating sophistication.

Harness engineering exists specifically because professional engineers require safeguards when collaborating with AI agents. When experienced practitioners need architectural documentation, design constraints, and garbage management systems to maintain alignment, this reveals something essential regarding the underlying demands. These mechanisms function as structural support preventing system collapse.

A crucial practical consideration deserves emphasis: when non-professional developers generate code via AI and deploy it directly without governance structures, architectural review, or oversight, they introduce genuine organizational danger. Technology develops rapidly, yet rushing adoption warrants careful consideration.

But what if you provide the harness?

The logical counterargument follows naturally: if restraints make AI-assisted development dependable, why withhold this framework from citizen developers?

The reason: harnesses restrict possibilities but don't impart comprehension. You narrow error categories without eliminating the requirement for expertise.

Returning to construction terminology: providing blueprints, protective gear, and building standards doesn't teach comprehension of structural documentation. Understanding why load-bearing walls require immobility, or foundation changes resulting from water table fluctuations, exceeds harness capabilities. These devices prevent specific mistake categories — they don't substitute for profound systems knowledge.

Such judgment reflects accumulated decades of design methodology. In software contexts, this encompasses domain decomposition into independently-evolving components, when to employ eventual versus immediate consistency, designing schema modifications without production disruption, and planning for scenarios where external systems become unavailable. Harnesses don't convey these understandings — rather, harnesses exist because of them.

Establish clear boundaries

The danger emerges when organizations observe AI programming tools and conclude distinctions have become irrelevant. The presumption follows that anyone possessing Claude or Copilot access can construct anything. This parallels giving an amateur a crane while anticipating high-rise construction capability.

Equipment performs lifting. However, someone must comprehend beam positioning.

Everyone possesses code-generation capacity currently, meaning anyone builds applications. This doesn't guarantee proper architecture, problem-solving alignment, or usability quality.

Organizations should pursue dual approaches: cultivate citizen development within established parameters, supplying business professionals with controlled environments for constructing improvements to their responsibilities. Concurrently, establish harness engineering methodologies for everything beyond this scope. Enterprise systems require professional engineers determining structure, design, and validation mechanisms — whether human developers or automated systems generate code.

Technology accelerates development, yet software engineering functions must assess quality. Quality encompasses systems-level architectural soundness, product-perspective problem resolution ensuring genuine user requirements receive attention, and UX design promoting intuitive operation.

The engineering role evolves

Harness engineering doesn't democratize enterprise application development — it increases professional engineer requirements. Professional roles shift from direct coding toward establishing environments where automated systems generate quality code. This represents increased complexity, not simplified responsibilities.

AI currently expedites professional engineering substantially. Production-grade systems achieve unprecedented speed. Nonetheless, technology lacks self-governance capacity, cannot function as architectural overseer, and cannot validate production readiness.

Citizen development and enterprise engineering coexist successfully exclusively through transparent boundary delineation. Basement renovations differ fundamentally from apartment structures. Tooling may appear similar. Required discipline diverges substantially. This conflation produces fragile systems lacking comprehensive organizational comprehension.

Technology removes development barriers. Creating consequential systems retains undiminished responsibility.


Join the discussion on LinkedIn.