What GenAI Does to the Shape of Software Work

The New Pressure Points

Not a member? Click here to read.

Photo by Vimal S on Unsplash

My Thesis

In addition to accelerating the parts of the software development lifecycle, GenAI changes the shape of the work.

A lot of the current conversation around AI-assisted software delivery is still trapped in a productivity frame: faster code, docs, tests, prototypes, summaries, faster everything. There is truth in that. The build pipe has gotten wider. A developer, analyst, tester, architect, or product owner can now produce artifacts in minutes that once took hours or days.

But the SDLC was never just a code-production machine. It was a system of flow, interpretation, validation, coordination, correction, and trust. It was a collection of human and technical mechanisms designed to move ideas from ambiguity to production reality. Some parts of that system were slow because they were wasteful. Other parts were slow because they were doing necessary work.

GenAI changes the rate at which artifacts appear, but it does not automatically change the rate at which humans can understand, validate, align, secure, integrate, or trust those artifacts.

That is where the new pressure points appear. The build pipe gets wider. The review pipe may not. The testing pipe may not. The security pipe may not. The business-definition pipe may not. The subject-matter-expert pipe almost certainly does not.

Going faster relocates the pressure points.

The SDLC Was Tuned for Human-Speed Work

Most mature software delivery processes were shaped around human-speed creation.

A business analyst gathered requirements. A developer interpreted them. A tester challenged the implementation. A subject matter expert clarified edge cases. A product owner made priority decisions. Security, architecture, documentation, and change management translated the work into operational reality.

That process was never perfect. It had handoffs, queues, delays, rework, politics, gaps, and rituals that sometimes survived long after they stopped creating value.

But it also had something we should not dismiss too quickly: pacing.

The old pace gave assumptions time to surface. It gave people time to disagree, notice that two teams were using the same word differently, ask annoying questions, and warn everyone that the “simple change” was not simple. It gave humans a chance to stew.

Not every delay was waste. Some of that time was being used for cognition, coordination, and risk mitigation. When GenAI accelerates artifact creation, those hidden safety benefits can disappear before anyone notices they were doing useful work.

Pipework, Pressure, and Flow

One useful way to think about this is pipework.

In the old SDLC, work moved through a series of pipes: requirements, design, build, review, test, security, release, support, and feedback. Each pipe had capacity, constraints, valves, filters, and inspection points.

GenAI opens up some of these pipes dramatically. Code can be drafted faster. Test cases can be generated faster. Documentation can be summarized faster. Architecture options can be compared faster. User stories can be decomposed faster. Data mappings can be proposed faster.

But the whole system does not become faster just because one pipe becomes wider.

• If generation speeds up but validation does not, pressure builds at review.
• If developers can produce five versions before the business can validate one assumption, pressure builds at the SME layer.
• If documentation can be generated faster than anyone can confirm whether it is true, pressure builds around trust.
• If AI can generate code and tests from the same flawed assumption, pressure hides inside a false sense of correctness.
• If every team member uses a private chatbot and gets a slightly different interpretation of the requirement, pressure builds in the seams between people.

We are playing whack-a-mole with the bottleneck.

The Electric Circuit Analogy

In a basic battery-and-bulb circuit, we often put a resistor in series to limit current and keep the bulb or LED from burning out. The resistor is not there because we hate light. It is there because uncontrolled flow can destroy the thing we are trying to power.

But for the SDLC analogy, the more important safety mechanisms are often fuses, circuit breakers, meters, grounding wires, and surge protectors.

• A resistor manages flow.
• A fuse interrupts unsafe flow.
• A circuit breaker stops unsafe flow and can be reset.
• A meter tells us what is actually happening.
• A ground gives excess energy somewhere safe to go.
• A surge protector limits sudden spikes before they damage the system.

That distinction matters because too many conversations about process treat every slowdown as “friction.” Of course, some friction is waste, but some is also safety, cognition, and accountability. Some friction is the system asking, “Are we sure?” before the cost of being wrong gets expensive.

