BMAD for Team-Safe AI-Assisted Development

I’ve had a few conversations over the past week that circled around the shifting or diminishing rewards of being a developer in the age of agents. If the fun of coding & debugging is shifted into agent loops, what’s the rewarding part of the job now? Answers varied, but themes like - “I now have time for everything else...” - “It’s like being in a library, I get to read, study, adapt and relearn everything every day...”  - “I don’t exactly know, is it going to be fun again…” From my perspective, I don’t think that AI will replace my engineering capabilities, at least not yet. I may be naive, but it still takes at least some engineering skill to build a pipeline for cranking out software that is production ready. Then again creating code is not really the value I think a good engineer, or engineering leader brings to the job. Anecdotally I’ve observed a key challenge in using this new automation superpower. Software exists to solve some customer need, whether it’s an internal tool to manage a business, or a consumer offering in the end a user interacts with what’s built. Setting aside future mass-market visions of Agents talking to Agents while end users sit around and wait to be prompted for input, the reality is that users need to be able to both continue their current jobs, and learn to work with the rapidly evolving set of digital tools being thrown at them. For me I think I need to spend some time reading & thinking through how to manage this accelerated rate of change to best support whoever my customers are. I suspect there’s something in the space of Cognitive Load Theory & Adaptive Micro Learning - https://lnkd.in/gA4mrZGg - that I’ll be able to form into an approach to serving the consumer. One of the key skills of a leader or engineer is discernment, and I think we need that more than ever. In addition, I think the value of a good engineering leader or developer is the ability to dialog about what should really be built, and whether it actually addresses what’s needed, not just what’s been asked for. Just like the PB&J Challenge - https://lnkd.in/gYivM9pE - shows it actually takes a lot of back and forth to really understand another human’s intent. Sure you can do a lot with frameworks like BMAD - https://lnkd.in/g6Ef-Gav - to dialog through and resolve ambiguities, but I still think there’s a ton of benefit in human conversation. It serves as a counter to the urge to just click accept/allow and let those agents rip, without really understanding the core of what’s needed. That ability to work down to actual requirements is fundamental especially with the ability to create with such speed. In the end, I think that’s what the fun will be for me, learning these new skills and using them to find what I can do to accelerate others. The work is people not code, and that is an evergreen opportunity.

Spec-driven development is having a big moment right now. But it's also getting a bit of a rap from some for being too "waterfall-y". Here's my take from working daily with agentic SDD tools for the past 6-ish months in data & AI engineering. It's all about JEDUF: Just Enough Design Up Front. The idea has been kicking around agile circles for 20ish years†, but it maps nicely onto agentic development today. It's not waterfall, but also not having NO plan. With JEDUF, you plan and design up front just enough to get you 80% of the way there (or maybe less). Taking time to consider what must be, should be, could be, and won't be is important. The reason this isn't waterfall comes down to two things. BDUF (Big Design Up Front) assumes you can figure it all out before building. Plot twist: you probably can't. Requirements change, you learn things during implementation, and by the time you ship the world has moved on. Pure Vibe Coding on the other hand assumes you don't need to plan anything out at all. Just prompt, accept, prompt again, hope for the best... yes, it works for small stuff or isolated work, but it can fall apart fast on anything non-trivial. JEDUF sits in the middle. You write a spec, but it's not frozen - it's a living artifact that updates as you learn from implementation. And because you can iterate so quickly, the cost of being wrong in your spec is low. You revise and go again. That's the agile feedback loop with better documentation. The key takeaway: it's not about having all the answers before you put hand to code or prompt to agent. What you build in your first shot won't be perfect and honestly might not even be that good. But it's about using agents methodically to refine your thinking at the zero-th step. Then building, iterating, and refining from there. †https://lnkd.in/eF5YcKsv

🧠 Day 14: Prompt versioning and management Prompts have a way of sprawling quietly. A team starts with a clean system prompt, someone adds a line to fix an edge case, someone else tweaks the tone, and three months later nobody can explain why a particular instruction is there or what breaks if you remove it. This is a solved problem in software engineering, and the solution applies directly to prompts. Version control your prompts. Store them in your codebase or in a dedicated prompt management tool (LangWatch for example - not sponsored 😉), track changes with meaningful commit messages, and review prompt changes with the same scrutiny you'd apply to a code change. A prompt edit that looks cosmetic can produce meaningful behavioral changes across a wide range of inputs, and without version history those shifts are nearly impossible to trace. Testing is the other half of the picture. Before deploying a prompt change, you need a way to measure whether it made things better or worse. This is where evaluation datasets become essential: a set of representative inputs with known good outputs that you can run your prompt against before and after any change. Without this, prompt development is essentially trial and error in production. At scale, teams often separate prompt management from application code entirely, using tools that let non-engineers iterate on prompts while the evaluation and deployment pipeline stays under engineering control. The specific tooling matters less than the underlying discipline: prompts are a first-class artifact with proper ownership, history, and a test suite. ---- I'm Martijn. I'm writing this series because I wish it had existed when I started. Follow along for one core principle of AI engineering per day.

