Pods and Poding

The Next Generation of Software Development

I have been thinking a lot lately about how software development changes when AI is no longer a novelty, no longer a demo, and no longer a side tool that developers occasionally ask for help.

I don’t mean “AI-assisted development” as a feature in an IDE.

I mean AI-first engineering.

I mean teams that assume, from the beginning, that every engineer has access to multiple models, multiple coding agents, multiple reasoning engines, local models, hosted models, specialized tools, and the ability to ask for ten different approaches to a problem before lunch.

Once that becomes normal, a lot of the things we have treated as sacred in software engineering start to look very old.

Especially Agile.

And particularly the SDLC.

I know that sentence will upset some people.

Good.

Because it should.

Get used to it.

Agile Was Built for a Different Bottleneck

Agile was a response to a real problem.

Big waterfall projects were slow, expensive, over-specified, over-managed, and often wrong by the time they shipped. Agile helped teams break work into smaller chunks, get feedback earlier, involve customers more often, and avoid spending a year building the wrong thing.

That was useful.

But Agile was designed for a world where the bottleneck was human production capacity. The team could only write so much code. The team could only test so much code. The team could only explore so many options before committing. The team could only prototype one or two approaches before someone had to make a call and start the long march toward implementation.

So Agile created a management system around that reality.

Sprints. Backlogs. Standups. Estimation. Velocity. Ceremonies. Refinement. Retrospectives. Story points. Burndown charts.

And then, like every management system, it became a religion.

And not a pleasant one.

It went from agile to AGILE. We got AGILE classes, AGILE certifications, AGILE coaches, and AGILE maturity models. Somewhere along the way, we stopped asking whether the process was helping us build better software and started asking whether we were following the process correctly.

That is usually the moment a process has stopped serving people and people have started serving the process.

Now AI and AI-first engineering have moved the bottleneck.

The bottleneck is no longer how fast a team can produce code. The bottleneck is how fast a team can decide what is worth building, give the right context to the machines, evaluate the output, validate the architecture, and ship safely.

That is a very different bottleneck.

In an AI-first engineering world, the code can be finished faster than the ceremonies and processes around it.

That is the problem with AGILE today.

When a small team can build a working prototype in hours or days, a two-week sprint planning cycle starts to feel absurd. When a pair of engineers can ask four models to generate four different implementations, compare them, write tests, have an agent refactor the best one, and then use another model to review the security implications, the old idea of “velocity” starts to lose meaning.

Let’s be honest with ourselves: velocity measured in story points was always a little fake. It was a way to avoid committing to sizing while still giving business users the illusion that we had explained how “long” things would take.

In an AI-first world, the whole concept becomes ridiculous.

The question is not, “How many points did we finish this sprint?”

The question is:

Did we solve the problem?

Did we learn something important?

Did we ship something real?

Did we validate it with users?

Did we make the system better or worse?

That is what matters.

Enter the Pod

I am going to put myself on the record and make a bold prediction: the next generation of software development will be built around Pods.

Or, because every movement in software engineering apparently needs an awkward verb:

Poding.

A Pod is not a Scrum team. It is not a feature team. It is not a committee. It is not twelve people in three time zones having daily standups while one person shares a Jira board that no one believes anyway.

A Pod is two engineers and a swarm of AI capability.

The ideal Pod is one senior engineer and one junior engineer, working together with access to a diverse set of models, agents, tools, and environments.

The senior engineer brings judgment, taste, scar tissue, and hopefully some wisdom they have acquired along the way. The junior engineer brings energy, curiosity, and a willingness to challenge assumptions because they have not yet been trained to accept all the weird organizational scar tissue as normal.

The agents bring acceleration.

The models bring optionality.

The combination is incredibly powerful.

This is not just pair programming with a chatbot. Pair programming was two humans looking at one problem from two perspectives. Poding is two humans surrounded by a set of specialized digital collaborators, each able to reason, generate, critique, test, document, refactor, search, summarize, and challenge.

