Cost-Effective Agent Usage: How Disciplined Teams Get Real Leverage From AI Coding Tools

Cost-effective agent usage is an engineering workflow discipline. The goal is to cost effectively boost engineering leverage: better output, faster learning, less rework, stronger verification, and lower long-term maintenance cost.

This talk explains how teams waste engineering time and token budget through vague prompts, repeated rework, poor context management, wrong model selection, long thrashing sessions, and agents rediscovering information the engineer already had. Excessive token usage is usually a signal that the workflow is poorly bounded, the context is unfocused, the task is underspecified, or the engineer didn’t stop when the agent drifted.

The session gives teams concrete practices for improving agentic workflow efficiency: defining the question being answered, bounding the files in scope, setting stopping conditions, reviewing intermediate plans, matching the model to the task, providing focused context, avoiding unnecessary rediscovery, stopping when agents thrash, and capturing reusable understanding in durable artifacts.

Attendees will leave with a practical model for managing agent usage as an engineering discipline. The point is to make every session produce leverage that justifies its cost in engineering time, review burden, rework avoided, or maintainability improved.

This talk directly references the author’s Engineering Standards for Agentic Software Development, especially CU1, CU2, CU3, CU4, CU5, CU6, CU7, CU8, and CU9: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience: Engineering managers, AI enablement teams, platform leaders, tech leads, and organizations managing AI coding tool costs and productivity.

Preferred Session Duration:
50 mins including Q&A

AI Coding Tools Expose Gaps in Engineering Rigor

AI coding tools expose gaps in engineering rigor because they let teams generate more code than they can specify, verify, refactor, review, and safely own.

This talk explains why agentic coding raises the bar for engineering discipline across the full software delivery workflow. Teams need stronger preparation before generation, clearer verification standards after generation, more disciplined refactoring before review, and a higher bar for accepting AI-generated code into production. Without that rigor, agentic coding can produce large amounts of plausible output that looks productive while quietly increasing maintainability risk, architectural drift, and ownership burden.

The session gives CTOs, VPs of Engineering, and engineering directors a practical way to think about AI workforce development. Engineers need to learn how to interrogate requirements, define constraints and invariants, confirm that tasks are independently verifiable, check agent assumptions against actual system behavior, review for architectural fit, and own every meaningful change they merge. These are trainable engineering behaviors, and they need to become explicit standards as AI coding tools become normal parts of software delivery.

Attendees will leave with a clear model for identifying where their teams need more rigor before scaling agentic coding: specification, verification, refactoring, review, architecture, product understanding, and accountability. AI can accelerate execution, but engineering rigor determines whether that acceleration produces technical wealth or technical debt.

This talk directly references the author's Engineering Standards for Agentic Software Development, especially TD1, SP1, VT1, AM4, AC2, and DK1: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience: CTOs, VPs of Engineering, engineering directors, technical program managers, and executives responsible for AI workforce development.

Preferred Session Duration:
50 mins including Q&A

AI Is Making Code Easy and Software Hard

AI is changing the economics of software creation. Tools like Cursor, Claude Code, GitHub Copilot, Codex, Bolt, Lovable, v0, Replit, and other AI development platforms make it dramatically easier to generate working code, create realistic user experiences, and move from idea to prototype.

This creates a new leadership problem: generating code is getting easier. Building software that remains understandable, maintainable, architecturally coherent, and safe to evolve is getting harder.

In this session, I’ll explain why AI-accelerated development changes the role of CTOs, VPs of Engineering, Engineering Directors, senior architects, and product engineering teams. Product managers and designers can now use AI tools to create Realistic Interactive Prototypes, or RIPs, that make traditional MVP thinking feel slow for many discovery efforts. Engineers are also using agentic coding tools to delegate raw code generation to AI. The engineering role is shifting from manually writing every line of code to supervising, shaping, refactoring, and composing AI-generated software into systems humans can understand and maintain.

That shift creates the need for a new engineering discipline: the Software Composer.

A Software Composer doesn’t accept AI-generated code just because it works. Software Composers shape systems around clear architecture, intuitive domain models, readable abstractions, durable boundaries, and strong maintainability standards. This becomes more important as AI increases code volume and accelerates architectural drift. Without strong engineering discipline, teams can quickly create larger, more fragile codebases that look productive in the short term but become expensive to modify, test, debug, and extend.

The session will cover the shift from MVPs to RIPs, the rise of agentic coding, the maintainability risks of AI-generated code, and why architecture determines whether software can survive growth. I’ll also explain how AI-generated Daily Reports can improve team awareness, reduce status meetings, surface blockers earlier, and maintain alignment without adding process overhead.

The core message is simple: AI can help teams move much faster, but speed alone doesn’t create durable software. The winning teams will combine AI-enabled product discovery, agentic coding, strong architecture, domain clarity, continuous refactoring, and human-centered maintainability discipline.

Target audience
CTOs, VPs of Engineering, Engineering Directors, senior software architects, principal engineers, product engineering managers, and technical program managers responsible for improving software delivery outcomes in AI-accelerated product teams.

Preferred session duration:
50 minutes including Q&A.

Product Oriented Software Engineering (POSE): A New Era of Software Development

Imagine an engineering culture where teams move faster, stay aligned with product goals, and take ownership—without sacrificing technical excellence. Product-Oriented Software Engineering (POSE) redefines engineering’s role by transforming software engineers into Product Engineers who take ownership of both technical execution and strategic product alignment.

Traditional development models often struggle with misalignment, inefficiencies, and process-heavy workflows. Engineers can find themselves in reactive cycles, managing handoffs, resolving miscommunications, and navigating product decisions without full visibility into the bigger picture. POSE eliminates these inefficiencies by embedding product awareness into engineering teams and introducing the Flex Engineer role—a key enabler of real-time collaboration and technical alignment.

By acting as a bridge between product and engineering, the Flex Engineer ensures smooth execution, prevents bottlenecks, and provides timely insights based on continuous awareness of engineering progress. This role, combined with real-time collaboration, deep product understanding, and technical ownership, enables engineering teams to operate with greater autonomy, efficiency, and strategic impact—while maintaining seamless alignment with product vision.

Why POSE Matters to Engineering Leaders
• Faster Execution: Engineers make informed decisions without constant Product Manager input.
• Less Rework, More Impact: Product Engineers align with business goals, reducing misalignment and wasted effort.
• Optimized Engineering Flow: Fewer meetings, less Jira overhead, and more time for deep work.
• Stronger Technical Voice: Engineers influence product strategy early, ensuring smarter technical trade-offs.
• Real-Time Alignment: The Flex Engineer bridges product and engineering, preventing miscommunication.

This approach isn’t theoretical—it’s a proven methodology that has been implemented and refined over nearly two decades at G3 Technologies. POSE has been refined over nearly two decades at G3 Technologies, enabling teams to ship faster, smarter, and with greater autonomy.

Join this session to explore how POSE enables engineering teams to move faster, stay aligned with product goals, and take ownership of both execution and strategic impact. Learn how this approach enhances collaboration, reduces misalignment, and empowers engineers to deliver high-quality products with confidence.

Target Audience - Engineering VPs, Engineering Directors, CTOs. This talk can be adjusted to different audiences.
Preferred Session Duration - 30-60 minutes. This duration can be adjusted.
Session Delivery/Format - In-person and virtual.

Supercharging Agile Professionals with AI

This seminar will focus on how AI tools can elevate the productivity and skill sets of individual Agile professionals, including Product Owners, Scrum Masters, Designers, Tech Leads, and Developers. AI is revolutionizing the way professionals work by enhancing decision-making, automating routine tasks, and accelerating personal expertise development.

We’ll introduce specific AI tools and demonstrate their practical utility, showing how Product Owners can expand their skill sets to take on greater strategic involvement. Scrum Masters can leverage AI to automate routine activities, take on a strategic role as liaisons between business and technology, and enhance their role in aligning team efforts with business goals. Designers will benefit from AI’s ability to support rapid prototyping and iteration, automated image and graphic creation, and smart recommendations based on user behavior and design trends. Tech Leads can use AI to gain a broader and deeper awareness of coding progress, and Developers can elevate both their output and technical sophistication.

