A few weeks ago, I had the opportunity to speak at Product Jam 2026, organized by the wonderful Product Makers Romania community. Eight minutes were enough to explain Gen AI, software architecture, testing, operations, product thinking, and the future of software engineering.
Constraints are useful, they force clarity.
Compressing months of ideas and several long-form articles into four slides helped me realize that the most important change brought by Gen AI is not technical. It is organizational.
Much of the discussion around AI focuses on prompts, models, context windows, agents, and benchmarks. We compare outputs, debate which model writes better code, and spend endless hours searching for the perfect prompt. Yet after working with Gen AI for some time, I have become convinced that we are often optimizing the wrong thing.
The problem isn’t how to write better prompts. The problem is how to continuously steer AI-generated systems toward our intent.

During the talk, I described Gen AI as a probabilistic collaborator rather than a deterministic machine. That distinction matters because deterministic systems execute instructions exactly as written. Probabilistic systems approximate what we mean. Sometimes they approximate extremely well. Sometimes they approximate spectacularly badly. In both cases, reliability doesn’t emerge from perfection up front. It emerges from correction.
That realization changes the nature of software development itself.
For decades, our industry focused on generating artifacts. We generated requirements, generated code, generated tests, generated deployments. Gen AI accelerates all of these activities dramatically. But acceleration creates a new problem: systems can now become wrong much faster than before.
This is why I believe we are moving from generating software to steering software toward intent.
The cycle becomes simple: define intent, generate something, validate it, correct it, and repeat. The feedback loop becomes more important than the generation itself. This is also where the various roles inside product development become even more valuable.
Product Owners are not becoming obsolete because AI can generate features. Quite the opposite. AI can build functionality, but it cannot determine whether that functionality delivers value. Product feedback becomes the mechanism that keeps generated systems aligned with real user needs. Behavior Driven Development, usability testing, story mapping, and customer feedback are no longer optional activities. They become navigation instruments.
Architects experience a similar shift. AI can generate services, APIs, and abstractions extremely quickly. Unfortunately, it can also generate entropy at exactly the same speed. Boundaries slowly erode, naming becomes inconsistent, and systems drift away from their original design. Increasingly, architects are not designing static structures; they are designing guardrails and feedback systems that continuously preserve coherence.
Operations contributes yet another feedback loop. Development validates assumptions. Production validates reality. Systems that appear perfect during implementation often reveal their weaknesses only after encountering real users, traffic, failures, and unexpected interactions. Observability, incident learning, infrastructure testing, and chaos engineering transform operational experience into continuous learning. Production remains the ultimate truth detector.
Testing plays a particularly interesting role in AI-assisted development. If Gen AI accelerates creation, testers accelerate truth discovery. AI naturally optimizes for happy paths. Testers specialize in unhappy paths. They explore edge cases, challenge assumptions, break workflows, and expose weaknesses hidden beneath apparently correct implementations. In many ways, testers have become professional skeptics, and skepticism is becoming one of the most valuable engineering skills we have.
Developers themselves are changing too. They are no longer only writing code. They are shaping how AI interprets problems. Their standards, prompts, naming conventions, ADRs, and code reviews become feedback mechanisms that determine whether generated systems converge toward quality or toward chaos.
One idea I touched on during the talk is adversarial cooperation.
Humans already improve ideas by disagreeing with each other. Architects challenge developers. Testers challenge assumptions. Product Owners challenge implementations. The same principle may become increasingly important for AI systems. Instead of having one AI generate requirements, code, and tests, we can have multiple agents challenge each other. One agent builds. Another attempts to break. A third validates semantics. A fourth questions assumptions.
Truth often emerges faster from constructive disagreement than from blind agreement. This is why the “old” disciplines of software engineering suddenly feel surprisingly modern again.
For years, we treated architecture, testing, operations, and feedback as overhead. AI is reminding us why they existed in the first place.
Not to slow us down, but to prevent us from accelerating in the wrong direction. The age of Gen AI may not be killing software engineering after all. It may simply be forcing us to rediscover its foundations.
And if there is one idea I hope people remembered after those eight minutes at Product Jam, it is this: Reliability is engineered, not prompted.
Resources
Here are some articles and research items to continue exploring the topic in more depth.
The eight-minute format forced me to compress a lot of concepts into one slide, but fortunately many of the underlying ideas are backed by excellent papers and longer articles.
The final slide of the presentation included some of the resources that influenced both the talk and the series that followed.
Slides
Adversarial Cooperation
One of the ideas I find most interesting is adversarial cooperation: the notion that truth emerges faster when independent perspectives challenge each other instead of blindly agreeing.
Humans already work this way. Architects challenge developers. Testers challenge assumptions. Product Owners challenge implementations. Constructive disagreement is often what improves outcomes.
Increasingly, AI systems may benefit from the same principle.
Some resources that inspired this line of thinking are:
- Adversarial Cooperation in Code Synthesis – the paper that originally sparked many of my thoughts around AI agents challenging each other instead of self-validating.
- Adversarial Collaboration, by Daniel Kahneman – a powerful approach for resolving disagreements by jointly seeking evidence rather than defending positions.
- Improving Factuality and Reasoning in Language Models through Multi-Agent Debate – research showing how multiple agents debating can improve reasoning quality.
- The Cornell University work on Multi-Agent Debate – further exploration of collaborative and adversarial AI reasoning systems.
These ideas influenced several sections of the Architect, Ops, and Tester articles, especially around agentic governance and AI-versus-AI validation.
In-Depth Articles
The lightning talk itself only scratched the surface. Each role eventually evolved into a dedicated article with considerably more detail.
Product Development with Gen AI Using Feedback Cycles
The original article introduces the central idea behind the series:
Reliability is engineered, not prompted.
Product Owner View: Gen AI Needs Product Feedback, Not Just Prompts
Explores how Product Owners provide feedback loops through BDD, usability, user journeys, and business outcomes.
Software Architect View: Gen AI – Guardrails Over Genius
Discusses architecture fitness functions, DDD, naming consistency, ADRs, governance, and preventing entropy at AI speed.
Ops View: Gen AI Meets Reality in Production
Focuses on observability, infrastructure as code, incident learning, chaos engineering, and agentic operations.
Tester View: Breaking the System with Intent
Covers exploratory testing, contract tests, adversarial cooperation, edge cases, and continuous validation.
https://blog.adrianbolboaca.ro/2026/05/tester-view-breaking-the-system-with-intent
For readers interested in AI and software engineering more broadly, I also highly recommend visiting:
Because if there is one lesson I hope people remember from both the talk and the articles, it is this:
In the age of Gen AI, reliability is engineered, not prompted.