Haberman Michael
3× Founder & CTO | Building Reliable Software in the AI Era
Tel Aviv, Israel
Actions
Michael Haberman is a 3× founder and CTO working on how software teams build reliable products in the AI era. He has built production AI agent systems, led AI-native engineering teams, and helped organizations rethink how context, specifications, validation, and evidence flow through the software-development lifecycle. Previously, he co-founded and sold Aspecto, a developer infrastructure company focused on observability and distributed systems. His work today focuses on the practical consequences of AI-generated software: how teams preserve quality, understand their systems, and learn faster as implementation becomes cheaper. Michael has spoken and taught at technology conferences in Israel and internationally for more than a decade.
Area of Expertise
Topics
Your AI Agent Worked in Dev. Production Had Other Plans
Everything looked good in development. Then real users, real data, and the real production environment showed up.
With nondeterministic software, even saying an agent “works” is surprisingly vague. Different team members may judge the same behavior differently. In production, several variables also change at once: the context the agent receives, the tools it can use, the data it encounters, and the way customers actually use or misuse the product.
The team building an agent naturally tests the scenarios it expects. But engineers are not very good at pretending to be unfamiliar users or imagining how the product may be used months later. LLMs are much better at adopting unfamiliar perspectives.
In this session, I’ll share how we use LLMs to generate unexpected users, edge cases, and usage patterns, then run them against production-like environments. You’ll leave with a practical method for testing beyond your team’s imagination and turning surprising behavior into repeatable evaluations.
Target audience: AI engineers, software engineers, tech leads, architects, and engineering managers building LLM-based products.
Level: Intermediate.
Preferred duration: 30–45 minutes.
Format: Production experience report with practical examples and a demo.
Prerequisites: Basic familiarity with LLM applications or AI agents.
Source: Lessons from building, testing, and operating AI-agent workflows in production.
Before You Blame the Model: Spec, Context, Validation
When an AI agent produces the wrong result, blaming the model is easy. But many apparent model failures begin outside the model.
An agent can be viewed as a black box: it receives an input and produces an output. Around that box, teams still control three critical elements.
The specification defines what the agent must do. The context makes that task correct for a particular user, company, system, and moment. The validation method determines whether the polished-looking output is actually right.
Each can fail independently. A request to update a page “title,” for example, may refer to the visible H1 or the browser title. The agent can make a perfectly reasonable choice while solving the wrong problem.
Using practical examples and a demonstration, this session introduces a framework for writing less ambiguous specifications, identifying the context an agent truly needs, and validating its work independently of how convincing the result appears.
Target audience: AI engineers, software engineers, product engineers, tech leads, and teams designing agent workflows.
Level: Intermediate.
Preferred duration: 30–45 minutes.
Format: Framework-based session with examples and a live or recorded demonstration.
Prerequisites: Basic experience using LLMs in development or product workflows.
Source: Lessons from building and reviewing production AI systems.
Your Team Is Shipping Faster and Understanding Less
In theory, a code change is the same whether it was written by a human or generated by AI. The diff may even be identical.
What is different is what the team learned while producing it.
When developers wrote each line themselves, they accumulated familiarity with the system. They made small architectural decisions, discussed alternatives, noticed inconsistencies, and gradually built a shared understanding of how the codebase worked.
AI can generate the same change without transferring that understanding to anyone.
This creates two risks. First, coding agents make small but consequential decisions that developers may never notice. Second, thousands of individually reasonable changes can gradually shift the architecture, conventions, and structure of the system.
In this session, I’ll demonstrate a system we built to surface hidden decisions during development and expose longer-term architectural drift. The goal is not to slow AI-assisted development down. It is to ensure that the team’s understanding can keep up with the code.
Target audience: Software engineers, architects, tech leads, platform teams, and engineering leaders adopting AI coding tools.
Level: Intermediate–advanced.
Preferred duration: 30–45 minutes.
Format: Experience report with system examples and a prototype demonstration.
Prerequisites: Familiarity with pull requests, software architecture, and AI-assisted coding.
Source: Lessons from AI-assisted development and building tooling to expose hidden decisions and codebase drift.
The Output Looks Right. Where’s the Evidence?
LLMs are exceptionally good at producing outputs that look complete, coherent, and convincing. That creates a dangerous shortcut: we read the result, it makes sense, and we continue working as though it were correct.
Sometimes that is enough. Sometimes it is not.
For higher-impact work, plausibility is not evidence. We may need to know that the model used the right information, performed the necessary checks, considered relevant constraints, and produced an outcome that satisfies the actual requirement.
The challenge is not to verify every token an LLM generates. It is to decide what evidence this particular task requires before accepting the result.
In this session, I’ll share a practical framework we use to define evidence requirements for AI-generated work. We’ll examine when human review is sufficient, when stronger evidence is necessary, and how to make evidence part of the workflow instead of an investigation performed only after something goes wrong.
Target audience: AI engineers, software engineers, product teams, tech leads, and anyone responsible for reviewing AI-generated work.
Level: Intermediate.
Preferred duration: 30–45 minutes.
Format: Practical framework with real examples from AI workflows.
Prerequisites: Familiarity with using LLMs for consequential development, research, or product tasks.
Source: Lessons from designing validation and evidence requirements around production LLM systems.
The Hidden Trade-Offs Behind AI-Generated Work
An AI system can usually explain what it produced. That does not mean it will reveal everything it decided along the way.
Most meaningful tasks contain trade-offs. The model may choose simplicity over extensibility, speed over precision, consistency over local optimization, or one implementation path over several reasonable alternatives.
The final result may look good while hiding the fact that a consequential decision was made silently.
As AI-generated work becomes a larger part of software and product development, reviewing only the final output is no longer enough. Teams need a way to uncover the assumptions, alternatives, and trade-offs embedded inside it.
In this session, I’ll share the framework I use to expose those hidden decisions. We’ll look at how to make an LLM generate alternative paths, identify the dimensions it balanced, surface assumptions it treated as facts, and reveal relevant considerations it may have omitted.
The goal is not to eliminate trade-offs. It is to ensure that humans know which trade-offs they are accepting.
Target audience: Software engineers, product engineers, architects, tech leads, and teams reviewing AI-generated work.
Level: Intermediate.
Preferred duration: 30–45 minutes.
Format: Practical framework with examples from software and product-development decisions.
Prerequisites: Basic experience using LLMs for complex or open-ended work.
Source: Lessons from reviewing AI-generated outputs and exposing silent decisions, assumptions, and alternatives.
Your AI Workflow Will Change. Context, Specs, and Artifacts Won’t.
Software teams are redesigning how work moves between humans and AI. Some are adding lightweight automation. Others are introducing agents throughout the development lifecycle or moving toward much greater autonomy.
The workflows differ, but across the teams I have worked with, three requirements remain constant: context, specifications, and artifacts.
Context tells each human or agent what matters in the current situation. A specification defines what the current step must accomplish. An artifact captures its output so the next step does not begin by reconstructing what happened before.
Artifacts also make organizational learning possible. A customer complaint cannot improve the original product specification unless the team can trace it backward through the implementation, architecture, design, and product decisions that produced the experience.
In this session, we’ll follow the chain from product intent through implementation, testing, deployment, production behavior, incidents, and customer feedback and examine why context, specs, and artifacts must survive every transition.
Target audience: CTOs, engineering leaders, architects, product leaders, platform teams, and engineers redesigning their SDLC around AI.
Level: Intermediate–advanced.
Preferred duration: 35–45 minutes.
Format: Field report and workflow framework based on work with engineering and product teams.
Prerequisites: Familiarity with the software-development lifecycle and AI-assisted development.
Source: Lessons from helping teams introduce automation and autonomy across software-development workflows.
Shipping Faster Isn’t the Advantage. Learning Faster Is
Organizations have always designed their processes around protecting their most expensive resources. In software companies, that resource used to be engineering time.
Before developers began implementing a change, product managers, designers, architects, and other stakeholders worked to reduce uncertainty. Experimentation was limited because building two alternatives could add weeks of engineering effort.
AI changes that economic constraint. Code is becoming cheaper to produce, alternatives are easier to build, and teams can run far more experiments.
But running more experiments does not automatically create more learning.
As implementation accelerates, teams must form better hypotheses, produce specifications faster, collect useful evidence, and interpret results without becoming the next bottleneck.
In this session, I’ll share how we redesign the loop from assumption to experiment to evidence to decision. We’ll compare traditional analytics with LLM-assisted methods for analyzing qualitative and quantitative results, identifying patterns, and deciding what to test next.
The advantage is not producing more software. It is reducing uncertainty faster.
Target audience: Product leaders, engineering leaders, founders, product managers, and teams using AI to accelerate product development.
Level: Intermediate.
Preferred duration: 30–45 minutes.
Format: Field report and practical framework with experimentation examples.
Prerequisites: No deep AI knowledge required; familiarity with product experimentation is helpful.
Source: Lessons from running AI-native engineering workflows and helping teams rethink experimentation and learning speed.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top