Target Audience - Product Owners, Scrum Masters, Designers, Tech Leads, and Developers. This talk can be adjusted to different roles.
Preferred Session Duration - 60 minutes. This duration can be adjusted.

First public delivery:
Agile Alliance (Agile Tech Talks) on Jan 8, 2025

Session Delivery/Format - In-person and virtual.

Preferred Session Duration: 50 mins including Q&A

Achieving Product Team Agility: Empowering Cross-Functional Individuals with AI

As software complexity has grown 50x since the inception of Agile and Scrum, the next evolution in agility demands a shift from cross-functional teams to cross-functional individuals—professionals who blend technical expertise, product thinking, and collaboration skills. This evolution is now highly achievable with the advent of AI tools that accelerate skill growth and amplify individual impact.
Drawing from strategies I’ve successfully implemented with my own engineering teams, this talk will explore:
1. A spectrum of product team topologies, ranging from the least agile to the most agile, and how shifting toward cross-functional individuals accelerates agility.
2. How cross-functional individuals reduce handoffs, accelerate decisions, and enhance team responsiveness, enabling smaller, more efficient teams by collapsing traditional role silos.
3. How AI tools empower lesser technical staff to operate with near Tech Lead-level insights for effective technical team management and engagement.
4. Practical strategies for using AI to help team members become cross-functional individuals, based on real-world experience.
Attendees will leave with actionable insights grounded in proven practices that have helped my teams unlock faster innovation, improve collaboration, and deliver meaningful business outcomes with greater efficiency.

Target audience:
This talk is intended for product, engineering, and Agile leaders who are trying to improve agility in modern software organizations where complexity, coordination overhead, and role specialization have outgrown the assumptions behind traditional Agile and Scrum practices.

It is especially relevant for Product Managers, Product Owners, Engineering Managers, Tech Leads, Scrum Masters, Agile Coaches, UX leaders, delivery leaders, and executives responsible for improving software delivery performance. The talk will also be valuable for organizations exploring how AI can help teams reduce handoffs, improve collaboration, and develop more cross-functional talent without simply adding more process or more people.

Attendees should be interested in the next evolution of product development: moving beyond cross-functional teams toward cross-functional individuals who can think across product, engineering, design, delivery, and business concerns. The session is best suited for leaders and practitioners who want practical ways to use AI to strengthen team members’ judgment, accelerate skill growth, improve technical engagement, and build smaller, more responsive teams capable of delivering better outcomes in increasingly complex software environments.

Preferred Session Duration: 50 mins including Q&A

Evolving the Engineer: A Leadership Roadmap for the AI Era

AI is here—and it’s transforming software engineering faster than most leaders are prepared for. GenAI tools like Copilot and Cursor are boosting productivity by automating routine coding tasks, but they’re also contributing to significant layoffs. Pure software engineering roles are under threat, and leaders urgently need a plan to evolve their teams.

In this talk, Andrew Park—a longtime Engineering and Product Leader—delivers a clear, field-tested roadmap for evolving engineers in the AI era. He shows how to help your teams harness AI for speed—while leveling up in the areas GenAI can’t touch: product thinking, system design, craftsmanship, maintainability, and the collaboration skills needed to work across product, design, customers, and dependent teams.

You’ll walk away with a practical strategy for transforming engineering roles and building smaller, more capable teams—enabling your organization to meet executive demands to do more with less, without sacrificing product quality or long-term agility. This is how you secure engineering careers—and your product’s future—in an AI-driven world.

This talk is intended for engineering leaders, product leaders, technology executives, and software delivery leaders who are trying to understand how AI will reshape software engineering roles, team structures, and talent strategy.

It is especially relevant for CTOs, VPs of Engineering, Engineering Directors, Engineering Managers, Tech Leads, Product Leaders, Agile leaders, and senior software professionals responsible for improving productivity while protecting product quality, maintainability, and long-term delivery capability.

The session is best suited for leaders who are under pressure to do more with smaller teams, adopt AI coding tools responsibly, and prepare their engineers for a future where pure coding skill is no longer enough. Attendees should be interested in practical strategies for evolving software engineers into higher-value professionals who combine AI fluency with product thinking, system design judgment, technical craftsmanship, maintainability discipline, and stronger collaboration across product, design, customer, and dependent-team boundaries.

This talk will be particularly valuable for organizations that want to use AI to increase engineering output without creating fragile codebases, hollowing out technical talent, or weakening the human judgment required to build durable software products.

First public delivery:
DeveloperWeek Leadership on May 28,2025 in San Francisco.

Preferred session duration:
50 mins including Q&A.

From Cagan to Pichler: Crafting the Right Product Playbook for DoD Applications

The Defense Industrial Base has mastered compliance and program management, but it has struggled mightily in software engineering and even more so in product management. This gap explains why firms like Anduril and Palantir are thriving. They brought modern product management discipline into a space that had virtually none.

This talk introduces a spectrum of product management philosophies and maps them to DoD opportunity contexts.
• High consequence systems such as weapons, sustainment, and space programs require structured, risk managed strategy frameworks. Thinkers like Roman Pichler, Clayton Christensen, and Geoffrey Moore provide approaches that fit these domains.
• Mid tier programs such as logistics, command and control, ISR, and cyber defense can benefit from Teresa Torres’s continuous discovery habits, Ash Maurya’s Lean Canvas, and Bryar and Carr’s Working Backwards.
• Innovation contexts such as software factories, special operations projects, and AI or machine learning prototyping thrive with empowered, experimental approaches from Marty Cagan, Eric Ries, and Steve Blank.

Attendees will leave with a practical framework for matching product playbooks to defense opportunities and a sharper understanding of why product management, not just engineering or compliance, will decide the future of the Defense Industrial Base.

This talk is intended for Defense Industrial Base executives, capture leaders, program managers, product leaders, engineering leaders, and DoD acquisition professionals who want to better match product management approaches to different defense opportunity contexts.

It is especially relevant for organizations competing in software, C2, ISR, cyber defense, sustainment, space, AI/ML, software factories, and special operations programs. Attendees will gain a practical framework for applying the right product playbook to the right opportunity and understanding why product management is becoming a decisive advantage in the future of the DIB.

Preferred Session Duration: 50 mins including Q&A

Achieving Product Team Agility: Empowering Cross-Functional Indivuduals with AI

As software complexity soars, the next evolution calls for cross-functional individuals who unite tech, product, and collaboration skills. This talk shows how AI accelerates growth, reduces silos, and drives faster, more efficient innovation.

Target audience:
This talk is intended for product, engineering, and Agile leaders who are trying to improve agility in modern software organizations where complexity, coordination overhead, and role specialization have outgrown the assumptions behind traditional Agile and Scrum practices.

It is especially relevant for Product Managers, Product Owners, Engineering Managers, Tech Leads, Scrum Masters, Agile Coaches, UX leaders, delivery leaders, and executives responsible for improving software delivery performance. The talk will also be valuable for organizations exploring how AI can help teams reduce handoffs, improve collaboration, and develop more cross-functional talent without simply adding more process or more people.

Attendees should be interested in the next evolution of product development: moving beyond cross-functional teams toward cross-functional individuals who can think across product, engineering, design, delivery, and business concerns. The session is best suited for leaders and practitioners who want practical ways to use AI to strengthen team members’ judgment, accelerate skill growth, improve technical engagement, and build smaller, more responsive teams capable of delivering better outcomes in increasingly complex software environments.

Preferred session duration:
50 mins including Q&A time.

The Software Risk Your PMO Can’t See: Using code evidence to manage contractor performance

Defense program managers are being asked to deliver measurable software outcomes, accelerate modernization, and hold contractors accountable for progress that survives beyond the next sprint demo. The problem is that many software-intensive programs are still managed through indirect evidence: contractor status reports, sprint reviews, Jira summaries, IMS updates, risk registers, and PowerPoint briefings.

Those artifacts show activity, reported progress, planned milestones, and visible delivery. They often don’t show the condition of the codebase the government will inherit, sustain, modernize, and depend on for years.

