Part 2 — The End of Coding as the Primary Constraint

For decades, software organizations have optimized for one scarce resource: developer time.

Project schedules, team structures, budgets, and delivery methodologies were all designed around the assumption that writing software was the most expensive and time-consuming activity in the engineering lifecycle and that assumption no longer holds.

This does not mean software engineering has become easy. Nor does it mean that AI has eliminated the need for experienced engineers. The scarcity has just moved.

The modernized engineering organization is no longer constrained primarily by its ability to write code. It is constrained by its ability to make sound decisions and the distinction has profound implications for how engineering teams should operate.

Coding Has Become a Commodity

Throughout the history of computing, programming required humans to manually translate ideas into machine instructions.

Every feature, every algorithm, every interface, every integration represented hours or days of careful implementation.

Today, Large Language Models can generate production-quality implementations for many common engineering tasks in minutes and they do NOT eliminate engineering.

They DO change where engineering creates value.

The ability to manually type source code faster than another developer has become less economically significant.

The ability to define the right problem, select the appropriate architecture, evaluate competing solutions, and validate correctness has become dramatically more valuable.

In other words: Coding is increasingly abundant and Engineering Judgment remains scarce. Organizations that recognize this distinction outperform those that continue optimizing for programming throughput alone.

The New Engineering Bottlenecks

If coding is no longer the primary constraint, what is? In my experience, enterprise software organizations are now limited by several interconnected challenges.

1. Architectural Clarity

AI can generate excellent implementations. It cannot reliably determine whether the underlying architecture supports the organization’s long-term objectives.

Architectural decisions determine:

• scalability
• maintainability
• operational resilience
• organizational flexibility
• long-term engineering costs

Poor architecture simply produces technical debt much faster.

2. Requirements Engineering

Software rarely fails because engineers cannot write code. Projects actually fail because organizations misunderstand what should be built.

Requirements remain one of the highest-leverage activities in software engineering.

AI accelerates implementation, it does not replace conversations with stakeholders. It does not negotiate competing priorities. It does not understand organizational politics.

Experienced engineers still perform those functions.

3. Context Engineering

One of the least understood disciplines emerging from AI-native development is Context Engineering.

Every AI system performs only as well as the information available to it.

Providing relevant architecture documents, coding standards, product requirements, business constraints, business goals, security policies, previous design decisions, testing strategies, and organizational knowledge has become an engineering discipline in its own right.

Organizations that manage context effectively produce dramatically better AI-assisted outcomes than organizations relying on isolated prompts.

Context is an enterprise infrastructure.

4. Verification

Generating software has become inexpensive while Proving software is correct has not.

Every production system still requires:

• testing
• validation
• security review
• compliance verification
• performance evaluation
• architectural review

As implementation accelerates, verification becomes even more important.

The faster software is produced, the more disciplined validation must become.

5. Governance

Enterprise software exists within regulatory, operational, financial, legal, and security constraints.

AI has no inherent understanding of organizational accountability.

Governance remains a human responsibility.

Engineering organizations that integrate governance throughout development (not merely at deployment) will maintain higher quality while reducing operational risk.

AI Does Not Replace Human Engineering Teams

One misconception surrounding AI is that software organizations will need fewer engineers. I believe the opposite is more likely because organizations still need experienced engineers.

The human engineers work has changed.

The highest-performing engineers increasingly spend their time:

• defining problems
• designing systems
• reviewing architecture
• validating outputs
• coordinating autonomous agents
• improving engineering workflows
• reducing organizational friction
• mentoring less experienced engineers
• establishing technical standards

Notice that very little of this involves manually typing source code and this observation is not a criticism of programming because of course programming remains essential.

It is simply no longer where senior engineers generate the greatest organizational value.

From Individual Productivity to Organizational Productivity

Historically, software engineering performance was often measured at the individual level.

• How many tickets were completed?
• How many features shipped?
• How many pull requests were merged?

These metrics remain useful, but they no longer capture the full picture.

The question engineering leaders have to now ask is:

How effectively does our engineering system produce reliable business outcomes?

This shifts attention toward:

• engineering workflows
• organizational learning
• reusable knowledge
• automation
• documentation
• architectural consistency
• deployment reliability
• continuous improvement

The objective is now maximizing organizational capability rather than maximizing individual output.

Introducing Loop Engineering

The shift with AI First / AI Native techniques & methodologies has led me to hone the methodology our tech industry refers to as Loop Engineering.

Loop Engineering is not another software development methodology competing with Agile or DevOps, it complements them. The

It recognizes that modern software engineering increasingly involves collaboration between experienced professionals and autonomous computational systems.

Rather than assigning every task directly to people, Loop Engineering creates structured feedback loops that continuously improve engineering outputs.

Loop engineering replaces manual prompting with self-sustaining AI systems that discover work, assign tasks to sub-agents, test, and verify results. At Anthropic, the engineers design iterative loops using tools like Claude Code so models autonomously build and refine code or data. The Anthropic loop engineering methodology focuses on building automated harnesses and feedback cycles that rely on these core components: Goal-Driven Autonomy, Robust Verification, State Persistence, Sub Agents & Work Trees. I suggest you ask any of your favorite or many different AI models about Anthropic’s Loop Engineering methodology.

Currently, my own technique for each loop consists of five essential activities using my preferred software development tools of the day (Cursor or Codex or Claude or …).

Observe

• Gather requirements.
• Collect context.
• Understand constraints.
• Clarify objectives.

Generate

• Use specialized AI systems to propose architectures, implementations, documentation, testing strategies, deployment plans, and alternative approaches.
• Generation is exploratory.
• It is intentionally abundant.

Evaluate

Professional engineers review outputs. They assess:

• correctness
• maintainability
• security
• scalability
• business alignment
• operational risk

This stage transforms raw generation into engineering decisions.

Refine

• Outputs are revised.
• Context improves.
• AI agents receive additional guidance.
• Design decisions become clearer.
• The system learns.

Verify

• Testing.
• Documentation.
• Deployment.
• Operational monitoring.
• Continuous feedback.
• Every completed loop strengthens future loops.
• Engineering becomes cumulative rather than repetitive.

Designing Autonomous Software Factories

As these loops mature, organizations naturally evolve toward what industry experts describe as an Autonomous Software Factory and what I’m creating with MoniGarr Intelligence Led Engineering Systems and MoniGarr Operating Models.

This is an engineering ecosystem (not a single AI model). My time goes into setting these up based on my own professional experience as a software architect / engineer for 30+ years and then I provide all of this to my autonomous software factory. Soon, my AI Agents and team of AI Agents will be able to do many of these tasks using the templates that I’ve been honing with each new software project and my experiences in a rapidly evolving industry.

It includes:

• specialized AI agents
• documentation systems
• architectural knowledge bases
• coding standards
• testing frameworks
• deployment pipelines
• security policies
• validation procedures
• governance models
• continuous learning

Instead of replacing human engineers, the factory amplifies their expertise.

Experienced professionals define the standards.

Autonomous systems execute repeatable work.

Together we achieve results neither could accomplish independently.

Why This Matters to Executive Leadership

The implications extend beyond engineering because they affect the economics of the entire organization. Human Engineering teams capable of designing AI-native delivery systems can:

• reduce time-to-market
• improve software quality
• shorten feedback cycles
• increase organizational learning
• preserve institutional knowledge
• reduce repetitive engineering work
• improve onboarding
• strengthen documentation
• improve consistency across projects

These outcomes influence revenue, operational efficiency, customer satisfaction, and long-term competitiveness.

Technology leaders should avoid asking:

“How can our developers use AI?”

A more valuable question is:

“How should our engineering organization evolve now that coding is no longer the primary constraint?”

The answer to that question will shape the next generation of enterprise software organizations.

End of Part 2

In Part 3, I’ll move from principles to implementation by exploring how Autonomous Software Factories, AI agent teams, enterprise architecture, documentation, governance, and verification systems work together in practice. I’ll show how organizations can move beyond isolated AI tools toward an integrated engineering operating model that consistently delivers enterprise-quality software.