The goal is not to remove every safety mechanism. Some of them are keeping the system from catching fire.

Review Is Not Merely Resistance

Review, testing, governance, architecture, and security are often treated as drag. They are described as blockers, gatekeepers, or legacy rituals. Sometimes that criticism is fair. There are plenty of review processes that create ceremony without safety. But sometimes our resistance brings value.

• Review is current control.
• Testing is failure detection.
• Governance is decision accountability.
• Security is blast-radius management.
• Architecture is load distribution over time.
• Subject matter expertise is contact with reality.

When GenAI accelerates output, these functions become more important. The faster the system can produce plausible artifacts, the more valuable it becomes to know which artifacts have actually earned trust.

Generation Is Not Validation

GenAI can produce a thing that looks finished before it has been validated. This includes code, tests, documentation, run books, data dictionaries, release notes and much more. But the existence of an artifact is not evidence that the artifact is correct.

That was true before GenAI, but GenAI makes the problem easier to miss because the artifact often looks polished. It has structure, headings, confident language, comments, test cases, and a tidy explanation of its own logic.

The danger is not only that the AI might generate nonsense. The bigger danger is that it may generate something plausible from an untested assumption.

For example, suppose a team asks AI to help implement the definition of an “active client.” The business rule seems obvious, so the team does not slow down to test it against source data or historical usage. The AI helps generate the code. Then it helps generate the tests. The tests pass because they were generated from the same assumption as the code.

Everything looks aligned. The dashboard refreshes. The number is wrong. The system did not fail because AI was useless. It failed because generation outran validation.

The same pattern shows up outside data work. A team might ask AI to add an approval step to a purchasing workflow. The generated code handles the happy path, updates the screen, sends the notification, and passes tests written from the same simplified story. But nobody validated what happens when the requester is also the approver, when the approval limit changes mid-request, when the approver is out of office, or when an audit trail must preserve the original authority chain. The workflow works. The control does not.

When the Build Pipe Outruns Meaning

Building software systems is about transforming meaning into behavior. That transformation is fragile because meaning lives in people, documents, data, habits, exceptions, old decisions, forgotten constraints, and production scars. A word like “active” may mean one thing to a manager, another to a developer, and something else entirely in the source system.

Before GenAI, those differences often surfaced through friction. A developer asked a question. A tester challenged a scenario. A report number looked strange. A subject matter expert remembered an exception. A production support person warned that the field was unreliable before 2019.

That discovery process could be slow, but it was doing work.

Now a team can move from ambiguity to working prototype so quickly that the old discovery moments may never happen. The screen renders. The API responds. The test suite passes. The demo works. The documentation sounds reasonable.

And yet the meaning may still be wrong. That is the new pressure point. The system can now create technical confidence faster than it creates shared understanding.

The Private Chatbot Problem

Personal AI tools can make individuals stronger while making the project less coherent.

A business analyst may ask their chatbot to clarify a requirement. A developer may ask another chatbot how to implement it. A tester may ask a third chatbot for test cases. A manager may ask for a status summary. Each answer may be reasonable. Each answer may be helpful. Each answer may move the individual forward.

But the project can still drift.

• The BA’s AI may interpret “approved purchase” as a completed workflow state.
• The developer’s AI may interpret it as a database flag.
• The tester’s AI may reduce it to approve/reject examples.
• The manager’s AI may summarize the team as aligned because everyone appears to be using the same phrase.

Code works. Tests pass. The workflow advances. The team feels productive. The control is still wrong.

This is not a cartoon failure where the AI gives one obviously bad answer. This is a more dangerous failure where every person gets a slightly different plausible answer. Private AI assistance can create parallel universes of interpretation.

The project does not need everyone to use the same tool, but it does need shared definitions, shared decisions, shared assumptions, shared test evidence, and shared unresolved questions.