A Pod might use one model to reason through the architecture, another to generate implementation options, another to write tests, another to look for security issues, another to explain the code to the junior engineer, another to produce documentation, another to generate migration scripts, another to create test data, and another to review the pull request.

A local model might be used for proprietary code or sensitive design work. A hosted frontier model might be used for broad reasoning, prototyping, or open-source work. A small fast model might do repetitive code transformations. A larger reasoning model might be used when the Pod is stuck and needs a second brain.

The point is not that one model is magical.

The point is that diversity wins.

The Apollo 13 Lesson

There is an episode from the Apollo 13 saga that every engineer understands immediately.

The astronauts are freezing. They are stuck in the LM, the lunar module, a spacecraft designed for two people for two days but forced to host three people for four days. Carbon dioxide is building up. The team on the ground has to figure out how to make a square filter work in a round hole using only the materials available on the spacecraft. Ed Smylie led the effort with a team around him.

They do not start with a backlog.

They do not estimate story points.

They do not schedule a refinement session.

They start with a mission: keep people alive.

They have constraints: this is what is on the spacecraft.

They have time pressure: solve it now.

They have a diverse group of people with different expertise staring at the same problem from different angles. The genius is not that one heroic person knows the answer. The genius is that the team has the right mission, the right constraints, the right urgency, and the right mix of capabilities.

That is how a Pod should work.

A Pod starts with a mission and constraints. It has access to tools. It explores options quickly. It tests ideas. It discards bad ones. It documents what worked. It ships.

The Apollo 13 team did not need more ceremony.

They needed clarity, autonomy, constraints, and speed.

So do software teams.

Diversity of Models Matters

A lot of organizations are making a basic mistake with AI.

They are trying to pick “the model.”

Or even worse, they are picking an inference vendor the way companies picked RDBMS vendors in the 1990s: we need one vendor that does everything because we can negotiate better terms and put it into a standards document.

That is the wrong question.

There will not be one model.

There will be many models, and the best engineering teams will learn how to route work across them.

Some models are better at long-context reasoning. Some are better at code generation. Some are better at debugging. Some are better at summarization. Some are faster. Some are cheaper. Some are better at explaining. Some are better at following strict instructions. Some are safer to run locally. Some are better when you need raw horsepower and do not care about cost for a few minutes.

And some are good enough to run inside your own infrastructure, close to the code, close to the data, and away from the public internet.

A Pod should not be forced into a single approved assistant any more than an engineer should be forced into a single text editor, one programming language, and one debugging strategy.

IT should not decide which brand and type of hammer a carpenter uses for the job, nor should it decide which model an engineer needs for the task.

The best results come from a diversity of ideas from divergent models.

That has always been true of human teams.

It is now true of human-plus-AI teams.

Major inference providers give us access to powerful general-purpose reasoning and coding models. Local models like Qwen give us another dimension: control, privacy, repeatability, and the ability to work on things that should never leave the building.

The combination is what matters.

A senior engineer working with a junior engineer and a diverse set of models can explore a design space that used to require a much larger team. Not because the humans are less important, but because the humans are finally able to operate at the right level.

Less typing boilerplate.

More architecture.

Less waiting.

More validation.

Less ceremony.

More learning.

The Senior Engineer Changes

In the Pod model, the senior engineer is not just “the person who writes the hardest code.”

That was never a great definition, but AI makes it completely obsolete.

The senior engineer becomes the context engineer. The tastemaker. The architect. The reviewer. The risk detector. The person who knows when the model is hallucinating with confidence. The person who knows which shortcut will cost us weeks, six months later.

The senior engineer is the person who can look at three generated approaches and say, “This one is clever, this one is maintainable, and this one will wake us up at 2 a.m.”

That judgment is more valuable than ever.

AI does not eliminate senior engineering. It exposes the difference between seniority and experience.

There are people with ten years of experience who have really had one year ten times. AI will not help them much. They will just produce more of the same decisions faster.