Exploring how AI is evolving from a coding assistant to a full development team 🤖💡 The BMAD Method introduces a new way of building software with agent-driven collaboration ⚙️👨💻 It’s not just about writing code anymore—it’s about orchestrating intelligent systems 🧠🚀 The future of development is nearer than we think 🔥 #AI #SoftwareEngineering #Agile #DevOps #FutureOfWork #TechInnovation #Developers

Solution Engineers know something most developers don't: the best architecture comes from understanding the problem first, not jumping to code. That's the same principle behind the BMAD-Method — an open-source framework I built for AI-assisted development. Instead of "vibe coding" with AI, BMAD gives you structured phases: Analysis → Planning → Solutioning → Implementation. Each phase uses specialized AI agents that build on the previous phase's output. Bug fix? 3 commands. New SaaS platform? Full agile with PRD, architecture docs, epics, and sprints — all AI-guided. I just published Part 1 of a series walking through the core framework. If you're shipping AI-assisted code in production (or thinking about it), give it a read. https://lnkd.in/epJDEDNk #SolutionEngineering #AIAssistedDev #BMAD #ClaudeCode #SoftwareEngineering

The bottleneck on AI-assisted software engineering is not the model. It is how your org moves context around the model.                                    Two engineers on the same team ask Claude the same architectural question an hour apart. They get different answers, not because the model is inconsistent, but because each one pasted a different subset of the same docs into the prompt. I wrote a proposal for an SDLC design that treats this as the core problem. The argument: Every AI output in an org is a function of three inputs and most orgs are getting all three wrong. - Knowledge is scattered across Confluence, Notion, and people's heads - Skill is locked inside senior engineers who cannot scale themselves   - Expectation is sloppy PRDs and half-finished solution docs The post proposes a git-backed, LLM-agnostic system that assembles all three automatically: one command, full context, zero manual prompt assembly. And a compounding loop where every shipped ticket makes the knowledge base richer and the skills sharper. This is a proposal with zero miles on it. I have not run it in production. The post says where it is weakest and invites pushback.                               If you are thinking about how to make AI usage across an engineering org less of a per-person lottery, this is for you. https://lnkd.in/gmKVDWSM

Software engineering fundamentals are becoming more important than ever. As Agents take over more syntax, scaffolding, refactoring, and implementation work, the value of engineering fundamentals is going up, not down. We are moving from traditional SDLC to AI-DLC and Agentic Development Life Cycle, where humans define intent, architecture, constraints, feedback loops, and quality gates while agents accelerate execution. That is why I am cautious about the pure specs-to-code mindset. A spec alone does not create great software. Without architectural ownership, AI-generated code can quickly create software entropy: code that works today but becomes hard to reason about, modify, secure, and scale tomorrow. For me, the new builder discipline looks like this: 1. Design before delegation Before asking AI to code, force clarity. Let the agent grill you on the product intent, edge cases, user flow, data model, and failure modes until the plan is sharp. 2. Create a shared language Every serious codebase needs a living markdown file that defines domain terms, module boundaries, assumptions, and architectural rules. AI performs better when it shares your vocabulary. 3. Use tests as the control loop TDD is no longer optional. Tests become the guardrail that keeps agents from outrunning the system and producing confident but fragile code. 4. Build deep modules Great architecture hides complexity behind clean interfaces. That allows humans to own the system design while AI safely handles implementation inside well-bounded areas. 5. Delegate strategically We must decide what should be deterministic, what can be agentic, what requires human review, and where risk boundaries live. What is missing in most AI coding conversations is governance of the codebase itself: architecture records, evals, security checks, dependency hygiene, observability, rollback strategy, and ownership of generated code. Sure, agents have already made builders faster. But discipline is what turns that speed into durable systems.