Personal AI memory helps the individual. Shared project memory helps the project. And even shared memory is not enough unless it is governed, curated, versioned, and grounded in sources. Otherwise, shared memory becomes a landfill with better search.

Testing Has to Move Earlier

If GenAI makes it faster to build from assumptions, then teams must get better at testing assumptions before building from them. That is especially important in data-heavy systems, reporting systems, workflow systems, and enterprise integrations where production reality is often messier than the requirement language.

• Before writing the dashboard logic, test whether the source data can actually support the proposed definition.
• Before generating workflow code, test the exceptions, authority boundaries, and audit requirements.
• Before creating test cases, ask whether the test cases are validating the business rule or merely validating the generated implementation.
• Before accepting a clean AI-produced explanation, ask what source evidence supports it.

This is not about slowing down. It is about moving the right validation earlier, before the system has produced a large pile of polished artifacts based on a shaky premise.

In AI-assisted delivery, “testing starts before coding” is not a slogan. It is a survival mechanism.

Code Complete Is Not Done

At human speed, long build cycles accidentally gave systems time to be observed, challenged, tested, and reworked.

At GenAI speed, an entire working version can exist before reality has touched it. That changes what “done” should mean.

Code complete used to be a meaningful milestone. It still matters, but in AI-assisted work it may only mean the first artifact exists. Done has to include more than generated code and passing tests. Done should mean:

• the assumptions were named.
• the source data was checked.
• risk-based tests passed.
• integration behavior was observed.
• security was reviewed at the right level.
• telemetry exists where the risk justifies it.
• rollback is understood.
• documentation was verified, not merely generated.
• a human owner accepted the behavior.
• reality had a chance to participate in the test suite.

Reality is part of the test suite.

What the New Meters Need to Show

If GenAI changes the pressure profile of software work, then our dashboards need to evolve. Traditional project status dashboards often show progress: stories completed, defects opened, defects closed, test pass rates, deployment dates, velocity, burndown, and release readiness.

Those still matter, but AI-assisted delivery needs additional telemetry. Not just status. A useful SDLC dashboard for AI-assisted work might show:

• generated artifacts awaiting review.
• unvalidated assumptions.
• conflicting definitions across stories, tests, documents, and code.
• SME backlog and open questions by age.
• tests generated from the same context as the code they are supposed to challenge.
• AI-assisted changes included in a release.
• source checks that failed.
• rework caused by misunderstood assumptions.

That is not bureaucracy. That is instrumentation. A pressure gauge is not a blocker. A smoke detector is not anti-fireplace. A circuit breaker is not anti-electricity.

This Is Not an Anti-AI Argument

The answer is not to stop using AI. It is to stop pretending that faster artifact creation automatically means healthier delivery.

GenAI can help teams explore options, draft code, generate tests, write documentation, summarize decisions, identify edge cases, explain unfamiliar systems, and accelerate learning. Used well, it reduces drudgery and opens up space for better thinking.

But used carelessly, it can also flood the system with plausible work products faster than the organization can validate them. That is not a reason to panic. It is a reason to redesign the circuit to give us better:

• meters.
• grounding.
• shared project memory.
• assumption testing before code generation.
• deterministic safety interrupts, not just prompt-level guardrails.
• ways to distinguish wasteful friction from protective friction.
• options to preserve the human space where doubt, discomfort, and pattern recognition can do their work.

If we understand where the pressure is building, we can work to optimize throughput.

The Shape of AI-Assisted Work

GenAI does not just make the SDLC faster. It changes where the pressure builds.

That means the next generation of software delivery maturity will not be defined only by who can generate more code, more tests, or more documentation. It will be defined by who can maintain shared meaning while output accelerates, validate assumptions before they become architecture, separate useful friction from waste, and build systems where humans and AI operate at different speeds without tearing the project apart.

These are the fuses, meters, grounding wires, and circuit breakers that keep AI-assisted SDLC work viable.