There are people with five years of experience who have deep judgment, curiosity, and taste. AI will make them terrifyingly effective.

The senior engineer in a Pod is responsible for shaping the work, not just doing the work. They define the context, challenge the output, protect the architecture, and teach the junior engineer how to think.

That last part matters.

A lot.

The Junior Engineer Changes Too

The junior engineer may gain even more from Poding.

Historically, junior engineers learned slowly because they had limited access to senior attention. They were given small tickets, asked to fix bugs, told to read the code, and maybe got a few minutes of review when someone had time.

“Here, can you document these APIs?”

That model is broken.

In a Pod, the junior engineer is constantly exposed to reasoning.

Why this architecture?

Why this tradeoff?

Why not use this dependency?

Why is this test insufficient?

Why does this code smell wrong?

Why did the model produce something that compiles but should not ship?

The AI can explain. The senior engineer can correct. The junior engineer can ask more questions without feeling like they are interrupting the whole team.

That creates a much faster learning loop.

And the junior engineer brings something critical back to the Pod: they are less trapped by institutional memory.

They will ask why.

They will ask why again.

They will ask why the build takes 40 minutes. They will ask why the deployment process needs six approvals. They will ask why the local environment requires a wiki page, a VPN exception, a tribal incantation, and a senior architect who retired in 2019.

That is good.

We need more of that.

We needed it 20 years ago but forgot.

The MiniSheet Story

I have seen this work. Pods can do amazing things.

One of the best examples from my own teams was a headless spreadsheet project. The idea was simple but very different from the traditional model. Instead of starting with a spreadsheet UI, rows, columns, buttons, menus, toolbars, and a giant browser-based editor, the team started with the backend.

What if a spreadsheet was an API-first service?

What if AI could create, modify, analyze, and export spreadsheets through a clean service layer?

What if the visual editor was only one possible interface, not the center of the product?

A small engineering Pod built the backend in three weeks.

Three weeks.

It supported a classic formula language. And, for you spreadsheet nerds, yes, it supported pivot tables. It had hooks into a local AI model. It was designed as a service, not as a bloated web application pretending to be a desktop application in the browser. And because it was backend-focused, it did not carry the massive overhead of a WebAssembly-based productivity editor.

This is the kind of thing that changes your sense of what is possible.

Once you watch a Pod build something real that quickly, it becomes very hard to sit through a planning meeting where people are debating whether a prototype should be five points or eight.

Your brain starts to reject the old operating model.

As it should.

Agile Ceremonies Cannot Be the Center Anymore

I am not arguing for chaos.

I am not arguing that planning does not matter.

I am not arguing that teams should just vibe-code production systems with no accountability.

That would be stupid.

And I am a pretty smart guy.

What I am arguing is that Agile ceremonies cannot be the center of the software development universe anymore.

In an AI-first engineering world, the center has to be the Pod and the outcome.

The Pod needs a clear mission. The Pod needs constraints. The Pod needs access to users or product truth. The Pod needs architectural guardrails. The Pod needs automated tests, security checks, and deployment paths. The Pod needs enough autonomy to move quickly.

Far more autonomy than most teams have today.

What the Pod does not need is three hours of ceremony to decide whether a two-day prototype should be assigned three points or five.

That is performance theater.

The old Agile machine assumes the team needs process to produce. The Pod model assumes the team needs context, trust, tooling, and fast feedback.

That is a very different management model.

It is also a much more human one.

The IBM PC Lesson

Large companies have seen this pattern before.

The original IBM PC did not happen because IBM found a way to speed up the normal IBM process. It happened because Bill Lowe understood that the normal IBM process was the problem. IBM created a small Boca Raton team under Don Estridge, Project Chess, gave it a clear mission, allowed it to use standard components and outside suppliers, and gave it enough autonomy to move at a speed the larger organization could not match.

The result was the IBM PC, developed in about a year, and an entire industry was built around it.

That is the lesson.

Autonomy is not chaos. Autonomy is what happens when a small, capable team has a clear mission, enough funding, executive protection, and permission to make the decisions required to win.

