Edit this page


Intent-Oriented Programming — a symbolic human form reaches toward a red holoflux of intent, connecting evidence, constraints, outcomes, policies, verification, observation, feedback, agents, architecture, code, tests, and runtime evidence
Intent as the organizing semantic center: human purpose unfolds through evidence, constraints, coordinated agency, implementation, verification, observation, and feedback.

If AI can increasingly generate the implementation, should programmers still organize software primarily around implementation structures?

Object-oriented programming gave us a powerful organizing idea: model a system as objects with state, identity, relationships, and behavior.

That abstraction changed software because it changed the unit around which programmers thought.

But AI introduces a strange inversion.

A growing part of implementation can now be delegated. Agents can explore repositories, propose architecture, write code, generate tests, review changes, operate tools, and inspect runtime evidence.

If implementation becomes cheaper to produce, perhaps the next important programming abstraction is not another way to organize implementation.

Perhaps it is a way to organize intent.

Not intent as a prompt.

Not intent as a ticket.

Not intent as a one-line requirement handed to an agent and forgotten.

But intent as a living semantic structure:

Intent
Evidence
Constraints
Outcome
Policy
Verification
Observation
Feedback

This post explores that possibility.

The philosophical figures used later are conceptual lenses, not authorities for the programming model. Bohm, Minsky, and Krishnamurti illuminate different aspects of the problem; the engineering proposal must stand on its own.

I will call it Intent-Oriented Programming.

Contents

  1. From objects to intent
  2. Intent is not a prompt
  3. A programming unit for the agentic age
  4. Bohm: from implicate meaning to explicate form
  5. Minsky: intent organizes a society
  6. Krishnamurti: observation before interpretation
  7. The intent loop
  8. What Intent-Oriented Programming might look like
  9. Why Ruby is an unusually good laboratory
  10. Rails after convention over configuration
  11. Intent does not replace objects
  12. A small executable experiment
  13. The deeper responsibility
  14. Conclusion
  15. References

From objects to intent

Object-oriented programming asks questions such as:

What objects exist?
What state do they hold?
What behavior do they expose?
How do they collaborate?

Those remain useful questions.

Intent-Oriented Programming begins one level earlier:

What are we trying to change?
Why?
What evidence supports that intention?
What constraints must survive?
What outcome would count as success?
Who or what may act?
How will the result be verified?
What will reality tell us afterward?
From Objects to Intent — implementation structures on one side and intent, evidence, constraints, outcome, policy, verification, observation and feedback on the other
The proposal is not to discard implementation structures, but to place a semantic unit above them: intent with evidence, boundaries, outcomes, verification, and observation.

The shift can be summarized like this:

The object is an implementation abstraction.

The intent is an engineering-semantic abstraction.

That distinction matters once AI becomes capable of moving between the two.

Intent is not a prompt

A prompt is an instruction given at a moment in time.

An intent should survive the moment.

For example:

"Improve checkout reliability."

is not enough.

A useful intent might carry:

Intent
  reduce checkout failures

Evidence
  support tickets
  abandonment metrics
  payment errors

Outcome
  higher successful-checkout rate

Constraints
  PCI boundaries
  idempotency
  no duplicate charges

Verification
  contract tests
  failure-path tests
  reconciliation checks

Observation
  payment latency
  retry rate
  failed-checkout rate

Feedback
  new incidents
  customer reports
  production behavior

The intent is therefore not only what we want.

It also carries why we believe it matters, what must remain true, and how reality is allowed to disagree with us.

That last part is crucial.

A programming unit for the agentic age

Traditional source code is full of implementation units:

class
function
object
module
service
component

Intent-Oriented Programming adds another unit above them:

intent

But an intent cannot stand alone.

A minimal structure might be:

Intent
├── Evidence
├── Desired outcome
├── Constraints
├── Policies
├── Delegation
├── Verification
├── Observation
└── Feedback

This gives an AI agent something richer than a task description.

It gives the agent an engineering contract.

The point is not that this exact vocabulary is final.

The point is that we can make intent itself executable and inspectable.

Bohm: from implicate meaning to explicate form

David Bohm gives us a useful metaphor for this transition.

In his discussion of the implicate and explicate orders, Bohm describes an order in which patterns may be enfolded and then unfolded into explicit form. His broader idea of the holomovement emphasizes movement and wholeness rather than isolated static parts.

I am not claiming software engineering is Bohmian physics.

The metaphor is useful because intent has a similar relationship to implementation.

Intent contains more than a list of instructions.

It can enfold:

purpose
constraints
relationships
trade-offs
expectations
possibilities

Implementation unfolds these into explicit structures:

architecture
code
tests
configuration
deployment
runtime behavior
From Intent to Explicate Form — a conceptual portrait of David Bohm beside intent unfolding through agents into architecture, code, tests, deployment and runtime evidence
Interpretive illustration: Bohm's implicate/explicate vocabulary is used here as a metaphor for meaning unfolding into software form and returning through evidence.

AI changes the economics of this unfolding.

Instead of requiring a human to manually translate every layer:

intent
  ↓
design
  ↓
implementation

we increasingly have:

intent
  ↓
semantic model
  ↓
agents
  ↓
many possible implementations

And production creates the reverse pressure:

runtime evidence
  ↓
incidents
  ↓
feedback
  ↓
new understanding
  ↓
revised intent

Intent-Oriented Programming is therefore not a one-way compiler.

It is a continuous movement between meaning and form.

Minsky: intent organizes a society

Marvin Minsky gives us another essential piece.

In The Society of Mind, intelligence is not treated as one indivisible faculty. It is explained through the interaction of many relatively limited agents.

That maps unusually well to modern agentic engineering.

An intent probably should not be handed to one gigantic agent that is expected to understand the product, architecture, implementation, testing, security, deployment, and production equally well.

A better structure is a society of specialized agents.

Intent Organizes a Society — a conceptual portrait of Marvin Minsky with specialized discovery, architecture, development, testing, security and operations agents
Interpretive illustration: intent coordinates specialized agents with bounded responsibilities rather than assuming one agent is the whole engineering system.

The programming model changes from:

intent
  ↓
one agent
  ↓
answer

to:

intent
  ↓
specialized society
  ├── discovery
  ├── architecture
  ├── implementation
  ├── testing
  ├── security
  └── operations

Each agent can have bounded:

knowledge
skills
tools
permissions
responsibilities
evidence requirements

The intent becomes the structure that coordinates them.

This is where Intent-Oriented Programming becomes more than a DSL.

It becomes a model for organized agency.

Krishnamurti: observation before interpretation

There is also an epistemological problem.

An AI system can accumulate enormous amounts of knowledge:

documentation
ADRs
tickets
code
tests
incident history
RAG
memory
previous agent conclusions

But accumulated knowledge is not identical to what is happening now.

Krishnamurti repeatedly distinguished observation from the concepts, memories, and judgments through which we interpret what we see. In the language of engineering, that suggests a discipline that is surprisingly practical:

what is happening
      ≠
what we know
      ≠
what we think it means
      ≠
what remains unknown
Observation Before Interpretation — a conceptual portrait of J. Krishnamurti beside observation, knowledge, inference and unknowns
Interpretive illustration: observation, accumulated knowledge, inference, and the unknown should remain distinguishable in an agentic engineering system.

This has direct consequences for AI systems.

An agent looking at a failing production service should not collapse:

RAG result
historical incident
current trace
model hypothesis

into one undifferentiated “understanding.”

A better model keeps them distinct:

Observed evidence
Historical knowledge
Inference
Unknowns

That gives us another principle for Intent-Oriented Programming:

Intent must remain revisable in the presence of observation.

If reality contradicts the original assumption, the system should not merely optimize harder toward the original intent.

It should be able to question it.

The intent loop

These three lenses now meet.

Bohm gives us a metaphor for movement between implicit meaning and explicit form.

Minsky gives us a model for coordinated specialized agency.

Krishnamurti reminds us not to confuse accumulated representation with direct observation.

Together they suggest a programming loop:

Intent
  ↓
Semantic structure
  ↓
Society of agents
  ↓
Implementation
  ↓
Observation
  ↓
Evidence
  ↓
Learning
  ↓
Revised intent

The key difference from a conventional development pipeline is that intent is not immutable.

It is a living part of the system.

What Intent-Oriented Programming might look like

Ruby makes the idea easy to experiment with.

Imagine:

intent :reduce_checkout_failure do
  evidence :support_tickets,
           :checkout_metrics,
           :payment_errors

  outcome :successful_checkout

  constraints do
    require :pci_compliance
    preserve :idempotency
    prevent :duplicate_charge
  end

  delegate :architecture,
           :implementation,
           :verification

  verify :checkout_contract,
         :payment_failure_paths,
         :reconciliation

  observe :checkout_success_rate,
          :payment_latency,
          :retry_rate

  revise_from :incidents,
              :customer_feedback,
              :runtime_evidence
end

This is not meant to replace classes.

It is meant to answer questions classes do not naturally answer:

Why does this behavior exist?
Which evidence justified it?
Which constraints must never be violated?
What outcome are we optimizing?
Who may act on it?
How do we know the implementation is acceptable?
Which runtime observations should challenge our assumptions?

The compiler—or framework—could project this one intent into many artifacts:

agent tasks
architecture prompts
policy checks
test plans
observability configuration
documentation
semantic graph
evaluation criteria
review context

That is where the programming model becomes interesting.

Why Ruby is an unusually good laboratory

