diff --git a/public/md-articles/best-practice/ai-native-coding-pods.md b/public/md-articles/best-practice/ai-native-coding-pods.md
new file mode 100644
index 0000000..d34f157
--- /dev/null
+++ b/public/md-articles/best-practice/ai-native-coding-pods.md
@@ -0,0 +1,725 @@
+---
+title: "AI-Native Coding Pods: The Promise, Risks, and How to Make Them Work"
+description: "What an AI-native coding pod is, the benefits and risks it introduces to a software team, and concrete mitigations covering code quality, review capacity, architecture, security, and human accountability."
+author: "Florin Bidirean"
+date_published: "2026-09-09"
+canonical_url: "https://www.dotkernel.com/best-practice/ai-native-coding-pods/"
+category: "Best Practice"
+language: "en"
+---
+
+# AI-Native Coding Pods: The Promise, Risks, and How to Make Them Work
+
+## TL;DR
+
+An AI-native coding pod is a small engineering team - often just two or three people - that builds AI coding agents into every stage of the development lifecycle, letting a small group deliver at the scale of a much larger traditional team.
+That leverage cuts both ways: it can produce inconsistent code quality, a code-review bottleneck, propagated architectural mistakes, weaker engineering fundamentals, and concentration risk in a small team, so it needs deliberate quality gates, risk-based review, architectural checkpoints, and explicit human accountability to pay off safely.
+
+## What Are AI-Native Coding Pods?
+
+An **AI-native coding pod** is a small software engineering team designed from the ground up to use AI as a core part of how software is designed, built, tested, reviewed, and maintained.
+
+This is different from simply giving developers access to GitHub Copilot, ChatGPT, or another coding assistant.
+
+A traditional software team might look like:
+
+> **6 developers → each person owns particular areas of the codebase → development tools assist them**
+
+An AI-native coding pod might look more like:
+
+> **2–3 engineers + AI coding agents → humans provide architecture, product judgment, review, and accountability → AI handles a large portion of implementation and analysis**
+
+AI may participate throughout the development lifecycle:
+
+* Requirements analysis
+* Codebase exploration
+* Architecture proposals
+* Code generation
+* Refactoring
+* Test generation
+* Debugging
+* Documentation
+* Code review
+* Dependency analysis
+* CI/CD support
+
+The fundamental idea is that AI becomes part of the **engineering operating model**, rather than simply another developer productivity tool.
+
+---
+
+## What Makes a Coding Pod "AI-Native"?
+
+Several characteristics distinguish an AI-native coding pod from a conventional team using AI assistants.
+
+### AI participates throughout the development lifecycle
+
+Instead of only asking AI to write a function, developers might delegate entire engineering tasks:
+
+> "Understand this issue, identify the relevant parts of the codebase, propose an implementation, write the tests, implement the change, run the test suite, and prepare a pull request."
+
+### Engineers become higher-level orchestrators
+
+Developers spend proportionally more time on:
+
+* Architecture
+* Requirements
+* Technical trade-offs
+* Code review
+* Testing strategy
+* Security
+* Product decisions
+* Debugging complex problems
+
+### AI agents can specialize
+
+A pod might use different AI agents for:
+
+* Codebase exploration
+* Implementation
+* Testing
+* Security review
+* Performance analysis
+* Documentation
+* Code review
+
+### The unit of work becomes larger
+
+Instead of:
+
+> "Write this function."
+
+The unit of delegation becomes:
+
+> "Implement this feature."
+
+That shift has potentially enormous implications for software development organizations.
+
+---
+
+## The Potential Benefits
+
+AI-native coding pods can dramatically increase the amount of software that a small team can produce.
+
+A developer who previously spent hours doing this work may be able to delegate much of that work to AI:
+
+* Reading unfamiliar code
+* Writing boilerplate
+* Creating tests
+* Refactoring repetitive code
+* Debugging straightforward problems.
+
+This can allow a small team to behave more like a substantially larger engineering organization.
+
+But the same leverage creates significant risks.
+
+## The Disadvantages of AI-Native Coding Pods
+
+### 1. Inconsistent Code Quality
+
+AI can produce functional code very quickly, but **functional does not necessarily mean good**.
+
+AI-generated code may:
+
+* Follow poor architectural patterns
+* Introduce unnecessary complexity
+* Duplicate existing functionality
+* Handle edge cases incorrectly
+* Create subtle performance problems
+* Ignore established conventions
+* Introduce technical debt
+
+The danger is amplified by the speed of generation.
+
+A developer can now create in minutes what previously took hours to write—which means bad code can accumulate much faster too.
+
+#### Potential mitigation
+
+Establish strong **engineering quality gates**.
+
+These can include:
+
+* Automated unit and integration tests
+* Static analysis
+* Type checking
+* Linters
+* Security scanning
+* Code coverage requirements
+* Architectural constraints
+* Mandatory code review for important changes
+
+AI-generated code should pass the same engineering standards as human-written code.
+
+The objective should be:
+
+> **Increase coding speed without lowering the quality bar.**
+
+---
+
+### 2. The Code Review Bottleneck
+
+One of the biggest risks is that AI dramatically increases code production while humans remain responsible for reviewing it.
+
+Consider:
+
+> **AI generates 10× more code → humans still have to understand and review it**
+
+At some point, the organization simply cannot review everything carefully.
+
+This creates a dangerous possibility:
+
+> **The bottleneck moves from writing code to understanding code.**
+
+#### Potential mitigation
+
+Introduce **risk-based code review**.
+
+For example:
+
+##### Low-risk changes
+
+* Automated tests
+* Formatting
+* Documentation
+* Simple refactoring
+
+→ Primarily automated validation.
+
+##### Medium-risk changes
+
+* Business logic
+* API changes
+* Database queries
+
+→ Human review plus automated testing.
+
+##### High-risk changes
+
+* Authentication
+* Payments
+* Security
+* Data migrations
+* Infrastructure
+* Privacy-sensitive functionality
+
+→ Mandatory expert human review.
+
+AI can increase the volume of code entering the system, but the organization needs to deliberately protect **human review capacity**.
+
+---
+
+### 3. AI Can Propagate Architectural Mistakes
+
+AI coding agents can work across multiple files and increasingly across entire repositories.
+
+This creates a new failure mode.
+
+Suppose an agent misunderstands an architectural constraint.
+
+It may then implement that misunderstanding consistently across:
+
+> **10 files → 30 files → multiple services**
+
+The result can be a large amount of internally consistent but fundamentally incorrect code.
+
+#### Potential mitigation
+
+Introduce **architectural checkpoints**.
+
+Before implementation, important features should have an explicit design phase:
+
+> Requirements → Architecture proposal → Human approval → AI implementation → Automated validation → Human review
+
+AI should be encouraged to explain:
+
+* Which components it intends to modify
+* Why those components are relevant
+* What architectural assumptions it is making
+* What alternatives it considered
+* What risks the implementation introduces
+
+This makes AI reasoning inspectable before large amounts of code are produced.
+
+---
+
+### 4. Loss of Deep Engineering Understanding
+
+This may be one of the most important long-term risks.
+
+If developers continuously delegate:
+
+* Coding
+* Debugging
+* Testing
+* Refactoring
+* API research
+
+to AI, they may become increasingly dependent on it.
+
+A junior developer might be able to produce sophisticated-looking software without understanding:
+
+* Memory management
+* Concurrency
+* Distributed systems
+* Database behavior
+* Security principles
+* Networking
+* Performance characteristics
+
+The result could be **higher short-term productivity but weaker engineering capability over time**.
+
+#### Potential mitigation
+
+Preserve deliberate opportunities for engineers to build fundamental skills.
+
+For example:
+
+* Require developers to understand AI-generated code before merging it.
+* Use AI as a tutor, not only as a code generator.
+* Conduct architecture and debugging sessions without AI when appropriate.
+* Rotate engineers through difficult technical problems.
+* Maintain engineering competency standards independent of AI capability.
+
+The goal should be:
+
+> **AI makes engineers more capable—not less capable without AI.**
+
+---
+
+### 5. Reduced Code Ownership
+
+Traditional development encourages developers to develop a strong mental model of the systems they own.
+
+With AI agents generating large amounts of code, developers may increasingly become reviewers of code they did not personally write.
+
+That creates a potential disconnect:
+
+> **"I approved this code, but I don't really understand how it works."**
+
+This is particularly dangerous in complex systems.
+
+#### Potential mitigation
+
+Make **code ownership about understanding, not authorship**.
+
+The responsible engineer should be able to explain:
+
+* What the code does
+* Why it exists
+* Its dependencies
+* Its failure modes
+* Its performance characteristics
+* Its security implications
+
+AI-generated code should not be treated as a black box simply because it passed automated tests.
+
+---
+
+### 6. Less Productive Technical Disagreement
+
+AI often makes it easy to generate an apparently reasonable solution very quickly.
+
+That can reduce the amount of time teams spend debating alternatives.
+
+But disagreement is valuable in engineering.
+
+Questions such as:
+
+* Should this be a microservice?
+* Should we use SQL or NoSQL?
+* Should this logic live in the frontend or backend?
+* Should we build or buy this component?
+* Is this abstraction actually necessary?
+
+often produce better systems through disagreement.
+
+#### Potential mitigation
+
+Use AI to **increase the quality of technical debate**, rather than eliminate it.
+
+For example, ask AI to provide:
+
+* The strongest argument for an architecture
+* The strongest argument against it
+* Alternative designs
+* Expected failure modes
+* Long-term maintenance costs
+
+Then have engineers debate the alternatives.
+
+AI becomes a **technical sparring partner**, not the final architect.
+
+---
+
+### 7. Technical Debt Can Accumulate Faster
+
+AI makes implementation cheaper.
+
+This can create a psychological shift:
+
+> "We can always clean it up later."
+
+Because AI can generate code so cheaply, teams may accept more shortcuts.
+
+Over time this can produce:
+
+* More abstractions
+* More dependencies
+* More duplicated code
+* More configuration
+* More services
+* More tests that are difficult to maintain
+* More undocumented behavior
+
+The organization can end up with a large codebase that is cheap to create but expensive to understand.
+
+#### Potential mitigation
+
+Treat **codebase simplicity as a first-class engineering metric**.
+
+Regularly measure and review:
+
+* Complexity
+* Duplication
+* Dependency count
+* Build times
+* Test maintenance
+* Dead code
+* Architecture violations
+* Developer time spent understanding the system
+
+AI should be used for refactoring and simplification as aggressively as it is used for code generation.
+
+---
+
+### 8. Security Risks Can Scale With Coding Speed
+
+AI can introduce vulnerabilities just as quickly as it can introduce features.
+
+Potential problems include:
+
+* Insecure authentication
+* Improper authorization
+* SQL injection
+* Secrets accidentally exposed
+* Unsafe dependency choices
+* Incorrect cryptographic implementations
+* Insecure API endpoints
+* Excessive permissions
+
+The risk becomes more significant when AI agents have the ability to modify repositories, run commands, access databases, or interact with deployment systems.
+
+#### Potential mitigation
+
+Build security into the development pipeline.
+
+Use:
+
+* Static application security testing
+* Dependency scanning
+* Secret detection
+* Container scanning
+* Automated security tests
+* Least-privilege access
+* Protected production environments
+* Mandatory human approval for sensitive changes
+
+AI agents should have only the permissions necessary for their task.
+
+For example:
+
+> **An agent writing application code should not automatically have production database access.**
+
+---
+
+### 9. AI Coding Agents Can Become a Management Problem
+
+An AI-native pod may have only three engineers but dozens of automated workflows and agents.
+
+Someone now has to manage:
+
+* Agents
+* Prompts
+* Context
+* Repository permissions
+* Model selection
+* Tool access
+* Evaluation
+* CI/CD integration
+* Agent failures
+
+This can create a new type of engineering management complexity.
+
+#### Potential mitigation
+
+Treat every important AI agent as a **software system**.
+
+Each agent should have:
+
+* A defined purpose
+* An owner
+* Explicit permissions
+* Input/output specifications
+* Evaluation criteria
+* Monitoring
+* Failure handling
+* Documentation
+
+If nobody can explain why an agent exists or how its performance is measured, it probably shouldn't be part of the production workflow.
+
+---
+
+### 10. Vendor and Model Dependency
+
+A coding pod may become heavily dependent on a particular AI model or coding platform.
+
+If that provider changes:
+
+* Pricing
+* Context limits
+* Coding performance
+* API behavior
+* Availability
+* Tooling
+
+the team's productivity could change significantly.
+
+#### Potential mitigation
+
+Keep the engineering workflow as **model-agnostic as reasonably practical**.
+
+Maintain ownership of:
+
+* Source code
+* Prompts
+* Agent instructions
+* Evaluation tests
+* Development workflows
+* Documentation
+
+Critically, build evaluation suites that allow the organization to compare models based on actual engineering tasks.
+
+The important question is not:
+
+> "Which model is best?"
+
+but:
+
+> **"Which model performs best on our engineering workload, at an acceptable cost and reliability level?"**
+
+---
+
+### 11. Small Teams Can Become Fragile
+
+An AI-native pod may allow three engineers to accomplish what previously required ten.
+
+That's powerful—but it can create concentration risk.
+
+Imagine:
+
+* Engineer A understands architecture
+* Engineer B understands the AI agent infrastructure
+* Engineer C understands deployment
+
+If one person leaves, a disproportionate amount of knowledge may disappear.
+
+#### Potential mitigation
+
+Make critical knowledge **team-owned rather than individual-owned**.
+
+Document:
+
+* Architecture
+* Agent workflows
+* Development environments
+* Deployment processes
+* Important decisions
+* Failure modes
+* Evaluation procedures
+
+Every critical system should have more than one person capable of operating and modifying it.
+
+---
+
+## Three Additional Safeguards
+
+### 12. Measure Engineering Outcomes, Not Lines of Code
+
+AI makes lines of code almost meaningless as a productivity metric.
+
+A developer generating 10,000 lines of code isn't necessarily more productive than one generating 1,000.
+
+Better metrics include:
+
+* Lead time for changes
+* Deployment frequency
+* Change failure rate
+* Mean time to recovery
+* Defect rate
+* Customer-impacting incidents
+* Developer time per feature
+* Review time
+* Rework rate
+* System performance
+
+The most important metric is ultimately:
+
+> **How much valuable, reliable software can the pod deliver per unit of human engineering attention?**
+
+---
+
+### 13. Keep Humans Accountable for Production
+
+A dangerous organizational pattern is:
+
+> "The AI wrote it."
+
+That isn't an engineering responsibility model.
+
+Someone must still own:
+
+* The architecture
+* The implementation
+* The security
+* The operational consequences
+* The production outcome
+
+AI can write the code.
+
+It cannot be the person on call when the system fails.
+
+For production systems, **human accountability should remain explicit**.
+
+---
+
+### 14. Start With Bounded Engineering Workflows
+
+Organizations shouldn't necessarily attempt to make every software engineering activity autonomous immediately.
+
+Start with areas where:
+
+* Requirements are relatively clear
+* Changes are measurable
+* Automated tests exist
+* Mistakes are recoverable
+* Human review is possible
+
+Good starting points might include:
+
+* Test generation
+* Bug fixes
+* Documentation
+* Refactoring
+* Small feature development
+* Dependency upgrades
+* Codebase exploration
+
+Once reliability is demonstrated, the pod can gradually delegate larger units of work.
+
+A useful progression is:
+
+> **AI autocomplete → AI-assisted development → AI task delegation → AI coding agents → AI-native coding pod → greater autonomy**
+
+---
+
+## A Practical AI-Native Coding Model
+
+A useful division of responsibility looks like this:
+
+| Responsibility            | Primary role       |
+|---------------------------|--------------------|
+| Code generation           | AI                 |
+| Boilerplate               | AI                 |
+| Codebase exploration      | AI + engineer      |
+| Test generation           | AI                 |
+| Debugging                 | AI + engineer      |
+| Refactoring               | AI + engineer      |
+| Architecture              | Human + AI         |
+| Requirements              | Human              |
+| Technical trade-offs      | Human + AI         |
+| Code review               | Human + automation |
+| Security                  | Human + automation |
+| Production accountability | Human              |
+
+This creates a useful operating principle:
+
+> **AI writes more code. Engineers make sure it is the right code.**
+
+---
+
+## The Deeper Principle
+
+The biggest change introduced by AI-native coding is not simply that **code becomes faster to write**.
+
+It is that the bottleneck in software engineering begins to move.
+
+Historically:
+
+> **Idea → design → coding → testing → deployment**
+
+Coding was a significant portion of the work.
+
+With increasingly capable AI:
+
+> **Idea → design → AI implementation → validation → deployment**
+
+Implementation becomes cheaper.
+
+The scarce resources increasingly become:
+
+* Product judgment
+* Architecture
+* Context
+* Verification
+* Engineering taste
+* Security
+* Human attention
+
+This creates an important paradox:
+
+> **When code becomes cheap, understanding code becomes more valuable.**
+
+---
+
+## The Best AI-Native Coding Pod
+
+The strongest AI-native coding pod is therefore not necessarily the one with the most agents or the highest lines-of-code-per-developer ratio.
+
+It is the one where:
+
+* AI handles repetitive implementation
+* Engineers understand the resulting system
+* Architecture remains deliberate
+* Automated tests catch routine failures
+* Humans review high-risk changes
+* Security is built into the workflow
+* Technical debt is actively managed
+* Knowledge remains distributed across the team
+* Production accountability remains human
+
+In other words:
+
+> **AI provides scale. Automation provides repetition. Engineers provide judgment. Tests provide verification. Governance provides safety.**
+
+The goal is not to remove engineers from software development.
+
+It is to make a small number of excellent engineers **dramatically more capable and productive**—without sacrificing the qualities that make good software engineering valuable in the first place.
+
+## FAQ
+
+**Q: What is an AI-native coding pod?**
+A: A small software engineering team, often just two or three engineers, that builds AI coding agents into requirements analysis, codebase exploration, architecture proposals, code generation, testing, debugging, documentation, and review, rather than only using AI as an autocomplete tool.
+
+**Q: What are the biggest risks of AI-native coding pods?**
+A: Inconsistent code quality, a code-review bottleneck as AI output outpaces human review capacity, propagated architectural mistakes across many files, loss of deep engineering understanding, reduced code ownership, faster-accumulating technical debt, security risks that scale with coding speed, and concentration risk in a small team.
+
+**Q: How should teams manage the code review bottleneck?**
+A: With risk-based code review: automated validation for low-risk changes like tests, formatting, and simple refactoring; human review plus automated testing for medium-risk changes like business logic and API changes; and mandatory expert human review for high-risk changes like authentication, payments, security, and data migrations.
+
+**Q: Who remains accountable when AI writes the code?**
+A: A human engineer, not the AI. Someone must still own the architecture, implementation, security, and operational consequences, and be the person on call when the system fails - "the AI wrote it" is not an engineering responsibility model.
+
+**Q: What is the deeper shift AI-native coding introduces?**
+A: As implementation becomes cheaper, the bottleneck in software engineering moves from writing code to understanding it, making product judgment, architecture, verification, and engineering taste the scarce resources rather than raw coding speed.
+
+**Q: What does the strongest AI-native coding pod look like?**
+A: One where AI handles repetitive implementation while engineers still understand the resulting system, architecture stays deliberate, automated tests catch routine failures, humans review high-risk changes, security is built into the workflow, and production accountability remains human.
diff --git a/public/opengraph/article/twitter-card-ai-native-coding-pods.png b/public/opengraph/article/twitter-card-ai-native-coding-pods.png
new file mode 100644
index 0000000..1fcaf82
Binary files /dev/null and b/public/opengraph/article/twitter-card-ai-native-coding-pods.png differ
diff --git a/src/App/src/Fixture/articles_cleaned.json b/src/App/src/Fixture/articles_cleaned.json
index ba73b29..504e939 100644
--- a/src/App/src/Fixture/articles_cleaned.json
+++ b/src/App/src/Fixture/articles_cleaned.json
@@ -3098,6 +3098,20 @@
                 "excerpt": "What TOTP Does A Time-based One-Time Password (TOTP) is a security algorithm used as part of two-factor authentication (2FA) to protect against account attacks. The mechanism is integrated into dot-totp to enhance security by requiring both a password and an additional one-time code.",
                 "tl_dr": "dot-totp adds two-factor authentication (2FA) to Dotkernel Admin using time-based one-time passwords.\nUsers authenticate with their password plus a 6-digit code from an Authenticator app that refreshes every 30 seconds.\nInstallation is one Composer command plus a set of forms, handlers, middleware, and templates from the official code examples, applying a TotpTrait to the relevant entity, migrating three new database columns, and registering routes/pipeline/ConfigProvider updates.",
                 "tags": []
+            },
+            {
+                "post_title": "AI-Native Coding Pods: The Promise, Risks, and How to Make Them Work",
+                "post_date": "2026-09-09 12:00:00",
+                "post_status": "publish",
+                "author": {
+                    "display_name": "Florin Bidirean",
+                    "github": "bidi47"
+                },
+                "isObsolete": false,
+                "opengraph_img": "/opengraph/article/twitter-card-ai-native-coding-pods.png",
+                "excerpt": "What an AI-native coding pod is, the benefits and risks it introduces to a software team, and concrete mitigations covering code quality, review capacity, architecture, security, and human accountability.",
+                "tl_dr": "An AI-native coding pod is a small engineering team - often just two or three people - that builds AI coding agents into every stage of the development lifecycle, letting a small group deliver at the scale of a much larger traditional team. That leverage cuts both ways: it can produce inconsistent code quality, a code-review bottleneck, propagated architectural mistakes, weaker engineering fundamentals, and concentration risk in a small team, so it needs deliberate quality gates, risk-based review, architectural checkpoints, and explicit human accountability to pay off safely.",
+                "tags": []
             }
         ]
     }