That creates a dangerous blind spot. A program can look green while the codebase is becoming harder to change, harder to test, harder to transfer, and harder to sustain.

Technical debt, fragile modules, weak maintainability, knowledge concentration, rework patterns, and uneven contractor performance often stay invisible until they become schedule slips, expensive sustainment, failed transitions, painful recompetes, or modernization drag. By that point, the PMO is usually reacting to a problem that has been compounding for months or years.

This session makes the case that technical debt should be treated as program risk. Program managers don’t need to read source code, but they do need objective evidence derived from the codebase. Maintainability trends, contributor concentration, module-level risk, code ownership patterns, team comparisons, and rework indicators can help PMOs detect risk earlier and manage contractor performance with evidence instead of instinct.

The session will show how code-derived evidence can strengthen oversight across the program lifecycle: pre-award contractor evaluation, active development monitoring, pre-delivery acceptance, sustainment planning, transition risk management, and recompete decisions. It will also explain why labor categories don’t prove capability, why contractor status reporting doesn’t equal software health, and why maintainability should become a routine part of program reviews.

Attendees will leave with a practical framework for asking stronger software oversight questions. Is the codebase becoming easier or harder to change? Which modules are creating the most future sustainment risk? Where is critical knowledge concentrated? Which contractor teams are improving, and which are creating future O&M exposure? What evidence proves the software is more sustainable than it was 6 months ago?

The goal is responsible oversight of long-lived software. If defense PMOs are expected to manage outcomes, they need evidence that goes deeper than reported status. The codebase already contains many of the signals PMOs need. The next step is translating those signals into program management insight. 

Target audience:
Program Managers, Deputy Program Managers, PEO staff, acquisition leaders, technical directors, contracting officers, systems engineers, software factory leaders, sustainment leaders, and defense industry executives.

Preferred Session Duration: 50 mins including Q&A

The MVP Is Too Slow for Product Discovery Now: How RIPs help teams find the right product faster

Most software teams still treat the MVP as the first serious product discovery tool. That made sense when realistic screens, workflows, and interactions were expensive to create. AI tools have changed that sequence.

At Edensoft Labs, we offer product development services for organizations that need software delivered quickly, designed clearly, and built for long-term ownership. Our work starts before coding. We learn the domain, clarify the vision, surface the right problems early, and create software that non-technical stakeholders can understand and engineers can maintain after handoff. Our process combines requirements discovery, UX and product management, architecture, development, testing, and maintainability from the beginning. Every engineer is trained on our 149 maintainability standards, so maintainability and legible architecture are enforced whether the code is written directly by an engineer or produced with agentic coding under the engineer’s control. The result is software that’s readable, reliable, built to last, and not dependent on us after delivery. 

This session explains how Edensoft Labs uses AI-assisted RIPs as the front end of that product development process. The core idea is simple: many teams should stop using MVPs to discover basic product requirements. They should use Realistic Interactive Prototypes, or RIPs, first.

A RIP looks and feels like working software, but its purpose is discovery. It gives users, product managers, program managers, designers, engineers, and executives something concrete to inspect before the team commits serious engineering dollars. Users react better to realistic workflows than abstract requirements. Product managers see where the concept is weak. Engineers see complexity earlier. Program managers get a better basis for scope, phasing, budget, and delivery decisions.

The MVP has a role, but it should come later. The MVP should validate a buildable product after the team has already used RIPs to discover workflows, clarify requirements, expose bad assumptions, and create shared understanding across the people who need the software to succeed.

The session will walk through Edensoft Labs’ product development approach: start with the vision, turn early ideas into realistic interactive workflows, put those workflows in front of users quickly, refine requirements through concrete feedback, then move into MVP development with stronger alignment and less waste. We’ll share real-world examples of how this approach has sped up discovery and delivery times by 4x by replacing abstract requirement debates with concrete user feedback much earlier in the process.

The goal is faster discovery, better requirements, lower rework, and software that doesn’t become tomorrow’s sustainment problem. Attendees will learn how to distinguish a demo, a RIP, and an MVP; when to use each one; why AI makes RIP-first discovery practical; and how to avoid the common trap of treating a prototype like production software.

This talk is designed for program managers, product managers, UX designers, technical directors, innovation teams, and software leaders who need to discover the right product faster and then build it with enough discipline to last.

Conquering Technical Debt Once and For All: A 21-Year, Field-Tested Solution

Conquering Technical Debt Once and For All: A 21-Year, Field-Tested Solution

Technical debt is one of the main reasons software organizations lose modernization speed. The first release works. The demo looks good. The contract deliverable passes acceptance. Then the code becomes harder to change, harder to transfer, harder to understand, and harder to trust. Over time, the software stops moving at the speed the mission requires.

In this talk, Andrew Park shares the field-tested approach he developed over 21 years leading long-lived software product lines for Department of War clients. Since 2004, Andrew’s teams have delivered mission-critical software into demanding defense environments where sustainment, modernization speed, and reliability directly affected operational outcomes. Across 30 million lines of delivered code and 56,258 rigorous code reviews, his teams sustained continuous modernization without emergency contractor interventions caused by code maintainability failures. 

The central lesson is direct: technical debt can’t be conquered through occasional cleanup sprints, heroic refactoring, or generic code quality dashboards. It has to be addressed at the source. That means making code sustainability visible, measurable, enforceable, and coachable at the contractor, project, module, and developer level.

Andrew will walk through the 9 kinds of technical debt he has encountered repeatedly across his career: incoherent architecture, architectural debt, structural debt, documentation debt, code complexity, poor abstractions, code smells, test debt, and style violations. He will explain why these categories don’t carry equal risk, how some forms of debt amplify the others, and why documentation debt is often the hidden accelerant that makes every other sustainment problem worse. 

The talk then introduces the secret Andrew discovered across 21 years of field experience: technical debt becomes manageable when leaders stop treating it as a vague engineering concern and start treating it as an inspection, scoring, coaching, and enforcement system. In the same way cybersecurity teams use objective tools to find and enforce vulnerability compliance, software organizations need objective visibility into maintainability compliance before the code becomes too expensive to change.

Andrew will show how sustainment risk can be measured by examining intent and business context, documentation gaps, evolving system knowledge, audience-specific documentation, traceability and rationale, function/class/file descriptions, language clarity, and code readability and structure. These factors are converted into actionable risk scores that help program managers, product leaders, and engineering executives see which parts of the codebase are sustainable, which parts are dangerous, which contractors are creating long-term risk, and which developers have become single points of failure.

This session will also explain why traditional code quality tools are useful but insufficient. Tools like SonarQube and CodeClimate can help detect defects, syntax violations, security issues, and code smells. They don’t fully answer the question that matters most for long-lived systems: will this codebase survive transition, personnel turnover, scaling, modernization, and years of sustainment?

Attendees will leave with a practical model for turning technical debt from an invisible drag on modernization into a visible leadership control system. They’ll learn how to identify the forms of debt that create the most long-term damage, how to expose sustainment risk before transition, how to reduce knowledge silos, how to guide developer improvement, and how to hold contractors accountable for producing code that can be sustained after delivery.

This talk is designed to inspire another one-time cleanup effort. The goal is to show how technical debt can be managed continuously, objectively, and permanently, before it becomes the reason modernization slows down.

This talk is designed for program managers, engineering executives, CTOs, technical directors, product leaders, software acquisition professionals, and anyone responsible for long-lived software systems.

Preferred Session Duration: 50 mins including Q&A

Conquering Technical Debt in the Age of Agentic Coding

AI is collapsing the old handoff model between product, design, and engineering.

Product managers and designers no longer need to stop at static wireframes, Figma flows, or backlog items. With tools like Bolt, Lovable, v0, Replit, and other AI app builders, they can now create Realistic Interactive Prototypes, or RIPs, that look and feel much closer to working software. These RIPs expose product gaps, usability issues, workflow problems, and requirement misunderstandings long before a full engineering team is committed to building the wrong thing.