Ruby has a long history of creating languages inside the language.

Rails:

has_many :orders

RSpec:

expect(order).to be_valid

Rake:

task deploy: :environment

Bundler:

gem "rails"

These APIs do more than shorten code.

They turn infrastructure into domain vocabulary.

Intent-Oriented Programming needs exactly that ability.

Its primitives are not primarily machine operations.

They are engineering concepts:

intent
evidence
constraint
outcome
policy
delegate
verify
observe
revise

Ruby can make these executable without making them look like configuration plumbing.

But the AI age adds a new requirement.

The DSL must not hide meaning behind runtime magic.

It should produce an explicit semantic representation that agents can inspect.

So the design goal becomes:

Ruby expressiveness
        +
explicit semantic model
        +
machine inspectability

Not just beautiful syntax.

Rails after convention over configuration

Rails may have an equally interesting opportunity.

Convention over configuration historically reduced human cognitive load.

The agentic interpretation could be:

Convention over configuration gives agents a more predictable semantic environment.

A Rails application already encodes a large amount of structure:

routes
controllers
models
associations
validations
jobs
transactions
migrations
policies
tests
events
deployment conventions

If Rails made these relationships more explicitly queryable, an agent could ask:

What can change an Order?

Which business rule protects this transition?

Which jobs can eventually modify this model?

Which request specs verify this endpoint?

Which migration introduced this field?

Which runtime signal should reveal a failure here?

That is a larger opportunity than simply adding an AI assistant to Rails.

It suggests Rails itself as a semantic environment for agents.

Intent does not replace objects

A new abstraction does not need to destroy the previous one.

SQL did not eliminate data structures.

Rails did not eliminate HTTP.

Objects did not eliminate functions.

Intent does not eliminate objects.

The layers can coexist:

Intent
   ↓
Engineering semantics
   ↓
Architecture
   ↓
Objects / services / modules
   ↓
Functions / data
   ↓
Runtime

Intent-Oriented Programming would sit above implementation structures.

Its purpose would be to preserve why those structures exist and connect them to evidence and observation.

That is why the name matters.

This is not “prompt-oriented programming.”

The intent is durable.

The prompt is transient.

A small executable experiment

The companion package includes a small dependency-free Ruby prototype that tests this idea.

The declaration:

system = IntentSystem.define do
  intent :reduce_checkout_failure do
    evidence :support_tickets, :checkout_metrics
    outcome :successful_checkout

    constraints do
      require :pci_compliance
      preserve :idempotency
    end

    delegate :architecture, :implementation, :verification
    verify :checkout_contract, :payment_failure_paths
    observe :success_rate, :latency
    revise_from :incidents, :customer_feedback
  end
end

creates an explicit semantic model.

The prototype can serialize that model to JSON and generate a Mermaid view of the intent lifecycle.

The important experiment is not the syntax.

It is the invariant:

the executable declaration and the inspectable semantic model come from the same source.

The included tests were run against Ruby 3.3 in the authoring environment.

Download the Intent-Oriented Programming support package

The deeper responsibility

The AI age creates a temptation to focus entirely on generation:

How much code can the agent write?
How quickly?
How autonomously?

Intent-Oriented Programming asks a different set of questions:

Does the system still know why this code exists?

Can it distinguish evidence from inference?

Can it preserve constraints across agent handoffs?

Can runtime evidence challenge the original plan?

Can humans inspect the semantic structure that guided the agents?

Can a new agent inherit the intent without reconstructing it from fragments?

Those questions are less spectacular than autonomous code generation.

They may be more important.

Because the challenge of agentic software is not merely producing more implementation.

It is preserving meaning while implementation becomes increasingly fluid.

The Intent Loop — a red holoflux at the center of a circular engineering cycle connecting intent, semantic structure, society of agents, implementation, observation, evidence, learning, and revised intent
A closing synthesis: intent becomes a living loop that moves through structure, coordinated agency, implementation, observation, evidence, learning, and revised intent.

Conclusion

Object-oriented programming helped us organize implementation around objects.

The agentic era gives us a reason to explore another organizing principle above implementation:

intent.

Intent-Oriented Programming would treat intent as a first-class, executable, inspectable engineering structure.

It would carry:

evidence
constraints
outcomes
policies
delegation
verification
observation
feedback

AI agents could then unfold that structure into implementations.

A society of specialized agents could collaborate around it.

Runtime evidence could challenge it.

Humans could inspect it.

And the intent itself could evolve.

The result is not programming without code.

It is programming where code is no longer the only—or even the highest—artifact that matters.

Perhaps the next programming question is therefore not:

What objects should this system contain?

But:

What intention is this system trying to make real, what must remain true while it does so, and what evidence will tell us whether we were right?

That is a different starting point.

And AI may finally make it practical.

References

Mermaid diagram