That is what Pods need.

Not a blank check.

Not no rules, but managed autonomy.

A clear mission, real constraints, fast feedback, and the authority to move before the market moves without you.

The SDLC Has to Change Completely

This is where things get uncomfortable for large organizations.

Most SDLC processes were built for control.

Not speed.

Not learning.

Not AI.

Control.

They assume scarcity of engineering output and abundance of time. They assume that review boards, ticket workflows, approval chains, and gated environments are how you reduce risk.

Sometimes they do reduce risk.

But most of the time, they just move the risk somewhere else.

If it takes a week to get a port opened, engineers will find a workaround. If it takes a month to get a development environment, engineers will build in the wrong place. If using the approved tool makes the work impossible, engineers will quietly use the unapproved tool.

Process does not eliminate reality.

It just determines whether reality is visible.

In an AI-first world, SDLC needs to move from approval-based control to automated, observable, policy-based control. That means security policies embedded into the repo. Automated dependency scanning. Automated license checks. Automated test generation and coverage expectations. Automated threat modeling assistance. Automated architecture review prompts. Automated documentation generation. Automated audit trails.

It also means model-use policies that understand data classification.

Clear rules for what can go to public models, what must stay on private models, and what must run locally. Fast sandbox provisioning. Ephemeral environments. Pre-approved infrastructure patterns. Deployment guardrails instead of deployment committees.

The SDLC should become a paved road.

Not a toll booth.

This is the biggest mindset shift.

Traditional SDLC says: “Stop until someone approves you.”

AI-first SDLC says: “Move fast inside clear, automated, observable guardrails.”

That is how you get speed and safety. Not by pretending a committee can review every decision faster than a Pod can build.

Because in this AI-first Poding world, the Pod will be done before the SDLC committee meets.

The Skunk Works Lesson

This is not the first time we have seen small teams outperform large systems.

Lockheed’s Skunk Works became legendary not because it had no process, but because it had the right kind of process. Kelly Johnson did not build a bureaucracy designed to make everyone feel included. He built a system that protected small teams, shortened communication paths, reduced friction, and gave the engineers enough authority to solve the problem.

That distinction matters.

The lesson is not “remove all rules.”

The lesson is “remove rules that exist only to satisfy the machine.”

AI-first engineering needs the same kind of thinking. We do not need fewer standards. We need better standards. We do not need less security. We need security that is embedded, automated, and fast. We do not need less architecture. We need architecture that is close to the work and available when decisions are being made.

A Pod with no guardrails is dangerous.

A Pod trapped inside a traditional SDLC is wasted.

The answer is not chaos or bureaucracy.

The answer is high-trust, high-context, high-automation engineering.

Open Source Changes the Equation

There is another interesting wrinkle.

If the work is open source, many of the concerns about public AI tools change.

Not all of them.

But many of them.

If the code is going to be public anyway, then using public AI coding tools becomes far less scary from an IP exposure perspective. The engineering team can take advantage of higher token limits, more diverse models, and more flexible workflows.

For proprietary components, the rules change.

Those should be built with private or local models.

That is where local model capability matters a lot. It gives teams a way to get AI acceleration without leaking proprietary code, customer data, or product strategy.

This is not a religious argument about open source.

It is a practical engineering argument.

Use public models where the work is public. Use private and local models where the work is proprietary. Do not force every kind of work through one AI policy.

That is lazy governance.

And lazy governance is how companies convince themselves they are being safe while making their best engineers slow, frustrated, and eventually gone.

How a Pod Actually Works

A Pod starts with a mission, not a backlog.

Something like: build the file-sharing service. Create the AI-native spreadsheet backend. Implement chat persistence and search. Prototype the meeting summarization pipeline. Design the migration path from the current system.

The Pod then creates a context pack.

That context pack includes architecture notes, relevant code, constraints, security requirements, performance expectations, user stories if useful, non-goals, known risks, and examples of what good looks like.

