Juan G Carmona
Software Architect | AI Strategist | Critical & Secure Systems | Software Development Engineer at Plain Concepts
Madrid, Spain
Actions
Juan G. Carmona is a Software Architect at Plain Concepts with more than twenty years of experience in software engineering, architecture, and technical leadership. He has designed and led full-stack, cloud, distributed, and security-critical systems across aerospace, defence, mobility, motorsport, and enterprise software, working with organisations including Airbus, Alstom, Porsche Motorsport, and Solera.
His background also spans DevSecOps, cybersecurity, machine learning, applied AI, consulting, and entrepreneurship. He remains hands-on while helping teams turn complex requirements into secure, scalable, and maintainable systems.
Juan builds open-source software, writes, teaches, and has spoken at RootedCON and CONVEX. His current work includes Product Definition as Code, an open proposal for improving how products are defined and evolved, and ProductShape, its reference implementation.
Area of Expertise
Topics
Issue to Merge: Agentic SDLC in Practice and What Breaks It
AI is changing how we build software, but the value only shows up when it supports the whole lifecycle and not only code generation.
In this session we follow a single feature from a badly written user story to a merged pull request. Agents take part at every stage: refining the requirement, planning, implementing, testing and reviewing. Guardrails are present throughout the process to keep agents aligned with security, compliance, architectural and quality requirements, ensuring automation stays within agreed boundaries.
Some of that work is interactive, in the editor and the terminal. The rest runs unattended as GitHub Agentic Workflows or GitHub regular workflows.
Along the way we show how custom agents, skills and MCP integrations keep the work inside conventions the team already has, and which published workflows are worth installing before you invent your own. That is the practice. The rest is what breaks it.
In our experience the failures are rarely about the model. They are missing context, documentation that agents cannot read, decisions never written down as ADRs, repositories that all look different, prompts doing work that plain CI should own, guardrails that are either missing or applied too late, and expectations that nobody agreed. For each one we show what it looks like in a demo repository and what we do about it.
The goal is not to present AI as a shortcut, but as a practical teammate that needs the same things a new joiner needs: context, standards, guardrails, a definition of done and a review process.
Make Haste Slowly: Define Better to Build Faster
No product starts with a complete and final definition. Products are discovered, tested, and refined. The problem is not that decisions change. The problem is that they become scattered across roadmaps, tickets, documents, specifications, and conversations.
A product rule is agreed and delivered. Later, it changes. Some teams update their work, while other specifications, tests, and assumptions still reflect the previous decision. That is how features are built and rejected, requirements are misunderstood, and work is refined repeatedly or rebuilt from scratch.
AI and coding agents make this happen faster. Spec-Driven Development adds useful discipline by defining each increment before implementation, but it does not by itself prevent a growing set of specifications from repeating, reinterpreting, or contradicting product decisions.
This talk presents Product Definition as Code as a recently proposed, open framework for maintaining an evolving product definition that delivery work can cite instead of recreate. It shows how explicit product changes, connected decisions, and stale-reference detection help Product, Engineering, and QA stay aligned as the product evolves.
The goal is not to return to waterfall or freeze requirements. It is to make changing the product cheaper, reduce rework, and let teams develop faster because they are defining and verifying better.
Engineering an AI-SDLC for Agentic Delivery
Reviewing a PR delivered by an AI agent is the wrong time to ask questions. What was it meant to change? Where did its context come from? How was it implemented?
We will show an AI-SDLC used to bootstrap greenfield applications and work safely in established systems. It starts before an agent touches code. A person defines the change, its acceptance criteria, and the evidence a reviewer will need. Commands and skills carry it through refinement, proposal, implementation, validation, and review.
We will run a feature and then an urgent hotfix. You will see the Definition of Ready, the proposed specification and task plan, CI, tests, screenshots, PR evidence, merge, and the review that improves the next change. Only two steps wait for a person: approving the plan and reviewing the diff with its checks.
AI makes code cheap enough to expose gaps teams once absorbed as hand-offs, ambiguity, and rework. Engineering becomes the work of turning a business decision into safe, verified behaviour in production.
The Architecture Before the Agent: Product Definition as Code
Agentic delivery has a context problem. A product decision must survive through architecture, data models, specifications, prompts, tests, security controls, and code. As the product evolves, these artefacts can retain different versions of the truth.
Product Definition as Code (PDaC) is an open technique that treats product definition as an architectural asset: structured, versioned, linked, and changed explicitly. Instead of asking teams and agents to reconstruct the product from tickets, documents, and conversations, it provides a shared semantic layer for delivery, quality, and governance.
This session shows how product rules, actors, journeys, boundaries, requirements, and quality constraints form that layer; how Product Changes preserve the reasoning behind evolution; and how dependency checks expose divergence before it becomes costly rework.
The result is clearer context for AI agents, keeping product, architecture, security, and QA aligned as the system changes.
AI-Assisted Development at Scale: Keeping Product Decisions, Specs, and Agents Aligned
AI-SDLC creates a traceability problem that becomes expensive as products evolve. A product decision changes, while the delivery specifications, security requirements, test cases, and agent instructions built around its previous version remain unchanged.
Product Definition as Code is a recently proposed, open framework for tackling this problem. It keeps accepted product decisions versioned and connected, so delivery work, agent instructions, and checks can cite them instead of restating or reinterpreting them. This also reduces the repeated prose and supporting material that spec-driven workflows tend to accumulate.
We will follow one product rule from a versioned product definition into a delivery specification, GitHub Copilot instructions, security and quality requirements, and CI checks. Then we will change that rule and show how the workflow identifies consumers that are now relying on stale context.
The session combines product-definition traceability with secure AI-assisted engineering. It covers what can be checked mechanically, what coding agents can surface, and where human judgement remains essential.
Attendees will leave with a concrete way to accelerate AI-assisted delivery without letting outdated assumptions, product drift, or security gaps move silently into production.
Hard and Soft Guardrails for Agentic Software Engineering
An agent can only be as safe as the engineering discipline it is given. If warnings are ignored, architectural boundaries are implicit, security checks run late, and tests are optional, an agent will reproduce those weaknesses at machine speed.
This talk shows how to turn engineering standards into guardrails for agentic software development. A hard guardrail is deterministic and enforced: it fails the build, blocks the commit, or stops the agent before the damage ships, and a human verified the check itself is correct. A soft guardrail is advisory: it surfaces a warning, a hint, or a review question, and leaves the decision to an experienced engineer.
The distinction is not the tool. A type check can be soft (a warning you dismiss) or hard (a CI gate that fails the build). What makes it hard is that the rule is deterministic, it blocks automatically, and a human checked that the check is right. What makes it soft is that it leaves room for judgement.
Soft guardrails preserve the decisions that still require an engineer: whether a change is ready, whether its design fits the system, whether its evidence is enough to merge. Hard guardrails remove the mistakes that no engineer should have to catch by hand.
The craft is knowing when a soft rule has hurt enough to turn hard. When the same warning keeps getting ignored, when the same bug ships twice, you turn the suggestion into a gate. Over time, the workflow becomes harder to misuse and easier to trust.
The tools are not the main point. The team's engineering judgement is. The important step is to make that judgement explicit and executable, so the agent inherits your standards instead of your habits.
The result is an AI-assisted SDLC that lets agents move quickly without letting security, quality, or architecture silently degrade.
Software Engineering 2.0: Designing, Building, and Validating Products with AI
For years, we have been cutting back on good engineering practices to deliver on time. Now that we can delegate much of the implementation to AI, we have an opportunity to review, and an obligation to improve, our processes from end to end.
I have been developing software for more than twenty years. Over the last few years, working with AI has made me rethink many things: what my project needs to work with agents, what agents need to adapt to the project, how to ensure technical decisions are respected, and how to validate that what is delivered matches what was expected.
In this talk, I will share what I am putting into practice and what I am still refining. We will discuss agentic development, Spec-Driven Development, hard and soft guardrails, and the evolving concept of software product definition. Using real examples, I will explain the advantages and drawbacks of AI at each stage of the process and what still depends entirely on us.
AI is changing software engineering, and this is how some of us are shaping the way we will practise our profession in the years ahead.
Juan G Carmona
Software Architect | AI Strategist | Critical & Secure Systems | Software Development Engineer at Plain Concepts
Madrid, Spain
Actions
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