Engineers are facing an equally large shift. Tools like Cursor, Claude Code, GitHub Copilot, Codex, and Cline are moving software development from manual code production toward agent-directed software construction. The engineer’s job is no longer centered on typing every line of code. It’s centered on guiding agents, inspecting their work, refactoring aggressively, protecting architectural clarity, and making sure the resulting system can be maintained by humans after the AI session ends.

That shift creates a major leadership challenge.

AI can increase software output dramatically. It can also accelerate technical debt dramatically. Faster code generation creates more code to review, more integration risk, more architectural drift, more hidden complexity, and more maintenance burden for the engineering team.

This is why MVP thinking is becoming too slow for many discovery efforts. Product teams can now use RIPs to validate workflows, assumptions, and requirements much faster, then reserve serious engineering investment for ideas that have already been pressure-tested through realistic interaction.

It’s also why traditional delivery metrics like velocity and DORA are no longer enough to judge engineering health. A team can appear faster while the product quietly becomes harder to change. Deployment frequency may rise. Lead time may fall. Maintainability, architecture, test quality, and human understandability can still degrade.

In this talk, I’ll explain why AI forces CTOs, VPs of Engineering, and Engineering Directors to rethink product discovery, engineering roles, team metrics, and technical debt prevention.

I’ll introduce the concept of the engineer as a Software Composer: a technical professional who orchestrates AI-generated code into a coherent, maintainable, human-centered system. Software Composers don’t merely accept AI output. They shape it, constrain it, challenge it, refactor it, and integrate it into a durable architecture.

I’ll also show the 9 kinds of technical debt I’ve encountered across 21 years of leading teams that delivered mission-critical software to Department of War clients. More importantly, I’ll share the secret I discovered for addressing them: technical debt is conquered by changing the daily engineering behaviors that create or prevent it at the source.

The session will cover practical strategies for using AI without allowing it to turn your codebase into tomorrow’s legacy system. I’ll explain how to embed continuous refactoring, architectural clarity, AI-generated Daily Reports, engineering standards, product alignment, and maintainability discipline into the normal rhythm of product development.

The future belongs to teams that use AI to discover better products, compose better systems, and preserve the craftsmanship required to keep software understandable, adaptable, and durable. 

Target audience:
CTOs, VPs of Engineering, Engineering Directors, senior architects, product engineering managers, technical program managers, and product leaders working with AI-accelerated product teams.

Best fit for teams using or evaluating tools like Cursor, Claude Code, GitHub Copilot, Codex, Bolt, Lovable, v0, Replit, and other AI development tools.

Preferred session duration:
50 minutes: 40 minutes of talk, 10 minutes of Q&A.

When AI makes code cheap, engineering judgment becomes priceless

AI has already changed the economics of software engineering. Code generation is becoming cheap, fast, and abundant. That moves engineering value upstream into judgment.

Agentic coding gives engineers extraordinary leverage, but it also compresses the timeline for technical debt. Agents can generate working code faster than teams can absorb it, review it, understand it, and fit it into the architecture. When engineering discipline doesn’t scale with output, teams get architectural drift, cognitive debt, duplicate logic, shallow documentation, fragile abstractions, and code nobody truly owns. 

This talk shares the engineering standards I’ve put in place with my own teams as we’ve adopted tools like GitHub Copilot, Cursor, Claude Code, Bolt, and other AI development tools. I require engineers to master these tools, but never as a substitute for engineering judgment. The agent can generate. The engineer must specify, verify, refactor, document, and own the result.

The session focuses on the practices that separate AI-assisted coding from responsible agentic software development: requirements interrogation before generation, clear task boundaries, verification against actual system behavior, refactoring before review, architectural ownership, simplicity, and deep product understanding. These disciplines keep AI-generated work from becoming dark code: code that looks polished, passes tests, and enters the codebase without anyone fully understanding what it does, why it was built that way, or what it touches.

I’ll also show how this connects to the rise of Product Engineers. In an AI-accelerated environment, the most valuable engineers aren’t just faster coders. They understand the product, the domain, the quality attributes that matter, and the architecture that must survive long after the demo works. They work alongside Product Managers to shape PRDs, clarify requirements, reduce or eliminate detailed user stories, and connect business goals directly to engineering execution.

For engineers, engineering leaders, architects, and product-minded technical professionals, this session offers a practical roadmap for staying valuable in the age of AI. The future belongs to engineers who can guide agents, protect the architecture, build technical wealth, and turn cheap code generation into durable business value.

Target audience:
1. Software engineers using or preparing to use AI coding tools
2. Senior engineers responsible for architecture, maintainability, and code review
3. Engineering managers and directors leading AI-accelerated development teams
4. Product Engineers working closely with Product Managers and Designers
5. Software architects responsible for preventing architectural drift
6. Technical program managers responsible for delivery outcomes, software quality, and engineering coordination

Preferred Session Duration: 50 mins including Q&A

Product Oriented Software Engineering (POSE): A Game-Changer for Product Managers & Product Leaders

Imagine if your engineering team could reduce your workload, take ownership of day-to-day development tasks, and free you to focus on strategy, vision, and delivering real value. That’s exactly what Product-Oriented Software Engineering (POSE) offers. Unlike approaches where a single software engineer takes on product responsibilities, POSE transforms all software engineers into Product Engineers who deeply understand both the product’s technical and strategic goals. This unique approach eliminates misalignment, streamlines your workload, and tackles one of the most pressing challenges for Product Managers: burnout.

As a Product Manager, you may find yourself buried under tactical responsibilities like writing user stories, maintaining backlogs, prioritizing tasks, resolving misalignments, and monitoring dependencies. POSE can help you shed these burdens. Many of these responsibilities either disappear altogether or are shifted to Product Engineers. Misalignment issues decrease significantly because Product Engineers internalize the product vision and align their work accordingly, reducing the need for constant oversight. Similarly, operational responsibilities like refining requirements, managing day-to-day execution, and providing Level-of-Effort (LOE) estimates are taken on by Product Engineers, freeing you to focus on the strategic aspects of your role.

Teresa Torres’ vision of the “Product Trio” (Product Manager, Designer, and Engineer) is a powerful framework for collaboration that ensures alignment and effective communication. POSE makes this vision highly attainable because a Product Engineer (designated as a Flex Engineer) has a #1 priority responsibility to be available for collaboration at a moment’s notice. While not exclusively dedicated to collaboration, this prioritization effectively mimics dedicated availability, enabling seamless support for product discovery, design discussions, LOE estimates, and execution planning. This minimizes delays, reduces friction, and allows the Product Trio to work together efficiently toward shared goals.

How POSE Can Help You as a Product Manager:
• Eliminates some responsibilities altogether: Misalignment issues, repetitive micromanagement, and redundant oversight diminish as Product Engineers fully align with the product vision and execute autonomously.
• Shifts operational responsibilities: Tasks like refining requirements, tracking progress, resolving technical dependencies, and providing LOE estimates move to Product Engineers, reducing your cognitive load.
• Frees time for strategy: With fewer tactical demands, you can focus on vision-setting, market analysis, and high-impact decision-making.
• Improves collaboration: A shared understanding of the product vision ensures smooth communication and alignment across teams.

This approach isn’t theoretical—it’s a proven methodology that has been implemented and refined since 2004 while delivering mission critical software to Department of War clients. Regardless of your particular domain, POSE can help you, as a Product Manager, lead large, complex efforts with less friction, fewer misalignments, and greater success. It offers a clear path to reducing burnout and enhancing your focus on strategic leadership, enabling you to thrive in your role.

Join this session to learn how POSE can transform your role as a Product Manager by lightening your workload, amplifying your strategic impact, and giving you the space to thrive. Let’s unlock the full potential of your teams and deliver better products—together.

Flying Blind — Why Program Offices Can't See the Risk Inside Contractor Code

Tagline: Real technical oversight happens at the code level.

Abstract:
Defense program offices managing software-intensive programs operate with a structural visibility gap: the technical risk accumulating inside contractor codebases is invisible under current oversight regimes. Schedule status comes from contractor Agile ceremonies. Quality assessments come from contractor demos. By the time the PMO sees evidence of a problem, it has already compounded into a cost or schedule crisis, the same pattern that produced $4B+ overruns on programs like AEGIS Combat System and ECSS.