Then the Pod uses multiple agents and models to explore. One model generates a design. Another critiques it. Another writes a prototype. Another creates tests. Another writes docs. Another looks for security issues. Another compares implementation options.

The engineers decide.

They are no longer cogs in a machine.

They are creators.

The humans remain accountable. The models are collaborators, not owners.

The Pod ships small, working increments continuously. Not because a sprint says so, but because small working increments are the best way to learn.

The Pod maintains a living technical journal: what was tried, what worked, what failed, what decisions were made, which model helped, which model was wrong, and which assumptions changed.

That journal becomes more useful than most sprint reports ever were.

A sprint report tells management what moved across a board.

A Pod journal tells the organization what was learned.

Those are not the same thing.

What Managers Do in a Poding World

Managers do not disappear.

But their job changes.

The manager’s job is not to run ceremonies. The manager’s job is to create the conditions where Pods can move. That means staffing the right pairs, removing infrastructure friction, making sure the Pod has access to models and tools, protecting focus, clarifying priorities, connecting Pods to users, ensuring architectural alignment, watching for burnout, making sure the junior engineer is learning, and making sure the senior engineer is not becoming a bottleneck.

Walt Disney’s greatest skill was not that he was the best animator in the building. His genius was building creative teams and pairing different kinds of talent in ways that produced something neither person would have produced alone.

If you were terrified of Lady Tremaine, Cinderella’s wicked stepmother, and her cat Lucifer, that was not an accident. Frank Thomas brought a serious, controlled, emotionally precise realism to Lady Tremaine. Ward Kimball brought a very different instinct to Lucifer: playful, strange, funny, and brilliant at visual gags. Together, that contrast created something richer than either style alone.

That is Poding.

A great manager does not just assign people to tickets. A great manager composes Pods. They know when to pair the deeply serious engineer with the chaotic prototype genius. They know when to pair the senior architect with the junior engineer who will ask the uncomfortable question. They know when a Pod needs stability and when it needs a troublemaker.

The manager becomes less of a process operator and more of a force multiplier.

Which, frankly, is what engineering management should have been all along.

This Will Be Messy

Every major transition in software engineering is messy.

Object-oriented programming was messy.

COM was not just messy; I still have scars somewhere from it.

Open source was messy.

Cloud was messy.

DevOps was messy.

Remote work was messy.

AI-first engineering will be messy too.

Some teams will use it badly. Some people will ship garbage faster. Some organizations will create fifteen new approval boards for AI usage and then wonder why nothing got faster. Some vendors will sell “AI Agile Transformation Frameworks” with maturity models and certification paths and laminated diagrams.

Please do not buy those.

The point is not to create a new religion.

The point is to recognize that the economics of software creation have changed.

When the economics change, the organization has to change.

This is the part many companies will resist. They will try to keep the same org chart, the same approval flows, the same quarterly planning rituals, the same SDLC, the same vendor approval process, the same architectural review boards, and the same definition of productivity.

Then they will add AI tools on top and wonder why nothing transformational happened.

That is not transformation.

That is decoration, and expensive decoration at that.

The Future Is Smaller Teams With More Leverage

The next generation of software development will not be defined by bigger teams.

It will be defined by smaller teams with more leverage.

Pods.

Two engineers.

One senior.

One junior.

A swarm of agents.

A diversity of models.

Clear missions.

Fast feedback.

Automated guardrails.

Local models where control matters.

Hosted models where scale and reasoning matter.

Less ceremony.

More shipping.

Less estimation.

More validation.

Less process theater.

More engineering judgment.

That is Poding.

And I not only think this is where software development is going, I am actively doing it with my teams, with incredible success. You think prompt engineering is fast? Pods are in another league altogether.

The companies that figure this out will build faster, learn faster, and attract the kind of engineers who want to operate at the edge of what is now possible.

The companies that try to pour AI-first engineering into yesterday’s Agile and SDLC machinery will get exactly what they deserve.

A really expensive, faster way to wait.