I joined a project three months in. Perfect Agile. Perfect XP. Perfect TDD. Nothing worked. Dev ran one database. Prod ran a different one. Tests passed in an environment that didn't represent reality. No monitoring. No logging. No recovery plan. The consulting company had set up perfect process. But they didn't make architectural decisions — that wasn't their expertise. Good developers. Disciplined process. Wrong foundation. I spent months helping fix what process alone couldn't prevent. Years later, I saw the same pattern with AI coding agents. Different builders. Different tools. Same lesson: Process tells you how to work. It doesn't tell you what to build. That's why I don't run sprints anymore. I do architecture first — in a day, not months — then let AI agents build within those constraints. Waterfall's discipline at agile's speed. People ask how I build a system in six days. Honest answer: I built it across my entire career. The six days is just when the code got written. Full article this week. Have you ever seen perfect process produce the wrong system? #IntentDevelopment #AIAgents #SoftwareArchitecture #Agile #EngineeringLeadership

DAY 1 #LearningInPublic AI Engineering | LLM Systems | Full-Stack | Web3 | System Design 🧠 Today’s Focus: Version Control Systems — Track, Collaborate, Build Better Code If you're writing code without version control… You're coding without a safety net. Version Control Systems (VCS) are essential for modern software development. 📌 What is a Version Control System? A Version Control System tracks changes in code over time. It allows you to: • Save versions of your code • Revert mistakes • Collaborate with teams • Work on features safely • Manage project history Simply put: 👉 A system that tracks and manages code changes 📌 Why Version Control Matters Without VCS: • Code gets overwritten • No history of changes • Collaboration becomes messy • Bugs are hard to trace With VCS: • Every change is tracked • You can go back anytime • Teams work smoothly • Safer experimentation 📌 Types of Version Control Systems 1️⃣ Local Version Control • Stores versions on your computer • No collaboration support • Example: simple file backups 2️⃣ Centralized Version Control (CVCS) • Single central server • Everyone connects to one repository • Example workflow: checkout → edit → commit Pros: • Easy to understand • Central control • Simple collaboration Cons: • Single point of failure • Requires internet/server access • Slower for large teams 3️⃣ Distributed Version Control (DVCS) • Every developer has full repository copy • Work offline supported • Faster branching and merging Examples: • Git • Mercurial Pros: • No single point of failure • Offline work possible • Faster operations • Better branching & merging Cons: • Slightly steeper learning curve • More concepts to understand 📌 Centralized vs Distributed (Quick Comparison) Centralized: • One main server • Must connect to work • Risk if server fails Distributed: • Full copy on every machine • Work offline • More flexible & powerful 👉 Modern development uses Distributed VCS (like Git) 📌 How It Fits in Real Projects Version control helps in: • Team collaboration • Feature development • Bug fixing • Code reviews • CI/CD pipelines • Open-source contributions 📌 Common Mistakes • Not committing often • Working directly on main branch • Poor commit messages • Not pulling before pushing • Ignoring branching strategy 📌 Simple Action Plan • Install Git • Create a local repository • Make changes & commit • Create a branch • Merge changes • Push to remote repository 📝 Key Takeaways • Version control tracks code history • Enables safe collaboration • Three types: Local, Centralized, Distributed • Distributed (Git) is modern standard • Essential skill for developers & AI engineers Learn version control… and you level up your development workflow. Found this valuable? ➕ Follow Muhammad Arslan Shahzad for more insights ♻️ Repost it if you like it. #VersionControl #Git #SoftwareEngineering #AIEngineering #LearningInPublic #Developers #Programming #TechSkills #OpenSource #CareerGrowth #DataScience

Coding agents did not just accelerate development. They quietly turned verification into the new bottleneck. Over the past two months, five CTOs I have spoken with have all reported the same shift. Dev Teams ship faster than their organizations can absorb. Design cannot keep the pace. Product cannot prioritize quickly enough. Scrum rhythms start to stretch. Shape Up seems to be a better fit. But the real pressure appears somewhere else. Verification. Agents can generate code and new versions all day. Someone, or something, still has to check if they are safe. And most staging environments were never built for that scale. Most environments used for testing are not real copies of production. They clone the code. Sometimes the services. Rarely the configuration. Almost never the data. In the agent era, that is a recipe for production disaster. What changes the equation is the ability to clone the entire production environment but not the old import/export way with rigid and never up-to-date dev / staging / pre-prod environments: code, infrastructure, configuration, and sanitized data. At Upsun (formerly Platform.sh), we have spent the last 10 years perfecting our unique instant cloning technology using Copy-on-Write: preview environments are lightweight, ephemeral, and production-parity by design. Teams can validate changes earlier, and agents can run large-scale regression checks safely before anything reaches production. Agent power, with human in the loop. At scale. And more is coming ... Fabien Guillaume Fred In the AI coding agent era, this is no longer a nice-to-have. It is a mandatory capability in the delivery pipeline: software is no longer limited by how fast code is written. It is limited by how safely that code can be verified. Is your infrastructure ready to support verification at agent speed? #agenticai #softwaredelivery #cloudplatform #cto #platformengineering