DoDI 5000.87 created the Software Acquisition Pathway and made clear that program offices are expected to exercise active technical oversight, but provided almost no guidance on what that looks like in practice for non-technical PMO staff. This talk fills that gap.

Drawing on hands-on experience with contractor-delivered defense codebases, this session presents a practical framework for code-level oversight that requires no programming knowledge to operate. Attendees will see what objective, repository-level delivery visibility looks like, how AI-generated daily summaries give non-technical product owners and their project managers real situational awareness of what contractors are actually building, and how maintainability scoring creates enforceable acceptance criteria, analogous to what Nessus did for cybersecurity compliance, that can be embedded in contract language today.

The talk includes live demonstrations showing how PMOs can gain objective visibility into contractor-produced code, including maintainability, code ownership concentration, duplication, and areas of hidden technical debt. These examples show how the current visibility gap creates measurable delivery risk and how PMOs can close it using practical steps already available within their existing acquisition authority.

Learning Objectives:
• Identify the 3 failure modes that emerge when PMOs rely on contractor self-reporting as their primary source of technical truth
• Understand how repository-level delivery monitoring translates complex engineering activity into actionable summaries for non-technical acquisition leaders
• Apply a maintainability scoring framework as a contractual acceptance criterion, defining what "good enough to deliver" means in measurable terms
• Recognize the specific contract vehicles and program phases where code-level oversight has the highest return on investment
• Leave with draft contract language and oversight process checkpoints ready for immediate PMO application

Target Audience:
Program managers, deputy PMs, contracting officers, and DCMA representatives managing software development contracts under the Software Acquisition Pathway. Particularly relevant to programs using time-and-materials or cost-plus contracts with embedded contractor development teams.

Preferred Session Duration:
50 minutes including Q&A.

The Sustainment Debt You Don't Know You're Buying

Tagline: 65% of defense software is in the sustainment danger zone. Here's how to find it before it owns your O&M budget.

Abstract:
Software O&M costs are the fastest-growing line item in the defense budget, and most of those costs were locked in years before the system ever reached the field. The root cause is code delivered to a standard no one measured, accumulated maintainability debt no one tracked, and a handoff to a sustainment organization inheriting a problem no one disclosed.
This talk presents an analysis of millions of lines of open-source defense sector code across dozens of projects and 200 developers, scored against an 8-factor, research-validated maintainability framework. The finding: 65% of that code sits in the sustainment danger zone, the range where personnel turnover, technology refresh, and future modification requirements will produce costs that exceed the value of the system.

That number was entirely invisible before the analysis. No existing contractor deliverable, CDRL, or DCSA inspection would have surfaced it.

This session introduces the Sustainment Intelligence framework, a pre-delivery scoring approach that helps defense software programs evaluate whether contractor-delivered code is ready to transition from development into long-term sustainment. Instead of treating the handoff as an act of institutional hope, the framework turns transition readiness into a documented, defensible risk assessment.

Attendees will understand how this scoring methodology differs from commercial code quality tools like SonarQube, why that distinction matters for defense acquisition, and how program offices across the services can embed transition readiness gates into their program structure before another software effort enters sustainment with hidden technical debt, weak maintainability, and unresolved contractor dependency.

Learning Objectives
• Understand the relationship between codebase growth, cognitive complexity, and sustainment cost, and why complexity compounds faster than most acquisition leaders expect
• Distinguish between developer-facing code quality tools and PMO-facing sustainment risk tools, and understand why conflating the two leaves a critical oversight gap
• Apply the 8-factor maintainability scoring model to evaluate contractor-delivered software before accepting delivery or transitioning to a sustainment organization
• Identify the specific contract clauses, CDRLs, and acceptance test procedures where sustainment risk scoring can be embedded with minimal acquisition reform
• Understand how AFRL's transition quality gate model can serve as a template for program offices seeking to institutionalize sustainment-ready design across the portfolio

Target audience:
Program Managers, Deputy Program Managers, PEO staff, acquisition leaders, technical directors, contracting officers, systems engineers, software factory leaders, sustainment leaders, and defense industry executives.

Preferred Session Duration:
50 mins including Q&A

Legacy Modernization Without Regret

Tagline: When the original developers are retired and the documentation is wrong, the runtime behavior is the specification.

Abstract:
Across NAVSEA, NAVAIR, AFMC, and AFLCMC, there are dozens of programs running COBOL, FORTRAN, C, and Assembly systems where the subject matter experts are retired, the documentation predates modern standards, and the cost of failure is measured in lives and national security. The standard answer, modernize aggressively, adopt commercial tooling, and move fast, is precisely wrong for this class of problem.

This talk presents a case-based decision framework for legacy modernization of mission-critical defense software, one where knowledge recovery precedes coding at every stage. The framework runs in 4 stages: Direct Engineering with operators and maintainers to understand how the system is actually used; Knowledge Recovery Interviews with original developers while they're still accessible; AI-accelerated refactoring with mandatory human validation of every changed behavior; and Incremental Outside-In Delivery that preserves certified behavior at every step.

The framework rests on a principle that distinguishes safety-critical modernization from commercial software replacement: when author interviews aren't feasible, the code's runtime behavior becomes the specification that must be captured, documented, and protected with higher rigor than any requirements document. This reframing changes what pre-work must happen before a single line of production code is modified, and changes what "done" means for a modernization increment.

Attendees will leave with a structured decision tree for assessing whether a legacy modernization program is following an approach proportionate to the risk, and a set of contract oversight questions that expose whether a contractor's modernization methodology is actually safe or merely commercially familiar.

Learning Objectives:
• Identify the 3 most common failure modes in legacy defense software modernization and trace each to a specific process or oversight gap
• Apply the Knowledge Recovery framework to structure pre-work before any code changes are authorized on a mission-critical system
• Understand the role of characterization testing as a safety net, and how to evaluate whether a contractor's test coverage is adequate to protect certified behavior
• Distinguish between modernization approaches appropriate for commercially-derived systems versus those required for safety-certified, operationally-constrained military systems
• Use repository forensic analysis, including change frequency, ownership history, and abandonment indicators, to identify high-risk modules before work begins

Target Audience:
Program managers and systems engineers at NAVSEA, NAVAIR, Space Systems Command, and AFMC managing legacy weapon system software upgrades. Also relevant to DCMA software quality assurance representatives and contracting officers overseeing legacy modernization contracts.

Format:
50-minute talk with 10-minute Q&A. Case study format with decision framework artifacts provided as handout material.

Why Defense Software Estimates Keep Failing

Tagline: Story points weren’t built for contractual commitments.

Description:
Defense software programs keep missing schedules, and the usual explanations are familiar: requirements churn, scope creep, contractor performance, technical debt, and shifting priorities. Those problems are real, but they often sit on top of a deeper weakness: the program never had an estimation capability worthy of the commitment being made.

Agile philosophy pushed software teams away from calendar-based predictability. Story points were created to avoid estimating software work in real development effort days. They’re subjective relative-size numbers assigned by each team, with no stable relationship to hours, days, staffing capacity, technical risk, codebase complexity, or contractor talent. A team can assign higher point values to the same amount of work and appear to increase output without delivering more capability.

That’s why measuring velocity in story points is so ineffective for defense program oversight. Velocity sounds like a delivery metric, but it’s built on a subjective unit intentionally disconnected from calendar time. Measuring how many story points a team completes each sprint gives program managers a trend line over an abstraction that was designed to avoid real estimation in the first place.

This creates a serious problem in defense acquisition. Defense programs have delivery obligations, funding constraints, milestone decisions, sustainment planning needs, and government oversight. A contractor can report improving velocity every sprint while the program remains disconnected from a credible forecast of delivery. The program manager sees motion, but not dependable schedule intelligence.

The good news is that much better software estimation performance is possible from contractors. The bad news is that many contractors may not currently have enough engineers with the talent required to produce it. Credible software estimation is a senior engineering skill. It depends on codebase knowledge, architecture familiarity, product and domain understanding, task decomposition skill, technical risk judgment, and awareness of the actual capability of the engineers doing the work.

