I help software organizations investigate why AI adoption is not improving delivery,
rebalance review and ownership, and define controls for agentic systems in production.
For enterprise software teams and IT services companies.
AI is a fundamental shift: an attempt to delegate parts of thinking to machines.
More than 20 years in software engineering and technology delivery, including over a decade
in leadership. Delivery and PMO responsibility across a portfolio of around 25 projects
and more than 120 engineers. That experience shapes my research into software delivery
and systems that depend on model judgment.
01 / Where I can help
Start with the decision you need to make.
Delivery / Diagnosis
“We bought AI tools. Delivery is not improving.”
Assess the delivery flow, review and verification capacity, rework, knowledge dependencies
and costs. Investigate the actual constraint.
Possible output: A prioritized diagnosis of delivery constraints and a plan for testing the next changes.
Possible output: A review of decision authority, operating limits and evidence gaps, with priorities for
addressing them.
SDLC / QA / Operating model
“Our process and roles have not caught up with AI.”
Work through requirements, evaluation, release decisions and human capacity in a focused
workshop.
Possible output: draft role and decision boundaries, learning routines and
an improvement backlog.
Potential outputs, depending on the agreed scope. The first conversation determines fit
and scope. Discuss your AI challenge →
02 / Research
Two questions behind the work.
What happens when machines generate faster than people can understand and verify? And what
changes when the software itself relies on model judgment?
01 / How we build
How do we rebalance AI-assisted delivery?
I see the AI-assisted SDLC as structurally unbalanced where generation accelerates faster
than human understanding, verification and ownership. More output can coexist with review
queues, rework and fragile maintenance.
The Subprime Code Crisis investigates this gap and how teams can rebalance
generation, verification and ownership. It treats proposed responses as hypotheses to test
in context.
How do we engineer systems that rely on model judgment?
Uncertainty Architecture studies what I call Thinking Systems: software in
which consequential runtime responsibilities depend partly on probabilistic model judgment.
This is where I see the fullest expression of today's AI potential — and some of its hardest
engineering problems.
The controlled object is the software system. Its control perimeter also includes human
roles, evidence, decision authority and corrective action. It needs development lifecycles
and operating models suited to uncertainty. Much remains to develop and test.
Thinking Systems for architecture; Externalization for generation and verification; Moat for
strategic differentiation. All five selected editions are English.
My work has included building delivery functions, resource planning, risk governance and
organizational design. It shapes the questions I bring to AI: what teams need to understand,
how decisions are made, and who owns the outcome.
I write for architects, engineering and delivery leaders, product owners and PMO
practitioners. This site connects the publications and living research behind that work.
Invited speaker at Corning’s internal technical AI workshop. Explore the talk ↗
This site is also a practical example of human-directed, AI-assisted delivery. About the build ↗
Bring a system, a delivery bottleneck, or a question you cannot yet frame. We can discuss
where the uncertainty sits and what a useful next step could look like.
Research collaboration, speaking invitations and professional opportunities are welcome
too.
Book a conversation
Choose a time for a conversation, or send me an email.