This session introduces an engineering-based approach to software estimation using Level-of-Effort estimates in real development effort days, expressed as ranges and calibrated against real engineering evidence. It also introduces a 4-level estimation maturity model that program managers can use to assess whether a contractor’s estimates are grounded in actual engineering knowledge or are just planning artifacts with limited predictive value.

The session will show how program managers can demand better estimation capability, measure estimation accuracy over time, and make contractor estimation talent visible before and during execution. Contractors will cultivate this talent when it becomes part of how programs evaluate credibility, manage delivery risk, and hold teams accountable.

Target audience
1. Defense program managers responsible for software delivery outcomes
2. Government engineering leaders assessing contractor technical credibility
3. PMO personnel responsible for schedule, cost, and delivery oversight
4. Technical directors and chief engineers responsible for contractor performance
5. Contracting officers and acquisition professionals shaping evaluation criteria
6. Contractor engineering leaders who need to improve estimation credibility

Preferred Session Duration: 50 mins including Q&A

Agentic Coding Is an Amplifier. Know What You're Amplifying.

Tagline: The AI-First mandate is real. So is the risk of mandating it without the discipline that makes it safe.

Abstract:
In January 2026, the Department of War issued its AI-First strategy. The institutional pressure on program offices to demonstrate AI adoption is now explicit and documented. The risk of mandating that adoption without understanding what it amplifies is not.

Agentic coding tools, deployed on contractor teams that lack the engineering discipline to use them safely, can produce tomorrow's legacy system in months rather than decades. The defining characteristic of legacy software is the absence of human understanding. When agents generate code faster than developers can absorb architectural complexity, dependencies multiply, abstractions drift, and unmaintainable code accumulates at a rate no existing PMO oversight process is calibrated to detect. A contractor team that was already struggling with technical debt before the agents switched on will produce more of the same problems, faster, and at higher volume.

The emerging contracting environment will compound this risk. The White House executive order directing agencies toward fixed-price and performance-based contracts will create stronger pressure to define deliverables, acceptance criteria, and contractor accountability up front. That shift can creates a software-specific danger: if maintainability, architectural coherence, meaningful test coverage, and code ownership are not part of the acceptance criteria, contractor incentives will naturally optimize around visible functionality. Every hour spent improving qualities the contract doesn’t measure will reduce margin. Program offices that define “done” as visible functionality risk buying a performance gap they won’t see until sustainment.

Agentic coding can give defense software programs a major advantage when skilled engineers apply it against well-structured codebases under clear engineering standards. The danger is pushing teams to adopt AI coding tools without requiring those safeguards. That approach will produce a lot of code quickly, while weak maintainability and poor architecture stay hidden under fixed-price delivery pressure until after the government has accepted the software.

Attendees will leave with a concrete framework for what contractor AI adoption maturity looks like, what contract language and acceptance criteria close the oversight gap, and the 8 questions every program integrating AI-enabled development should be able to answer before an architecture decision is locked.

Learning Objectives:
1. Understand what the DoD AI-First mandate directs, what it leaves unaddressed at the program office level, and where the resulting contractor accountability gap sits
2. Apply the agentic coding risk framework to assess whether a contractor's team discipline is proportionate to the output velocity their AI tooling is capable of producing
3. Identify the specific acceptance criteria gaps that fixed-price AI-enabled contracts create, and what contract language closes them before award rather than after delivery
4. Recognize the architectural failure mode created when cloud-dependent agentic coding tools are fielded on programs with denied, degraded, intermittent, and limited connectivity, tactical edge, or contested-environment requirements
5. Use the 'Engineering Standards for Agentic Software Development' framework to evaluate contractor AI adoption maturity during source selection, DCMA surveillance, and annual performance reviews

Target Audience:
Program managers, deputy PMs, contracting officers, and systems engineers at Navy and Air Force program offices managing software development contracts under the Software Acquisition Pathway. Directly relevant to PEO staff at NAVAIR, NAVSEA, PEO C4I, AFLCMC, and Space Systems Command who are responding to AI-First guidance and evaluating contractor AI integration claims.

Format:
50-minute talk with 10-minute Q&A. Opens with a live demonstration of agentic coding output on a real codebase to make the amplification dynamic concrete before the policy analysis begins.

AI Is Accelerating Technical Debt Faster Than Your Team Can See It

Agentic coding gives software teams a dangerous new capability: generating more code than their engineering discipline can absorb. The code may compile. The tests may pass. The demo may work. Under the surface, agents typically introduce duplicate logic, inconsistent patterns, unnecessary abstractions, architectural drift, and fragile design decisions that reviewers miss because the output looks polished and plausible.

This talk explains why AI-generated code changes the economics of technical debt. Before agentic coding, poor engineering decisions accumulated at human speed. Now they can accumulate at machine speed. Engineering directors and VPs need operating rules for how agent-generated code is specified, reviewed, refactored, and accepted into production.

The session introduces practical standards for preventing AI-accelerated debt: refactoring for architectural fit before review, checking for duplication before merge, challenging unnecessary complexity, and running recurring architectural drift scans across active codebases. It shows why local correctness is no longer enough and why engineering teams must treat maintainability, architectural coherence, and conceptual integrity as required outcomes of AI adoption.

This talk directly references the author's Engineering Standards for Agentic Software Development, especially RF1, RF3, RF4, AO4, and DN5: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience: Engineering directors, VPs of Engineering, CTOs, senior architects, and executives responsible for AI adoption across software teams.

Preferred Session Duration:
50 mins including Q&A

Dark Code: The AI Risk Your Dashboards Won’t Show You

AI-generated code can look deceptively clean, well-formatted, well-commented, and test-covered while becoming a serious long-term liability. The danger is large volumes of code that nobody understands well enough to modify safely, explain clearly, or own confidently after it has been merged. This talk discusses the dangers of dark code: code accepted into a production system without genuine comprehension by the engineers who reviewed or approved it.

Dark code becomes more dangerous in agentic development because AI tools produce output that appears more mature than it is. The code can include summaries, comments, generated tests, and convincing explanations, creating the illusion that the team understands what was produced. If the submitting engineer can’t explain what the code does, why it was built that way, what it touches, and what constraints shaped it, the team may have gained speed while quietly creating hidden risk.

This session gives engineering directors, managers, and senior engineers a practical framework for preventing dark code from entering their systems. It focuses on engineer accountability, comprehension as a merge requirement, documented rationale, traceable decisions, and the need for future engineers and agents to infer intent from the code itself. AI can generate the code. Engineers still own what enters the system.

This talk directly references the author's Engineering Standards for Agentic Software Development, especially AC1, AC2, DN2, DN3, and DW2: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience:
Engineering managers, engineering directors, senior engineers, staff engineers, architects, and technical program managers responsible for maintainability and ownership.

Preferred Session Duration:
50 mins including Q&A

Reviewing AI-Generated PRs Without Becoming a Rubber Stamp

AI changes the pressure on pull request review. When agents generate more code faster, review processes become the bottleneck. Teams often respond by reviewing faster, relying too heavily on passing tests, or skimming large diffs that appear reasonable. That turns PR review into a rubber stamp. In an AI-enabled team, rubber-stamp review becomes a vulnerability pipeline.

This talk lays out a stronger review discipline for agent-generated code. Reviewers must evaluate more than feature correctness. They must ask whether the code fits the existing architecture, preserves conceptual integrity, avoids unjustified complexity, protects the system’s most important quality attributes, and represents the simplest good solution rather than the fastest plausible one.

The session walks through a practical AI-generated PR review model that engineering teams can adopt immediately. It includes pre-review refactoring expectations, reviewer questions, merge blockers, verification evidence, and engineer comprehension requirements. Attendees will leave with a concrete model for scaling review discipline as AI increases output volume.

This talk directly references the author's Engineering Standards for Agentic Software Development, especially RD1, RD2, RF5, RF6, RF7, RF8, RF9, and Appendix A: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience: Engineering managers, tech leads, senior engineers, staff engineers, architects, and teams already reviewing AI-generated code.

Preferred Session Duration:
50 mins including Q&A

Agents Read Files. Architects Hold the System.

AI coding agents can read files, inspect functions, summarize modules, and generate plausible changes. They don't reliably hold the full system in mind: architectural intent, component boundaries, quality attribute tradeoffs, dependency consequences, invariants, and the historical reasoning behind design decisions. Therefore that structural understanding remains a human responsibility.

This talk explains why architectural ownership becomes more important as agentic coding scales. Agents make local decisions that often look reasonable inside a single file or PR. Across dozens or hundreds of sessions, those decisions can erode conceptual integrity, introduce inconsistent abstractions, duplicate existing concepts, and move the system away from its intended architecture. No single diff may look disastrous. The accumulated drift can still become expensive and difficult to reverse.

The session presents a practical operating model for architectural ownership in AI-enabled teams: re-orienting agents before each session, tracing impact boundaries before directing changes, maintaining current architecture diagrams, using Mermaid diagrams as repo-level architecture artifacts, and running agent-assisted architectural drift scans. The goal is to keep the system coherent while AI accelerates implementation.

This talk directly references the author's Engineering Standards for Agentic Software Development, especially AO1, AO2, AO3, AO4, RF5, RF6, and SI3: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience: Software architects, principal engineers, staff engineers, platform leaders, and engineering directors responsible for long-lived systems.

Preferred Session Duration:
50 mins including Q&A

What Great Engineers Do Before They Let AI Write Code

The most important AI coding work happens before generation begins. Great engineers don’t start by asking an agent to write code. They first understand the requirement, interrogate assumptions, surface constraints, define invariants, identify edge cases, and decide how the output will be independently verified. That preparation determines whether the agent produces real engineering leverage or fast, plausible waste.

This talk gives teams a practical preparation model for agentic development. It begins with stakeholder interrogation: clarifying what is actually needed, what is uncertain, what must never happen, and what quality attributes matter. It then moves to agent interrogation: using the agent to ask questions before implementation begins, exposing hidden assumptions and gaps in the engineer’s understanding. Finally, it covers specification discipline: translating the requirement into a clear technical plan before any code is generated.

The session is especially valuable for teams already experimenting with Cursor, Claude Code, GitHub Copilot, Codex, and similar tools but seeing inconsistent results. It shows how disciplined preparation reduces rework, improves verification, lowers review burden, and makes agentic coding safer for production systems.

This talk directly references the author's Engineering Standards for Agentic Software Development, especially RI1, RI2, RI3, TD1, TD2, TD3, SP1, SP2, and SP3: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience:
Engineering managers, tech leads, senior engineers, product engineering leaders, and product managers working closely with AI-enabled engineering teams.

Preferred Session Duration:
50 mins including Q&A

The AI Coding Merge Gate: How to Keep Fast Code From Becoming Fragile Code

AI-enabled teams need a clear definition of done for agent-generated code. Without one, teams accept code because it works, passes tests, or came from a trusted tool. That standard is too weak for production systems. Agent-generated code needs a merge gate that verifies specification quality, constraints, system behavior, architectural fit, refactoring discipline, and engineer comprehension before it enters production.

This talk presents a practical merge gate for AI-generated pull requests. It covers the required evidence teams should expect in every agent-generated PR: specification summary, constraints and invariants, tests run, logs inspected, workflows exercised, architectural impact, refactoring performed, and known risks. It also explains why certain items should be treated as merge blockers rather than review preferences.

The session is designed to be immediately useful. Attendees will see how to turn AI coding standards into a lightweight, enforceable PR review practice. The goal is to help teams move quickly without lowering the quality bar, especially as agents increase the volume and apparent polish of submitted code.

Attendees will leave with a practical pattern for defining what “done” means when agents generate code: specification before generation, verification against actual system behavior, refactoring before review, architectural review before approval, and engineer comprehension before merge.

This talk directly references the author's Engineering Standards for Agentic Software Development, especially Appendix A, SP1, SP2, SP3, EM1, VT1, RF1-RF9, and AC2: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience: Engineering managers, DevSecOps leaders, software factory leaders, tech leads, and teams formalizing AI coding governance.

Preferred Session Duration:
50 mins including Q&A

Product Oriented Software Engineering (POSE): Software Delivery Reimagined for Product Excellence

Imagine if your engineering team could reduce your workload, take ownership of day-to-day development tasks, and free you to focus on strategy, vision, and delivering real value. That’s exactly what Product-Oriented Software Engineering (POSE) offers. Unlike approaches where a single software engineer takes on product responsibilities, POSE transforms all software engineers into Product Engineers who deeply understand both the product’s technical and strategic goals. This unique approach eliminates misalignment, streamlines your workload, and tackles one of the most pressing challenges for Product Managers: burnout.

As a Product Manager, you may find yourself buried under tactical responsibilities like writing user stories, maintaining backlogs, prioritizing tasks, resolving misalignments, and monitoring dependencies. POSE can help you shed these burdens. Many of these responsibilities either disappear altogether or are shifted to Product Engineers. Misalignment issues decrease significantly because Product Engineers internalize the product vision and align their work accordingly, reducing the need for constant oversight. Similarly, operational responsibilities like refining requirements, managing day-to-day execution, and providing Level-of-Effort (LOE) estimates are taken on by Product Engineers, freeing you to focus on the strategic aspects of your role.

Teresa Torres’ vision of the “Product Trio” (Product Manager, Designer, and Engineer) is a powerful framework for collaboration that ensures alignment and effective communication. POSE makes this vision highly attainable because a Product Engineer (designated as a Flex Engineer) has a #1 priority responsibility to be available for collaboration at a moment’s notice. While not exclusively dedicated to collaboration, this prioritization effectively mimics dedicated availability, enabling seamless support for product discovery, design discussions, LOE estimates, and execution planning. This minimizes delays, reduces friction, and allows the Product Trio to work together efficiently toward shared goals.

How POSE Can Help You as a Product Manager:
• Eliminates some responsibilities altogether: Misalignment issues, repetitive micromanagement, and redundant oversight diminish as Product Engineers fully align with the product vision and execute autonomously.
• Shifts operational responsibilities: Tasks like refining requirements, tracking progress, resolving technical dependencies, and providing LOE estimates move to Product Engineers, reducing your cognitive load.
• Frees time for strategy: With fewer tactical demands, you can focus on vision-setting, market analysis, and high-impact decision-making.
• Improves collaboration: A shared understanding of the product vision ensures smooth communication and alignment across teams.

This approach isn’t theoretical—it’s a proven methodology that has been implemented and refined since 2004 while delivering mission critical software to Department of War clients. Regardless of your particular domain, POSE can help you, as a Product Manager, lead large, complex efforts with less friction, fewer misalignments, and greater success. It offers a clear path to reducing burnout and enhancing your focus on strategic leadership, enabling you to thrive in your role.

Join this session to learn how POSE can transform your role as a Product Manager by lightening your workload, amplifying your strategic impact, and giving you the space to thrive. Let’s unlock the full potential of your teams and deliver better products—together.

Target Audience - Product Managers, CPOs, CEOs. This talk can be adjusted to different audiences.
Preferred Session Duration - 30-60 minutes. This duration can be adjusted.

Session Delivery/Format - In-person and virtual.

Context Rot: Why Long AI Coding Sessions Go Bad and What to Do About It

Long AI coding sessions often degrade as the context window fills. The agent starts strong, then begins losing track of earlier decisions, drifting from constraints, producing circular fixes, or expanding the diff in ways that no longer match the original task. This degradation is a workflow risk that can create unreliable output and hidden rework.

This talk introduces context rot as a practical engineering problem in agentic development. Teams need disciplined ways to break work apart, manage session boundaries, and preserve continuity without polluting future sessions with bad assumptions. Large tasks should be decomposed into bounded steps. Each pass should have 1 job. Fresh-session handoff prompts can be more reliable than 1 long session trying to do everything.

The session explains how to structure multi-step work using orchestrator and subagent sessions. The orchestrator manages task state, coordinates handoffs, and incorporates human feedback. Subagent sessions each handle 1 bounded task with a clean context window. This pattern reduces context pollution, improves reliability, and can reduce token cost per task.

Attendees will learn how to identify signs of agent thrashing, stop and rescope safely, write handoff prompts, and capture useful understanding in durable artifacts. This is a tactical session for teams using agentic coding tools heavily and seeing quality degrade in longer sessions.

This talk directly references the author’s Engineering Standards for Agentic Software Development, especially TB1, TB3, TB4, TB5, TB6, CU7, and CU8: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience:
Senior engineers, staff engineers, AI tooling teams, platform teams, and developers using agentic coding tools for substantial implementation work.

Preferred Session Duration:
50 mins including Q&A

Is Your Codebase Safe for AI Agents to Work In?

AI agents perform better in codebases designed for comprehension. Clear boundaries, consistent structure, documented intent, current architecture diagrams, and navigable modules help agents produce safer, more maintainable output. Messy codebases force agents to guess, rediscover context, copy inconsistent patterns, and optimize for local plausibility rather than system fit.

This talk explains why AI readiness requires preparing the codebase so both humans and agents can reason about it safely. A codebase with well-documented rationale, clean interfaces, current diagrams, consistent naming, and strong navigability gives agents better examples to follow and fewer opportunities to drift. A codebase without those qualities pushes agents toward assumptions shaped by training data instead of the system’s actual constraints.

The session offers a practical readiness model for AI-enabled engineering teams. It covers documenting intent and rationale inline, making significant decisions traceable in code, maintaining architecture diagrams as version-controlled artifacts, designing deeper modules with clean interfaces, and organizing code so engineers and agents can quickly find the relevant area and safely ignore the rest.

Attendees will leave with a concrete way to evaluate whether their codebase is ready for agentic coding: can an engineer or agent find the right code quickly, understand the intent, identify the architectural boundary, verify the behavior, and avoid touching unrelated areas? If not, AI adoption may increase code volume faster than the codebase can safely absorb it.

This talk directly references the author’s Engineering Standards for Agentic Software Development, especially DW1, DW2, DW3, AO1, AO3, SI2, SI3, and DN3: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience: Architects, staff engineers, platform teams, engineering directors, and executives modernizing legacy or complex codebases for AI-assisted development.

Preferred Session Duration:
50 mins including Q&A

Great Engineers Fight the Complexity AI Agents Create

AI coding agents tend to produce solutions that are more complex than necessary to get the latest feature working. They often add abstractions, layers, dependencies, generalized frameworks, and common design patterns that satisfy the immediate requirement while making the system harder for both humans and future agents to understand, modify, and maintain.

This talk explains why great engineers must fight that complexity before it enters the codebase. Agents tend to draw from common patterns in their training data, even when the codebase needs a simpler solution. They also aren’t consistent about which patterns they choose across iterations. One session may solve a problem 1 way, while the next solves a similar problem with a different abstraction, naming style, dependency structure, or decomposition strategy. Over time, those inconsistencies erode conceptual integrity.

The session shows how AI-generated complexity enters production code through duplicate concepts, unnecessary service decomposition, shallow modules, inconsistent patterns, and generalized solutions for problems the system doesn’t actually have. It also shows how teams can build a simplicity discipline into their workflow: refactor for simplicity before review, make complexity carry the burden of proof, design modules with small interfaces and substantial internal functionality, and organize code so engineers and agents can navigate safely.

Attendees will leave with a practical model for identifying overbuilt agent output, challenging new abstractions, collapsing unnecessary layers, removing unjustified dependencies, reconciling inconsistent patterns, preserving conceptual integrity, and requiring the simplest good solution before merge.

This talk directly references the author’s Engineering Standards for Agentic Software Development, especially RF4, RF6, RF7, RF9, SI1, SI2, and SI3: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience:
Senior engineers, staff engineers, architects, tech leads, and engineering managers focused on maintainability and software craftsmanship.

Preferred Session Duration:
50 mins including Q&A

Before You Specify the Agent’s Task, Interrogate the Requirement

The most expensive AI coding failures often begin before the agent writes a single line of code. The engineer acts on an incomplete requirement, an unverified assumption, an unstated constraint, or a vague definition of done. The agent then fills the gaps with plausible defaults from its training data. The result can look impressive while solving the wrong problem or damaging important quality attributes.

This talk introduces requirements interrogation as a critical discipline for agentic software development. Before writing a technical specification, the engineer must surface what is unknown, interview stakeholders, clarify edge cases, define constraints, and understand what must not be sacrificed. After that, the engineer can use the agent to interrogate the requirement further by asking it to identify missing assumptions, unclear boundaries, and questions that should be answered before implementation begins.

The session is useful for product engineering organizations because it connects AI coding quality directly to product clarity. Teams that skip requirements interrogation will generate more code faster, with more rework. Teams that build the discipline will improve both engineering speed and product alignment.

Attendees will leave with a practical 2-stage model: stakeholder interrogation first, agent interrogation second. The goal is to surface missing assumptions, constraints, edge cases, and quality attribute priorities before generation begins.

This talk directly references the author’s Engineering Standards for Agentic Software Development, especially RI1, RI2, RI3, SP2, SP3, and DK1: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience:
Product engineering leaders, product managers, engineering managers, tech leads, and teams using AI to accelerate feature delivery.

Preferred Session Duration:
50 mins including Q&A

The Agent Wrote It. The Engineer Owns It.

Agentic coding changes how code is produced. It doesn’t change who owns it. If an engineer checks in agent-generated code, that engineer is accountable for it. The agent doesn’t carry the production support burden. The model doesn’t explain the code 18 months later. The engineer and the team do.

This talk focuses on accountability in the AI coding era. Engineers must understand what they merge, explain why it was built that way, verify it against actual system behavior, document significant decisions, and ensure another engineer can safely modify it later. AI raises the consequences of weak ownership because agents can generate far more code than 1 engineer could manually produce.

The session gives engineering managers and teams language they can use to reset expectations around AI-generated code. It addresses a common failure mode: treating AI output as something external to the engineer’s craftsmanship. Agentic coding should make engineering professionalism more explicit.

Attendees will leave with a clear ownership standard for AI-generated code: if you merge it, you can explain what it does, why it was built that way, what it touches, how it was verified, and how it fits the system.

This talk directly references the author's Engineering Standards for Agentic Software Development, especially AC1, AC2, DN2, DN3, VT1, and AM4: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience:
Engineering managers, senior engineers, tech leads, directors, and organizations defining accountability standards for AI-generated code.

Preferred Session Duration:
50 mins including Q&A

Keeping Engineering Control When Agents Write the Code

Agentic coding creates leverage only when engineers stay in control of the workflow. Once agents begin writing code, the engineer’s job is to bound the task, supervise the work, verify the output, refactor the result, and own every meaningful change that enters the system.

This talk explains how engineers can keep control when AI coding agents are producing significant implementation work. The control point is not one perfect prompt. It is a disciplined workflow: clear task boundaries, explicit checkpoints, specification before generation, verification before trust, refactoring before review, and comprehension before merge. Without those controls, agentic coding can move faster than the engineer’s understanding of the system.

The session shows how to structure agentic coding so speed does not outrun engineering rigor. Engineers need to break work into bounded tasks, require agents to map intermediate steps before execution, inspect intermediate output during the session, reduce scope when output gets shaky, and separate specification, generation, verification, and refactoring into distinct passes. For larger efforts, engineers need orchestrator and subagent workflows that keep task state clear, reduce context pollution, and preserve human control across multiple sessions.

Attendees will leave with a practical control model for agentic coding: define the task boundary, establish the validation loop, inspect intermediate output, rescope when the agent drifts, refactor before review, and require the submitting engineer to understand and explain every meaningful change before merge.

This talk directly references the author’s Engineering Standards for Agentic Software Development, especially SP1, TB1, TB4, TB5, AM1, RF1-RF4, and AC2: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se

Target audience: CTOs, VPs of Engineering, engineering directors, senior engineers, staff engineers, and teams scaling agentic coding practices.

Preferred Session Duration:
50 mins including Q&A